- April 8, 2016
- Posted by: admin
- Category: Testing
In my testing experience, there are quite a few new learnings which I have implemented successfully. I plan to write some of that here and hopefully, it proves useful to you too.
First and foremost, a test case need not have lots of details. A test case is not meant to confuse the user, it is meant to help the user to ensure that the system satisfies the requirements of the client. In the testing world, we follow a basic principle; ‘KISS’. No, this is not the one that you are thinking. This one is simpler: ‘Keep it simple & short’. Now, let us get down to the nitty-gritties.
The most perfect of the perfect test cases is the one which has each and every detail captured in about 100 columns. No, I am just kidding. Writing test cases don’t mean that the test case should have numerous columns to include all the details about a particular scenario. If the description explains the scenario crisply, it is sufficient.
1. Business analysis
‘Who’ are the target customers?
‘Which’ are the main modules impacting business?
2. Requirement analysis
Out of box thinking will help you to have a wide vision about the business. So, it would be easy for you to create use cases.
1. Analyze and identify the core module, having a lot of inter-related functionality & business value
2. Gather all possible positive flows & negative flows of each module
3. Analyze boundary values of each module
4. Analyze worst case scenarios also
And then we crafters start crafting the sculpture starting with a case ID for each.
3. Consistent naming of test cases (Test case ID)
Prefix TC_Module name_Unique ID
Test case Id should have the prefix as ‘TC’ followed by the module name to be tested & then finally suffixed with a unique Id.
For ex, TC_REG_001
We then move the mouse to the next column ‘module name’.
4. Name your module
Naming is an art. You name your new born child with something which you deem appropriate to them, not something like ‘sulphuric acid’ etc. Similarly, the module name should be appropriate. If the module is about managing customer details, then name the module as ‘Manage customers’. We have named the child. Next, we describe eloquent about the child.
5. Test scenario/Objective
Why is a particular component tested?
The test scenario/objective column should be a one liner which, crisply says “Why is a particular component tested”.
For example, ‘Password’ field in ‘Registration’ form. Here the ‘Component’ is ‘Password’ field & the one liner is ‘To check password field for boundary values’ i.e., what would be the minimum & maximum character limitation to set the password. So, this one liner will help us to get to know the aspects tested in this particular component “Password” field.
6. What are the components?
The ‘field’ column will help us to track, what ‘Kind of component’ it is; whether it is a ‘List box/Text box/Check box’ & so on. This may look unnecessary but it is critical. Let me share my experience on an issue that I faced & the resolution for it. When I was working in a project, one of my clients was changing the component ‘Country’ often in the form.
Client: Hey, have ‘country’ field as a text box.
Me: Ok Sir.
Client: Hey no, have the ‘country’ field as a list box.
Me: Ok Sir.
Client: Hey, I insisted to have ‘Country’ field as ‘Text box’ but you guys have added a ‘List box’
Me: Whattttt???? Please give some time. I will review and get back.
Thank god! We had the field tab in our test case.
Me: Boss, Please refer TC_REG_001. We have mentioned it clearly as a list box in the approved test case
Client: Well, You are right.
7. Precondition & Assumptions
Preconditions & assumptions column will explain ‘Yes’ or ‘No’ flow of the test cases. For ex, let’s assume a ‘Wedding planner’ website & 2 types of members are involved in the site. One is ‘VIP member’ & another one is ‘Member’. ‘VIP member’ will have access to 16 tabs in dashboard & ‘Member’ will have access to 12 tabs in dashboard.
Now the ‘Precondition’ here is, whether he/she is a ‘VIP member or ‘Member’ which paves the way for ‘Yes/No’ situation’. And the assumption is, Yes he/she is a ‘VIP member’. So, he/she will have access to 16 tabs in dashboard. Hope you guys understand the difference between ‘precondition’ & ‘assumption’.
8. Test data
This is the most important column, to help us get to know ‘what’ the test data used to test a component is. Most of the times, we testers bang our head when a scenario fails. It takes time to analyze, ‘What’ kind of data made the scenario to fail? So, it is better to have separate column as ‘Test data’. For ex, let’s assume ‘Mobile’ field as component & check what happens if the test data is ‘Alpha numeric’.
9. Expected behavior
The expected behavior column should clearly define ‘What would happen next on performing particular action’. Hurray!!! We have successfully done a legible test case. Three cheers to us. Now let us go test and take more life out of the developers.