NVP Software Solutions

Tag: Software Testing Strategy

  • Quality Assurance Process Improvement – Part 3

    Quality Assurance Process Improvement is the current topic in our Blog Series. We completed a series of 4 blogs 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 Why Carry Out Process Improvement and now want to address the question of “How to do it”. First we need to identify the processes that we want to improve. We will assume that this step has been completed already. Then we need to measure the existing process for what we want to improve. If we want it to be faster then we need to measure the time it takes. If we want it to be more consistent, then we need the measure the output against some standard. Once we have a baseline of measurements (you will probably be measuring more than one item since we do not want to improve one at the expense of another), then we can decide how we want to improve it. If we want the process to be faster, we might try to get the inputs to it at the right time or before they are needed. We might try cutting out any extra steps. While doing this we do not want to reduce the quality of the output so we will want to measure that as well. if you want it to be more consistent you might look for places where the product deviates from standard and try to improve those while making sure that does not make any other pieces of the product worse.

    The post improvement measurements should always be carried out after the process has had a chance to settle down and achieve some stability. Measuring too soon may lead to erroneous conclusions.

    The objective is to save the overall organization 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: Guest Blog

  • 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

  • Software Testing Strategy – The Test Strategy

     

    We discussed Test Plans and their contents in the earlier blog and today we will discuss the Test Strategy. Some people will look at the title above and think we are just repeating our blog from three weeks ago. Luckily, that’s not the case. We differentiate between Test Plans and Test Strategies.

    NVP considers a Test Strategy to be a document that outlines a long term direction for testing. It’s possible that the Test Plans for each project will borrow heavily from the Test Strategy and may even be based on it. We’re not necessarily considering that level of connection in this scenario.

    The following is a set of contents for a Test Strategy

    1. Introduction – outlines the purpose of the document
    2. Corporate Business Strategy – Copy and paste from the relevant business document
    3. A high level outline of the Test Strategy – See below
    4. Alignment with corporate strategy and identification of the gaps
    5. Baseline of current testing (where we are today)
    6. Gaps between the baseline and Test Strategy
    7. Goals or methodologies to close the gaps
    8. Strategy assessment process
    9. Continuous improvement

    The Test Strategy section would include answers to the following:

    1. Where is the best place to complete testing in the life cycle?
    2. Who are the best resources for each level and type of testing?
    3. What is the long term development process for the identified resources?
    4. From where are the resources going to be sourced?
    5. What is the long term automation process or direction?
    6. Where is the greatest ROI for testing?

    Some questions to assess your Test Strategy readiness:

    1. Do you have a Test Strategy?
    2. If you have a Test Strategy; has it been reviewed recently?
    3. Is there a person or a group responsible for the Test Strategy?

    If you answered No to any of the above questions, send us an email to see if a Test Strategy would be a fit for your organization.

    Next Week: Assessments – Deal with Results

  • Software Testing Strategy – The Test Plan

    Any given test plan and its contents vary widely depending on to who is doing the testing and what template is used. Test plans can be found anywhere on the web. They can be generic in nature or specific to a particular industry and have specific sections that are critical for regulatory or risk reasons. A test plan can also be seen as a strategy, while in some cases strategy is never considered. Sometimes test cases are included in a test plan.

    We consider a test plan to be a document that outlines a path for the testing but excludes the test cases (which we like to keep in a database). The test plan often includes the following (not a comprehensive list):

    1. Introduction
    2. Test Approach
    3. Assumptions and Dependencies
    4. Risks and the Risk Plan
    5. Schedule and Resources
    6. Glossary

    The Incredible Shrinking Test Plan

    We’ve seen where one client invested a lot of time creating a test plan template for use within their organization. The template with various sections indicated what the contents of that section should include, however, if the section was irrelevant,  a statement as to why it was inapplicable was to be noted. Under no condition was any section to be deleted. Unfortunately, one group misunderstood the importance of keeping ALL data and deleted any section they felt was unnecessary. They innacurately used the previous plan version as the template for the next one and so on. So every time a section was deleted it was lost forever. We used to refer to those plans as the The Incredible Shrinking Test Plan, it just got smaller and smaller.

      1. Do you write test plans?
      2. If you use a template, do you have trouble filling it out?
      3. Do you get test plans reviewed by the relevant stakeholders?
      4. Are they approved at any point?
      5. What is your experience in how well they test what you need to test?

    And most importantly: Do you ever review them after the project is over and see how well you adhered to the initial outline?

    Next Week: Assessments – How