The current situation has verified our pursuit of the desire to possess an excess of material goods. Nevertheless, the minimalism trend is invariably an oasis of respite from constant “more”. As a supporter of the idea of living well enough and having as much as we need, I began to wonder if I could also apply minimalism in my professional life. I think it can bring a lot of benefits. But is minimalism in testing for everyone?
One of the basic test activities is creating test cases based on the defined requirements for the software developed. According to the definition, a test case is “a set of input data, initial performance conditions, expected results and final performance conditions, developed to verify the compliance of the program with the expected result or to check test conditions”.
Test cases can be general or more specific.
High-level test cases are created without specific input values or expected results. They are usually used when expected values are not yet available to the tester at the creation stage or the requirements are undefined or given in a general way. They are also useful when there is an experienced tester in a team who wants to retain freedom in performing tests, as they enable more creativity, which also ensures greater coverage.
Low-level test cases always contain specific input values and expected results. It is better to use this type of test case when the tester is inexperienced, or when tests are performed by an expert in a given field, who knows the system perfectly but has no knowledge in the field of software testing. In addition, low-level test cases are ideal when the testing process goes through an external verification, such as an audit.
What does the test case consist of?
The classic test case should contain the following individual components:
- identifier (ID) – this is nothing more than a unique case designation, so that you can get back to it, if necessary,
- purpose – describes the reason for creating and conducting the test,
- prerequisites – they describe the criteria to be met by the environment and the system before the test can be performed,
- test data (for low-level cases),
- the expected result,
- initial conditions – the state of the environment or system after performing the test.
Sometimes, providing all of these components and including them in one test case can be a challenge for the tester, especially if he also takes care of preparing the test data for later test cases. All these activities can take a long time. We all know that nowadays time is money, so in this sense, the creation of test cases can be seen as a waste. So how to apply the idea of “zero waste” in testing? How to create test cases that will be of good quality, but which will not take a long time to prepare?
Tests: is less really more?
How can we make sure we only have what we need most, and distinguish between a “need” and a “whim”? The concept of minimalism helps here. In terms of testing, we can try to extract only those components of a classic test case that are most necessary in order to perform the test. In my view, only components such as the identifier and the expected result would remain from the abovementioned components. Why? The identifier is usually a number – but sometimes it can also be a title – which we use to get back to a given case in order to work on it once again or to do maintenance. However, the most vital part of the test case is the expected test result. Knowing the result that the test would give, we are able to say clearly whether the performance of the software after a correctly performed test is an error or not, and report it in order to improve it.
How to quickly create high-level cases?
By using only the identifier and the expected result, you can quickly create high-level test cases that do not contain unnecessary details. Preparing them takes much less time, because we do not provide all the detailed data. This type of test case can be written in any form as long as the project requirements allow it.
A very quick and effective way to write such test cases is to create a mind map which works great in these circumstances. In addition, the mind map method stimulates creativity, which is very important in the work of a tester. So it can bring an additional benefit in the form of varied and better-quality test cases than those written in traditional ways.
All kinds of checklists are another way to quickly list high-level cases. This checklist is one of the most important tools in the work of a tester. The strength of the list lies in simplicity, because all you need to create it is a pen and paper. It can cover all types of tests, from requirements tests to acceptance tests. We just need to remember to include only the most important test cases on the checklist. According to the idea of minimalism, the checklist is supposed to protect us from doing more than is necessary. Herein lies the temptation when it comes to limiting the time spent on preparing test cases: why not go one step further and not prepare them at all?
Projects carried out according to Agile methodologies are an ideal field for the above-mentioned experiment. When a tester is involved in the process of creating acceptance criteria for a given task from the very beginning, he is able to carry out tests based on those criteria. Admittedly, testing based on acceptance criteria is characterized by the fact that the criteria should be met unconditionally, and real tests only start later, but an experienced tester can easily provide test coverage for alternative paths than those described in the acceptance criteria, and thereby check different scenarios, not only those described in the requirements. However, in order to be able to afford such minimalism in testing, the tester should already have a lot of experience from various projects, as well as a well-developed tester’s sense. Otherwise, there is a big risk that the task will not be covered by a sufficient number of tests, and therefore the quality of the software may be lower. But is minimalism in testing for everyone?
Is minimalism in testing for everyone?
The last sentences of the previous paragraph seem to be the key to answering this question. Testing without test cases, and based on acceptance criteria or using high-level cases, is extremely risky. This calls for extensive testing experience. Such minimalist test practices require intimate knowledge of software testing, solid knowledge of the product being tested, its characteristics, vulnerabilities and critical paths for users. Otherwise, minimalism can do more harm than good. This does not mean, however, that I want to discourage you from experimenting with minimalism at work – quite the opposite! It’s good to get out of your comfort zone from time to time and try to intentionally limit your needs. Just to see if you really need so much. Often it turns out that you don’t. But try it and see for yourself!