My understanding about the Test Case is, a set of instructions to perform test on software. In test cases, we write the instructions how to perform a test, what to look for, how/what to expect as result depending on different combination of input. In a Test Case we breakdown the software functions into small units, that can be tested with different input, and compare the produced output with the expected output[3]. In short Test Case Document is about checking with
“Known Input, Expected Output (according to conditions)”.It is the guide for the test engineers who can perform the test just following the instructions. It’s not a rigid document. It’s open subject to changes on software version/ features/ product/ project. Very few things can be as highly important as this Test Case documentation in our Software Development Life Cycle / Software Test Life Cycle. Writing a good Test Case is really important than just writing the Test Cases. This is the document of all the test ideas, scenarios.
In this write up I'll be trying to point out things that will help to improve writing Test Cases. It's not about any Template or format of Test Case. There are few article that I found very appropriate for this topic. If interested you can read their article as well, all mentioned in the sources.
1. Enthusiastic Mind Set [1]- Before starting to write Test Cases, you will have to have a good enthusiastic mind set. Testing should not be considered as lower level job then the development. Might wonder what would be the relationship between the mind set and Test Case writing? I felt it from my experience, it plays vital role writing test cases. It will open up the boundaries’ that usually we the testers get from different level/ circumstances. It will let you open up your mind to think about "unrealistic" scenarios. When we report those unrealistic scenarios, usually we get demotivating reactions from the concerned people, but when user reports the same we get the heat. So, to keep yourself motivated in testing, mind set, what I felt, is the first thing to consider.
Clinton Staley [1], PhD, Professor of University of California, wrote in one of his writing about this-
“Good testers see testing as an art, and they’re right. They’re very enthusiastic about finding bugs. An SQA group with good morale will be found on lunch breaks bragging about the clever way they made an application fail this morning and how upset the developers were over the rough treatment given to their baby.”
He also mentioned,
“Good SQA people like breaking code. They’re creative, even devious, in finding ways to do so. And that’s good, because the kind of bugs that make it into the testing phase of software development are devious and deep, and they take organization and focused creativity to uncover.”2. Study about the Project/ Product's. Gather knowledge about your target software. Study the functional specs, Use cases and Business document. It's equally important to know the business application of the software. Feel free to Raise the Questions about the functional specs. From my experience what I have seen is, most of the time specs does not cover all the possible scenarios and thus lives some gray area which leads to some unpleasant conversation with developers/ leads. So, clear it up first.
3. Organize your Test Case. Like any other document, you need to plan how you will organize your test plan. It can be done Following a Sequence on screen, could be done with some simple part, could be done by functionality. Whatever method you follow it should be easy to follow/ relate with the screen/ functional steps. Order the functionalists, write the test case accordingly. Better not to mix up functional test cases with non-functional test cases.
4. Elaborate the Test Activities. Instead of writing some brief instruction, try to elaborate the steps. For example, "Check the Name field, should work accordingly" does not give clear idea what to do with it. If we can guide it with what test to perform, what test data set to use, would help and save time. Mention methods that you going to perform, like, equivalence classes portioning, boundary value analysis, normal and abnormal conditions etc [3].
5. Modularize Test Cases. Instead of repeating the same task several times in different scenarios, modulerize the test cases, i.e. create common Test Cases that can be used as a sub test case in different places. Just like the methods/ functions that developers write to organize their code. If I need to test some common field, I usually create a common test case that will use different data sets based on the type of the field. For example, if I need to test a Name field which is a Text field type, I create a common Test case that will cover different combination on that field - Max/ Min length checking, blank, LTrim, RTrim, CAP sensitivity, valid input, invalid input set etc.
6. Preparing Test Data [1], [2]. As a part of writing test case, when you are thinking of certain combination, you should start creating the test data set for that scenario and link the test data with the test case/ test case steps. This saves a big time and effort later.
7. Avoid any Assumption. Something that I learned and I give importance to it is not to Assume anything while writing the Test Case. Like I said before, if anything is not clear, raise flag, ask question, know it well. Write the test cases referring to Specs. If circumstances does not favor at all, then at least, mention the limitation of the test cases in clear so that anyone can understand. For example, usually now a days, storage capacity is not a issue for devices/ software applications. We should not just assume it that application will never run of storage space. We should have a Test Case that would check such scenarios no matter whether it happens in real world or not.
8. Write the Testing Cases first and then execute it. Think about all the possible combinations that you can think of by looking at the UI/ Use Cases/ Specs. There could few things that was missed during writing the Test Case document, like I said before, it's not a rigid document, should be updated periodically, if necessary. If you start performing a test without writing it at the first place, from my experience I can tell you there is a great chance you will forget it. (May not be a Agile Approach, but at least I would not use it as excuse). Writing the ideas on the test case will make it less dependent on particular person. It helps for the Tester as well as the company.
Tried to write down the ideas that I learned from my experience. I'm sure I haven't seen all of them, but at least, for the time being, by following the above helps me to write an effective Test Case that will be easily understandable to all. Some people may feel in-secured documenting all the techniques that s/he applies for testing, finding issue, which is not unusual. Think about it in this way, if you have everything written down then you won't have to worry about any steps that you missed or not. Also remember, our own memory can betray with us at any moment. If you are good at something, no matter how many places you wrote it down, nobody can do things like you do. Don't feel in-secured.
Have Fun Testing!!!!
Sources:
[1]. Writing Effective Test Cases, by Clinton University
of California , Santa Barbara
