The Five Goals of Software Testing

0
111

Testing can mean many things depending on who is doing it and where a process is performed. The programmers, administrators, users, and consultants all have something different in mind when testing. A dedicated tester can often feel lost in the competing interpretations. To be effective, however, a tester needs a specific job description. These five goals of software testing are an excellent basis.

Verification

The primary objective of testing is the most misunderstood. If you think it is to find defects, then you are wrong. Flaws will be seen by everybody using the software. Testing is a quality control measure to verify that a product works as desired. Testing provides a status report of the actual product in comparison to requirements (written and implicit). Simultaneously, this is a pass/fail listing of product features; in detail, it includes confidence numbers and expectations of defect rates throughout the software.

Software Testing

This is important since a tester can hunt bugs forever yet not say whether the product is fit for release. Having many defect reports is useless if no method exists to value them. A corporate policy regarding product quality needs to be in place. It must state what conditions are required to release the software. The tester’s job is to determine whether the software fulfills those conditions.

Priority Coverage

Not everything can be tested, not even a significant subset. Therefore, testing needs to assign effort reasonably and prioritize thoroughly. This has been by no means a simple topic. Generally, you’d like to have every feature covered with at least one valid input case. This ensures at least a baseline utility to the software.

Beyond the baseline, you’ll need to test further input permutations, invalid input, and non-functional requirements. In each case, the realistic use of the software should be considered. Highly present and frequent-use scenarios should have more coverage than infrequently encountered and specialty scenarios. Overall, you target a wide breadth of coverage with depth in high-use areas and as time permits.

Traceable

Exactly what was tested and how it was tested are needed in an ongoing development process. In many environments, such proof of activities is required as part of a certification effort or to eliminate duplicate testing efforts. This shouldn’t mean extra documentation; it simply means keeping your test plans clear enough to be reread and understood.

You must agree on the documentation methods; every team member should not have their own. Not all features should be documented the same way; however, several different approaches will likely be employed. Unfortunately, there aren’t many commonly agreed principles in this area, so in a way, you are kind of on your own.

Unbiased

Tests must balance the written requirements, real-world technical limitations, and user expectations. Regardless of the development process being employed, there will be a lot of unwritten or implicit requirements. It is the job of the tester to keep all such requirements in mind while testing the software. A tester must also realize they are not a software user; they are part of the development team. Their personal opinions are but one of many considerations. Bias in a tester invariably leads to a bias in coverage.

The end user’s viewpoint is vital to the software’s success, but it isn’t all that matters. If the needs of the administrators can’t be met, the software may not be deployable. If the needs of the support team aren’t satisfied, it may be unsupportable. If the marketing conditions can’t be met, it may be unsellable. The programmers can’t be ignored; every defect must be prioritized concerning their time limits and technical constraints.

Deterministic

Issues should not be discovered randomly. Coverage criteria should expose all defects of a decided nature and priority. Furthermore, later-surfacing defects should be identifiable as to which branch in the coverage they would have occurred, and thus, detecting such defects in future testing can present a definite cost.

This goal should be a natural extension of having traceable tests with priority coverage. It reiterates that the testing team should not be a chaotic black box. Quality control is a well-structured, repeatable, and predictable process. Having clean insight into the process allows the business to gauge costs better and direct the overall development.