I am Confused | How to write Test Conditions + Test Scenarios + Test cases

Testing terminologies can sometimes confuse even the most experienced of IT professionals. If you were asked to write a test case, you would know what to do. What about a Test scenario? Or a Test condition? Recently I got a query at LinkedIn,

“I am new looking into my first job in Testing. I already read about functional, integration and system and Test cases. But will need to write Test scenario first before Test cases. I am confused now, how to write Test scenario on Functional testing – say for Amazon.”

The first step is learning what different Testing terminologies actually mean. To a layman Test conditions, Test Scenarios, Test cases and Test suite might seem similar but there is a subtle difference between these terms which make a world of difference for a Software tester. Each of these implies a different level of detail and is used for a different purpose. Once a tester knows what each of these terms mean, they can figure out how to use them to describe the testing work that is done on a daily basis.

Test Conditions | What Functionalities

“An item or event of a component or system that could be verified by one or more test cases, e.g., a function, transaction, feature, quality attribute or structural element. For example: Test Object: Login form.”

Condition, i.e. a situation or a circumstance. In layman terms, Test Condition is nothing but the high-level pieces of a puzzle, i.e. different events/features of an application-under-test. A functionality that you want to verify as a Software tester. I have always found Test conditions useful in deriving the different pieces of functionalities under test. It helps me in preparing a functional-checklist that can then be taken as an input for further test coverage. For example if I look at ‘Amazon Homepage’, the first thing I would do is to make a list of Test conditions, i.e. different functionalities/test ideas under scope.

  1. Home Page rendering
  2. Different sections displayed – Header/Content/Footer
  3. Main Menu Options & Navigation
  4. Sub-menu Options & Navigation
  5. All Navigation (All hyperlinks, some 50/100+)
  6. Search functionality
  7. Slider functionality
  8. Location Detection
  9. Any particular Business Logics
  10. Language Translations
  11. Device/Browser compatibility
  12. Page Load performance

It is advisable to treat Test conditions as a chance to generate Test ideas, where you can think of ALL the functionalities/scope which can be tested – high-level things to be verified. Starting point to ensure your Test coverage.

Test Scenario | What Business Flows within Functionalities

Scenario, i.e. a setup or a setting. Now that we have derived the Test conditions, or the functionalities – the next logical step is to list different business flows within each functionality.

“A business process flow is composed of Stages, and within each stage there are Steps to complete.”

It’s time to move from high-level to mid-level Test coverage. Test scenarios help in achieving a good test coverage by breaking down a functionality in different possible business flows, i.e. different ways to accomplish a task.

“All possible attributes, functionalities, features and aspects of the software product that needs to be tested is commonly referred as Test Scenario.”

Talking about the syntax, there is no particular standard format. Just that it’s a short description about the business flow under test. Put yourself in the end-user shoes and figure out the real world scenarios which can be performed on the application. Continuing on our example of Amazon Homepage, below can be a set of Test scenarios for Test Condition #2 – Different sections displayed – Header/Content/Footer.

  1. Verify that Header is displayed at the top of the web page.
  2. Verify the UI of the Header, text-color-font-size-etc.
  3. Verify the Amazon logo displayed in the header.
  4. Verify that the location is auto-detected & displayed correctly in the header.
  5. Verify the Category menu.
  6. Verify the Sign In menu & options displayed.
  7. Verify the ‘Prime’ menu options & navigation.
  8. Verify the ‘List’ menu option & navigation.
  9. Verify the ‘Cart’ option displayed in the header.
  10. Verify the Search menu and the Search functionality using all categories.
  11. Verify the Offer (if any) displayed at the top right corner.
  12. Verify other navigation options available.

Typically, a test scenario will require testing in a few different ways to ensure the scenario has been satisfactorily covered. Since Test scenarios offer little information about how to complete the testing, they offer the maximum amount of flexibility.

Test Cases | How to Test Business Flows

“A test case is a document which consists of a set of conditions or actions which are performed on the software application in order to verify the expected functionality of the feature. Here we describe the end to end logical flow of a specific requirement with test data, prerequisites and expected results.”

Test case is the most detailed document within the Test Design process, the smallest unit of testing. It consists of a Test case description, execution pre-condition, steps to follow, a set of input values, expected results and executed post condition. Generally we maintain the traceability starting from the requirements – test conditions – test scenarios – test cases – defects. Coming back to our Amazon Homepage example, let’s try to create a Test case for the Search functionality,

  1. Open Amazon website in a web browser | Website is displayed successfully
  2. Verify the Search box at the top | Search text-box is displayed with category options at the left & search icon at the right.
  3. Verify the categories displayed for the Search option | Below list of categories are displayed.
  4. Select ‘Amazon Fashion’ category | Category is selected successfully.
  5. Enter the Search criteria as below & click Search icon | Search results are displayed.

Test Data: Valid Fashion brand, valid fashion clothing, valid different-category input, only numeric values, alphanumeric values including special chars, Unicode chars, Blank value, NULL value, JavaScript insertion, all spaces, etc.

As you can see, Test case is the most detailed entity. Any new tester should be able to start test execution when going through a test case. It details the test steps & expected outcome along with a set of test data (valid & invalid).

Test Suite | Manageable Grouping

Now that we have designed the conditions, scenarios & cases – there has to be a way to organize it. A Test suite is a collection of test cases that fall under the same category. Category here can be according to the Test level – Smoke Test Suite, Regression Test Suite, System Test Suite – OR can be clubbed as per the high-level business logic – Homepage Tests, Product Detail Page, Payment Gateway, Shopping Cart – etc. A Test suite often contains detailed instructions or goals for each collection of test cases and information on the system configuration to be used during testing.

The Relation between What & How

Now that we have designed the conditions, scenarios and cases – it is important to know how these are related. As you might have guessed, there is a one-to-many relationship as follows,

Requirement >> Test conditions (features to be tested) >> Test Scenarios (different business flows of a feature) >> Test cases (different cases within a business flow) >> Defect(s) encountered.


This particular article might not be of complete help to the requester since he was looking for more kind of example list of Test scenarios for functional testing of Amazon. But Amazon in itself is a complete e-commerce portal which has different components handled by multiple teams. There will be a Homepage team, a product detail page team, Payment gateway team, Shopping cart team, Offers team, Search team, etc. No one team can test a complete e-commerce portal. The point here is – not to look for a list of example Test scenarios or cases – better understand the process/logic/approach/or the dynamics behind each Test design document. Once the logic & approach to take is clear, a tester can then write effective test conditions, scenarios and cases more efficiently.

Both Test cases and Test scenarios are major components to software testing. With time, as everything is changing, 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 process easy and transparent, way of documentation can be changed. So, which one is the best to use: test conditions, test scenarios, or cases? The extreme level of detail in test cases is important when working with testers off-site, but in a time-sensitive situation where you may not have time to write detailed test cases, a test scenario may be sufficient. Test conditions can be used to brainstorm test ideas & kick-off the test coverage discussions. It all depends on your organizational & project needs. Using both Test scenarios and Test cases together will ensure a robust, high-coverage testing initiative.

Please feel free to post your opinion in the comments. I don’t mind to re-edit this post with valuable information from the comments.



Leave a Reply

Your email address will not be published.