NVP Software Solutions

Tag: Process Improvement

  • Scheduling Test Cycles

    Scheduling Test Cycles often seems to create challenges for Managers, so we thought we’d tackle this for today’s blog. In our experience, there seems to be an ingrained view from Test Managers and Development Managers to not leave time between the Test Cycles or the Fix Cycles for the other party to do their work.

    I have seen Test Cycles scheduled consecutively with no room to actually fix anything. The idea was that they could fix the bug overnight or during the weekend because nothing could impede the test effort at this stage. The alternate problem is scheduling by the Development Manager who puts all the time into the Fix or upgrade time and allocates nothing for testing. The same question elicits a similar answer that testing can proceed overnight or on weekends.

    What is obvious is that there has to be compromise on both sides.

    However, it is possible to schedule overlap. Certainly Developers can start fixing bugs found early in the test cycle. before the cycle is finished, and it’s probably better that they do. However, this requires strong promotion and code control procedures and a plan on how the environments are going to organize. Otherwise, fixes start getting into the test environment before other testing is done. Similarly testing can continue even when Developers are in fix-mode. Planning is required to cover items they aren’t working on at the moment.

    We just need to plan our way through this with the understanding that there will be changes as the project evolves, dependencies arise, and items change.

    Discussion Questions

    1. Have you Scheduled Test Cycles?
    2. If yes, to number 1, how did it work out?
    3. What would you have done differently based on what you know now?

    Next Week: Final meetings for the year

  • Quality Assurance Process Improvement – Part 2

    Quality Assurance Process Improvement is the current topic in our Blog Series. We completed a series of 4 on Assessments because at the end of the Assessment process a lot of organizations won’t act on the Assessment results if they don’t have a plan for moving forward. This is particularly true if the Assessment has not been tailored to the particular company in question. A standardized Assessment process generates standard recommendations which may not be applicable. Make sure you detail your expectations at the beginning of the Assessment so you get value from the process and your expenditure of time.

    Last time we looked at What Process Improvement is and now want to address the question of “Why do it”. We stated earlier that we needed to understand the intent of an Assessment and use it going forward. And that is  after-the-fact in terms of the answering the question. Why do an Assessment and continue on with Process Improvement in a Quality Assurance environment in the first place?

    The answer is that Process Improvement Saves Time and Money. We do not carry out any Process Improvement activity without the intent of saving money. The activities we do must have a positive ROI. This, however, is the more difficult question to answer since the positive ROI is not always in the current project. Putting in a defect management process; improving the review process; ensuring early involvement of Quality Assurance personnel in a project benefit the next project but not the current one.

    The objective is to save the overall organisation funds; not just the current project. As such the results of an Assessment and the activities done as part of Process Improvement must be assessed at the corporate level and not at the project level.

    Next Week: Scheduling Test Cycles

  • Quality Assurance Process Improvement – Part 1

    Quality Assurance Process Improvement is the next topic in our Blog Series. We completed a series of 4 on Assessments and at the end of the Assessment process a lot of organizations tend not to act on the results if they do not have a plan for moving forward. This is particularly true if the Assessment has not been tailored to the particular company. A standardised Assessment process generates standard recommendations which may not be applicable. Make sure you detail your expectations at the beginning of the Assessment so you get value from the process and your expenditure of time.

    Assuming that you have the results of an Assessment available, the next step is often some sort of Process Improvement. So what is Process Improvement?

    We define Process Improvement as a planned and measured activity that leads to a better process.

    Planned – Process Improvement carried out without a plan is simply change for the sake of change with no knowledge of whether this is an improvement or not.

    Measured – Measurements need to be taken both before and after the process improvement activity is completed. Before measurements provide a current baseline of how the process is currently operating. After measurements determine whether the process improvement activity has had the desired effect. Without both, there is no point to the process improvement.

    Better Process – The measurement process tells us whether the process has improved at all. There is a number of things that could be measured. Maybe the process has got quicker; maybe it is cheaper in some way; maybe it is more consistent so the results are more similar; or maybe the end product or service generated from the process is better. It would be nice to get all four with one process improvement activity but frequently it will require multiple iterations of the process improvement cycle to start realising gains on all four items.

    Next Week: Coming Meetings

  • Quality Assurance Assessments – Part 4

    Quality Assurance Assessments take a variety of forms in an IT project and can range from very informal to very formal. This week we will discuss What to do with the results of a QA Assessment now that we have completed an explanation of HOW to do Assessment in a past blog.

    What to with the results of a QA Assessment

    There is a strong temptation to (facetiously) say Do Nothing with the Results since that happens so frequently. The Assessment is completed and everyone just wants to forget about it. Not only is that a direct waste of the effort and time included in the assessment, it also sends the signal to everyone that their effort was unnecessary and their thoughts unappreciated. Don’t expect a lot of effort next time under this scenario.

    If we use the example from the last blog (referenced above) of the questionnaire or in person interviews to elicit the information using open-ended questions, then we will end up with a lot of disparate information that may not be readily parsed.

    The steps are as follows:

    1. Review all the provided answers.
    2. During the review write down some general categories for the answers (i.e. insufficient testing; requirements issues; development issues; testing issues). If these categories were predetermined then this step does not apply.
    3. Allocate the answers into the categories.
    4. Allocate the answers that fit into more than one category (put them into both).
    5. Allocate the answers that only occur once and do not fit into any category (make a category of Other and put them there).
    6. Extract a common consensus from each category (there is a lot of work in this step)
    7. Start a process of finding the root cause of the common problems.

    Now we have to act on the root causes and resolve them. This could be a whole series of blogs but we will leave that for the process improvement cycle.

    If you are having trouble working this out, contact us and we can help guide you and your team in the right direction.

    Finally, we’ll leave you with a few questions and ask you to post your answers.

    1. Have you participated in a Test Process Assessment?
    2. Has anyone acted on the results?
    3. Were the results used for Process Improvement?

    Next Week: Vocabulary

  • Quality Assurance Assessments – Part 3

    Quality Assurance Assessments take a variety of forms in an IT project and can range from very informal to very formal in nature. This week we will discuss HOW to do a QA Assessment now that we have completed an explanation of WHY to do Assessment in a past blog.

    HOW Quality Assurance Assessments are Done:

    The following needs to be done in order to complete a Quality Assurance Assessment:

    1. Determine the objective of the assessment. (Refer to Why Quality Assurance Assessments are Done in a past blog).
    2. Set up a team (may be a team of 1) to do the assessment.
    3. Determine the targeted group who are going to provide information to the team.
    4. Determine the method of getting the information (questionnaire; in person interviews; survey).
    5. Using the method selected above, carry out the assessment.
    6. Collate the results.
    7. Provide a report.

    The above is a general methodology. The following is a short example of a very basic QA Assessment.

      1. The objective is to determine how well the Software Testing Process worked on the last project.
      2. The team will be the Quality Assurance department (not involved in the particular project).
      3. Target audience: Software Testers, Developers, Project Manager(s), End Users, Management, all other interested stakeholders.
      4. Methodology: Individual interviews using a questionnaire. Some sample questions follow
        • What went right with the project in terms of Software Testing?
        • What went wrong with the project in terms of Software Testing?
        • What expectations were and were not met?
        • How could the process be improved?

    This is a very small sample of questions to be answered. From there:

    1. Compile the answers into a report removing the names and any identifying comments.
    2. Create a set of recommendations based on the results.

    If you are having trouble working this out, contact us and we can help guide you and your team in the right direction.

    Finally, we’ll leave you with a few questions and ask you to post your answers.

    1. Have you participated in a Test Process Assessment?
    2. What was the justification for the Assessment?
    3. Were the results used for Process Improvement?

    Next Week: KWSQA, TASSQ and London Peer-to-Peer

  • Quality Assurance Assessments – Part 2

    Quality Assurance Assessments take a variety of forms in an IT project and can range from very informal to very formal in nature. This week we will discuss WHY we want to do a QA assessment now that we have completed an explanation of WHAT an Assessment is in a past blog.

    WHY Quality Assurance Assessments are Done:

    1. They’re Mandated

    If it is mandated but not accepted then it is an exercise in futility. This is quite possibly the worst reason to start a QA Assessment, especially from the viewpoint of those carrying out the assessment. The process will be completed with little effort given, in the shortest time possible and the results will end up on a shelf, never to be discussed again.

    2. To Find Out What Went Wrong

    In this case, there will be an effort to find out what went wrong in the just-completed project and even if no further action is taken, at least people are aware of what everyone considered to be problems (which may not have been obvious to other people in the project). The danger is that this session and the final report can easily turn into an exercise of complaint and self justification.

    3. To Improve the Process

    This is by far the best justification for a Test Process Assessment. If parties are focused on what needs to be done to make the next effort easier, better, or more effective, then the discussion will focus on finding solutions to problems encountered. The participants cannot simply list their problems and concerns and then walk away.

    We want to finish with a few questions and ask you to post your answers.

    1. Have you participated in a Test Process Assessment?
    2. What was the justification for the Assessment?
    3. Were the results used for Process Improvement?

    Next Week: Test Plans

  • Quality Assurance Assessments – Part 1

    Quality Assurance Assessments take a variety of forms in an IT project and can range from very informal to very formal in nature. No matter where each assessment lands on the spectrum, they are intended to do only one thing: Improve the Processes that are used. This week we will discuss the various forms of assessments.

    Post Project

    Post project assessments have had a variety of names throughout the years:

    1. Post-Implementation Review
    2. Lessons Learned
    3. Post Mortem

    Regardless of what they are called, they all have one purpose. The people on the project are asked to recall what went right and what went wrong in a project. This could mean trying to remember things that are a few years old, which isn’t always ideal. The person conducting the assessment then provides the information to a recorder. The resulting information is compiled somewhere and (sometimes) used for process improvement. (More on that in our next blog series).

    In-Project Assessments

    In-Project Assessments can have a variety of formats:

    1. Walkthroughs
    2. Reviews (checkpoint and in process)
    3. Inspections

    Sometimes the above are referred to as Reviews and not as Assessments.

    Test Process Assessment

    The last type of Assessment we want to discuss is the Test Process Assessment. This one is aimed solely at assessing the Test Process used for any particular project. It is often carried out by an independent group although it can be done by a Quality Assurance person or a test manager. The assessment looks for places where the process is not efficient or not effective. It looks for redundancies and repetition. Frequently the assessment starts with the Quality Assurance aspect of the project but finds itself extending back into the Development piece and forward into Implementation. It’s usually difficult to carry out an assessment just of the Quality Assurance piece when there are so many other interlocking pieces that impact Quality Assurance and Quality Control. See nvp.ca/services/assessments/ for further details.

    Next Week: Test Cases

  • Quality Assurance

    Toward the end of last year we encountered a situation where our presence in a project was there to “Assure Quality” or that “Quality was Assured” simply by us being there. Although the comment was made somewhat in jest, it showed a misunderstanding of Quality Assurance that can lead to dire consequences. Quality Assurance is not a standard although it includes standards. It is a process and a journey (and not a destination).

    Quality Assurance looks at the processes that are being used and tries to find places for improvement so that everything can be smoother. It looks for root causes of existing problems and eliminates or reduces their impact so that they no longer impact the process further along. Sometimes this is referred to as “Removing the Rocks in the Stream” so that the flow of the project is smoother. Quality Assurance also tries to anticipate other items that might impede smooth project completion and eliminate those as well. This is why it is never complete. There is likely to be improvements that will still occur and we can continue to identify those opportunitiess. Even if we can’t identify opportunities for improvement it is likely that someone in the organization can see something that can be changed. Every project is slightly different and the opportunities for improvement or to change processes are also different. If the projects are not different, then they can be turned into a standard process and there is no need for any individual improvements. That will still leave process improvement as a possibility.

    It is suspected that the initial comment at the beginning of this blog was really related to Software Testing and not Quality Assurance at all. However the misconception exists.

    Next Week: Quality Assurance Centre of Excellence