Is there a guide for systematic way of writing test scenarios?

Question

Are there best practices in coming up with effective test scenarios? Are there documented test scenarios that can be reused across different systems?

Answer 1

Katrina,

It is possible to include some important approaches and goals for software testing that tend to be beneficial in creating effective test case scenarios in a wide variety of testing situations. They include:

1. Don't repeat yourself (e.g., keep scenarios "DRY"); don't repeat combinations of test inputs more than you need to because you would find out more with the limited time you have if you tested as many different combinations of test inputs as you can in the limited time you have available.
2. Maximize variation (the flip-side of the "DRY" principle). Changing things as much as possible between each test case is an excellent way to trigger as many defects as possible in as few tests a possible.
3. Cover as much as possible in a manageable number of tests (because you'll never have time to test everything).
4. Use basic concepts like Equivalence Class Partitioning and Boundary Value analysis to focus your tests on where the defects are most likely to be.
5. Have an easy and maintainable approach to ensure that you're testing for all of the requirements that key stakeholders have told you that they want tested - but go far beyond that "minimum" list to "earn your keep" as a value-adding software tester.
6. Systematically and intelligently prioritize what combinations of inputs get tested vs. what combinations will not get tested using methods such as pairwise testing and/or combinatorial testing that are designed to maximize the amount of coverage you can achieve with the limited time you have available to test. (Test design tools, as mentioned below, can often be a big help here).
7. With a tip of the hat to Laura for her good comment (below)... Be sure to include tests based on ideas gathered from reviewing bug reports. Even if bugs have been found and fixed, bugs tend to "cluster" and places in the code that have broken before are more likely than other code to misbehave in the future.

A complete list of "best practices" is not possible to cram into a stackexchange answer though.

Accordingly, if you're serious about advancing your understanding from here about how to write effective test scenarios, I'd suggest:

1. Reading books about effective strategies for software test design. There are relatively few around, but I would highly recommend these 3:

   • A Practitioner's Guide to Software Test Design by Lee Copeland
   • Essential Software Test Design by Torbjörn Ryber and
   • The superb recently released book by Elisabeth Hendrickson called "Explore It!"
2. Try out software test design tools like our company's Hexawise tool and others listed on sites like pairwisetesting.com and pairwise.org. Learn their benefits and limitations. While they can be a big help to quickly generate powerful sets of test scripts when they are used correctly, in order to be used to their full potential, they rely on the critical thinking skills of thoughtful testers who understand the fundamentals of solid software test design principles.

On a related note, you might find the sqa.stackexchange question about "Systematic Approaches to Selection of Test Data" to be of interest.

Thanks and good luck.

Answer 2

There are different approaches possible:

• if you have system requirements document, you may write one or more test cases to each requirement

• another approach is based on system / user manual, you read this document and then write test scenarios trying to cover described functionalities

• in Agile / Scrum teams you may use acceptance criteria definition for the user story / epic and write your test cases based on this document

Answer 3

For the login process, have a look at this mindmap from Darren Mcmillan

Answer 4

What we do at my company is this: We sit down and model the flow through the application. Every point where the user makes a decision causes a branching path, and every path ends with an expected outcome. That way we're sure we understand everything the software is meant to do (And often, the developers hadn't thought about the user doing things out of sequence or some such action, so they forgot to account for it). Then it's easy to write test cases: just follow each path (we use an automated tool that generates manual test scripts from models).