Tag: Centre of Excellence

  • 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

  • Quality Management

    Is there any difference between software and manufacturing?

    Last week we 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.

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

    Photo by Maria Jose Oyarzun on Unsplash

  • Hack or Poor testing

    Was it a Hack or Poor Testing?

    Recently we went to a restaurant for a quick dessert (pick up only at the current time). Usually this restaurant is quite fast and we have our order and are out within a few minutes. This time, to minimize the number of people in the restaurant, only one person went in and the rest of us stayed in the car. For a little while we did not worry – it was a busy time and there was a line up at the drive through and quite a few cars in the parking lot. However, by the time we had been sitting for 20 minutes catching up on mail, reviewing calendars, and reading it began to seem like a long time. The lightening storm to the north was quite good to watch also so that passed some time.

    Then we began to get text messages from the person inside.

    When they came out, with the order in hand, we got the full story.

    1. Order was submitted at the counter (not via the machine) and a receipt with number obtained.
    2. Many other people were also waiting.
    3. Drive through orders were being run out to the two waiting spaces (which was probably an indication of problems).
    4. Then the trouble began.
    5. The orders were disappearing from the screen one by one.
    6. Then the entire screen went blank.
    7. Once that happened, no orders were filled.
    8. The person in the restaurant had to go back to the counter to get the order filled and eventually came out with it.
    • Was it a one time Hack of the system?
    • Was it some sort of bug?
    • Was it the storm affecting the system – there was a lot of lightening?

    We never found out but we did hear that there had been a similar problem a month earlier when another family member went to the restaurant to pick up supper. That seemed to be too coincidental so we suspect poor testing.

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

    Photo by Charles Deluvio on Unsplash

  • Shift Left

    Why is Shift Left not occurring?

    Recently NVP contributed to a blog on why Shift Left was not occurring. Speaking as someone who has experienced it from a Test Lead position, our concern was the inability to free up resources while still continuing with existing testing. The full article can be found here.

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

    Photo by Charles Deluvio on Unsplash

  • The purpose of Meetings

    Recently I was asked to provide a short history of a local Quality Assurance organization.

    Starting with the previous organization, I went through the 25-year history in about 5 minutes. The one major overriding change in those 25 years was the advent of the internet that created a vast information trove that is free to all. Prior to that, people were isolated within their organizations with limited contact with people with the same interests in other organizations. Solutions to problems were generally home-grown.

    Having provided that very brief synopsis we were left with three questions about the purpose of the organization:

    1. Are we an organization dedicated to networking?
    2. Are we an education organization?
    3. Are we a social organization?

    Unfortunately we do not have enough of the history documented to determine what has been the best use of the time. Clearly my synopsis was based on what I remembered and I was not always in attendance at all the meetings or always on the board. So the question is still open.

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

    Photo by Jon Tyson on Unsplash

  • Staying In – Part n+10 – How much proof is necessary?

    One of the problems QA people have is deciding how much proof is enough. 

    Proof is expensive and time-consuming to generate.  Even with the current test tools taking screen images and storing them, you may have to annotate the proofs and combine them with other items to send to various places.   You may want to weed out items you don’t want and add things that are missed.  Having done all of that and made a nice package, you then wonder if anyone ever looks at it.   We have had clients look and some clients need it for regulatory purposes.  However, a lot want to know it is there and they could look at it if they had a need but they don’t ever open up the package and look. 

    Of course it also gets superseded with new executions of the test case, new test runs or simply new code.  Sometimes the proofs accumulate in the test tool or a directory until they overwhelm storage and get put onto backup just in case they are every needed.  Eventually either they can no longer be read or someone cleans up all the old backups.

    We have two major questions:

    1. Are the proofs necessary?
    2. How long should they be kept?

    The answer to the first question depends on risk, and the ability to learn and use items from the past.  There is no doubt that higher risk items need more proof and it needs to be kept.  But the second part is even more critical, can we use the value in the proofs to inform future testing efforts in the software.  Often a second review will identify other items that might have been missed either in the existing proof or in test coverage.

    The answer to the second question is actually a process that should exist for all documentation.  There is an absolute upper limit in terms of years after which, if the proof is that old and the testcase has not been re-executed in all that time, then it is not likely it is going to come back.  Alternatively, if the testcase has been executed multiple times since the the original proof was stored and all the subsequent proofs have been retained, then we will not be going back and it is probably safe to discard the older proofs.

    Either way, we do not keep everything for ever.

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

    Photo by Bekir Dönmez on Unsplash

  • Staying In – Part n+9 What is QA?

    One of the problems QA people have is explaining Software Quality Assurance to IT or to the business. 

    Some people will talk about Software Testing.  Others will refer to Test Automation.  Still others will refer to Process Improvement.  Some will start down the path of Types or Phases of testing and explain all those terms.  Test Strategies and Test Plans will start to fill the room.  Test Cases, Actual Results, and Expected Results will proliferate until the explosion occurs.  Finally there will be references to that elusive animal: The software bug.

    For people in IT, these references may mean something.  For people not in IT, the eyes start to glaze over very quickly. 

    We are left with the question of what do you do and how does it benefit me plus a request to put it in business terms.   

    If you have been in this position of knowing what you do and just how much time it takes and how much it all costs, this question can be frustrating or annoying.  Many people feel they could have dealt with a dozen test cases while trying to explain it.

    Eventually, the Software Quality Analyst despairs of making the user understand and asks for them to just leave them to get on with their work.  This never works!

    The business may leave for a while, but they always will come back with the same question and they will start to regard the Software Quality Assurance department as a Cost Centre.  That is also not good.

    If you have been in this position contact us to watch a short powerpoint presentation that puts the above into Business Terms.

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

    Photo by Bekir Dönmez on Unsplash