NVP Software Solutions

Category: QA

  • 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
  • No plan survives – Part 3

    No plan survives – Part 3

    No plan survives contact with the enemy

    An earlier post referenced the fact that the Quality Assurance and Business Plan need to be integrated to be successful.  In addition, A LATER made the comment that a Quality Assurance initiative can be derailed by passive or active resistance (as can all plans).  Even though Quality Assurance is inherently a long term process, and depends on trends over months and years, there may be a need to change direction.  It is entirely possible that the competitive environment may change or a new discovery changes a process.  The business plan may also change as a result of the items mentioned already or as they try something new.

    Whatever the reason, there has to be flexibility in the QA plan as well.

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

  • Out of Ideas

    Out of Ideas

    What happens if you are out of ideas of what or how to improve?

    Not surprisingly this has been considered by some of the pioneers of Quality Assurance. They understood that there was a limit to the number of ideas a person could generate.  The recommendation was to change the composition of the group coming up with the solutions while retaining continuity. One recommendation was to change everyone except the group note-taker.  There is nothing to prevent people coming back in a few years with new solutions to new problems (or suggesting them to the new group once they have had a chance to recharge).  Giving a break can work wonders for creativity.

  • No plan survives – Part 2

    No plan survives – Part 2

    No plan survives contact with the enemy

    An earlier post referenced the fact that the Quality Assurance and Business Plan need to be integrated to be successful.  In addition, the last post made the comment that a Quality Assurance initiative can be derailed by passive or active resistance (as can all plans).  The additional concern is that QA initiatives are small incremental long-term improvements.  The ROI does not fit nicely into a financial quarter or even an annual plan.  We also referenced the need to know the Stakeholders and their wishes to address them pre-emptively.

    However, the key consideration is to ensure accurate and supportable measurements that can be used to demonstrate any successes and to start with small improvements to have demonstrable successes reasonably quickly.  Then we build on those successes to make more changes that have more substantial impacts.

  • TASSQ and National Software Testing and Quality Engineering Conference 

    TASSQ and National Software Testing and Quality Engineering Conference 

    TASSQ April 2026 Meeting

    Presenter: Ari Rowland [Future proofing yourself in the AI world]

    Location: Online – Zoom

    When: Tuesday April 28, 2026

    Networking 6:00 – 6:30

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

    Cost: $20.00 (CAD)
    Register at https://tassq.org/events.  (Still coming)

    Presentation Abstract: Will be coming

    National Software Testing and Quality Engineering Conference 

    The National Software Testing and Quality Engineering Conference is scheduled to take place on May 26, 2026, at the Delta Marriott in Downtown Toronto– 75 Lower Simcoe St, Toronto, ON M5J 3A6, Canada

    This conference is specifically designed for experts in software testing, quality assurance, and quality engineering, and it aims to provide a thrilling new gathering tailored to their needs.

    The field is currently experiencing a revolution with the introduction of AI, making this an ideal moment for professionals to take charge and stay ahead of the curve.

    By attending this one-day event in May, participants will have the opportunity to network with industry pioneers who are shaping the future, as well as leverage the power of AI through interactive workshops.

    For further details.