Here at QualiTest, we use system breakdowns for every project. However, for some reason, it seems like this isn’t the norm in the IT industry. Testers and clients alike are often unfamiliar with it; most new testers we hire have never heard of the process, but once we train them on it they admit that it’s one of the best methods for system mapping available.
We aren’t the only ones who know about and use system breakdowns, but it’s still a very small percentage of the industry that do so. Therefore, it’s apparent that the task for teaching the testing industry about this principle has fallen upon us- but don’t worry, we’re up for the challenge. We’ve decided to do a two-part blog series on the topic, discussing system breakdowns, why they should be performed, their positives and negatives, and more. Here’s our answer to the question we keep getting, time and again:
System breakdown is by far the best approach for outlining a system under test, and as said above, it’s one that’s vastly underused and under-discussed. It’s the process of splitting a system into separate blocks and a list of their integrations, which are in turn broken down recursively into smaller and smaller units. These are then tested both on their own and with regard to their integration within the system. The result of the system breakdown is a map of the system’s components from the very broad level to a very specific one, almost down to specific test cases.
System breakdown is by far the best approach for outlining a system under test, and it’s one that’s vastly underused and under-discussed. It’s the process of splitting a system into separate blocks and a list of their integrations, which are in turn broken down recursively into smaller and smaller units.
A system breakdown also is not necessarily a static thing: it is a breathing process, one which can morph and change as the project it relates to does. Sections may need to be added, removed, or connected in new and different ways over the course of the testing and development effort. At the lowest level, the system breakdown can be nothing more than a list of test cases or exploratory test charters.
However, system breakdowns are not only useful from a testing standpoint; they can be equally relevant, perhaps even more so, to development and design staff. The best-case scenario would be for a system breakdown to be provided about 80-90% finished to the testing team by the designers. This aids in breaking down the testing process while still leaving room for the addition of other information gleaned by the testing team.
This is a process that should be done at the beginning of every relevant process ever. It is systematic and methodical, making it easier to divide the work amongst the testers while also providing a more thorough, demonstrative understanding of the system. System breakdowns don’t need to only relate to the testing effort, either; they don’t need to deal simply with modules and features. Other common usages for a system breakdown, aside from the functional testing aspects, could be a breakdown of business processes, testing steps, user data, and more. Any system breakdown can serve as a baseline for defining testing scope and development, from the very first steps of the process onward. It can be used in relation to scripted testing, exploratory testing, and any combination of the two.
The main characteristic of a successful system breakdown is that it is detailed enough to give a microcosmic idea of the system itself, but not so detailed that each individual module takes only a few minutes to run. A good system breakdown will also be totally unambiguous and completely clear; this is indispensable to determining what it covers and what goes where. It’s also helpful for adding new aspects to the systems because, as discussed, it’s a breathing entity; a proper system breakdown means you don’t have to think about where things go.
In this blog post we’ve talked about what system breakdowns are and why they matter, but we’ve only scratched the surface on their importance to the development and testing process. In our next blog, we’ll discuss the downsides of system breakdowns and what to keep in mind when performing your own.
