An important aspect to writing a good functional test case is to make sure that the scope of your test is aligned with the feedback you care about.
Oftentimes when our customers first start writing tests in Rainforest, they try to cram too much into a single test case.
Ideally, the scope of a single test case should represent a complete (but simple) user activity; an e-commerce example might be leaving a review for a past purchase, or creating a new account. While testing these two activities in one long test case might seem like it will save time, ultimately each set of actions represents a different activity, and should be separated into two test cases.
Over time, creating tests that are too broad in scope will lead to a test suite of duplicative and overlapping tests. Better to keep tests short, modular, and testing a specific functionality or user flow.
A good example: Log in to Airbnb using an email and password that do not yet exist as an account, and verify an error message is thrown.
Bad example: Sign up as a new user using an invalid email, verify that an error message is thrown, then sign up with a valid email and password, verify that it works, then search for an Airbnb stay in Paris, France and verify you receive results. This test is too broad in scope and is trying to test several unrelated user actions together.
Bad example: Click on the sign up button, and verify that a sign up modal appears. This test is too narrow in scope and does not test a complete user activity.
To keep tests modular and simplify test suite maintenance, we recommend using embedded tests to reuse pre-written tests as building blocks.
- For a more tactical guide on how to write Rainforest tests, check out our Building Your First Test Suite guide.
- For more information on QA Strategy, check out our Getting Started with QA Strategy guide.
- Seeded State Management: As you mature your process, consider setting up seeded states to cut down the steps required to set up test accounts into the specific state needed for testing.