NVP Software Solutions

Tag: Quality Control

  • Quality Assurance Centre of Excellence

    Quality Assurance Centre of Excellence

    Recently we discussed a misconception about Quality Assurance. Judging from some of the feedback we received, the post struck a nerve. Many people talked about the how they had encountered a similar misconception and what could be done about it. Although education seems to be the answer, it is ongoing and can be frustrating from time-to-time. Does one just leave it alone when people make these comments (even if the one I heard was probably not entirely serious)? Does one attempt to correct the misconception? That usually means starting a long dialogue (monologue?) with sometimes frustrating results. Either people start to glaze over, have something pressing to do somewhere else, or else simply misunderstand what was said (wilfully at times).

    So with all that in mind, we are going to start into a series on what is a Quality Assurance Centre of Excellence. This is different from a Testing Centre of Excellence. A Testing Centre of Excellence had to have a delivery component. A delivery component for a Quality Assurance Centre of Excellence is going to be a little harder. This means that this is going to be slightly more of a challenge. We will work through the same hierarchy insofar as it applies to this situation but obviously the emphasis will be different.

    So, having started the plan for the plan which always reminds me of The Siphonaptera next week we will start into the real classifications.

    #QA,#QualityAssurrance,#SoftwareTesting,#SoftwareTestingStrategy,#TASSQ,#NVP

    https://www.linkedin.com/newsletters/7399187902221443072

  • Testing for System Integrators – Part 2

    Testing for System Integrators – Part 2

    Two days ago we asked two $10,000 dollar questions and this week we promised the possible answers. Unlike the questions, which are specific to the final client and the suppliers, the answers are more general and apply to both.

    1. The contracts state the following specifically about Quality Assurance and everyone is in agreement
    2. The contracts says nothing about it so far but we have Quality Assurance as a topic and the contract will not be finalised without this discussion
    3. The contracts says nothing about Quality Assurance so far but now that you have brought it up we will add it.
    4. There is something in the contracts about Quality Assurance and we can look it up for you (contracts are signed).
    5. There is nothing in the contracts (contracts are signed) and there is no intention of putting anything in the contracts about Quality Assurance
    6. We don’t know (but that is a good question)
    7. We don’t know (and we don’t care)

    Suffice to say the items in the above list have an obvious gradation from good to terrible in the order they are presented. If you get the first answer, you’re well on your way. If you get some of the middle answers you have some work to do, but you may be in time to effect some change. If you get the last few answers, you are in trouble!

    Next: What to do with the answers.

    #QA,#QualityAssurrance,#SoftwareTesting,#SoftwareTestingStrategy,#TASSQ,#NVP

    https://www.linkedin.com/newsletters/7399187902221443072
  • Quality Management

    Quality Management

    Is there any difference between software and manufacturing?

    We recently participated in a preparation session for an upcoming webinar. The person we will be presenting with is involved Quality Management for Products while I was representing Software.

    It was quite surprising how similar we sounded in terms of what we do:

    1. Product Planning Phase turning into Requirements.
    2. Design Phase
    3. Testing Phase
    4. Production Phase
    5. End-of-Life
    • We both wanted measurements and opportunity to institute process improvement.
    • We both looked at the entire lifecycle.
    • We both looked at training as a method of attaining Quality objectives.
    • We both end up with a product.
    • We both wanted to add process improvement at all stages.

    There does not seem to be a lot of difference. But, then again, we took our Quality Assurance from Crosby, Deming and Juran.

    #QA,#QualityAssurrance,#SoftwareTesting,#SoftwareTestingStrategy,#TASSQ,#NVP

    https://www.linkedin.com/newsletters/7399187902221443072
  • The purpose of Meetings

    The purpose of Meetings

    Recently I was asked to provide a short history of a local Quality Assurance organization.

    Starting with the previous organization, I went through the 25-year history in about 5 minutes. The one major overriding change in those 25 years was the advent of the internet that created a vast information trove that is free to all. Prior to that, people were isolated within their organizations with limited contact with people with the same interests in other organizations. Solutions to problems were generally home-grown.

    Having provided that very brief synopsis we were left with three questions about the purpose of the organization:

    1. Are we an organization dedicated to networking?
    2. Are we an education organization?
    3. Are we a social organization?

    Unfortunately we do not have enough of the history documented to determine what has been the best use of the time. Clearly my synopsis was based on what I remembered and I was not always in attendance at all the meetings or always on the board. So the question is still open.

    #QA,#QualityAssurrance,#SoftwareTesting,#SoftwareTestingStrategy,#TASSQ,#NVP

  • Conferences and Webinars in June 2026

    Conferences and Webinars in June 2026

    TASSQ June 2026 Meeting

    AI in Testing: How We’re Building a QA Platform We Can Trust — and Why an AI-First Approach Alone Is Not Enough

    Presenter: Anna Karnaukh

    Location: Online – Zoom

    When: Tuesday June 30, 2026

    Networking 6:00 – 6:30

    Presentation 6:30 p.m. (until 7:30 p.m.) EST

    Cost: $20.00 (CAD)
    Register at – coming shortly 

    ____________________________________________________________________________________________

    Test Automation Summit Toronto

    The future of testing is being shaped by AI, automation, and intelligent quality engineering—and Toronto is where the conversation happens next.

    Test Automation Summit—Toronto brings together the testing and QA community for a powerful day of learning, testing, and meaningful networking.

    Expect a full day featuring:

    • 10+ expert talks, keynotes, tutorials, and panel discussions
    • Real-world insights into AI-driven testing and automation
    • Practical strategies to improve quality, speed, and reliability
    • Opportunities to connect with QA leaders, engineers, and decision-makers

    Whether you’re a QA leader, automation engineer, test architect, or DevOps professional, this summit will give you the clarity and connections needed to stay ahead.

    Registration

  • Focused decision-and-action engagement

    Focused decision-and-action engagement

    Stop release chaos: clearer priorities, faster decisions, and quality you can trust.

    Focused decision-and-action engagement with department managers and key stakeholders – 2 weeks – This engagement is designed to identify the most important measurable impediments affecting confidence, flow, responsiveness, adoption, and maintainability, align leadership around the issues that matter most, and produce a practical 90-day action plan that can be used immediately.

  • Importance of Counting             

    Importance of Counting             

    In a previous post we discussed the perception that QA may be counting too much.  Before we go deeper into that consideration, one of the other concerns is the reliability of the measurement.  We define Reliability as getting the same result if the measurement is taken under the same conditions twice.  Whether that result is correct is a different question but if the measurement is different when taken under the same conditions, it is not only invalid; it is also unreliable.  This can cause real problems, as it has in some projects.  Measurements taken by the vendor differed from the ones taken by the customer.  Not surprisingly the vendor measurement showed less outstanding defects than the customer’s ‘equivalent’ measurement.  It was eventually traced to one label used on only a few defects that was being excluded by an earlier filter on the vendor side.   Once that condition was removed, the counts agreed. 

  • Count the ‘Bouncebacks’

    Count the ‘Bouncebacks’

    “Bouncebacks’ is not a technical term in common use. In our usage here we are counting the number of times a defect (or issue) bounces back and forth between tester and developer (or other personnel). It is common for a defect to have a count of at least 2 and maybe 4 if some clarification is required. Here we are looking for defects or issues that are bouncing back and forth between development and testers too many times. One of our clients recently did this and then concentrated on the items that had high counts. Not surprisingly they discovered that the majority of the issues with high bounceback counts revolved around poorly written requirements. Instead of getting the requirement correct in the first place, the concept was being clarified by continuous back and forth communication late in the project with a high overhead and testing cost.