Testers play arguably one of the most important roles and functions in software life cycle. They are responsible for the quality of the final product. Every software tester needs to be familiar with these three terms: test case, test condition, and test scenario. But what do those terms mean? I’ll try to explain them in detail.
Test case
It’s a set of input data, initial conditions, steps to be taken, and expected results. Test cases are created for a specific purpose or test conditions.
- Input data – a set of input data necessary to execute a test case. Actual input data doesn’t always have to be defined.
- Initial execution conditions – conditions that must be met for a test to be executed properly.
- Test steps – defined and structured actions that must be taken to execute a test case.
- Expected result – the result that should happen after a test case is executed properly. If the value received after the test matches the expected result, we can consider the test case a success. The expected result must be defined before a test. If it’s not clearly specified, an incorrect test result may be misinterpreted as correct.
Depending on an input data type, we can define two types of test cases: high- and low-level.
Low-level test case (detailed)
A test case with defined input values and expected results.
Example based on an app that performs addition:
High-level test case (logical)
A test case without defined input values or expected results. It uses logic operators, but actual values are not defined yet. It’s also known as “abstract test case”.
Example based on an app that performs addition:
High-level conditions give greater freedom, and their execution depends largely on the tester. Two different people can execute the same case and enter different data, so specific results will also differ. It could even be that one person gets an error while the other doesn’t.
Low-level cases are used in automated tests, where actions are 100% repeatable. For manual tests, it’s better to use high-level cases and tap into a tester’s potential.
Test condition
A test condition is an element or event in a module or system that should be verified by one or more test case(s), e.g. a function or transaction.
Example: we are tasked with testing the login feature of a system.
TEST CONDITION
TEST CASES
Test scenario
A test scenario is a document containing a set of test cases (steps) needed to verify whether a system is working properly within a defined scope. Each scenario should reflect a precisely defined functionality. Test scenarios are also known as test scripts or test procedure specifications.
Each test scenario should consist of test scenario identification, a list of preparatory actions, test cases, and final actions.
- Test scenario identification – this section documents such data as: scenario name and ID, scenario description (goals), scenario type (e.g. functional tests, safety tests).
- List of a test scenario’s preparatory actions – a list of all actions that must be completed before starting a test scenario. These preparatory actions may include verifying software installation and configuration, verifying the tools necessary to perform and document tests, or verifying users and their permissions required for testing.
- List of test cases – this section should list, in order, all test cases required to complete a test scenario.
- List of a test scenario’s final actions – a list of all actions that must be performed after completing tests within a scenario. These are required actions without which subsequent scenarios would be impossible to carry out. These can also be actions resulting from safety policies.
Example: we are tasked with testing a new functionality of a system.
TEST SCENARIO
TEST CASES
Above you can find a few examples of test cases, but, of course, you can also test what will happen when you enter too many or invalid characters.
Test cases — what should you pay attention to?
When creating test cases, you want to make sure they fulfil their objectives in the testing process. They should act as benchmarks for software quality and help businesses make decisions about further development of their products. Moreover, test cases should uncover defects and discrepancies in tested systems. Even if no issues are found, it doesn’t mean the cases were constructed incorrectly. You still get information about app quality and adherence to specifications. Having a tester or quality analyst should ensure that cases will effectively uncover defects.
Equivalence class
Equivalence class is a set of data with a similar processing method and characteristics, used to perform a test. Here, you simply need to test if a given method works for several elements within an equivalence class. If it does, you can assume it’s valid. This alleviates us of having to test all elements within a set.
Equivalence classes can be divided into two categories:
- Valid classes – sets of values for which we predict that the software will work correctly.
- Invalid classes – sets of values for which we predict that the software will work incorrectly.
Example: we have a system that only lets people in the 18–110 age group register. We want to test if the validator of this data is working properly. The classes we should look at are values lower than the minimum age (invalid equivalence class): {-5, 0, 17}, values within the allowed age group (valid equivalence class): {20, 44, 78}, and values higher than the maximum age (invalid equivalence class): {120, 200, 10,000}.
Boundary values
Boundary values are values located on the “border” of an equivalence class. There are correct boundary values (within an equivalence class) and incorrect boundary values (outside that class). When designing test cases, make sure to cover both correct and incorrect boundary values. The boundary values technique is easy to use and uncovers many defects. It’s often considered an extension of the equivalence classes technique.
Example: let’s use the system that only lets people in the 18–110 age group register, again. Tested boundary values are: {17, 18, 110, 111}.
Does more mean better?
When testing software, you can’t verify all possible scenarios, so it’s impossible to find all errors. You have to make several important decisions. What should you test? What to omit? What to test first, and what to leave for later? Oftentimes, after an error is fixed, another defect may emerge. You must choose the areas that you really need to focus on. Not all test cases are equally important from the perspective of system quality, time investment, or customer requirements. Using more cases doesn’t mean the app will be tested more thoroughly. You must pay attention to priorities.
Test cases – priorities
When assigning priorities to test cases, think about the area of the app that is most susceptible to errors. With complex functionalities, there is a high probability that fixing one error will uncover more defects. Below I have listed areas most plagued by numerous defects:
- Complex functionalities – this is one of the most common causes of errors. Programmers can’t predict everything as they write code, so they often overlook things when creating complex functionalities.
- Modified or re-written areas – regression tests should be sufficient in those areas, but you should also assign priorities to regression test cases.
- Functionalities created by many people – the more people work on the same project, the harder it is to communicate. Information is often distorted, misinterpreted, or omitted. This can happen with both coding and testing.
- Functionalities created under time pressure – inaccurate time estimates, unforeseen situations, and communication issues cause delays during coding and testing. When a deadline is looming, it’s easy to miss things and make mistakes. Lack of time forces us to bypass our planned course of action and resort to shortcuts. This can cause many defects to be overlooked during testing.
Example: we want to verify the functionality of sending messages in an online messenger.
TEST CASES
Below, you can find an example of two test cases verifying the functionality of sending messages in an online messenger. The first case has higher priority, as sending text messages is a fundamental need for end-users wanting to use the messenger. Inserting emoticons is an additional “gimmick”, so it can be checked later.
Test cases and tools
Before creating test cases, you should think about the tools to be used. There are multiple apps on the market for streamlining the testing process, e.g. TestLink or Targetprocess. In my opinion, a spreadsheet can be equally useful. Cases and scenarios organised in tables are clear and easily accessible.
Designing test cases results in the systematisation of tester’s work, but it is not obligatory. This very much depends on the actual company the tester works for. Some companies require extensive test documentation, while others find it expendable. Nonetheless, I think that test cases should primarily help testers verify software correctness. Test cases remind us about the priorities, which is crucial during tests and useful when we are running out of the time allocated for conducting tests. Also, while designing test cases, you should keep in mind that we are not able to cover 100% of a given functionality, as even the best tester won’t predict all the possibilities. Similarly, it is impossible to pinpoint each and every error in the system. That said, you should strive to uncover all critical errors, though.
