8 Tips To Create Complete Test Cases

How can you explain to a beginner tester the idea of writing, executing and reporting of test cases? It’s a tough job, I found this quite recently by training a new person in the team. Everything I had in my head but there was not one clear and consistent explanation on the paper. Many years of experience, unfortunately, has not helped me to verbally justify and explain this issue. This post will be an attempt to complete my own thoughts and these coming from the environment.

For beginning, a few sentence to clarify what are the test cases and test scenarios and how they are different and in what order must exist. Starting from the end, let us answer the question “why?”. Test case is a description, a recipe for tester, dealing with how to test a given functionality and how to check whether this works correctly. Looking at the structure, we can identify types of relationship: Test scenario -> test case -> Test Step. Starting from the end again, because it will be easier, I can write:

• Test Step – specifies an action to perform, and the expected response of the test application. For example: Action : Type the password in the password box, Expected result: Your password should be dotted / hidden.
• Test Case – a list of test steps. Also defines the environmental situation and may link to related bugs, requirements etc.
• Test Scenario – usually comes directly from business requirements or userstory. Management tools often ignore test scenario for linkage with a list of the requirements. Scenario contains a list of test cases and often their sequence.

As you can see, varies between a test case scenario is significant, and often the two concepts are confused.
How to ensure the quality of the test cases are created? How to manage their life cycle? How to deliver them quickly and when developers need it ?

1. Template – need one and complete template for creating test cases. We can create it in a text editor, spreadsheet or buy or customize the tool. I have written about this in the context of the JIRA.

2. Descriptive and specific – you need a short, concise title and description. Should clearly define the purpose and scope of their operations. We are writing to all testers, not only for yourself, use simple language, complicated language figures are not popular here. Use rather imperative, therefore “Write abc and press enter” not “I am writing abc, and pressing Enter.”

3. Reusable – one and the same test case can be used in many scenarios. Let us remember that! Creating a new item, we must imagine a different kind of use case of our work. I also imagine that test step could be reused, so pay your attention at this level too.

4. Atomic – the greatest tester nightmare struggled with the manual testing is a test case, which is too long and doing too much dependency checks. Person carrying out a process must have a sense of progress, otherwise is bored, reducing its vigilance, and motivation. Tester may have to perform 100 test cases and do them in one day, but it can also have their 10 and do it for a week. Let us create test case, which can be performed up to several minutes, and gain the favor of the other fellow testers, among the satisfied, we can also include those who write automation scripts.

5. Positive and negative – the next important thing is the order of creation. What to do when the project manager requests a set of test cases on the day following approval of an implementation plan? Usually we do not say that he wanted only the beginning of positive tests, those which check whether the functionality exists and acts in accordance with the requirement. Give him as  such set as soon as possible, then we can deal with the preparation of a negative description situation and the relationship between other requirements. To sum up: Positive -> Negative -> Relationships

6. Refactor – if you already done your job we have to remember that applications are changing and the changes in the test cases should follow this process. We can version it, using clone and change method for a given version number. Head of the tests should determine how many past versions we support and we should care enough about our current collection of test cases.

7. Test data – there are moments in which along the correct execution of the test we have to provide some data, which usually (if they are too complex to be described in the text) are attached as binary files. We need to analyze whether it is easier to provide test data or may be easier to add the appropriate test steps.

8. Setup and tear down – if the test case requires the initial configuration, call a particular component, we need to take this into account in the zero step. It is also important to cleanup in the last step like in unit testing or automation, but I believe that during the test manual is worth to preserve this good practice.

Summary
Take to heart my observations if you do not agree write a comment. Perhaps I skipped something, if I drop what I will do an update. At this moment it appears as a complete manual. I promise that soon we will put post in which I will describe exactly the structure of the template test case.