NVP Software Solutions

Category: Uncategorized

  • 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

  • TASSQ Webinar for January 2026

    TASSQ Webinar for January 2026

    How a Coach can transform your IT Career

    Presenter: Rob Virdee Location: Online – Zoom

    When: Tuesday January 27, 2026 6:15 p.m. (until 7:30 p.m.) EST

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

    Presentation Abstract: HOW A COACH CAN TRANSFORM YOUR IT CAREER In today’s fast-paced tech landscape, technical skills alone won’t get you to the top. Whether you’re a developer, engineer, analyst, or aspiring leader, the key to thriving in your IT career lies in mastering the human side of success—clarity, confidence, and strategic growth. This webinar dives into how professional coaching can accelerate your career trajectory, helping you navigate challenges, build influence, and align your work with your deeper purpose. Join us to discover how coaching empowers IT professionals to break through plateaus, lead with impact, and future-proof their careers in an industry that never stops evolving. If you’re ready to move from reactive problem-solver to intentional change-maker, this session is your launchpad.

  • 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






  • TASSQ April 2025 Talk

    TASSQ April 2025 Talk

    Toronto Association of System and Software Quality -TASSQ is pleased to announce our Webinar for Aprilh 2025.

    Topic: The Pursuit of Failure

    Presenter: Chris Armstrong

    Location: Online/Zoom

    When: Tuesday April 29 at 6:15 p.m. until 7:30 p.m. EST

    Cost: $14.00 CAD

    Register at: TASSQ

    Presentation Abstract:

    As testers, we often seek balance: risk & quality, introvert & extrovert, holistic & granular, failure & success.

    Throughout my twenty years in testing, I have had the longest relationship with failure. It has the power to demotivate, derail, break, and end progress.

    Is our identity as testers in finding bugs, in pointing out where things are incorrect, do we only bring negativity, are we diametrically opposed to developers in this saga called software development?

    What you will learn:

    1. Methods of reflection and retrospection to break the cycle of failure into success.
    2. The language that we use as testers has power.
    3. Awareness, movement, and relevancy – software is ever evolving, and we need to change with and help to shape its future, without burning out

  • Quality Assurance in a Pandemic

    Many people have asked what the point of Quality Assurance is during a pandemic. It seems that when things are in such a rush, Quality Assurance gets pushed to one side. There is no doubt that there is some pressure to get some items done in the shortest of time and people feel that Quality Assurance can be eliminated or at least reduced. This view is prevalent whether or not there are pandemics in the background but a pandemic exacerbates the situation. This is based on the view that Quality Assurance is simply Software Testing.

    Using the definition of Quality Assurance as Process Improvement changes that view. When we look at accelerated schedules with limited ability to correct items, the need to get it right the first time, and disrupted communications; proper processes suddenly look a lot more attractive. We have already seen several projects get delayed while things get bounced back and forth in asynchronous communications. If we had done it right in the first place, much of the communication would have been eliminated. This includes fundamental processes like issue tracking as well as technical design and project decisions. All can benefit from improved processes.

    Some clients are delaying anything new until the end of the pandemic. They will be re-launching their projects when everything is back to ‘normal’.
    Meanwhile another group are seizing this opportunity to implement Quality Assurance improvements while the pipeline is little reduced.

    We know who we expect to come out the other end with an enhanced business model.

    If you have input on the above, you might want to consider our survey.

    Image by Vladimir Fedotov on Unsplash.

  • Manual Testing

    This year is the n’th time we have heard about the demise of Manual testing and the n+1’st time it has not occurred.To paraphrase Mark Twain “Rumours of the death of Manual Testing have been greatly exaggerated”.

    Why does this keep coming up year after year:

    1. We keep inventing new items that are not amenable to being automated.
    2. New startups have neither the time or the budget to worry about automating testing. Their emphasis is on getting the product out the door and into the hands of their customers.
    3. Some organisations have a great deal invested in an old automated tool. They are not maintaining the existing scripts or adding new but no one is willing to throw them out.
    4. Some testing tools have not lived up to their promises and people are unwilling to try again with a new test tool.
    5. Most project managers do not have budget for automation of testing and since they do not benefit from it (the next project benefits) they see little reason to add it to their project.
    6. If it becomes a corporate or central responsibility to automate, then the question of funding it becomes awkward. Who is responsible for the cost fo the tool and the automation effort? How is that cost amortized and apportioned?
    7. It appears cheaper to get Manual Testers.

    So will this change in the 2020? It seems unlikely in view of the above unless we consider the following:

    1. Calculate the real cost of repeatedly executing the same testcases manually.
    2. Calculate the real benefit of implementation of automation over multiple projects and years.
    3. See whether the automation will pay for itself using the above two figures.
    4. Find an automation tool that suits your situation. There are many good ones around; you just need to find the appropriate one. Talk to us about a well tested methodology for test tool acquisition.

    Photo by Hunter Haley on Unsplash

  • Who do we tell?

    In light of some of the comments received, this blog is aimed at the ‘official’ list of people who should be told the results of testing. As per some of the comments, there are lots and lots of unofficial channels and these can be more useful and more informative than some of the official ones. However, (in order to stop the blog going on forever) we are looking at the ones who are listed as requiring the information.

    We encounter two major attitudes to this question:

    1. Everyone must know everything.
    2. How can I avoid being added to this list?

    The above may seem odd and probably depends a lot on the trust factor within the organisation. In some places, everyone gets added no matter how much the notifications and emails pile up. In others people avoid being told. There is an obvious dependency on the sophistication of the notification process and where the information is being stored. Less sophisticated processes will not have the granularity required or no-one to administer them. More sophisticated ones can do almost any desired work flow.

    One other comment that came back was that we need to recall that we have clients and they need to be kept informed of what is occurring (whether or not they look at it).

    In our next blog on this topic we will provide some specific suggestions.

  • What should be reported from your Testing Efforts – Part 4

    Feedback is always welcome and this week we are indebted to Paul Seaman for some very valid comments on the What should be reported from your testing – Part 2. He pointed out that the blog seemed to have a written bias, missed the value of verbal communication and seemed to silo testers.

    We were considering mainly final reports using an independent test team and with the potential need for an audit of the testing. So some bias may have crept in and Paul pointed that out. Let’s look at each of these.

    Siloed Test Team: The more you silo a test team, the less effective they are. Information does not flow to them or from them. So the opportunities to learn from each other is lost. In addition, any information that does flow back and forth will likely be somewhat distorted by the time it gets to the other party. Testers need to be included throughout the lifecycle embedded in the team.

    Verbal Communication: This is an obvious follow on from the previous point. If you are remote, or restricted in communication then the chance to provide and receive feedback is reduced. Non-verbal communication tends to be asynchronous – something is sent and there is a delay before there is a response. Verbal (throughout the project or testing effort) allows instant feedback and may speed up responses and reactions to changing events. The only thing you may lose is an audit trail. Anything crucial needs to be noted and put into a decision log for retention.

    Written bias: This comes down to the same thing as the last comment in the previous paragraph. Crucial information that needs to be retained should be documented and stored. If the report is simply a status that is being provided then it may not need to be fully documented. Point taken.