Introduction

Testing is one of the key steps in the development of a software product. Both while preparing for a banquet (it is necessary to take into account all the dishes) and in order to conduct quality testing, we need to take the main artifacts into account - Software Specification, Test Plan, Test Case, Test suite, Bug reports, and checklists. In this article, we will review one of the main artifacts, which is the test case.

What is the test case?

A test case is a description of the actions that must be performed in order to check if the program is running well or not. Just like any dish includes the main ingredients, the test case mandatorily includes the following attributes:

  • The unique identifier of the test case (it is necessary for convenient storage and navigation).
  • The title is the main topic or the idea of the test case. In one word it is the brief description of the test case.
  • Precondition is a description of conditions that are not directly related to the tested functionality but must be completed.
  • Steps are a description of a sequence of actions that should lead us to the expected result.
  • The expected result is the result that we expect to see after completing those steps.

The Recipe

So, now we know what exactly should be included in our dish (the test case), but what ingredients should we avoid in order not to spoil it?

  1.  Dependence on other test cases. This should be avoided because the adjacent test case can always be removed when it is not needed, or it can be modified, which leads to confusion.
  2.  Unclear wording of steps or expected results. If the description of the steps or the expected results is unclear, then this blocks the passage of the test case.
  3.  Lack of information necessary for the test case to go through. For instance, if we check the login window on the website, then we need the login and password, otherwise, it will be impossible to go further.
  4.  Excessive details. For example, if we are checking the possibility of creating a comment, then it is not worth writing in which corner of the screen the login window should be since in the future it can be moved to another place or deleted.

So, now let's take a look at a properly “prepared” test case:

ID: Test case №1

Title: Creating the resident without the full name

Steps:

1. Go to the website www.dev_test.ua (login - test, password - test).

2. Log in as the administrator (login - admin, password - password).

3. Go to the “Residents” tab.

4. Click the “Create the resident card” button.

5. Click the “Save” button and do not fill in any of the fields.

Expected result: The following message about an error appears- “Please fill in the required fields”.

When should you use our test cases?

Test cases are needed when we work with the following things:

1. Vital systems, an error which can lead to death (aircraft construction, medicine, software for nuclear power plants). You have to test very carefully and thoroughly in these areas.

2. Complex system or a complex part of a system. In order not to ask the following question (How do I do this?) all the time, it is better to write a test case.

3. New workers constantly join your team, and test cases reduce the time to assimilate the product.

4. Functionality testing or, in other words, imitation of a real user.

the advantages and disadvantages of the scenario approach

What can be added to already existing

testing with test cases?

As we already understood, testing with test cases alone is incomplete testing. What can you add to this dish? Exploratory testing, performance testing, UI testing, and many other types can be used to complement it. Exploratory testing can be featured as the main addition. This method isn’t structured in many ways, and it gives a lot of freedom to the tester. Testers can apply an exploratory approach both when developing new tests at the beginning of an iteration and when analyzing tests that have already been completed. Thus, the exploratory approach has many advantages and additions while using it, for example:

1. It gives more freedom to the tester, develops his/her skills. Let him/her work and develop new testing techniques and strategies.

2. All the time needs to be devoted to testing only.

3. The QA tester researches the new software product more deeply and gains its insights.

4. This approach lets you find the major bugs as soon as possible.

5. There are no additional expenses for updating test cases.

Conclusion

This way, the scenario approach in testing is a very delicious dish. However, just like any delicious dish, it is supplemented with sauces, spices, side dishes, and stuff like that, this approach should be supplemented with other types of testing in order to conduct a better and deeper test.