NVP Software Solutions

Tag: #qualityassurance

  • A vision without the ability to execute is probably a hallucination

    A vision without the ability to execute is probably a hallucination

    This quote is interesting and would probably be disputed by many people. They would say that a Vision is something you want to do and whether or not it can be executed has no impact on its validity (or whether it is a hallucination).  While the quote is not new, the applicability to today’s world with the concerns expressed about AI Hallucinations provides it with a fresh applicability.

    Over the years we have encountered a lot of Visions for Software Testing and Quality Assurance.  Unfortunately, many of them do not get realised.  Budget is often stated as the main culprit despite the fact that almost all Visions relate to doing tasks better and cheaper.  Quality Assurance Visions are even worse.  Saying that we want to make Process Improvements without some concrete actions to back it up (not part of the Vision directly but certainly related) does not go very far.  But with no Vision at all, no improvement will ever occur and the same processes and same errors will recur for every project or initiative.

    Make 2026 the time you realise your Visions for Software Testing and Quality Assurance.

    Software Testing solves your problems for today and yesterday. Quality Assurance makes your Vision reality.

  • You can only predict things after they occur

    You can only predict things after they occur

    “You can only predict things after they occur” This quote was attributed to Eugene Ionescu in the source I had.

    There are several related quotes:

    “Those who have knowledge don’t predict” and its corollary “Those who predict, don’t have knowledge.”

    Or lastly: “The best way to predict the future is to create it” (Peter Drucker).

    Maybe we could use these quotes the next time someone says how long testing is going to take.  The interesting part is when you push back and say: “How long did it take last time?” or “How much bigger (in whatever the favourite measure is) is this project compared to the last one?”.  Neither of those questions elicit much useful information or a response at all so the analogous method using internal numbers is unavailable.

    If you have no previous statistics from the organisation, there are lots of statistics available online or you can use one of the Estimation Methodologies (PERT, Planning Poker, WBS, Function Point Analysis or Test Point Analysis).  They provide a good starting point but must be adjusted for the particular situation. 

    One of the major aspects of Quality Assurance is to gather up statistics on what occurred last time and use that to predict the future. While no one can get 100% accuracy, it certainly helps to know what occurred in the past.  Adjust for the situation at hand and go forward.

    Software Testing solves problems for yesterday and today.

    Quality Assurance solves your problems coming tomorrow!

  • Don’t fix issues later; fix them now!

    Don’t fix issues later; fix them now!

    “Don’t fix issues later; fix them now ” or “Never put off to tomorrow what you can do today”. This seems so obvious but try doing it in a project when the schedule and budget are under pressure.  If this is restricted to Software Testing then issue classification and prioritisation can help to clarify which issues are worth fixing and which can be safely left for a future release. 

    However, if the issue relates to a process used in the project, then not only does the issue potentially impact the schedule and budget at the time it is discovered, but it will impact the project each time that process is repeated.  Fixing it now will not only save the current project time and money; it will save the coming projects a lot more assuming it is documented and the fix is implemented.  Some processes we have seen add time and budget to a project include the following:

    1. Failure to classify defects and move them to the relevant group allowed one person to repeatedly reclassify defects and change priorities until the software vendor bogged down in multiple half completed code changes.
    2. Moving ahead with documentation that had not been fully reviewed and approved lead to more changes and a huge recoding effort.  In particular, adding an approval step to every piece of documentation in a system meant opening every function to code an extra step.
    3. Failure to agree on defect metrics lead to inconsistent counts and hours wasted reconciling expectations between the vendor and client.

    Fixing any of these would have saved millions of dollars and years of time on the project.

    Software Quality Assurance solves problems for yesterday, today and tomorrow.

  • 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

  • TASSQ 2025 – 2026 Schedule

    TASSQ 2025 – 2026 Schedule

    TASSQ is pleased to announce their September 2025 through February 2026 schedule.

  • 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.

  • Privacy

    Privacy

    Privacy of data is becoming increasingly important to the industry. With increasing regulations and increased scrutiny from the press, no organization can hide data breaches for too long.

    Issue The client was facing a privacy audit from one of their customers.

    Please take a look at Case Study 10: https://nvp.ca/wp-content/uploads/2021/06/Case-Study-10-Privacy.pdf to see what was provided.

  • 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.