This is a post by Sakshi Dewan, the STC team member. More on her later, let’s see how not to write test cases first!
You must be thinking why a ‘not to’ article when there are a plethora of articles/papers explaining how to write test cases. Probably, your thinking is right. But, after reviewing thousands of test cases written by new and experienced testers alike I felt that there is a need to educate testers on the fine line between excellent and ok test cases. This is necessary as winning projects in testing and carrying out testing successfully is a game of confidence. Every client (how so ever cool he/she might be) will come back to you with more work only if he is confident about your abilities. Writing flawless test cases and including all the necessary test items will build confidence in the clients. They will feel better placed when walkthroughs of test cases are carried. Too many review comments for test case walkthrough’s with clients/stakeholders might be an indication that your relationship with that particular client might not go for too long.
What Is A Test Case?
Nobody is going to stop you and ask hey, quickly tell me what a test case is. But, you must know this or your effort might not yield good results. In very simple language, a test case is an individual set of step by step instructions detailing what is expected from a test case, with expected results defined to aid the tester in test execution. Successful completion of a test case will ensure that a particular part of the requirement is covered successfully.
A Typical Test Case Will Have The Below Attributes:
| Test Suite ID or Test Scenario ID | The superset ID of the test case. |
| Test Case ID | A unique name of the test case. |
| Test Case Summary | A brief one line explaining the test case. |
| Related Requirement ID | Traceability to the requirement covered by this test case. |
| Prerequisites | Any checks which need to be completed before starting execution of test case |
| Test Procedure | Step by step explanation of test case with what to do in each step and an expected result which will determine if a test step can be marked passed or failed. |
| Test Data (Optional) | The test data used while conducting the test. |
| Expected Result | Pre-defined results as understood from AD/FSD or Walkthrough calls with Clients/BA/Developers etc. |
| Actual Result | This column needs to be filled by the tester while executing the test case. |
| Status | If Actual Result matches Expected Result, then the test is passed else failed. |
| Remarks (Optional) | Any comments |
| Created By | The name of the author of the test case. |
| Date of Creation | Author name |
| Executed By | Name of tester executing test. |
| Date of Execution | The date on which test was executed. |
| Test Environment | The environment name and attributes. |
Here is an excel & word test case format: Download Sample Test Case Format
How Not To Write A Test Case (Important Don’t Point In Test Case Writing):
What are the important don’t your test suite need to pass through in order to impress clients :
1. Do Not Write One Test Case Covering More Than One Independent Sub-Functionality: Many testers feel it inappropriate to write multiple test cases, instead, they will couple more than one requirement in one test case and save lots of effort. What they do not realize at that point is that by doing this they are increasing their own testing work. Let me explain, while regression testing, a tester will have to pick that test case and execute all the sub functionalities even if the defect does not affect any area. This will lead to the unnecessary effort which can be avoided by breaking down requirements into single independent testable units. This is also termed as making test cases ‘atomic’
2. Don’t Eat Steps: I have observed that while writing test cases, many testers eat steps which they consider are too obvious to write, especially the initial few steps where users are taken to the concerned screen from the start of an application under test. These are the same testers who gasp for fresh air when they are retesting defect fixes or carrying out regression. They sit and wonder, how on earth to reach to that particular screen.
3. Do Not Just Write Test Cases For Positive Scenarios: A developer codes to make a program work and not to make a program fail. While testing an application, no matter at what stage we are we should include a sufficient number of negative test cases. This will prove that not only does our application work as expected, but its behavior is monitored and tested ok when the user enters values that our application never expects or is not made for.
4. Don’t Write The Test Steps In Very Tough Language And Confuse The Other Testers: Your English language skills should be used to write test cases in the most simple, lucid language possible. By using tough English a tester might be causing hindrance to his own team.
5. Don’t Use Passive Voice: Use of active voice ‘Do this’ or ‘Run xyz command’ is recommended while writing a test case.
6. Don’t Be Ambiguous While Writing Test Case: One of the factors which differentiate a good test case from an excellent test case is the use of exact job names, file locations, etc. If a tester uses exact correct attributes then even a novice can execute it without any help.
7. Don’t Include Unnecessary Steps: If a test case can be completed in two steps, so be it. As a tester do not think that it will reduce the complexity of the test case and justify yourself by adding more irrelevant steps.
8. Don’t Write Test Cases Which Cannot Be Reused
9. Don’t Write Test Cases Which Are Not Traceable: Believe it or not, but traceability is a very big responsibility that lies entirely with the testing team. No one is going to help you in choosing the test cases which need to be executed around a defect fix. And believe me, when I say this, I have seen many experienced testers committing this blunder unknowingly only to regret later. Traceability is a very easy mapping of test cases back to the requirements. In some test management tools, this mapping can be done by default. In others, you might have to manually set up traceability. If in case, you are not using any test management tools, a simple excel spreadsheet can be used to establish traceability.
10. Don’t Write Test Case Without Any Focus: A test case summary should tell the tester what is intended in the test. It should neither be too technical nor be too non-methodological. It should be focused on the ultimate goal. In other words, the tester should write a test case summary keeping the test purpose in mind. A test case written to test a positive login attempt should not have a test case summary like ‘To verify the login functionality of the xyz application’. I agree that your main motive is to test the login functionality and it’s the test case summary which should be concise and short. But, just writing a vague test login functionality of xyz will be too generic a statement. There might be many roles of users logging into our application. There might be different kinds of login to our application. E.g. in an ecom application there are separate login screens for prospective customers, admin people, and sellers who need access to register their products and track stock/orders. So, a more apt test case summary can be ‘. To verify the login for a customer in xyz application’ or ‘ To verify login of a seller in xyz application’. Don’t you think the welcome screen shown to a prospective customer should be very different from the welcome screen shown to a seller?
11. Don’t Write Test Cases Such That They Are Not Maintainable: Consider a scenario where the requirement change after completion of test case writing. The tester should be able to effortlessly amend the affected test cases. The change request will probably have the affected requirements and tester should be able to trace back the requirements to the test cases if, test cases are uniquely defined and they are traceable.
12. Don’t Just Write Test Cases, Think If There Is Anything Required For Execution: Test cases are generally written in the initial phases when the application is not yet ready and testers have the FSD (functional specification document) to base their test cases on. Many test teams just write test cases blindly only to find at the time of execution that the test data relevant to the test case does not exist in the system and needs to be created. To avoid this mess, it is highly recommended and appreciable if the test team dwells some though on the practical aspects and what data/conditions will be required to run this test case while execution. Obviously, if you are writing a test case chances are that you are going to execute it. By following this approach test team can regulate the test data creation and request environment teams to ensure that such data is already present when they hand over the environment to the test team.
13. Don’t Just Stop At Creating Test Suite And Getting It Signed Off: You need to version the test suite and baseline it for a version of the application under test. Change is the only constant; tomorrow in case your application undergoes any changes, howsoever big or small, instead of updating your test suite, update the version and get it baseline for that version of the application. Keep all the previous test case versions in your repository.
You may be interested in reading » How to Write Good Test Cases?
About Author:
This article “How Not To Write Test Cases” is written by STC team member Sakshi Dewan. She’s always happy to share her passion for Software Testing related articles at Software Testing Class. She worked on various popular domains like Banking, ECommerce, SAAS etc.
If you still have any questions about how not to write test cases, feel free to share your queries in the comments below.
⇓ Subscribe Us ⇓
If you are not regular reader of this website then highly recommends you to Sign up for our free email newsletter!! Sign up just providing your email address below:
Happy Testing!!!