NVP Software Solutions

Tag: Process Improvement

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

  • 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

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

  • Are you satisfied with your testing?

    Are you satisfied with your testing?

    Most people we speak to answer that question with a resounding NO; they are not satisfied with their testing. The answer may vary from stakeholder to stakeholder, and the intensity and source of the dissatisfaction may be different.  However, doing something about it is a different matter.    The most recent of many examples involved someone who complained about the testing and was promptly put in charge.  Not the result they were aiming for at the time!

    Solving the dissatisfaction is very difficult. Process improvement is resisted on many levels and there is usually a large number of potential improvements that may impact the perception.  The starting point is with a stakeholder survey and process assessment; this gives the basis for supportable incremental changes to improve satisfaction. 

    Take a look at Assessments for a starting point on what to include.

  • Is your testing Ad hoc?

    Is your testing Ad hoc?

    While most people won’t come out and say that their testing is Ad Hoc, it can usually be inferred from some of the following comments:

    1. We keep redoing things.

    2. We seem to lose everything with every iteration.

    3. We keep re-inventing the wheel.

    4. We have thousands of testcases and most of them have not been looked at in years.

    5. We miss things in every release even though we saw them in the past.

    6. We keep solving the same problems in development.

    And on the list goes.

    If you feel you are stuck in this rut, it is time to break out

    .

    But that requires a fresh look at the following items:

    * Current assets

    * Current processes

    * Missing pieces

    * Left over items and problems. Breaking out of Ad Hoc testing is very difficult. Process improvement is resisted on many levels.

  • What do Test Managers do in a project?

    What do Test Managers do in a project?

    There would be an obvious answer to that question if one replaced the word Test with the word Project. So, if we transfer in reverse the answer is the same. Since we had to answer this question …

    Please take a look at Case Study 11: https://nvp.ca/wp-content/uploads/2025/05/Case Study 12.pdf  for an answer to this question.

  • Mentoring

    Mentoring

    Frequently organizations encounter a roadblock on their Quality Assurance Processes. Most tasks are progressing well but there is a hitch or a stumble somewhere. The problem is not large enough to warrant a full consulting contract but it needs to be resolved. This is where Mentoring helps.

    Issue: A client, who creates websites for government departments and high profile clients, was having trouble with their Quality Assurance process.

    Please take a look at Case Study 11: https://nvp.ca/wp-content/uploads/2021/10/Case-Study-11-Mentoring.pdf to see how this was solved quickly and cheaply.

  • Designing Testing

    Designing Testing

    Frequently organizations grow concerned about their Quality Assurance Processes. They are not sure if they are using the best processes for their testing. Everything has been internally built with little input from outside the organization. Over time the isolation may lead to inefficient processes. There may not be an awareness of what has changed and how it might impact their work habits.

    Please take a look at Case Study 7: https://nvp.ca/wp-content/uploads/2021/06/Case-Study-7-Consulting.pdf to see how the process was redesigned.