NVP Software Solutions

Tag: Assessment

  • Starting Quality Assurance – Part 7

    Starting Quality Assurance – Part 7

    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 that one person or a group could generate.  Even though it was possible to identify the problems, solutions might not be obvious.  After all, if there was an obvious solution, it would have been implemented already.

    The recommendation was to change the composition of the group coming up with the solutions while retaining a minimum of continuity.  One recommendation was for everyone but the idea recorder to change.  The thought was that the idea recorder would know what had been considered (retaining the history) but might not have a vested interested in either supporting or denigrating any of the existing or new ideas.    The change needs to be done before the group becomes entrenched and before it loses momentum.

    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 been outside for a while).  Experience always helps.

     

    Test Leader or Manager with concerns? Consider the Test Managers Conference.

    Services NVP Quality Assurance Services

    Contact Contact us

    Meeting Book a Meeting with NVP

    LinkedIn Group LinkedIn Group

    LinkedIn Company Page LinkedIn Company Page

    Photos by Chandan Chaurasia on Unsplash and Andrew Measham on Unsplash

  • Starting Quality Assurance – Part 6

    Starting Quality Assurance – Part 6

    Have we been successful?

    Last time we gathered some statistics based on the new process once it had settled down. Now we need to compare the new results with the baseline from before the changes were made. If the results have improved, then we keep the change we made. If things have not improved then we need to back out the change and measure again.

    Once we have everything either at the same level as the baseline or improved, then we can embark on the next round of improvements using the same process.

    Two things that can cause problems:
    1. Sometimes the changes are interrelated. This will require research and a method of disentangling the impacts of the changes. Otherwise we may end up undoing the wrong change and find ourselves bouncing back and forth with no long term improvement.
    2. We have to watch for noise in the system or special items that cause the measurements to be inconsistent. No two measurements will be identical and there will be some variation at some level. This has to be ignored or the measurements taken over a long enough time period to even out any variations due to noise in the system. The other item that has to be watched is some special item like a large project or a freeze on development that will cause either the baseline or the new measurements to be inaccurate. Either an adjustment will have to be made or the measurements excluded from the calculation.

    Test Leader or Manager with concerns? Consider the Test Managers Conference.
    NVP Quality Assurance Services
    Contact us
    Book a Meeting with NVP
    LinkedIn Group
    LinkedIn Company Page

    Photos by Chandan Chaurasia on Unsplash and Andrew Measham on Unsplash

  • Starting Quality Assurance – Part 5

    Starting Quality Assurance – Part 5

    Last time we gathered some baseline statistics.  These need to be recorded and retained somewhere.  Now we want to make some changes.  We may want to pause the measurements while we make the changes since they will not be accurate.

    Based on some of the statistics we gathered last time.

    1. Is the process taking too long? Look for parts of the process that are delayed (waiting for inputs or resources) or repeated and resolve the issue.
    2. Is the process being repeated with the same inputs because of failures? Complete a root cause analysis of why the inputs are wrong and fix the upstream process.
    3. Is there a long delay in the middle while external resources are assembled or contacted? Determine if better coordination with external departments would help or consider training internal resources to do the task.
    4. Are computer resources maxing out during the process? Enlist an expert in performance to determine the exact cause of the resources maxing out.  Which tasks are taking all the resources?  Do we need more CPU/Memory or do we need to fix something in the program that may be searching too many records(for example).

    Once the changes above have been implemented and have had a chance to take effect, re-enable the statistics gathering with the same set of measurements being recorded.

    Next blog: Have we been successful?

    Test Leader or Manager with concerns? Consider the Test Managers Conference.
    NVP Quality Assurance Services
    Contact us
    Book a Meeting with NVP
    LinkedIn Group
    LinkedIn Company Page

    Photos by Chandan Chaurasia on Unsplash and Andrew Measham on Unsplash

  • Starting Quality Assurance – Part 4

    Starting Quality Assurance – Part 4

    As promised last week we will talk about statistics in this blog. In the last blog, we talked about completing a deeper dive into a process that was identified as causing problems. Before we make any changes we have to gather some statistics to form a baseline. This can be a little difficult since it may not be obvious what we should be counting. However, here are some suggestions based on the process analysis.

    1. Is the process taking too long? Measure the length of time it takes (pick some obvious end point like when the process is started and when it is finished).
    2. Is the process being repeated with the same inputs because of failures? Count the number of repeats with the same data.
    3. Is there a long delay in the middle while external resources are assembled or contacted? Measure the wait time and make sure to remove it from total time the process takes.
    4. Are computer resources maxing out during the process? Enable a performance monitor and save the results.

    Some of these will be guesses and some may need to be measured at a lower level to get more granular figures. But the idea is to identify items that are possible candidates for improvement.

    Next blog: Act on the statistics.

    Test Leader or Manager with concerns? Consider the Test Managers Conference.
    NVP Quality Assurance Services
    Contact us
    Book a Meeting with NVP
    LinkedIn Group
    LinkedIn Company Page

    Photos by Chandan Chaurasia on Unsplash and Andrew Measham on Unsplash

  • RCA – Why – Part 1

    Why bother with Root Cause Analysis on Defects? We have enough to do without adding to the work!

    1. We found a defect.
    2. We fixed the defect.
    3. We retested the defect.
    4. We closed the defect (pending success on item 3).
    5. Enough said. Let’s move on to something else!

    We acknowledge that once we have a defect, all of the above have to occur (hopefully only once and not repeatedly). But Root Cause Analysis is intended to prevent 1 – 5 ever coming back to bother us again. The key word is ever! We never want to see that defect again. In order to do that, we need to find out where it occurred, why it occurred; and make sure that combination never comes up again. In the long term this saves us a lot of money and time and allows us to concentrate on more important items.

    October is Quality Month. Sign up for our newsletter, to see some things about Quality Month or request a copy if you are too late for this month.

    Photo by JJ Ying on Unsplash

  • Trend Analysis on Defects – Part 2

    Last week we discussed some prerequisites for Trend Analysis on defects. We are only discussing defects here but there are many other project metrics that could be analysed.

    Assuming that the prerequisites from the previous blog have been satisfied, what can we determine.

    1. The trend in the number of defects in each project (after normalization by some project size measurement).
    2. The trend in the number of defects in each Priority and Severity level (again after normalization).
    3. The phase or process that consistently generates the most defects.
    4. Any weak or defect prone supplier processes.
    5. Any product weaknesses that cause consistent customer complaints.

    Once we have the information listed above, we are in a strong position to fix any weak areas and correct any issues that may be costing us customers or internal funds. This is process improvement devoted to making sure that our internal processes are the best possible and we are generating the best possible product. There is more to trend analysis than we are mentioning here, but there are entire books and conferences devoted to this topic. We have only touched the surface of one item we can measure, address and improve.

    October is Quality Month. Sign up for our newsletter, coming out next week, to see some things about Quality Month.

    Photo by Stephan Henning on Unsplash

  • A Better Way – Case Study 5 – Distributed with Poor Testing

    A Better Way – Case Study 5 – Distributed with Poor Testing

    In our last several blogs we have discussed ‘A Better Way to Test”.

    The issue is to apply this to actual situations. We have 5 Case Studies we plan to use over the next several weeks to address this. The fifth case study might be called “Distributed with Poor Testing”.

    In this case the developers were geographically remote, the Quality Assurance (such as it was) was local and the clients were geographically remote. This was a somewhat unusual situation since it is frequently the Quality Assurance that is remote and the other two local. However, some of the considerations had to be the same. We needed a way of communicating things without losing anything in transit.

    Two solutions came to mind immediately:

    1. Make sure there are stated expectations regarding the flow of information. This applies to any artifact like a test case, a requirement, a defect, or a design document. We did this via some flow charts we placed in the Master Test Plan although there are certainly other places they could have been recorded.
    2. Acquire some tools that will support this information store. There are many free or very cheap cloud-based tools that support these processes.

    Once we had the framework in place, we set up the appropriate loops and feedback mechanisms to ensure information flow and good quality. As time went on we expanded the groups who had access to the systems ensuring that the information flowed in the correct way and with sufficient security to the concerned parties. The two way flow of information allowed us to eliminate a backlog of defects that had accumulated and start addressing customer concerns in a timely manner.

    The investment was not large when compared to the improvements realised.

    If you want to discuss this further contact us.

  • A Better Way – Case Study 3 – Test Plan in a Hurry!

    A Better Way – Case Study 3 – Test Plan in a Hurry!

    In our last several blogs we have discussed ‘A Better Way to Test”.

    The issue is to apply this to actual situations. We have 5 Case Studies we plan to use over the next several weeks to address this. The third case study might be called “Test Plan in a Hurry!”.

    This issue came up from an organisation that was part way through (as usual!) an engagement and suddenly required a test plan to satisfy the client. The request came from the Project Manager on Friday with a deadline of Monday afternoon. There was no prior exposure to the project; no knowledge that the request was coming; and very little in the way of Project Documentation (with certainly no time to review it). There was a temptation to ignore the request and had they not been an existing client, we might have been tempted to point out that this was not really an effective use of time. However, given the nature of the request and the people from whom it came, we went ahead with the attempt.

    Clearly, we were not going to get detailed testcases or test objectives based on what we had been given. So we opted for a process based Master Test Plan. In other words, we put together a statement of how the project would be tackled from a Quality Assurance point of view when the information became available. We put in processes for all the Quality Assurance items and highlighted the risks inherent in testing under these conditions (including the lack of any understanding of the project) and went forward with that. We put a strong emphasis on what was required now in order to make this work.

    If you want to discuss this further contact us.