Articles | January 26, 2023

A minimalist software test case

Do we could also apply minimalism in my professional life? I think it can bring a lot of benefits. But is minimalism in testing for everyone?

A minimalist software test case

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?

What is in a test case?

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”.
The test execution process can include general or more specific tests.

  • High-level test cases

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 software 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

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 software application 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.

BigCTA MarekCzachorowski

Elevate Your Application Development

Our tailored Application Development services meet your unique business needs. Consult with Marek Czachorowski, Head of Data and AI Solutions, for expert guidance.

Schedule a meeting

Who Writes Test Cases?

While the answer to this question may seem obvious, it is not always so. Sometimes these responsibilities are attributed to business analysts.

Analysts write business requirements and stories. Usually, test cases for these requirements are written by testers. In the agile methodology, everyone has their own responsibilities, and analysts can also write scenarios and test cases on which the testing team works during the sprint. Once the development work is complete and ready for QA, testers execute the test cases and move the story to „DONE” based on the results of the test case. So, Test Cases is written by Testers.

Read also: Continuous testing: get started with shift left testing approach.

What does the test case consist of?

The classic test case should contain the following individual components:

  • identifier (test case 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.

  • Mind maps

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.

  • Checklists

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?

  • Agile methodology

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 test cases, 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?

Test Case Management Tools – Examples

The test management process is critical, detail-oriented and instrumental to ensuring success. Test case management tools can help you manage software and hardware development, organize your scenarios and test cases and build a test plan. Here are a few of them:

  1. JIRA
  2. TestRail
  3. Xray
  4. Zephyr
  5. TestFLO

Different Types of Test Cases

Test cases can measure many different aspects of code. Knowing the differences between them is helpful for qualified specialists in choosing the right test case format. Some common test case examples:

  • Functionality test cases – These are the most basic and standard test cases to write.
  • Unit test cases – Involves analyzing individual units or components of the software to confirm each unit performs as expected.
  • Integration test cases – The main purpose of this particular test case is to confirm that the interfaces between different modules work correctly.
  • Database test cases – These test cases ensure that the database meets its functional and non-functional requirements.
  • User interface (UI) test cases – This type check that each graphical user interface (GUI) element works correctly, displays, and is easy to use.

Read also: Reasons why software testing is important

What is the difference between Test Scenario vs Test Case vs Test Script?

The test scenario is the least detailed test case documentation. Describes the purpose of the user using the program/application. This gives the tester the greatest flexibility.

Test Cases are more specific than scenarios and describe a specific idea that is to be tested, without detailing the exact steps to be taken or data to be used. Test cases give flexibility to the test engineer to decide exactly how they want to complete the test.

A Test Script is the most detailed way to test document. It usually contains „steps” and the expected results of those test steps. The key disadvantage is frequent changes in active projects. To be effective over time, testers must constantly update their scripts to match the new product.

Is minimalism in software 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!

Consult your project directly with a specialist

Book a meeting

Testerka oprogramowania, której główną dewizą w pracy jest „Ufaj, ale sprawdzaj”. Testowanie to dla niej bycie rzetelnym na każdym etapie powstawania oprogramowania, natomiast najważniejszym czynnikiem w zespole jest komunikacja. Od początku swojej kariery związana z testami manualnymi aplikacji webowych, ale po 7 latach nadszedł czas na zmiany, bo pokochała testowanie mobilne i to z nim zamierza spędzić kilka najbliższych lat. Prywatnie pasjonatka motoryzacji i szczęśliwa posiadaczka Hondy CRX z '89 roku.

Exclusive Content Awaits!

Dive deep into our special resources and insights. Subscribe to our newsletter now and stay ahead of the curve.

Information on the processing of personal data

Exclusive Content Awaits!

Dive deep into our special resources and insights. Subscribe to our newsletter now and stay ahead of the curve.

Information on the processing of personal data

Subscribe to our newsletter to unlock this file

Dive deep into our special resources and insights. Subscribe now and stay ahead of the curve – Exclusive Content Awaits

Information on the processing of personal data

Almost There!

We’ve sent a verification email to your address. Please click on the confirmation link inside to enjoy our latest updates.

If there is no message in your inbox within 5 minutes then also check your *spam* folder.

Already Part of the Crew!

Looks like you’re already subscribed to our newsletter. Stay tuned for the latest updates!

Oops, Something Went Wrong!

We encountered an unexpected error while processing your request. Please try again later or contact our support team for assistance.

    Get notified about new articles

    Be a part of something more than just newsletter

    I hereby agree that Inetum Polska Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as: my full name, e-mail address, telephone number and Skype ID/name for commercial purposes.

    I hereby agree that Inetum Polska Sp. z o.o. shall process my personal data (hereinafter ‘personal data’), such as: my full name, e-mail address and telephone number for marketing purposes.

    Read more

    Just one click away!

    We've sent you an email containing a confirmation link. Please open your inbox and finalize your subscription there to receive your e-book copy.

    Note: If you don't see that email in your inbox shortly, check your spam folder.