This article isn’t only going to cover Test Cases Vs Test Scenarios but it will cover following:

• Real Time Examples
• Conditions for Documenting Test Cases
• Test Case And Test Scenario Example
• Difference Between Test Cases And Test Scenarios
• Conclusion of this Post

Few years back, when I was working in an MNC and dealing with a testing project, I suggested my colleagues to document the test Scenarios instead of test cases. Can you imagine, their reaction amazed me as they all were staring at me all together, I could not argue. It was like I have made a big mistake in my life. Everyone’s opinion was same except mine. They prefer to follow the traditional method of writing Test Cases and not Test Scenarios. Those who are newbies in this field might get confuse with the word Test Scenarios and Test Cases. This article will clear all doubts about it by giving real time examples and explanation.

Few years later, I Switched to another company and handled a testing project which was based on searching and generating different reports with the help of different menu options. We in a team were discussing about the project and how we can proceed with that? Actually, client wanted that project early and we were having deadline to complete the project. Considering my last experience about suggesting the documentation of Test Scenarios, I kept quiet and thinking of other idea. Suddenly, one of my colleagues raised his voice that “We should prepare Test Scenarios in a document”. This time, everyone was quite satisfied with his idea and we further started preparing the Test Scenarios. The conclusion of both cases suggests that preparing the Test Scenarios and Test Cases depends on the urgency and requirement of the project. Generally, in companies, test cases are prepared rather than documenting test scenarios.

Test Cases are replaced with Test Scenarios

As we all know nothing is permanent and with this concept, the software industries and their processes are also changing with time and cost constrains.

V-models and waterfall models which are considered to be traditional models are being replaced by iterative and agile models. In every testing project, document is indeed essential but to complete the project fast within the deadline and to make the process transparent and easy, the way of documentation is changed these days.

Following conditions are applicable for documenting Test Cases:

1. Client may ask for the same as part of his project
2. No Time constrain(But, I don’t think, it’s possible)
3. When software testers are fresher and new to the product.
4. When there is Company policy (I strongly have faith that it can be altered)

One of my experience will give you clear picture.

I was handling one of the testing projects from fortune 500 company and they didn’t give us any deadline to complete the project. That mean we were having flexible timelines to complete the project. We were already having template of test cases, and with the help of that we prepared the test cases and it got approved from client as well.

Once the development team finished their module, they were giving us to test it and most of our duty was to follow 100 test cases in a day. We used to document with pass/fail result, further sending it to the client at the end of the day. The project was really big and had different modules within it. To do the same process of documenting the test cases was a monotonous work for some of my colleagues. But at the end of the day, the company was generating revenue from it.

During the project, we had one break where we were not having any task of documenting the test cases. We were having a good time and I was discussing about new ideas and techniques so as make improvement in the existing test cases. I have found during that discussion that none of my colleague was interested in implementing those new ideas and techniques as they thought all the test scenarios is been covered already while making huge amount of test cases. No one was really interested in putting the efforts for new techniques as it a human mentality that we do not want to rework once the work is done. Our mind automatically stops making any efforts for any new ways and techniques for the past work. Same had happened with my colleagues and they just wanted to relax on that certain day.

It is also a fact that in IT companies, most of the testers follow the mechanical process of making the test case and no one really makes effort to make additional test case for the existing one? The same might have also happened with you, if I am not wrong.

Another experience:

While extensively involved in a team challenge activity, we were having a discussion and asked the team members to prepare the test scenarios for the product. We have all started to make the test scenarios and there was not a specific document where we would literally fill expected result and pre-condition for each test case. At the end of the day, we have collected almost 50 test scenarios and it was indeed a great experience while proceeding with that project.

Below example will make picture more clear:

Assume that you are having your website and it has features like username, password, and login page along with cancel button. If you were asked to write the test cases for the above features then your test case may exceed 50 and if you would ask to write the test scenarios, then it will be just a matter of lines. Below explanation will give you the exact idea about test scenario.

High Level Scenario:   Login Functionality
Low Level Scenarios:

1. To check Application is Launching
   2. To check contents text on login page
   3. To check Username field
   4. To check Password field
   5. To check cancel button and Login Button functionality

As we all are at short of time, test scenarios just acts as pain killer spray rather than that old time IODEX. And still the effect is same in both the case.

Finally, I would like to summarize difference as below:

	Test Cases	Test Scenarios
What it is =>	A concept which offers complete info what to test, steps to be taken and expected result of the same	A concept which offers one-line info about what to test.
It’s about =>	It’s more about documenting particulars.	It’s more about rational and conversing particulars.
Importance =>	It’s significant when testing is off shored and development is onsite. Writing test cases with particulars will aid both dev and QA team in sync.	It’s significant when time is less and most of the team members can agree / appreciate the details from one-liner scenario.
Advantage =>	One time documentation of all the test cases is helpful to track 1000s rounds of regression testing in future. Most of the time, it is helpful while bug reporting. Tester just need to give reference of test case ID and does not require mentioning each and every minute detail.	A time saver and idea generation activity, favoured by new generation software testing community. Modification and addition is simple and not specific to a person. For a huge project, where group of people know specific modules only, this activity gives a chance to everybody to look into other modules and brain storm and deliberate.
Beneficial to =>	A full-proof test case document is a life line for new tester.	Good test coverage can be attained by dividing application in test scenarios and it decreases repeatability and complexity of product
Disadvantage =>	Time and money consuming as it requires more resources to detail out everything about what to test and how to test	If created by exact person, the reviewer or the other user might not sync the precise idea behind it. Need more discussions and team efforts.

Conclusion of this Post:

Test cases are most significant part of Software Testing Life Cycle which is also referred as STLC. With its absence, it’s tough to understand, track, follow and reason out something. But in the era of Agile, test cases are being substituted fast with test scenarios.

Database testing, GUI testing, functionality testing has the common test checklist which is coupled with modern artillery and test scenarios. With participation in trainings, Discussions, questions and practice one can definitely learn and change the final graph of Bug report matrix and your productivity.

Latest Posts