How to write a complete Test case

How to write a complete Test case? Following are few tips to write a complete test case.

For begining, 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.