NVP Software Solutions

Tag: Process Improvement

  • Quality Assurance Centre of Excellence – Part 4

    Quality Assurance Centre of Excellence – Part 4

    Today we want to focus on the root cause analysis.

    Focused on Root Causes – This can be applied to both of the previous posts. When it comes to being proactive, the Quality Assurance CoE could look at Root Causes of potential issues and plan around them or else they could look at Root Causes from their analysis and work to understand and solve them. Regardless of which way this is dealt with, the problem could be solved at different levels. We could be looking at Root Causes for software development and deployment or we could be looking at root causes that impact the entire organization (structure, culture, management).

    There are two challenges that a Quality Assurance Specialist usually faces with respect to Root Cause Analysis:

    1. The Root Cause may be difficult to find.
    2. Once found, there may be resistance to fixing the Root Cause

    An example of the first occurs when someone is supplying information to another group and in the process of supplying it the information is manipulated or reformatted in some way. The manipulation adds in an error which is not obvious. The next group uses the erroneous data to make decisions. The error is not large enough to cause major problems but it has an impact further along. No one notices the problem until much later. This makes the Root Cause difficult to find and difficult to correct since no one is recognizing the initial error.

    The second is a much worse problem. The Root Cause has been identified and the solution created. Then there is resistance to making the required changes:

    • The problem may be outside your department.
    • Someone may have to admit they are wrong and have been wrong for years.
    • There may be costs attached to making the change and they will fall on someone else.

    All of the above can lead to resistance to the change.
    Next:  Process Focus

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

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

  • The AI Testing Landscape: Where Testers Create Value in the AI Era

    The session introduces a practical framework for understanding the different domains of AI testing and the evolving role of software testers.

  • 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
  • QA as an Afterthought

    QA as an Afterthought

    Why QA is so often an afterthought?

    1. Is it because QA is ‘traditionally at the end of the project”?
    2. Is it because people have too much else going on at the beginning of a project and cannot think about QA?
    3. Is it because QA does ‘not fit anywhere’ at the corporate level so ends up nowhere?
    4. Is it because QA is regarded as a necessary evil which no one wants to acknowledge?
    5. Is it because we do not know when QA is needed and by the time we find out it is too late to make a difference?
    6. Is it because QA does not do a good job of selling ourselves?
    7. Is it because …

    We could certainly go on with all the reasons that QA seems to be frequently ignored. 

    Not surprisingly, when people do take the time to consider the Return on Investment for QA, they are often shocked by how much it benefits them.

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

    https://www.linkedin.com/newsletters/7399187902221443072
  • 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.

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