This section provides an overview of what testing is, and why a developer might want to use it.

It should also mention any large subjects within testing, and link out to the related topics. Since the Documentation for testing is new, you may need to create initial versions of those related topics.

This technique divides input data into data classes to reduce test cases amount to validate a rule. The idea is that given a set of possible equivalent values, using just one of those values will be enough to design a test case.

An advantage of this approach is reduction in the time required for testing a software due to lesser number of test cases.

It strives to find errors that may arise based on information classes and reduce to the minimum the effort needed in terms of test case design as well as test data mass.

This technique should be used whenever you have boundaries defined into a spec. It is a great idea to apply it to any rule based on time, values, any kind of counting or scale to be triggered.

It also ensure and helps finding n + 1 errors. And yes, it is an expansion from Equivalence Partition concepts. Your decision to apply this or the other should be the boundaries existing and being clearly defined.

Using the EP

      June   |          July         |    August
... 28 29 30 | 01 02 03 ... 29 30 31 | 01 02 03 ...
    ^                    ^                   ^

Using the BVA

      June   |          July         |    August
... 28 29 30 | 01 02 03 ... 29 30 31 | 01 02 03 ...
           ^ | ^                   ^ | ^

This technique should be used when you have any workflow in place, and should consider positive test cases (transitions that can happen), as well as negative test cases (transitions that are not allowed).

Any rule that can be described, thinked, scratched as a state transition diagram, workflow, lifecycle can have their test cases designed using this technique.

This technique can be also works to find completeness problems inside worflows and diagrams during documentation analysis.

HOT TIP

If a state transition like rule is provided as a series of statements instead of a table or graphic diagram, you can proceed as following:

1. Make yourself a state transition table as in the ticket system example
2. Add question marks for unclear transitions
3. Add an extra column at the end for broad discussion with business - raise questions and take notes

This is a way common situation we face on daily basis, and this practice can be handful to gain confidence on what is being developed and how it should be tested