Test Cases Writing Tips:
One of the most frequent and major activities of a Software Tester (SQA/SQC person) is to write Test Cases. First of all, kindly keep in mind that all this discussion is about ‘Writing Test Cases’ not about designing/defining/identifying TCs.
There are some important and critical factors related to this major activity.
Let us have a bird’s eye view of those factors first.
What You Will Learn:
a) Test Cases are prone to regular revision and update:
We live in a continuously changing world and the same holds good for software as well. Software requirements change directly impact the test cases. Whenever requirements are altered, TCs need to be updated.
Yet, it is not only the change in the requirement that may cause revision and update of TCs. During the execution of TCs, many ideas arise in the mind and many sub-conditions of a single TC may be identified. All this causes an update of TCs and sometimes the even addition of new TCs. Moreover, during regression testing, several fixes and/or ripples demand revised or new TCs.
b) Test Cases are prone to distribution among the testers who will execute these:
Of course, there is hardly such situation in which a single tester executes all the TCs. Normally, there are several testers who test different modules of a single application. So the TCs are divided among the testers according to their owned areas of an application under test. Some TCs which are related to the integration of application may be executed by multiple testers while other TCs may be executed only by a single tester.
c) Test Cases are prone to clustering and batching:
It is normal and common that TCs belonging to a single test scenario usually demand their execution in some specific sequence or in the form of group. There may certain pre-requisites of a TC which demand the execution other TCs before running itself. Similarly, as per the business logic of the AUT, a single TC may contribute in several test conditions and a single test condition may consist of multiple TCs.
d) Test Cases have a tendency of inter-dependence:
This is also an interesting and important behavior of TCs that they can be interdependent on each other. In the medium to large applications with complex business logic, this tendency is more visible.
The clearest area of any application where this behavior can definitely be observed is the interoperability between different modules of same or even different applications. Simply speaking, wherever the different modules a single application or multiple applications are interdependent, the same behavior is reflected in the TCs.
e) Test Cases are prone to distribution among developers (especially in TC driven development environment):
An important fact about TCs is that these are not only to be utilized by the testers. In the normal case, when a bug is under fix by the developers, they are indirectly using the TC to fix the issue. Similarly, if the test driven development is followed, then TCs are directly used by the developers to build their logic and cover all scenarios in their code which are addressed by TCs.
So, keeping the above 5 factors in mind, Here are some tips to write test cases:
This statement seems a paradox. But, I promise it is not so. Keep all the steps of TCs atomic and precise. Mention the steps with correct sequence and with correct mapping to expected results. The test case should be self-explanatory and easy to understand. This is what I mean to make it simple.
Now, making it complex means to make it integrated with the Test Plan and other TCs. Refer to other TCs, relevant artifacts, GUIs etc. where and when required. But, do this in a balanced way. Do not make a tester to move to and fro in the pile of documents for completing single test scenario. On the other hand, do not even let the tester document these TCs in very compact manner. While writing TCs, always remember that you or someone else will have to revise and update these.
Never think that the job is done once you have written the last TC of the test scenario. Go to the start and review all the TCs once, but not with the mind of TC writer or Testing Planner. Review all TCs with the mind of a tester. Think rationally and try to dry run your TCs. Evaluate that all the Steps you have mentioned are clearly understandable and the expected results are in harmony with those steps.
Ensure that the test data specified in TCs is feasible not only for actual testers but is according to the real-time environment too. Ensure that there is no dependency conflict among TCs and verify that all references to other TCs/artifacts/GUIs are accurate. Testers may be in great trouble otherwise.
Do not leave test data on testers. Give them a range of inputs especially where calculations are to be performed or application’s behavior is dependent on inputs. You can let them decide the test data item values but never give them liberty to choose the test data items themselves. Because, intentionally or unintentionally, they may use same test data again & again and some important test data may be ignored during the execution of TCs.
Keep the testers at ease by organizing TCs per the testing categories and related areas of application. Clearly, instruct and mention which TCs are inter-dependent and/or batched. Similarly, explicitly indicate which TCs are independent and isolated so that tester may manage his overall activity accordingly.
At this point, you might be interested to read about boundary value analysis which is a test case design strategy used in black box testing. Click here to know more about it.
Never accept the FS or Design Document as it is. Your job is not just to go through the FS and identifying the Test Scenarios. Being a QA resource, never hesitate to contribute to business and give suggestions if you feel that something can be improved in the application. Suggest to developers too, especially in TC-driven development environment. Suggest the drop-down lists, calendar controls, selection-list, group radio buttons, more meaningful messages, cautions, prompts, improvements related to usability, etc.
Suggest to developers too, especially in TC-driven development environment. Suggest the drop-down lists, calendar controls, selection-list, group radio buttons, more meaningful messages, cautions, prompts, improvements related to usability, etc.
Being a QA, don’t just test but make a difference!
The most important stakeholder is the ‘End User’ who will finally use the application. So, never forget him at any stage of TCs writing. In fact, End User should not be ignored at any stage throughout the SDLC. Yet, my emphasis so far is just related to my topic. So, during the identification of test scenarios, never overlook those cases which will be mostly used by the user or the cases which are business critical even if they are less frequently used. Keep yourself in the shoe of End User and then go through all the TCs and judge the practical value of executing all your documented TCs.
So, during the identification of test scenarios, never overlook those cases which will be mostly used by the user or the cases which are business critical even if they are less frequently used. Keep yourself in the shoe of End User and then go through all the TCs and judge the practical value of executing all your documented TCs.
Test Case Writing is an activity which has a solid impact on the whole testing phase. This fact makes the task of documenting TCs very critical and subtle. So, test case writing should be properly planned first and must be done in a well-organized manner. The person who is documenting the TCs must keep in mind that this activity is not for him or her only, but a whole team including other testers and developers, as well as the customers who will be directly and indirectly affected by this work.
So, test case writing should be properly planned first and must be done in a well-organized manner. The person who is documenting the TCs must keep in mind that this activity is not for him or her only, but a whole team including other testers and developers, as well as the customers who will be directly and indirectly affected by this work.
So, the due attention must be paid during this activity. “Test Case Document” must be understandable for all of its users, in an unambiguous way and should be easily maintainable. Moreover, TC document must address all important features and should cover all important logical flows of the AUT with real-time and practically acceptable inputs.
What’s your test cases writing strategy? Share your tips with our readers and also put your queries in comments below.