NVP Software Solutions

Tag: QA

  • Anticipate the worst and plan for the best

    Anticipate the worst and plan for the best

    The press has been full of the Mars probe crash over the past week. A sensor malfunction caused the onboard computer to think the probe was much closer to the surface than it actually was and triggered a series of actions that caused it to crash. It’s not easy to anticipate everything especially when it has to be planned out so far in advance and last minute changes are not possible. Mars probes have failed for a number of reasons over the years and knowledge of the red planet is still limited. How could quality assurance helped? (more…)

  • Stress Testing

    Stress Testing

    Think of stress testing in software testing as the confirmation that any sudden increase in transactions per unit time can be accommodated by the program being tested and won’t cause the program to stop working or degrade its operation in any manner. i.e. a short sharp peak. (more…)

  • Quality Management – A How To

     Quality Management – A How To

    Three weeks ago we asked Quality Management – Why Bother?  This week we want to look at How Quality Management is tackled. (more…)

  • QA Management – Why Bother?

    QA Management – Why Bother?

    Two weeks ago we asked if QA Management was a oxymoron. Today we are going to partially answer that question with a  NO!

    In the smallest set of terms; QA Management is there to save a company or organization money and to make a project run more smoothly. (more…)

  • QA Management – An Oxymoron

    An oxymoron is two contradictory terms that have been used in conjunction so is “QA Management” an oxymoron or is it simply contradictory? Is it possible to manage Quality Assurance for Quality Assurance or are we wasting our time trying to manage quality? (more…)

  • How Do We Train Software Testers?

    Software tester training is something that appears to require a lot more attention, given the number of conversations we have on a regular basis. We get a surprising number of questions about software tester training and plans, so we’ve dedicated our next blog series on how to train software testers. (more…)

  • Test Conditions

    Test Conditions is a term that has multiple definitions. For the sake of this blog, we are going to define them as the equivalent of (Low Level) Test Objectives and state that they are One-Line statements of what is going to be tested. (High level Test Objectives may relate to more system level objectives and some of them may be derived from the Project Charter or plan.)

    For example, the Test Conditions may read as follows:

    1. Test that the system calculates interest correctly.
    2. Verify that the design allows for 100 simultaneous connections.
    3. Validate that the user interface is accessible according to the corporate standards.

    The question that frequently arises is why bother to write these Test Conditions? It seems like an extra step with minimal return. Why not just go directly to the Test Cases?

    We use them for a number of reasons.

    1. They allow the tester to consider the entire system rather than getting into detailed test cases at the first step.
    2. They allow other stakeholders to review the test coverage without having to read through full test cases.
    3. They can identify coverage and omissions in coverage with limited effort.
    4. They allow for estimation of the number of test cases that will be needed before the testcases are written.
    5. They allow for estimation of the test effort early in the project.
    6. They can help identify the components of the test environment earlier allowing it to be specified and built before it is needed.
    7. They determine the required test data and allow it to be gathered and made ready before testing starts.

    We have found that the effort in building test conditions is more than paid back in early information and helpful triggers for what needs to be done.

    Discussion Questions

    1. Do you write Test Conditions or Test Objectives?
    2. Were they beneficial to the project?
    3. What would you have done differently based on what you know now?

    Next Week: Process Improvement – Deal with Results

  • Quality Assurance Process Improvement – Part 4

    Quality Assurance Process Improvement is the current topic for our NVP Blog. 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 standard 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 blog focused on How to do Process Improvement and now we’ll address “Dealing with the results”.  Many people complete a process improvement assessment; discover a number of problems that need to be fixed but then drop the process without full solving the issues or taking advantage of all of the work that went into getting the results. This typically happens because of the following:

    • The work that needs to be done isn’t scalable or fun.
    • There’s no one to do the work.
    • There’s no budget for the implementation.
    • What was discovered is so unexpected that no one knows how to tackle it.

    These can all be addressed by the ‘divide and conquer’ methodology.

    Once the results of the assessment are known, they need to be organized into logical buckets. Each bucket is then assigned a set of tasks. Some people will tell you that we need to identify the synergies so that everything gets accomplished efficiently with minimal disruption. While that would be the optimal way of doing things; it is rare for anyone to be able to identify all the synergies simply by looking at the list of results of an assessment. We have to accept some redundancy and the fact that some items are going to have to be reversed when new ones are put in place.

    Now is the time to implement your results.

    Next Week: Scope of Testing