By Ian Jackman Davit Stepanyan

 User executed untested code.  The order in which statements were meant to be executed are different than the order used during testing.  The user applied a combination of untested input values.  The user’s operating environment was never tested.

Software testers must consider the software and the function it computes, the inputs and how they can be combined, in the environment in which the software will operate. However, this is easier said then done. Even the most experienced coder will have problems or the simplest software will have issues.

 Modeling the software’s environment  Selecting test scenarios  Running and evaluating test scenarios  Measuring testing progress

Identify and simulate the interfaces that a software system uses and enumerate the inputs that can cross each interface. The four common interfaces in a software environment.  Human Interfaces  Software Interfaces  File System Interfaces  Communication Interfaces

 User interaction that falls outside the scope of software testing. Considerations:  How do we select values for variable input?  How do we sequence inputs?

Most often used for selecting single values for variables at or around boundaries. Ex: Test minimum, maximum, and zero values. What about choosing values for multiple variables processed simultaneously?? Consider cross product value combinations.

 Treat each physical input and abstract event as symbols in a alphabet.  Create a model of that language. Most common models are regular expressions and grammars. Least common are stochastic processes and genetic algorithms.

Text editor example We can represent legal uses of the file selection dialog in, for example, a text editor with the regular expression: Filemenu.Open filename* (ClickOpen | ClickCancel)

 Typical use scenarios  Tests for each source statement  Tests for each branching structure  Tests for each data structure  Fault seeding  Discrimination criterion/random inputs

 Manual testing is expansive  Automated testing  Simulating environment  Expected output is correct  Formalism  Embedded test code

 Fix only the problem  Fail to fix the problem  Fix the problem OR break something else  Fail to fix the problem AND break something else  Takes time away from testing new code

 Number of inputs  Percentage of tested code  Number of starting the system  Number of terminating the system  Is finding many bugs good news???

 Testability  Low testability = more tests  Low testability = more time  Low testability = more testing money  Reliability  Time before the system fails  Cost of maintenance  Smartest people for testing  Appropriate tools and training  Listen when tester talks

 Test scenarios  Evaluate scenarios  Regression testing  Test measuring  Issues

Thank you for listening