Designing test cases with EP and BVA

-

Having identified the conditions that you wish to test, in this case by using equivalence partitioning and boundary value analysis, the next step is to design the test cases. 


The more test conditions that can be covered in a single test case, the fewer test cases will be needed in order to cover all the conditions. This is usually the best approach to take for positive tests and for tests that you are reasonably confident will pass. 


However if a test fails, then we need to find out why it failed - which test condition was handled incorrectly? We need to get a good balance between covering too many and too few test conditions in our tests.


When we come to test invalid partitions, the safest option is probably to try to cover only one invalid test condition per test case. This is because programs may stop processing input as soon as they encounter the first problem. 

However, if it is known that the software under test is required to process all input regardless of its validity, then it is sensible to continue as before and design test cases that cover as many invalid conditions in one go as possible. 

There should be separate test cases covering valid and invalid conditions. To cover the boundary test cases, it may be possible to combine all of the minimum valid boundaries for a group of fields into one test case and also the maximum boundary values. 

The invalid boundaries could be tested together if the validation is done on every field; otherwise they should be tested separately, as with the invalid partitions.



Why do we do both equivalence partitioning and boundary value analysis? 


Technically, because every boundary is in some partition, if you did only boundary value analysis you would also have tested every equivalence partition. 

However, this approach may cause problems if that value fails - was it only the boundary value that failed or did the whole partition fail? 

Also by testing only boundaries we would probably not give the users much confidence as we are using extreme values rather than normal values. 

The boundaries may be more difficult (and therefore more costly) to set up as well.
For example, in the printer copies example described earlier we identified the following boundary values: 


  • Suppose we test only the valid boundary values 1 and 99 and nothing in between. If both tests pass, this seems to indicate that all the values in between should also work. However, suppose that one page prints correctly, but 99 pages do not. 
  • Now we don't know whether any set of more than one page works, so the first thing we would do would be to test for say 10 pages, i.e. a value from the equivalence partition.

We recommend that you test the partitions separately from boundaries - this means choosing partition values that are NOT boundary values.


But notice that one equivalence value, e.g. 10, replaces both of the extra two
boundary values (2 and 98). This is why equivalence partitioning with two-value boundary value analysis is more efficient than three-value boundary value analysis.


Which partitions and boundaries you decide to exercise (you don't need to test them all), and which ones you decide to test first, depends on your test objectives. If your goal is the most thorough approach, then follow the pro-cedure of testing valid partitions first, then invalid partitions, then valid boundaries and finally invalid boundaries. 


  • However if you are under time pressure and cannot test everything, then your test objectives will help you decide what to test. If you are after user confidence of typical transactions with a minimum number of tests, you may do valid partitions only. If you want to find as many defects as possible as quickly as possible, you may start with boundary values, both valid and invalid.
  • If you want confidence that the system will handle bad inputs correctly, you may do mainly invalid partitions and boundaries. Your previous experience of types of defects found can help you find similar defects.
  • If there are typically a number of boundary defects, then you would start by testing boundaries.

Comments

Post a Comment

Popular posts from this blog

Types of Review

-
A single document may be the subject of more than one review. If more than one type of review is used, the  order may vary.  It is  apparent that none of the following types of review is the 'winner', but the different types serve different purposes at different stages in the life cycle of a document. The main review types:  Walkthrough Technical Review Inspection Walkthrough A walkthrough is characterized by the author of the document under review guiding the participants through  the document and his or her thought processes , to achieve a common understanding and to gather feedback. This is especially useful if people from outside the software discipline are present, who are not used to, or  cannot easily understand software development documents.  The content of the document is explained step by  step by the author, to reach consensus on changes or to gather information.  Within a walkthrough the author does most of the preparation. The participa
Read more

Roles and Resposibilities for a Formal Review

-
The participants in any type of formal review should have adequate knowledge of the review process. The  best, and most efficient, review situation occurs when the participants gain some kind of advantage for their  own work during reviewing.  In the case of an inspection or technical review, participants should have been  properly trained as both types of review have proven to be far less success-ful without trained participants.  This indeed is perceived as being a critical success factor. The best formal reviews come from well-organized teams, guided by trained moderators (or review  leaders). Within a review team, four types of participants can be distinguished:  moderator author scribe reviewer the management (in addition to the main four roles) The moderator The moderator (or review leader) leads the review process .  He or she determines, in co-operation with the a uthor, the type of review, approach and the composition of the review team.  The mo
Read more

Structure Based or Whitebox Testing Techniques

-
Image
Using structure-based techniques to measure coverage and design tests Structure-based techniques serve two purposes:  test coverage measurement structural test case  design.  They are often used first to assess the amount of testing performed by tests derived from  specification-based techniques, i.e. to assess coverage. They are then used to design additional tests with  the aim of increasing the test coverage. Structure-based test design techniques are a good way of generating additional test cases that are  different from existing tests. They can help ensure more breadth of testing, in the sense that test cases  that achieve 100% coverage in any measure will be exercising all parts of the software from the point of  view of the items being covered. What is test coverage? Test coverage measures in some specific way the amount of testing performed by a set of tests . Wherever we can  count things and can tell whether or not each of those things has been tested b
Read more