SWEBOK introduces this knowledge area with;
Testing is an activity performed for evaluating product quality, and for improving it, by identifying defects and problems.
SWEBOK defines it as follows:
Software testing consists of the dynamic verification of the behavior of a program on a finite set of test cases, suitably selected from the usually infinite executions domain, against the expected behavior.
In addition, SWEBOK provides further definition of four key issues in the above definition:
-
Dynamic: This term means that testing always implies executing the program on (valued) inputs. To be precise, the input value alone is not always sufficient to determine a test, since a complex, nondeterministic system might react to the same input with different behaviors, depending on the system state. In this KA, though, the term input will be maintained, with the implied convention that its meaning also includes a specified input state, in those cases in which it is needed. Different from testing and complementary to it are static techniques, as described in the Software Quality KA.
-
Finite: Even in simple programs, so many test cases are theoretically possible that exhaustive testing could require months or years to execute. This is why in practice the whole test set can generally be considered infinite. Testing always implies a trade-off between limited resources and schedules on the one hand and inherently unlimited test requirements on the other.
-
Selected: The many proposed test techniques differ essentially in how they select the test set, and software engineers must be aware that different selection criteria may yield vastly different degrees of effectiveness. How to identify the most suitable selection criterion under given conditions is a very complex problem; in practice, risk analysis techniques and test engineering expertise are applied.
-
Expected: It must be possible, although not always easy, to decide whether the observed outcomes of program execution are acceptable or not, otherwise the testing effort would be useless. The observed behavior may be checked against user expectations (commonly referred to as testing for validation), against a specification (testing for verification), or, finally, against the anticipated behavior from implicit requirements or reasonable expectations.
Finally, the SWEBOK identifies 5 subareas; Software Testing Fundamentals, Test Levels, Test Techniques, Test Related Measures, and Test Process.
Testing used to be an end of production – yes/no thing. Very much based on the production line thinking of the waterfall process. However, because of the nature of software production, it was actually a throw it back and forth over the programming wall process. Once the major show stopping bugs were fixed it was sent out to the customers. Agile has changed all that by promoting test driven development. Now it is considered standard operating procedure to involve testing from the very start. In fact, I had written about involving testers as part of pair programming. While this was a groundbreaking idea for me, later I found out that this was becoming a popular practice.
Of course, testers test the limits and boundaries of code, while developers use unit tests to create the code.
Allen