System Breakdowns: A Further Exploration
Last week we addressed what a system breakdown is, why system breakdowns are important in software testing and software development, and why you should perform...
Last week we addressed what a system breakdown is, why system breakdowns are important in software testing and software development, and why you should perform a system breakdown. Today, we’ll answer another important topic:
The downsides of a system breakdown
A thorough system breakdown has many positives to a project, but what are the negatives? It’s important to remember that it won’t solve all the problems that you may be testing for; like we mentioned above, it’s important to remember that usability testing is not included in a system breakdown and must be considered a separate effort. Working in this manner should also require testers to make a conscious effort to consider usability, as it is tempting to focus only on the functionality of the separate components without considering what the users’ experience with the whole product will be. A system breakdown provides a good functional checklist for coverage, but using it as a test plan tends to be really inefficient. This is because it doesn’t account for or address negative test cases, which can be just as important to the testing process as positive ones.
The best way to thoroughly test a system is by creating a comprehensive system breakdown, revising it regularly, and keeping its weaknesses in mind during the entire development and testing process.
This is to say nothing of the fact that simply ensuring the components all work well separately is only half of the effort required in a system breakdown. For example, let a car represent a system under test: the system breakdown ensures that the fuel pump works as it’s supposed to, but not that it’s connected to the engine properly. It can still work in and of itself, but if it’s connected in reverse, the engine still isn’t going to work properly. This is why integration is so important. Integration happens across existing connections, finding problems that might otherwise fall under the testers’ radar until the very end of the testing process, when the system is malfunctioning and nobody can figure out why.
This process is deceptively simple for so important a step. It goes something like this: two components are tested separately, and then together. The trick is to make sure that the connections between the two components are as few as possible, and that those which are present are as simple as possible. That way, it’s unlikely that errors within the connection itself are present, and they are, they can be pinpointed earlier on and much more easily.
To wrap things up…
The system breakdown should be an integral part of the testing process, but instead it’s often neglected – and by “often” we mean “almost always.” It may come across as overly complicated or seem generally unnecessary to some test managers, but its effects on the testing process are incredibly beneficial to both individual testers and the testing effort in general. The best way to thoroughly test a system is by creating a comprehensive system breakdown, revising it regularly, and keeping its weaknesses in mind during the entire development and testing process.