NVP Software Solutions

Category: Uncategorized

  • 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…)

  • The Results of Software Tester Training

    Software tester training seems to be something that needs a lot more attention, given how many conversations we’ve had on this topic. A few weeks ago we talked about How We Train Software Testers? We get a surprising number of questions about software tester training and plans, and we now want to touch on the results of software tester training. (more…)

  • System Boundary Diagram

    System Boundary Diagrams sometimes come up in the context of a Use Case and sometimes in the context of Software Testing. Either way they are a useful in the effort expended when determining what to test. While the ‘normal’ System Boundary Diagram shows the boundaries of the system and thus the boundaries of the testing, we try to use it only as a starting point for other diagrams that may also aid in defining the testing effort and scope. (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…)

  • Testing Sources of Information

    Sources of information for testing tend to come from two extremes. In some cases you may have almost no information and find it difficult to start. In other cases you may have far too much information and not know what to do with it all or where to start or stop reading. The ‘happy medium’ or ‘just right’ amount is rarely the case when it comes to testing sources of information. (more…)

  • Upcoming Course – Essentials of Leadership in Software Testing

     

    Happening October 20 – 21 in Toronto, Canada this 2-day course offers solutions and techniques available to Test Leads and QA Managers in the challenges they face in managing Quality Assurance and Testing within their organizations. (more…)

  • Why Test Training

    Test training is something that should be a ‘given’ and not something that a blog series should be devoted to. However, we get a surprising number of questions about test training and plans, that we thought we’d address a few of them here. So why train testers? You may recall that we defined three broad categories a couple of weeks ago in the blog. (more…)

  • The Out-of-Scope of Testing

    The Out-of-Scope of Testing has only one definition (unlike the Scope of Testing) but it is much harder to document. We want to list everything we are not planning to test! However, the inevitable question is how far to go with our list. Obviously we are not going to list everything we are not going to test and we cannot simply say that everything that is not in-scope is out-of-scope (tempting as that may be).

    The (not entirely rhetorical) questions you will get asked include the following:

    1. Are you planning to omit that from your testing? (should be included)
    2. What made you think that isn’t part of this project? (should also be included)
    3. There is too much risk to avoid testing that.

    The danger with listing out-of-scope items is that they remind people of other items and they then start to think about the risk of avoiding testing that item. You start to get scope creep on your testing and since it is not part of the plan you start to get schedule slippage and cost escalation. Very few people will tell you to test less – it is too risky to state that.

    Whatever your policy; the following will guide the creation of the out-of-scope list:

    1. What can we avoid testing?
    2. What will simply not be able to be completed within budget and resource constraints?
    3. What is the best use of the resources?

    Make sure to document the out-of-scope up front and get it signed off. That will reduce the problems later on and create a much more harmonious working relationship.

    One of the best methods is to build a System Boundary Diagram and let that drive the Scope of testing. Not only does it clarify the thoughts of everyone in the project, it is very effective way of conveying the scope and out-of-scope pieces of the project.

    In general we try to test the interfaces of the System Boundary diagram but avoid full testing of the items outside the System Boundary Diagram. Those are out-of-scope.

    Discussion Questions

    1. Do you define your Out-of-Scope of Testing?
    2. Has it been disputed?
    3. What would you have done differently based on what you know now?

    Next Week: Training