NVP Software Solutions

Tag: Test Results

  • Debugging versus Scenario Testing

    Recently someone in a class asked about the difference between debugging and scenario testing given the fact that many errors that need to be fixed must be completed in the code.

    If we make the assumption that we are doing a calculation of some sort or running an algorithm then the following applies.

    During User Acceptance Testing – the test should work end-to-end without an error in actual execution. The appearance, formatting or placement of the result may be incorrect but there should be no problems in running the actual process. This applies to normal cases. Clearly there is a possibility of issues with the unique cases that may have been identified late in the process. If the algorithm or test case does not run or cannot be completed then we are probably debugging rather than scenario testing.

    During System Testing – the calculation should complete although the result may be wrong and one or more steps along the way may provide incorrect results. So the results should be available and the algorithm complete although the results may be wrong. System Testing is aimed at Requirements so this is where we should whether the results agree with the requirements. If the individual test cases do not run or cannot be completed then we are probably debugging rather than scenario testing.

    During Integration Testing – each individual piece (validation of a piece of the overall algorithm) should run but they may not be able to work together. If the individual pieces do not work, then we are debugging. If they cannot be run as an integrated whole, then we are testing.

    During Unit Testing – we are debugging each individual piece of the algorithm. This is code debugging and is not expected to be anything else.

    Contact us to see whether you are scenario testing of debugging.

    Diagram by Veronica

  • Negative Testing

    Negative Testing

    In many software testing scenarios, testers can use positive testing and/ or negative testing methods. Positive testing means that the item being tested reacts as expected when the expected input is entered. Negative testing typically means that the system can handle invalid input or unexpected user behaviour. However, if the system responds by rejecting the data and providing an error message, that is what was actually expected, meaning that was positive testing rather than negative testing. (more…)

  • Examples of Verification in Software Testing

    In our last blog post, we included a list of Examples of Verification without going into too much detail. In this blog we will take a couple of those verification list items and expand on them. The examples of verification that most tend to impact software testers with the best return are Test Plans, Test Cases, Test Data and Test Results.

    Test Plans

    Applying verification techniques to a Test Plan can save hours of effort. The three methods we can use to review a test plan are:

      • Walkthrough – in this method, the author of the Test Plan ‘walks’ one or more of their peers through the test plan, explaining the sections and what is meant by the content. The role of the peers is to find problems, omissions, extra content, incomplete items, inconsistent items and to add things that they might feel were missed. The intent is to have a better document more accurately reflecting the needs of the project stakeholders. A new version is issued after all the errors are corrected and it is used going forward.
      • Document Review – In this method, a review committee (preferably selected from the interested stakeholders) reviews the documents and records the same items as listed above for the walkthrough. Once they are finished their individual reviews, they come together to create a final list of problems which need to be corrected. A new version is issued after all the errors are corrected and it is used going forward.
      • Inspections – In this method, formalized roles are defined and assigned and a procedure is followed to ensure proper inspection of the document. The intent and result is the same as the previous two methods. The only difference is the degree of formality.

    What’s the point in all of this? The payback from reviewing the plan (using any of the methods above, more than pays for itself in terms of less errors going forwrd, less work to be undone, redone and redone (again).

    If you know your test plan is poor, or you’re not even sure where to start give us a call at 416-927-0960 or visit our website at NVP.ca to find out where you would benefit from the implementation of Verification techniques in your organisation.