NVP Software Solutions

Tag: Quality Control

  • Don’t fix issues later; fix them now – Part 2

    Don’t fix issues later; fix them now – Part 2

    Last week we discussed the problems of putting off resolving issues and the extra costs incurred.  Due to the response received we thought we would revisit the issue with one further example and how it was solved.  Please review the post from last week, and particularly the third example (reproduced below) as an introduction to the problem.

    1. Failure to agree on defect metrics lead to inconsistent counts and hours wasted reconciling expectations between the vendor and client.

    The above, more general, problem manifested itself in a particular instance shortly after a new QA Manager showed up to take over the project.  About a week later, there a ‘crisis’ about 6 missing issues recording enhancements that needed to be costed by the software vendor.  The QA manager had not seen them at that time.  The vendor seemed to have no track of them.  However, the issues were recorded in a well-known issue tracker so they weren’t lost, just somewhere with a wrong classification.  Eventually they were found and put back into active consideration.

    Process changes solved the issue for the rest of the project:

    1. An initial classification was carried out by the client QA manager and then discussed at the Daily Issue Review meeting with the vendor to ensure that all issues were correctly classified within 24 hours of being raised.
    2. The second change was to add a view to the Issue Dashboard to list issues that had not been touched for 3 days.  This was a secondary check in case something was misassigned and was not begin addressed. It would be picked up 3 days later and checked.  N.B. Obviously this could be gamed by having someone go through and look at every issue every couple of days and stop them landing on the list.  See point 3.
    3. Every month and more frequently as the project came close to completing, a full listing of all Not Closed issues was reviewed just to ensure that nothing was being lost or simply moved forward without resolution.

    ‘Crisis’ solved and it did not return for the duration of the project. 

    Clearly, if there were few enough open issues, then memory would be enough to know what should be there.  In a multi year project with many testers and an external vendor this was more critical.

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

  • The need for Proof in Software Testing

    The need for Proof in Software Testing

    One of the problems QA has is deciding how much proof is enough.

    Proofs are expensive and time consuming to generate. Even with new tools saving everything in video and screen shots, there is still a need to confirm that the correct items appear, and they can be found later. This is particularly true in Projects with regulatory requirements. AI can certainly help with this and reduce a lot of the manual work. But we still need to set guidelines about how long, and where the proofs are kept. They must also be secured from unauthorized access and manipulation. Any mistrusted proof will cause issues at audit time. Lastly, they must be able to be found when required.

    Proofs are also helpful when we come to testing the new version of the software. Detailed actual results can not only pinpoint unexpected and detrimental changes in the new version but they can also guide other testing that may need to be done.

    Two questions arise:

    1. Are proofs necessary – Yes.

    2. How long should they be kept – that depends on the industry and requirements but (as should be the case for all documentation) a policy for document retention needs to be written, filed, and applied.

    Either way we do not keep everything for ever.

    Proofs are a crucial part of software testing and will be called upon in the future as software testing faces scrutiny in how they tested in the event of problems in production.

  • TASSQ November Meeting is just under 2 weeks away

    TASSQ November Meeting is just under 2 weeks away

    The session will focus on the ISTQB certification and how the CSTB supports it.

    ISTQB – Vision, Syllabus Scheme, Working Groups, Partner Program

    CSTB – Goal, History, Local activities, International Activities, Volunteering

    When: Tuesday, November 25th starting at 6:15 p.m. (until 7:30 p.m.) EST
    Cost:  $10.00 CAD

    Register at https://tassq.org/events

  • Software Quality is Everyone’s Responsibility

    Software Quality is Everyone’s Responsibility

    Last month we talked about how October was Quality Month. We want to follow on from that with a comment about how “Quality is Everyone’s Responsibility”.  This came up repeatedly at the conference last week (amongst all the talks on AI in QA)

    If you have heard any of the following statements you may be in trouble.  Our response is in the second line of each listed comment.

    1. We are doing quality.
    Quality is not done. It is a process that is on going.

    2. We have a Quality Assurance department and Quality is their concern.
    Quality is not just one department.

    3. We have finished the Quality Assurance.
    Quality is never done.

    4. Quality Assurance is built into our processes and we have no need to change.
    You were perfect from the start?

    5. We have never had a Quality Assurance problem.
    Now is a good time to stop the first one.

    Quality cannot be added to a product that is poor quality from the start. It is not something that can be inserted into a product after it is built.

    If you feel that this is you, get in touch to discuss where you can improve.  www.nvp.ca/contact

  • TASSQ November 2025 Webinar

    TASSQ November 2025 Webinar

    The Toronto Association of Systems and Software Quality (TASSQ) is pleased to announce the Webinar for November 2025.

    Topic: CSTB in a Nutshell

    Presenter: Amanda Logue

    Location: Online, Zoom

    When: Tuesday, November 25th @6:15 pm (until 7:30 pm) EST

    Cost: $10.00 CAD

    Register at https://tassq.org/events






  • Fractional Test Management

    Fractional Test Management

    Test Managers play a critical role in overseeing the quality assurance (QA) and software testing aspects of projects. In larger companies, a QA Manager often manages multiple projects simultaneously. In contrast, smaller companies or startups may have only one project requiring QA or software testing. In such environments, it is common for another team member to take on QA responsibilities in addition to their primary duties. However, this approach can lead to inadequate attention to QA and may result in complications later, especially when there is a need to demonstrate due diligence to investors, clients, or auditors. In these situations, recreating testing artifacts can require significant extra effort.

    Please take a look at Case Study 13: https://nvp.ca/wp-content/uploads/2025/10/Fractional Management Case Study.pdf for how this can be addressed.

  • 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

  • QA – Why Bother?

    QA – Why Bother?

    If you get the feeling that this is a question you encounter a lot, you are not alone. We get a lot of calls and emails asking us to explain this question. Of course, the answer is dependent on who is asking the question.

    People want to know why they should consider it and, more importantly, the benefit. Sometimes they are simply looking for something to carry back to the project or department.

    In order to answer the question, we need to appeal to the broader costs calculated over multiple projects.

    We define QA as Process Improvement and processes generally apply to multiple projects (or at least can be applied to multiple projects). Hence the need for long term measurements and metrics.

    The simplest example is Defect Management. A simple process to ensure all defects are addressed and handled only once by each member of the team would remove a lot of redundancy.

    Other examples include Testcase creation; Testing; Summary reporting; Development; and Requirements management.  With the advent of AI, this has become much more critical to get right. The chances of going off track at high speed have increased substantially.