NVP Software Solutions

Category: Software Testing

  • TASSQ Webinar for October 2025

    TASSQ Webinar for October 2025

    Topic: Enough is Enough – When is enough visual test coverage?

    Presenter: Derek Choy

    Location: Online, Zoom

    When: Tuesday, October 21at at 6:15 p.m. (until 7:30 p.m.) EST

    Cost: $10.00 CAD

    Register at: https://tassq.org/events

    Abstract:

    Enough is Enough – When is enough visual test coverage?

    The session will focus on how QA teams can accurately assess whether their applications have sufficient visual test coverage using modern tools and best practices. The presentation will introduce the concept of visual coverage, which goes beyond code coverage to reveal untested, under-tested, and high-risk areas of your user interfaces. We will explore technologies like visual heatmaps and intuitive gap analysis to instantly identify missing or redundant tests, helping teams streamline their QA processes and maintain consistent quality.

    Presenter Bio:

    Derek Choy is a seasoned technology executive with extensive experience in quality assurance (QA) and engineering leadership within fast-growing SaaS and enterprise software organizations. As CTO and previously COOr at Rainforest QA, Derek has been instrumental in driving product and technical innovation for one of the leading platforms in on-demand QA, scaling globally distributed engineering and product teams, and helping companies achieve robust, automated software testing processes. Derek holds degrees from Imperial College London and Stanford University and has served as a strategic advisor in cloud testing and machine learning QA initiatives. He is widely recognized for advancing scalable QA strategies.

    Register at: https://tassq.org/events

  • Isn’t there a better way to Test?

    Isn’t there a better way to Test?

    This is a question that gets asked very frequently especially at the end of projects that have not gone well.

    While there are many people who will advocate one methodology or another for testing and tell you their way is the only way, every method must adapt to the project at hand, the risks and the desired outcomes.  There is no one way to test but there are ways to improve the testing.

    The first need is time at the end of the project to evaluate what went right and wrong before people forget.

    Some common concerns:

    1. Too much documentation:  It is acceptable to reduce documentation if the same testers will be available for the next project but not so effective if the next project will be staffed with new people unfamiliar with the project.
    2. Too little documentation:  This can be solved but it takes time or can be fed through AI to generate the complete documentation.  Always review anything produced by AI.
    3. Too much repetition:  This is a process error that can be solved by RCA and then implemented but is not likely to have much effect for at least a project or two.
    4. Unused testcases:  This is a classification issue that can be solved with AI at this point.
    5. Too many escaped defects:  Again RCA with the aid of AI can address this but it is too late to implement the solution for the existing project.
  • Is your testing Ad hoc?

    Is your testing Ad hoc?

    While most people won’t come out and say that their testing is Ad Hoc, it can usually be inferred from some of the following comments:

    1. We keep redoing things.

    2. We seem to lose everything with every iteration.

    3. We keep re-inventing the wheel.

    4. We have thousands of testcases and most of them have not been looked at in years.

    5. We miss things in every release even though we saw them in the past.

    6. We keep solving the same problems in development.

    And on the list goes.

    If you feel you are stuck in this rut, it is time to break out

    .

    But that requires a fresh look at the following items:

    * Current assets

    * Current processes

    * Missing pieces

    * Left over items and problems. Breaking out of Ad Hoc testing is very difficult. Process improvement is resisted on many levels.

  • Resources

    Resources

    Resources are always a problem in projects. You may have too many at one point, too few at another point and the skills may be mismatched even if the number matches to what you estimated. Issue The client was expanding rapidly in a new industry. Two large organizations in a related industry had already started divisions to address this market but we were dealing with a new and much younger company.

    Please take a look at Case Study 9: https://nvp.ca/wp-content/uploads/2021/06/Case-Study-9-Resources.pdf to see how the process was managed.

  • Designing Testing

    Designing Testing

    Frequently organizations grow concerned about their Quality Assurance Processes. They are not sure if they are using the best processes for their testing. Everything has been internally built with little input from outside the organization. Over time the isolation may lead to inefficient processes. There may not be an awareness of what has changed and how it might impact their work habits.

    Please take a look at Case Study 7: https://nvp.ca/wp-content/uploads/2021/06/Case-Study-7-Consulting.pdf to see how the process was redesigned.

  • Test Leadership

    The role of a Test Lead varies widely between organisations and even within some large organisations. Some test leads execute a plan, other build and manage and some run multiple projects with other test leads running particular aspects.  If you are in this position, you may be wondering what to do. 

    Please take a look at Case Study 2: https://nvp.ca/wp-content/uploads/2019/06/Case-Study-2.pdf for how training was organised in one particular example.

  • Requirements

    Requirements

    While iterative methodologies do not expect full requirements at the beginning of a project, it may still be critical to eventually capture the entire set of requirements. Traceability between testing and requirements has become popular recently to provide auditability.

    Please see https://nvp.ca/wp-content/uploads/2021/06/Case-Study-8-Requirements.pdf for an example Case Study.

  • Test Tool Selection

    Test Tool Selection

    Test Automation is critical to any ongoing test efforts. Without automation., there is no way that testing can keep up and it is almost impossible to complete regression testing or any sort of Performance Testing. Tracking current status is also difficult. With AI coming into the mix in both the product and the test tool, the need is greater than ever to understand what is available and how it works.

    Please take a look at the Case Study 5: https://nvp.ca/wp-content/uploads/2019/07/Case-Study-5.pdf for more information