NVP Software Solutions

Tag: QA

  • So you want to be a software tester?

     

    So you want to be a software tester and don’t know how to start.

    There are plenty of ways to become a software tester and we’ve talked to a number of people curious about how to break into the field. If you ask current testers what their background is here are some answers you may get: (more…)

  • 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