Scenario 1: As a admin i want to verify pet owner names won't ask by IVR assistance < Pet Owner number register in PMS DB >

Description: weather user call for give IVR number while connecting IVR will check that number with PMS data base and if user number match with PMS data base IVR wont ask user name or it will ask.

Above scenario is written by myself, how can i improve myself to write good test scenarios?

  • 1
    Why you want to improve this ? Even a person like me who doesn't have a clue about the product understood what exactly the use case is. If you really want to improve, You can write the description in point of u want else it looks perfect
    – PDHide
    Jan 23, 2020 at 10:13
  • 2
    If I were given this test case, I'd just stare at it without knowing what to do. How to improve the scenario is a good question, but I'd start with the language. Really, it's important how you write, how many mistakes you make, what your grammar is. It's even more important in cases when other people will be reading it after you. I recommend starting there, it will pay off.
    – pavelsaman
    Jan 24, 2020 at 13:12

4 Answers 4


To improve the quality of test scenarios, you may follow these tips:

  1. Use clear and concise language: Write the scenario using simple language that can be easily understood by the stakeholders, including developers, managers, and end-users.

  2. Specify the goal and context: Clearly state the goal of the scenario and the context in which it will be tested.

  3. Define the expected outcome: Clearly define what the expected outcome of the scenario should be.

  4. Include pre-conditions: Specify any pre-conditions that need to be met before the scenario can be executed.

  5. Use examples: Use concrete examples to illustrate the scenario and make it easier to understand.

  6. Use a consistent format: Use a consistent format for all of your test scenarios to make them easier to read and understand.

  7. Get feedback: Share your test scenarios with other stakeholders and get feedback to improve them further.

  8. Ensure the scenario is testable. It should be clear what actions need to be taken and what the expected outcome should be.

  9. Include relevant context and background information that provides a clear understanding of the scenario.

  10. Consider different user perspectives, such as a customer, admin or developer, and write scenarios that test different use cases.

  11. Prioritize your scenarios based on the risk they pose to the system or the importance they have to stakeholders.

  12. Review your scenarios regularly and update them as necessary to ensure they remain relevant and up-to-date.

  13. Finally, ensure that the scenarios are easy to understand and use by all team members, including those who may be less familiar with the system being tested.

Here's an example:

Scenario: Verification of Pet Owner Information in IVR Assistance

Objective: To verify that the IVR system correctly identifies pet owners based on their registered phone numbers in the PMS database, and does not ask for their name when the number is found in the database.


  1. The pet owner initiates a call to the IVR system and provides their phone number.
  2. The IVR system matches the provided number with the PMS database.
  3. If the phone number is found in the PMS database, the IVR system skips asking for the pet owner's name.
  4. If the phone number is not found in the PMS database, the IVR system prompts the pet owner for their name.

Expected Results: The IVR system should only ask for the pet owner's name if their phone number is not found in the PMS database. If the phone number is found, the IVR system should not ask for the pet owner's name.


Your scenarion&description is not a test scenario to me, it is a feature description. One that is hard to read, which makes assumptions and lacks focus to be bluntly honest.

I would rewrite it in a As a ..., I want ... , So that ... user story format:

User Story 002: Automaticaly match pet owners names from PMS system

As Jack (some role) the user of the IVR assistance, (The persona)

I want pet owner names to be prepopulated if available, (The functional feature)

So that I can quickly handle phone calls without unnecessary interuptions (The value)

Acceptance Criteria:

  • IVR uses PMS database field <Pet Owner number register> for number matching

  • If number is not matched ask for the pet owner name, as described in User story 001

The persona <some role> is probably not the admin, the admin maintains the systems, probably he doesnt really care about how it functionally works. Maybe it is Jack the veterinary? I dont know your domain, but I doubt the correct persona is the admin. Also I like to use the firstname of a real person that does that action or uses the feature.

The feature is a behaviour you want to happen, you are describing something doesn't is not happening. This leaves room for interpretation what happens.

The value you do not describe the value for the persona.

Test scenarios for the feature could be:

  • Pet owner name is matched and displayed correctly
  • Pet owner name is notmatched and is asked
  • Pet owner name is asked when PMS system is down
  • Etc...

Maybe write them in Given When Then scenario style:

Scenario: name is matched and displayed correctly
  Given the pet owner name is in the PMS system
  When I open the screen for pet "Jack Russel"
  Then then the pet owner name is "Saskia"

I like the combination of a User Story, Acceptance Criteria and GivenWhenThen scenario's, because it makes our team think, communicate and colleborate on requirements and testcases.


Writing good and effective test cases covering all the scenarios depicts how efficient a qa services company is.

Below steps can also be followed that can be beneficial to cover test scenarios.

  • If user stories are provided with acceptance criteria mentioned,then direct test cases covering those scenarios can be created.
  • After previous step, more negative and positive use cases can be created to make them a part of regression testing cycle to assure all scenarios are covered.
  • Smoke and sanity test cases can be created to assure most important functions work and they work as expected.
  • Unit test cases can be created for each module separately covering them in depth.
  • Once unit test cases are created, test cases can be created covering the integration scenarios of the different modules.

To write good test scenarios, it is important to follow these best practices:

  • Start with a clear definition of the purpose of the scenario. The purpose should align with the goals and objectives of the project or product being tested.

  • Use a clear and concise language to describe the scenario steps. Use action verbs and clear nouns to describe the actions and objects in the scenario.

  • Be specific and provide enough detail to allow someone else to understand the scenario and be able to execute the test.

  • Consider adding relevant information, such as expected results, prerequisites, and any other relevant information that will help to understand the scenario.

  • Use a consistent format for all test scenarios, including the use of headings, bullet points, and indentations.

  • Review and refine the test scenarios regularly, updating them as necessary based on changes to the project or product being tested.

Now pplying these best practices to the scenario you provided, it could be improved as follows:

Scenario 1: Verify that IVR does not ask for pet owner name

Purpose: To confirm that the IVR system is able to verify pet owner numbers against the PMS database and does not ask for the owner's name when a match is found.


  • Pet owner's number is registered in the PMS database


  1. Call the IVR system
  2. Provide the pet owner's number
  3. Observe the IVR system's response

Expected Result:

  • The IVR system verifies the provided number against the PMS database
  • If the number is found in the PMS database, the IVR system does not ask for the pet owner's name
  • If the number is not found in the PMS database, the IVR system asks for the pet owner's name.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.