Difference Between Test Scenario Vs Test Case.
6 years ago, while working with a medium-sized MNC, when I suggested documenting test scenarios rather than wasting time on preparing the full proof document called test cases, all the heads turned to me in annoyance.
The look on the faces was clearly conveying that I made a big mistake by suggesting it. Although no one denied the idea no one even accepted. Everyone felt that following the tradition, i.e. writing test case documents, would be safer. I could not argue.
After 4 years, the company received a testing project, where the only constraint was time and the only expectation was full proof testing.
We were in the meeting again and were discussing ideas to meet the critical deadline. The application was mainly about searching and generating different reports via different menu items. Documenting test cases was supposed to snatch most of the time and we were not sure, how much the document was going to use to the client.
I suggested documenting test scenarios and somehow with some hesitation, everyone agreed. No need to mention that we could save precious time of documentation and could utilize it for testing.
Table of Contents:
Are Test Cases Being Replaced Fast With Test Scenarios?
With time, as everything is changing, the software industry and processes also have changed a lot.
Traditional Waterfall and V-models are being replaced by agile and iterative models. Documentation is necessary but to meet deadlines and making the process easy and transparent, the way of documentation can be changed.
When Is Documentation Of Test Cases Important?
- The client has asked for the same as part of the project.
- There is no time constraint (I don’t think it’s possible).
- Testers are fresher or unknown to the product.
- Company policy (I strongly believe that it can be changed).
Let me share with you one experience:
I and my team were involved in testing a project from a Fortune 500 company with flexible timelines. We documented test cases with the best available template and got it approved by the client.
Once the build started releasing to the QA team, for most of the day, our duty was, mechanically follow 100 test cases per day, update the document with pass/fail result and send it to the client at the end of the day. Most of the team members started complaining about monotonous work but the company was generating revenue.
Then there was a break for one day in between with no new build to test. We sat together at the beginning of the day and were discussing what we were going to do for the day. When I proposed to generate more ideas to improve the test case document, all the team members denied putting in efforts.
As per them, there was nothing more to think about as we had covered all the scenarios. And convincing them to think out of a box and generate more ideas was really tough.
Most of the time, when we document test cases and that too once approved by the client, that human mind thinks that we have done our job and our mind automatically stops considering any effort to think about other ways to test the product.
And believe me, when test cases document is prepared, we just want to follow it mechanically. Tell me for how many times in your career, you have experienced that you or the teammate offered additional test cases to the approved test cases document?
One more experience:
During weekly team challenge activity, we announced the application and asked the team members to pour in test scenarios.
All the team members, including those late responders or non-responders, put in ideas. Why? There was no formal documentation where they had to fill the expected result for every sequence of functionality and pre-condition for each test case. We collected 40 test scenarios in a day and that was a great experience.
To favor my experience, I would like to present an example.
Take a sample application, say login page with username, password, login, and cancel buttons. If asked to write test cases for the same, we will end up writing more than 50 test cases by combining different options and details.
But if test scenarios to be written, it will be a matter of 10 lines as below:
High-Level Scenario: Login Functionality
Low-Level Scenarios:
1. To check Application is Launching
2. To check text contents on the login page
3. To check Username field
4. To check Password field
5. To check Login Button and cancel button functionality
See Also => 180+ Sample Test scenarios for testing web and desktop applications.
As we all are short of time, test scenarios work as painkiller spray rather than that old-time IODEX. And still, the effect is the same.
Differences Between Test Scenario Vs Test Case In Tabular Format
Finally, I would like to summarize the difference between Test Scenario vs Test Case:
| Test Cases | Test Scenarios | |
|---|---|---|
| What it is => | A concept which provides detailed information what to test, steps to be taken and expected result of the same | A concept which provides one-line information about what to test. |
| It’s about => | It’s more about documenting details. | It’s more about thinking and discussing details. |
| Importance => | It’s important when testing is off shored and development is onsite. Writing test cases with details will help both dev and QA team in sync. | It’s important when time is less and most of the team members can agree / understand the details from one-liner scenario. |
| Advantage => | One time documentation of all the test cases is beneficial to track 1000s rounds of regression testing in future. Most of the time, its 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, preferred 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 everyone to look into other modules and brain storm and discuss |
| Beneficial to => | A full-proof test case document is a life line for new tester. | Good test coverage can be achieved by dividing application in test scenarios and it reduces 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 specific person, the reviewer or the other user might not sync the exact idea behind it. Need more discussions and team efforts. |
Conclusion
Test cases are the most important part of the Software Development Life Cycle and without the one, it’s tough to track, understand, follow and reason out something. But in the era of Agile, test cases are being replaced fast with test scenarios.
A common test checklist for each type of testing (Database testing, GUI testing, Functionality testing, etc) coupled with test scenarios is the modern artillery for Software Testers. Discussions, training, questions, and practice can definitely change the final graph of your productivity as well as a Bug report matrix.
As usual, we welcome your thoughts and queries. Please tune in.
it’s like one day cricket match replaced by 20-20.
In Less time we enjoy much
Hello Bhumika,
Thank you so much for great post, I really appreciate your description. Please keep share your ideas and thought.
Even this topic is not a mantra. Just the opinion of the blogger, as many we can find nowadays. Here is nothing wrong said. And each test environment finds the best QA fit and it’s best practices, no matter how QA process called Test Scenario or Test Cases, but must be good and effective for the revenue.
how much is u r package?
Hi,
I was a java developer for 4 years and now moved to testing. I am starting with manual testing and later move on to selenium once i get a strong hold on business knowledge and testing concepts. I found your site on Google its Amazing and thanks for the wonderful job. Since, there is so much information i am confused where to start, Appreciate your help if you can point a flow to navigating from beginner to advance testing articles.
Thanks for the sharing the information Bhumika mam. I am a fresher and i was looking for the same and you helped me a lot.
One request: Please share some useful notes to me at abhishek.arora22@gmail.com so that I can learn more.
Thanks
Dear author, thanks for the post. Agree that the TS is diligent task as compare to TC and yes its my experience. At fresher level I have been trained to write test cases and as time goes I started TS writting unknowingly realizing it as less time consumable. Then I discussed with my peers formally (some agreed, some not). Later we initiate this in our weekly call, again, we did not got 100% +ve response from our senior and the decision left to our suitability keeping high quality product. So write TS for large project which need to finish in less time and TC for the project having enough time.
The post is encouraging my thoughts as well.
Thank you and keep posting!
This is really a good post. Most of the time when we write the TC’s unknowingly we are writing TS’s. TS are more helpful than TC when we follow a Agile Process. I have a good experience on this.
@Bhumika
i agree with you.
i start working with small organization,that time
our QA team used test cases.But now a days the popularity to written test cases are reduces,in place of
most of the mnc are prefer Test scenario.the main reason to prefer test scenario is that not a enough a time to write a proper testcases.Test cases are detailed document as compare to test scenario.test scenario are not a detailed doc,its a simple doc to understand the check the functionality of an application AUT.
I also prefer test scenario rather than test cases.
@Bhumika,
Appreciate your effort for the nice article. Agree on your previous comment ‘Test scenarios will surely accomplish less documentation as well as bring down the testing effort’ but w.r.to requirement coverage, Is it possible get a good requirement coverage without using any formal testing techniques?
@Kirti, @Poovarasan, @Sai, @Sameer, @Yogesh
Thank you very much for encouraging words and your readership.
@Kirti, @Sameer,
Test scenarios are not bound with exploratory testing only. As mentioned, both has their own pros and cons, Test scenarios are getting more popular with regular testing (no matter what testing type) as it require more thinking and discussion and less documentation.
It’s really superb article. I can easily understand the differences between the Test case & Test scenario.
Its really a good article. But, I think we need to have detailed test cases, where we mention each scnarion in detail. If we miss anything and get caught in production, we can come back to our test cases and drill down if we really had this test case OR we need to include any.
If you have very good testers who can no doubt test each scenario then its good to go for Test Scenarios
writing test cases requires more efforts rather than focusing on different conditions to test.
while writing test scenarios, focus would be on thinking out of the box and coverage of maximum conditions.
and this is true that once you finish writing test cases for a particular functionality you don’t feel like thinking more for the same as you have already spent more than enough time in WRITING test cases.
I believe that both test scenarios as test cases are closely related and are an essential part of a good test. The test scenarios are more oriented to business needs (from the point of view of the customer), the tester will give an overview of the purpose and the types of tests like it easier for the team members know the generalities of product. Test cases allow the tester to capture business needs (test scenario) test cases at a more detailed level allowing reuse.
Good Post!!!
Even i also prefer to follow the test scenario pattern with my team..In today’s agile development model where the time is constraint to deliver the project this process fits best..
thanks for sharing examples…..this is helping a lot 🙂
This is really valid post..I agree with this… Test cases are really helpful to track the testing when there is manageable amount of work and have enough time for testing
But when working in really hectic schedules and when extensive testing is to be carried out, then Test scenarios is a better option which reduces time on documentation and keep track of the results.
So informative, thanks for providing and please keep posting with some more information.
For the last 3 years I was working for a small firm as a QA.
Where I have full rights i.e. I was the one who lead their testing and their I follow the concept of test scenario and that work effctively. Recently I joined a big MNC a CMMi level 5 company where we have to follow the process and that process contains through test case writing also.
After reading your post I fell , you wrote something that I am feeling here.
Thanks
If I get chance in my company I will try to share this with my team mates.
Additionally, can anyone please refer any free tool to manage test cases? Please sugegst
@Bibhu,
Test Scenarios is a formal, well-accepted testing technique and as I mentioned in the post, with practice, training, experience and discussion, someone can masterize the skill of writing test scenarios with proper details while not spending more time on documentation.
Hey Bhumika great one u jus wrote what my mind was thinking when i googled for this topic…. keep in touch arunonline47@gmail.com thanks
@Inder, @Latha, @Pandit
Thanks for the kind words and your readership.
Really nice article. It is very usefull to me. My confusion about Test case and Test Scenario cleared.. Thank u so much
Your post is short sighted and leads folks in the wrong direction. First of all a scenario should be viewed as a series of steps, using “dependant data”. In other words you are testing a use case using data you create and then use. This is simply a methodology and will never replace a test case, but is needed in conjuction with test cases.
Secondly your focus is that of a contractor making short term deliverables of some software. Your proposals actually dont see QA as a full process that includes bug tracking/verification, regression testing and automation. If your tools are integrated you can streamline your processes. For example a TC fails we can push it to JIRA (as is) with all the needed details associated with that single failure. We can also use it to create modular automated tests so we dont have to spend time debugging the scripts to figure out what failed. Lets assume you use sceanrios only … can you do this or will you again have to keep recreating the various test cases to use in various tools. Also what it really leads to is an SME based test team. And that usually ends up badly with folks leaving or taking forever to become productive.
So lets not propose changing these larger processes with a small focus or view
Thank you so much for shearing your experience. I am also thinking of having the same approach at my work place, as Scenario testing is done by creating test scenarios which replicate the end users usage. in this way we can definitely track the defects which a end user may face.
I believe that knowledge is the most important thing to have in today’s world. I have been working as a software tester from last 15 months in an MNC in general insurance domain but still sometimes I think that I need to improve my software testing knowledge to cement my position in the company by increasing the dependency and this can be done only when I think I have reached to a position where my PM can find my work as work of an expert level tester. This can be achieved by testers like me after following this kind of immensely helpful blogs. I salute you @Bhumika Mehta# for sharing your knowledge. Kindly allow to ask few queries so that I can gain even more knowledge.
@joy singh
You don’t need compulsorily knowledge of automation. It also depends upon the company requirement whether they are hiring for manual or automation.
In Agile testing, even making a test case document is not needed, as Test cases are documented in the test management tool itself. What is needed is unique and out of the box Test scenarios, which cover all regression as well as Functional aspects of the requirements.
Finding and executing great Test scenarios make you a better testers and helps to find bugs which are not found in normal test procedures.
Great post… thanks!!
Hi..can anyone please send me some experience test cases email id- sagarmule47@gmail.com pls anyone
Great Post!!!
My day starts with reading the Posts of this Website….
Simply amazing
Test scenario approach can be useful in exploratory testing where tester’s experience matters the most.
I couldn’t agree more. I too feel the same. It’s definitely more effective as a tester, and less time consuming. It’s not a mindless job of documenting but the tester is really thinking through of all different scenarios that can happen that may be missed by the PO or BA.
Thanks so much for sharing, I am so glad there are others who feel the same 🙂
@Mihir Mehta
Thanks for sharing your views and we respect it and believe me, no heart was broken by reading your comment :-).
With that I would like to point out following facts :
1. Test Scenarios are faster and brief version of testcases. Please refer above mentioned example of login page test scenarios. you will be able to see / understand what those low level scenarios are and with years of experience, you must be clear about the coverage of each low level scenario.
2. Test Scenario is not about knowing about swimming pool but not knowing the depth and details. You can better summarize it as – knowing each and every detail about swimming pool like depth, width, color and purity of water, capacity, opening and closing time etc. but presenting the details in a way that it takes minimum time and stack holders can easily understand them.
3. Test Scenarios are more about continuous practice, discussion, training and questions.
Thanks !!!
Yeah its right
Agreed to certain Level.
But dont you think Test Scenario is very high level, Just by using the test scenarios you cant identify few issues.
Agreed totally,Most of projects which don’t have time lines prefer this method or vice versa both are good has they have own pro’s and con’s.
Hello Bhumika,
Today’s software trend is so dynamic, that test case written a year ago, cant be used, because software has updated/changed so rapidly.
Its wells said that Test scenarios are better in everyway. As they reduce time. And in this case, Test scenarios are better.
Archana
Hi , basically we are using following ay for testing any application .
1)Analyzing the Requirements
2)Participating in preparing Test Plans
3)Preparing Test Scenarios
4)Preparing Test Cases for module, integration and system testing
5)Executing the Test Cases
6)Defect Tracking
7)Giving mandatory information of a defect to developers in order to fix it
8)Preparing Summary Reports
9)Preparing Suggestion Documents to improve the quality of the application
10)Communication with the Test Lead / Test Manager
could u plz give me how to make exel sheet or point for testing for ponit no 3 ,6 and 7
Hi,
Its really very nice article and helpful in today’s world of testing where we have share the build with client at the end of the day.
Thank you so much
Thanks for Sharing nice view, but i want to add one more thing, i don’t know readers will agree with my point or not?
but regarding software testing truth is “Test Scenario is ‘What to be tested’ and Test Case is ‘How to be tested”. we create different test scenario to execute different test cases.
Both things are different and we can not say TS is better than TC. For better software testing TC are necessary.
@Prashanth
Test Scenarios are not high level but as I mentioned discussions, trainings, questions and practice can make it more fruitful.
monotonic working means
@Archana, @Reegan, @Priyanka
Thanks for stopping by commenting kind words. We appreciate your readership.
Test cases – contains one user action at a time
will record the id, pre condition, module name and record the user actions on Test Description and based on the user actions will write the expected result based on the requirement and validate.
Test Scenarios – is nothing but combination of group of test cases it should be more than 2 to 50/more. Mostly covers the positive flow and real time negative flow (if a user logs on different CPUs and trying to perform action on previous cpu – what will happend like that)
Test Cases should ensure system testing have done thoroughly incase of any defects found on live will perform Root Cause Analysis on what & where went wrong etc, but on scenario’s not all the failure cases will perform RCA
This strategy will be defined on TPD and get approval from PM / DH.
Test Scenario’s are really important to derive real time positive / negative flow and how the software responds to the user.
But personally i dont recommend will skip Test Cases and maintain only Test Scenario’s. Both are required for delighting the customers.
Great.. this is really helping me alot
Yes, I have a same query related to database testing it will be best if you can share your opinion on test case/scenario writing on database testing.
Word of caution: We need to look when to use what. Let’s not carried away in one direction. This article has given us food for thought.
I manages multiple testing projects/products and use Test scenarios, test cases, and a mix of both.
The decision which approach to choose depends upon various inputs such as Level of Application and Domain understanding, skills/expertise of team, expectations of clients, budget, team size, schedule, conformance to process, deliverables, Knowledge sharing strategy etc.
In any case, We first write the Test Scenarios, then develop test cases. Test Scenarios also helps in identifying the testing coverage and review. Test cases makes you to think and document all possible scenarios.
However, in case you have skilled test engineers and less time then these test scenarios become the basis of testing. And we now RELY ON TEAM’s expertise for quality testing as there is no measure what they have tested under a specific Test scenario.
One of my team don’t write test case and use only Test Scenarios as they know the application/domain in depth. No Production issues. To avoid risk of becoming people depended testing, we have a strict policy of module rotation so that everybody knows about all components of a system.
Other projects where we have Automation in place, there we write test cases which automation team converts in Test Steps.
I hope my comments will offer some more points for the discussion.
Thanks
Mahesh
Dear all,
if any share how to write database test cases
Nice one..
Test Cases are for a long run & test scenarios are for short term projects..
In all the situations they can be replacement for each other.
If a person who has written the scenario is on leave due to some urgency, then no one can understand seeing the scenario what to test so at times both have their own importance.
Lesson learned is , don’t follow the process blindly, use the process case by case
Regards
Gaurav K
thank u for valuable information..
@Bhumika Mehta – Can we easily use test scenarios in Regression testing ?
@Manander , @Sneha, @Pravin, @Rajesh,
Thanks for your readership and we are glad that you liked the article and it was helpful.
I completely agree. Having more than 8 years of experience and day to day activity of testing. I completely agree because now a days people are following Agile methodology to save time and provide same quality of software in less time. I also agree with that section where its written that if we have offshore QA then test case will impact more rather than test scenario but if you have development and QA working at same place then test scenario and bug report will work and SDLC will be less in time.
Apart from that I would like to add one more practice which we were doing is, to continue add test scenario while doing actual testing. Meaning while testing most of the time you introduce (80% of time) new scenario so test scenario preparation should be done before execution but it should be continuous process while execution cycle as well.
I am sure it will be benefit to someone if we follow this procedure especially you have short deadline and need to deliver very good quality of software.
Great article, lately I have been having a paradoxical opinion on whether we should design our test thinking about the item we are trying to test and list all the possibilities that could affect this item (which will eventually fall into 1 test scenario), or start from the possibilities that could affect this one item (and in this case I might have a total of 10 test cases, each for a distinct possibility, and the combination of those 10 test cases would form the complete testing coverage for this item).
For example, I have a Qty Column in a table, its value is computed by a specific formula that takes 6 elements.
What is your starting point here? the Qty Column? and in this case, would you create 1 test scenario that combines the 6 elements or 6 test cases each representing credibility of the qty column for each element.
Also, in modern testing, automation is the main player here, it thinks it is easier to flag a test case as automated vs not then a test scenario because it is a one to one relation rather than many to many where automation coverage can be at 60% rather than 100%
what are your thoughts?
@Vaibhav,
Glad to know that it was helpful.
@ParagS
I do agree with your point. Thanks a lot for your readership
good example.. thanks!!!
Hi,
Nice Sharing. I believe Test scenarios are more important than test cases. But as some one has mentioned, processes in a particular company may need test cases. I work in an MNC which is process oriented. We prepare test cases based on the acceptance criteria’s mentioned in the user story . But while testing we focus on more into scenarios. Thinking as a customer makes a QA great. Customers never follow the test cases prepared by QA for their work. The draw back of scenario based testing is next time when you do a regression testing you may not remember the scenario followed. In my case, if a particular scenario has found a very high or high defect, we automate the scenario so it wont get missed next time or in future.
Regards,
Jacob
Agree! But if have ample time in hand, test cases should be grouped as positive and negative cases further grouped by Test Scenarios. It also depends on the type of application and methodology followed.
Also, one should keep time aside (in every iteration) to do exploratory testing as it is the one which is most likely to find bugs that are otherwise discovered by the client/end users
is it necessary for a testing fresher to have a deep n working knowledge of automation? I have sound knowledge of manual testing. is it not enough to start career in testing as a fresher?
Very nice article !!!
hello vijay sir
this is the very very good testing learning site in the india. i love the previous live project article which was based on orange HRM . i want 2 know how to prepare UAT test case and system test case AND Negative test case for the project .please send me the sample test case of the above 3.
thanks
@Nitin D
Thanks for your readership and we really appreciate your kind words.
Thanks for pointing out that difference. That’s correct.
Good explanation in very basic terms.
Also if you can suggest, Which strategy works out better TS or TC ?
My understanding is that each TS can lead into multiple TC’s. If i do not have all the TCs with me, don’t i miss testing few of the possible combinations ?
Thanks.
Hello friends,
I disagree to a certain extent the above article by the author that if there is a time constraint and the methodology is Agile, Test Scenarios will do the work. No I disagree. Executing your tests just on the basis of Test Scenarios is possible but without a gaurantee towards Quality and Customer Satisfaction. Its like knowing about a particular swimming pool in brief and not knowing how deep is the water and jumping in it. I am sorry if I have broker million hearts by saying this but I disagree completely having been working in Software testing area since last 16 years
Excellent and very useful post ..
Thanks you…
Really very nice explanation, helpful at fresher level.
Sorry but I just want to clear this in my head. Is it “full proof” or “fool-proof”? Thanks and more power.
@Bibhu, @Mallika,
Thanks a lot for your readership !!!
Nice
Hello sir,
Can please give some advice to how to create test plan with example. and load testing in iOS.
Thanks for sharing your experience and difference for TS and TC.
Now I am using the MANTIS bug tracker tool, I am writing only test cases, so please tell me how to write test scenario in mantis bt.
Thanks
Great work Bhumika…as always.
I really appreciate your work. I am regular reader of this site and your articles. Keep writing your experience.
One difference missing,I think, is TC are based on specs, on the other hand TS are based on user requirements.
In the end user requirements/satisfaction are more imp than specs, so I think TS should get higher points.
I want 150 test scenarios of gmail
thanks for sharing examples.
the preference of test cases or scenarios depends on the availability of time, resources, and their skills.
Good article. I am a BA helping setting up testing in my company and had questions regarding Test Cases vs. Test Scenarios. From my vantage point, if time permits which it does in my situation, I see a merge of both in once document to show the “focus areas” and then “how to”. After reading the post, I will use multi-tab excel with the first one being the Scenario and the next tab to show Test Case. This is a rough idea that seems promising to me. I can imagine issues with organizing, updating, sorting, etc. due to features possibly existing in multiple overall scenarios. When QA starts getting up to speed then I’ll detach the two and have them list applicable Test Cases for each scenario.
But this is a good document and thank you for posting. I particularly like the grid that shows differences between Test Cases and Test Scenarios.