Software Testing

Although it is true that testing should be rigorous, thorough and systematic, this is not all there is to testing.  There is a definite role for non-systematic techniques, i.e. tests based on a person's knowledge, experience,  imagination and intuition.  The reason is that some defects are hard to find using more systematic approaches,  so a good 'bug hunter' can be very creative at finding those elusive defects. Error guessing Error guessing is a technique that should always be used as a complement to other more formal techniques. The success of error guessing is very much dependent on the skill of the tester, as good testers know where  the defects are most likely to lurk.  Some people seem to be naturally good at testing and others are good  testers because they have a lot of experience either as a tester or working with a particular system and so are  able to pin-point its weaknesses.  This is why an error-guessing approach, used after more formal

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

Use case testing is a technique that helps us identify test cases that exercise the whole system on a  transaction by transaction basis from start to finish.  A use case is a description of a particular use of the system by an actor (a user of the system). Each use  case describes the interactions the actor has with the system in order to achieve a specific task (or, at least,  produce something of value to the user).  Actors are generally people but they may also be other systems.  Use cases are a sequence of steps that describe the interactions between the actor and the system.  Use cases are defined in terms of the actor, not the system, describing what the actor does and what the  actor sees rather than what inputs the system expects and what the system'outputs.  They often use the  language and terms of the business rather than technical terms, especially when the actor is a business  user . They serve as the foundation for developing test cases mostly at t

State transition testing is used where some aspect of the system can be described in what is called a 'finite  state machine'.  This simply means that the system can be in a (finite) number of different states, and the  transitions from one state to another are determined by the rules of the 'machine'.  This is the model on which  the system and the tests are based. Any system where you get a different output for the same input, depending  on what has happened before, is a finite state system. A finite state system is often shown as a state diagram. If you request to withdraw $100 from a bank ATM, you may be given cash.  Later you may  make exactly the same request but be refused the money (because your balance is insufficient).  This later  refusal is because the state of your bank account has changed from having sufficient funds to cover  the withdrawal to having insufficient funds. The transaction that caused your account to change its  state wa

The first task is to identify a suitable function or subsystem that has a behavior which reacts according to a  combination of inputs or events.  Credit card worked example  If you are a new customer opening a credit card  account, you will get a 15% discount on all your purchases today.  If you are an  existing customer and you hold a loyalty card, you get a 10% discount.  If you have  a coupon, you can get 20% off today (but it can't be used with the 'new customer'  discount). Discount amounts are added, if applicable.  The conditions and actions are listed in the left hand column. All  the other columns in the decision table each represent a separate rule, one for each  combination of conditions.  We may choose to test each rule/combination and if  there are only a few this will usually be the case. However, if the number of  rules/combinations is large we are more likely to sample them by selecting a rich  subset for testing. Note

The techniques of equivalence partitioning and boundary value analysis are  often applied to specific situations or inputs. However, if different combinations  of inputs result in different actions being taken, this can be more difficult to show using equivalence  partitioning and boundary value analysis, which tend to be more focused on the user interface.  The  other two specification-based techniques, decision tables and state transition testing are more  focused on business logic or business rules. A decision table is a good way to deal with combinations of things (e.g. inputs). This technique is  sometimes also referred to as a ' cause-effect' table . The reason for this is that there is an associated logic  diagramming technique called 'cause-effect graphing' which was sometimes used to help derive the decision  table Decision tables provide a systematic way of stating complex  business rules, which is useful for developers as well as for testers.