{"id":358,"date":"2021-10-27T23:08:02","date_gmt":"2021-10-27T23:08:02","guid":{"rendered":"http:\/\/rainforestqa.com\/how-to-write-a-test-plan\/"},"modified":"2025-03-18T13:14:04","modified_gmt":"2025-03-18T13:14:04","slug":"how-to-write-a-test-plan","status":"publish","type":"post","link":"https:\/\/www.rainforestqa.com\/blog\/how-to-write-a-test-plan","title":{"rendered":"How to write a test plan: Free template &#038; 6 step guide"},"content":{"rendered":"\n<p>A test plan outlines the objectives, methods, organization, and success criteria for testing a specific feature of a web application or other software project.<\/p>\n\n\n\n<p>A good test plan contains all the information you need to write automated tests and will help direct your efforts so you don\u2019t waste time creating unnecessary tests.<\/p>\n\n\n\n<p><strong>Here is the <\/strong><a href=\"https:\/\/docs.google.com\/spreadsheets\/d\/18dk2AV1na6r6dckz8jAuJdjrSTcKB3Cz4aos46ph3sk\/edit?usp=sharing\" target=\"_blank\" rel=\"noopener\"><strong>test plan template<\/strong><\/a><strong> we use with our clients.<\/strong>&nbsp;<\/p>\n\n\n\n<p>To use this template yourself, simply:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Open the document, and click on the tab marked <strong>\u201cTemplate &#8211; MAKE A COPY\u201d.<\/strong><\/li>\n\n\n\n<li>Click on the down arrow next to the tab label, and hover over <strong>\u201cCopy to\u201d.<\/strong><\/li>\n\n\n\n<li>Select <strong>\u201cNew spreadsheet\u201d.<\/strong><\/li>\n\n\n\n<li>From there, you should be able to open a new blank copy of the spreadsheet within your Google Docs Spreadsheets.<\/li>\n<\/ul>\n\n\n\n<p>(If you need the Functionality Map as well, make a copy of the whole document and then delete the Slack example features from both the Functionality Map and the New Workspace tabs.)<\/p>\n\n\n\n<p>Below, we walk through how to use the template and six steps for creating a test plan:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Develop a testing strategy.<\/li>\n\n\n\n<li>Create a functionality map.<\/li>\n\n\n\n<li>Define pass\/fail criteria.<\/li>\n\n\n\n<li>Write test descriptions.<\/li>\n\n\n\n<li>Define test organization standards.<\/li>\n\n\n\n<li>Create rules for failure categorization and bug classification.<\/li>\n<\/ol>\n\n\n\n<p><em><a href=\"https:\/\/www.rainforestqa.com\/talk-to-sales\">Talk to us<\/a> about setting up a Rainforest plan that fits your needs.<\/em><\/p>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_82_2 counter-hierarchy ez-toc-counter ez-toc-custom ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Contents<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.rainforestqa.com\/blog\/how-to-write-a-test-plan\/#1_Develop_a_Testing_Strategy\" >1. Develop a Testing Strategy<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.rainforestqa.com\/blog\/how-to-write-a-test-plan\/#2_Create_a_Functionality_Map\" >2. Create a Functionality Map<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.rainforestqa.com\/blog\/how-to-write-a-test-plan\/#3_Define_PassFail_Criteria\" >3. Define Pass\/Fail Criteria<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.rainforestqa.com\/blog\/how-to-write-a-test-plan\/#4_Write_Test_Descriptions\" >4. Write Test Descriptions<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/www.rainforestqa.com\/blog\/how-to-write-a-test-plan\/#5_Define_Test_Organization_Standards\" >5. Define Test Organization Standards<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/www.rainforestqa.com\/blog\/how-to-write-a-test-plan\/#6_Create_Rules_for_Failure_Categorization_and_Bug_Classification\" >6. Create Rules for Failure Categorization and Bug Classification<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/www.rainforestqa.com\/blog\/how-to-write-a-test-plan\/#Put_Your_Test_Plan_to_Use_with_Rainforest_QA\" >Put Your Test Plan to Use with Rainforest QA<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"1_Develop_a_Testing_Strategy\"><\/span>1. Develop a Testing Strategy<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>We\u2019ve written an entire article around just this first step because it lays the foundation for your functional testing program. <a href=\"https:\/\/www.rainforestqa.com\/blog\/automated-testing-strategy\/\" target=\"_blank\" rel=\"noopener\">You can read the article here<\/a>.&nbsp;<\/p>\n\n\n\n<p>The short version is that a testing <em>strategy<\/em> deals with big picture goals and how to achieve them, whereas a testing <em>plan<\/em> deals with the actual test procedure. It defines things like the scope of testing, test design standards, the testing environment, and other tactical aspects of testing.&nbsp;<\/p>\n\n\n\n<p>A test strategy includes:&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Defining your goals.<\/li>\n\n\n\n<li>Assigning testing responsibilities.<\/li>\n\n\n\n<li>Deciding what tests to automate.<\/li>\n\n\n\n<li>Deciding when to do functional testing.<\/li>\n\n\n\n<li>Choosing a test automation tool.<\/li>\n<\/ul>\n\n\n\n<p>The last step\u2014choosing a test automation tool\u2014is particularly important before writing a test plan because the tool will determine how easy it is to write test scripts, who can help out with test maintenance, and who needs to be involved at what stage in the testing process.<\/p>\n\n\n\n<p><strong>When choosing a test automation tool, you essentially have two options:<\/strong> code-based web automation frameworks like Selenium that require programming skills to use, or tools that allow users to create tests with some kind of no-code user interface.&nbsp;<\/p>\n\n\n\n<p>Most of the tools that call themselves <a href=\"https:\/\/www.rainforestqa.com\/blog\/codeless-automation-testing\" target=\"_blank\" rel=\"noreferrer noopener\">no-code test automation tools<\/a> are actually just an easy way to auto-generate Selenium code. Selenium is known to have <a rel=\"noopener\" href=\"https:\/\/www.rainforestqa.com\/blog\/selenium-alternatives\" target=\"_blank\">many drawbacks<\/a> when it comes to functional UI testing, but one of the biggest ones is the technical barrier to entry. Working with Selenium requires a full set of programming skills, and even the best no-code tools that generate Selenium code eventually require software engineers to step in and set up more complicated tests and troubleshoot any problems.<\/p>\n\n\n\n<p><strong>Rainforest QA is the only no-code automation testing tool that lets you write, run, and maintain tests without writing a single line of code. <\/strong>&nbsp;<\/p>\n\n\n\n<p>In Rainforest\u2019s visual editor, you can choose from a dropdown menu of preset actions (such as \u201cclick\u201d, \u201cselect\u201d, or \u201ctype\u201d). Then, you click and drag the cursor to take a screenshot of the element you want to apply the action to.&nbsp;<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/uploads-ssl.webflow.com\/60da68c37e5767dfb65004c0\/61b250fa0b013466232fafc2_Add%20a%20Click%20Action.gif\" alt=\"Add a Click Action in Rainforest QA: Try for Free Button\"\/><\/figure>\n\n\n\n<p>Once you\u2019ve created each action for the functionality you want to test, you can replay the actions you\u2019ve created to verify that the test will do what you\u2019ve intended.&nbsp;<\/p>\n\n\n\n<p>Because anyone can write Rainforest tests, non-technical stakeholders and team members can step in to help get a bunch of tests started right after you\u2019ve created your software test plan.<\/p>\n\n\n\n<p>Here are just a few of the additional benefits Rainforest QA offers that make it easier to implement your test plan:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Test What the User Sees Instead of What the Computer Thinks They See<\/h3>\n\n\n\n<p>Rainforest tests what your users will <em>actually<\/em> see, rather than what the computer thinks users should be seeing.&nbsp;<\/p>\n\n\n\n<p>This is because Rainforest tests use pixel-matching to verify that an element is visible instead of searching for locators in the underlying code, like most test automation tools.<\/p>\n\n\n\n<p>For example, if you wanted to validate the presence and content of a confirmation message via a code-based automation testing tool, you would need to create separate assertions to test: Is the element visible? Does it say what I want it to say? Is it the correct color? Is it the correct size? And so on.<\/p>\n\n\n\n<p>With Rainforest tests, all of this gets automatically tested with pixel-matching, and the tester only has to take one screenshot. This saves a lot of time when writing tests.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Test Automation That Doesn\u2019t Break with Minor, Behind-the-Scenes Code Changes<\/h3>\n\n\n\n<p>By testing the visual layer of the application, Rainforest automated test scripts are less susceptible to breaking due to minor code changes that don\u2019t affect the UI\u2014unlike tools that test the underlying code (<a href=\"https:\/\/www.rainforestqa.com\/blog\/cypress-selenium-katalon-comparison\" target=\"_blank\" rel=\"noopener\">like Selenium, Cypress, or Katalon<\/a>).&nbsp;<\/p>\n\n\n\n<p>If you\u2019re using a testing tool or framework that tests the underlying code, you could run into a variety of situations where the test might fail even though the UI is flawless.&nbsp;<\/p>\n\n\n\n<p>For example, if the CSS class of the button changed from &#8220;try for free button&#8221; to &#8220;tryforfreebtn2,&#8221; a Selenium test could break, but a Rainforest test would not\u2014as long as the pixels of the button on the page didn\u2019t change.&nbsp;<\/p>\n\n\n\n<p>A Rainforest test would fail only if the actual visual appearance of the button changed. For example, if the button was accidentally hidden due to a bug in a recent code push, the test would <em>(and should) <\/em>fail.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">An All-in-One Solution <\/h3>\n\n\n\n<p>Rainforest QA is an all-in-one UI test automation solution, which means it includes everything you need to create, run, and manage any number of automated tests. You don\u2019t need to pay for additional things like a cloud-based testing grid, project management tools, and team collaboration tools just to manage your automation efforts.&nbsp;<\/p>\n\n\n\n<p><strong>All <\/strong><a href=\"https:\/\/www.rainforestqa.com\/pricing\" target=\"_blank\" rel=\"noopener\"><strong>Rainforest QA pricing plans<\/strong><\/a><strong> include:&nbsp;<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>A built-in \u201ctest grid\u201d.<\/strong> The Rainforest platform includes all the infrastructure you need to run tests. All tests run on virtual machines in our cloud, including 40+ configurations of platforms and browsers.<\/li>\n\n\n\n<li><strong>Parallel test execution.<\/strong> No matter how many test cases you run at a time, they\u2019ll run simultaneously, getting you fast results.<\/li>\n<\/ul>\n\n\n\n<p>You can scale testing up or down as needed, without having to make an expensive upgrade to any of your testing infrastructure tools.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"2_Create_a_Functionality_Map\"><\/span>2. Create a Functionality Map<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>You may already have a functionality map for your application, which identifies the most important features of your application and ranks them by priority.&nbsp;<\/p>\n\n\n\n<p>If you do, you can skip this step.&nbsp;<\/p>\n\n\n\n<p>If not, you can refer to the first tab of our <a href=\"https:\/\/docs.google.com\/spreadsheets\/d\/18dk2AV1na6r6dckz8jAuJdjrSTcKB3Cz4aos46ph3sk\/edit?usp=sharing\" target=\"_blank\" rel=\"noopener\">test plan document<\/a> to see our example functionality map for an early version of the Slack web app.&nbsp;<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/uploads-ssl.webflow.com\/60da68c37e5767dfb65004c0\/61799c636b1c7ad8bc46485b_how-to-write-a-test-plan-1.png\" alt=\"Primary Functionality, Secondary, Tertiary, Negatives\"\/><\/figure>\n\n\n\n<p><strong>For most web applications, it\u2019s not practical or feasible to test every single user path through an app.&nbsp;<\/strong><\/p>\n\n\n\n<p>Instead, you should focus your testing efforts on the most important user paths. We like to use the <a href=\"https:\/\/www.rainforestqa.com\/blog\/automation-test-coverage\" target=\"_blank\" rel=\"noopener\">analogy of a snow plow<\/a> clearing a city\u2019s streets after a snowstorm. The streets that see the most traffic get cleared first, and some of the side streets may never get cleared because so few people travel on them. This ensures the most important parts of your app will work for the majority of your users.<\/p>\n\n\n\n<p>To identify the most important user paths, start by listing the most basic features of your app under the <strong>\u2018Primary Functionality\u2019<\/strong> column on the attached template. These will be the group names that all other tests are organized under.<\/p>\n\n\n\n<p>Next, under the <strong>\u2018Secondary\u2019<\/strong> column identify the basic functionalities for each of the features in the first column. You\u2019ll write your first tests for each of these functionalities\u2014this is your smoke test suite.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><strong><em>Smoke tests:<\/em><\/strong><em> Tests that run through the most essential user paths to make sure the application is stable enough to move on to further testing.<\/em>\u200d<\/p>\n<\/blockquote>\n\n\n\n<p>The<strong> \u2018Tertiary\u2019<\/strong> column is for additional functionalities that go beyond the basics. In the Slack example above, the most basic functionality under the \u2018Channel\u2019 feature is to create a new channel. Once you know you can create a new channel, you can start testing whether or not you can add additional channels and move back and forth between channels. These tests will make up your regression test suite.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><strong><em>Regression tests:<\/em><\/strong><em> Tests that check the overall functionality of a product after new features have been added to make sure the latest changes didn\u2019t introduce new bugs or break any existing functionality.<\/em><\/p>\n<\/blockquote>\n\n\n\n<p>Finally, the \u2018Negatives\u2019 column would include low-priority edge cases that should only be included in your regression suite if you\u2019re already covering everything in the Tertiary column.<\/p>\n\n\n\n<p>By following this setup, you\u2019ll be testing the functionalities of individual features before testing how these features interact with each other. This helps you understand the complexity of your application as a whole and helps your team focus their efforts.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"3_Define_PassFail_Criteria\"><\/span>3. Define Pass\/Fail Criteria<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>The <strong>first column<\/strong> on the second tab of the test plan document is where you will write the title for each test (we like to name tests with the feature group and the functionality being tested).&nbsp;<\/p>\n\n\n\n<p>The <strong>second column<\/strong> is where you write the objective of the test. Another way to think of the objective is that it determines the pass\/fail criteria.&nbsp;<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/uploads-ssl.webflow.com\/60da68c37e5767dfb65004c0\/61799c8f893164135bf14fc0_how-to-write-a-test-plan-2.png\" alt=\"Test Titles and Objectives\"\/><\/figure>\n\n\n\n<p>The objective of the test is the desired outcome (a pass). If this outcome isn\u2019t achieved (a fail), it means there\u2019s a bug in the system or a break in the test.&nbsp;<\/p>\n\n\n\n<p><strong>The more specific and concise your objective, the more effective your tests will be<\/strong>. You should be able to convert your objective into a question with a simple yes or no answer <em>(i.e. when the user clicks the \u2018add to cart button\u2019 does the item appear in their cart?)<\/em>.&nbsp;<\/p>\n\n\n\n<p>If you try to test too many functions in one test, you\u2019ll end up with tests that take longer to run because features are being tested one after the other instead of simultaneously (assuming you\u2019re using a testing platform like Rainforest). The longer it takes the test to run, the more time you\u2019ll spend sorting through test results to understand failures.&nbsp;&nbsp;<\/p>\n\n\n\n<p>These small decisions could be the difference between a test that takes 45 seconds to run and a test that takes 90 seconds to run. This might not seem like a big deal, but when you&#8217;re running a suite of 100 tests (let alone a suite of 500 tests like some of our clients) that\u2019s a difference of 75 minutes.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"4_Write_Test_Descriptions\"><\/span>4. Write Test Descriptions<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>The third column is where you can write out a description of each step of the test.&nbsp;<\/p>\n\n\n\n<p>By writing out each of the testing tasks, you\u2019ll be able to identify dependencies and determine whether the test is best suited for <a href=\"https:\/\/www.rainforestqa.com\/blog\/manual-vs-automated-testing\" target=\"_blank\" rel=\"noopener\">automation or manual testing<\/a>.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/uploads-ssl.webflow.com\/60da68c37e5767dfb65004c0\/61799ca8abcf8d7086949522_how-to-write-a-test-plan-3.png\" alt=\"Test Objectives and Test Descriptions\"\/><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">To write a detailed test description, you\u2019ll want to think about:<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What needs to be included in the test environment to run the test <em>(i.e. dependencies)<\/em>?<\/strong>\n<p>Continuing with the Slack example, if the objective is to verify a user can send a message, then there must be two user accounts in the workspace.<\/p>\n<\/li>\n\n\n\n<li><strong>What steps will you need to set up the test state with the needed dependencies?<\/strong>\n<p>There are two ways to get a test into the state you identified in the previous question: You can either create <a href=\"https:\/\/help.rainforestqa.com\/docs\/seeded-state-management\" target=\"_blank\" rel=\"noopener\">seeded states<\/a> or include additional steps in the test description. Seeded states allow testers to log in to an account where specific actions are already complete.<\/p>\n<p>With a seeded state, the test can start at the part of your application you need to test. Building off of the above example, the seeded state would be the <a href=\"https:\/\/help.rainforestqa.com\/docs\/creating-and-using-test-accounts-in-rainforest\" target=\"_blank\" rel=\"noopener\">existence of a workplace with two user accounts<\/a>.<\/p>\n<p>Setting up seeded states takes a little extra time during test creation, but it can save a lot of time during test execution, because the only other option is to include all of the steps to add two users in the test, which will extend the run-time of the test.<\/p>\n<\/li>\n\n\n\n<li><strong>Does this test need a reset step at the end? <\/strong>\n<p>For example, if you want to verify that you can <em>activate<\/em> a user, the user first needs to be <em>inactive<\/em>. If the last step of your test is to set the user back to an inactive state, the test environment will be ready the next time you want to run the test.<\/p>\n<\/li>\n\n\n\n<li><strong>Does this test include steps that can only be performed by a human?<\/strong>\n<p>For example, a feature may include verifying a CAPTCHA. If it does, make a note that this test needs to be run manually. With just the click of a button in Rainforest, you can choose to run tests with automation or with human crowd testers.<\/p>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/uploads-ssl.webflow.com\/60da68c37e5767dfb65004c0\/61799df8666a925b93d03dad_how-to-write-a-test-plan-4.png\" alt=\"Change Run Method: Automation Service + Tester Community, Tester Community, or On-Premise Testers.\"\/><\/figure>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Does this test cover just one feature?<\/strong>\n<p>Testing only one feature with each test will reduce maintenance while speeding up failure identification and debugging.<\/p>\n<\/li>\n\n\n\n<li><strong>Does this test have too many steps? <\/strong>\n<p>When writing tests for the Rainforest crowdtesting community, we recommend only writing 20 steps per test. This is a good proxy for most tests: If your test is more than 20 steps, the test is probably covering too much of the app and would be more efficient if broken into smaller tests.<\/p>\n<p><strong>In our experience, tests longer than 20 steps have a 40% higher chance of failure.<\/strong> Automated tests can include more steps, however, it\u2019s still best to use embedded tests <em>(more on those below)<\/em> when possible and take the most direct route for fulfilling the test objective without testing any side features.<\/p>\n<\/li>\n<\/ul>\n\n\n\n<p>Most automation tools offer some features to help speed up writing tests and test maintenance.&nbsp;<\/p>\n\n\n\n<p>Here are a few of the features Rainforest QA offers to help speed up the test writing process:&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Use Embedded Tests to Speed Up Test Writing and Maintenance<\/h3>\n\n\n\n<p>While writing your test descriptions, you may start noticing test scenarios that are repeated a lot.&nbsp;<\/p>\n\n\n\n<p>In Rainforest QA, you can use embedded tests for these repeated test scenarios so that you only have to write the test once.&nbsp;<\/p>\n\n\n\n<p><strong>For example, if multiple tests use the same sign up sequence, you can create just one test for signing up, and embed that test in every other test that requires a login step.<\/strong><\/p>\n\n\n\n<p>Here\u2019s an example of how we embed a \u2018Rainforest Signup Flow\u2019 test into another test (it includes every action from clicking the \u2018Try for Free\u2019 button through verifying that a \u2018Successful\u2019 message will appear):&nbsp;<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/uploads-ssl.webflow.com\/60da68c37e5767dfb65004c0\/61b251d647904d53ca291ea5_quality-assurance-metrics-3.gif\" alt=\"Rainforest Signup Flow example: Embed a Test\"\/><\/figure>\n\n\n\n<p>If any steps in the signup flow need to be updated (due to a product change), we can update the test in just <em>one place<\/em> and it\u2019ll automatically be updated in every single test that has the \u201cRainforest Signup Flow\u201d test embedded in it.&nbsp;<\/p>\n\n\n\n<p>This saves a ton of time on test maintenance.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Use Text-Matching to Make Tests Less Brittle<\/h3>\n\n\n\n<p>Text matching examines the text content of an element rather than the appearance.&nbsp;<\/p>\n\n\n\n<p>For example, the buttons below both say \u201cBuy Now\u201d even though the colors and shapes are different.&nbsp;<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/uploads-ssl.webflow.com\/60da68c37e5767dfb65004c0\/6123deea5ff4fd3b69f240fe_buy-now.png\" alt=\"Buy Now Button: Initial Button vs Updated Button\"\/><\/figure>\n\n\n\n<p><strong>If text matching is enabled, the test will pass with either version of the button.<\/strong> If the text locator is not enabled, it will only pass if your original screenshot matches the version being tested.&nbsp;<\/p>\n\n\n\n<p>When writing test descriptions for Rainforest tests, it\u2019s helpful to indicate whether a test should allow text-matching, or if it needs to look for an <em>exact<\/em> visual match.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/uploads-ssl.webflow.com\/60da68c37e5767dfb65004c0\/615b56d30c6bebf7a3d39734_allow-text-matching.png\" alt=\"\"\/><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"5_Define_Test_Organization_Standards\"><\/span>5. Define Test Organization Standards<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Test organization (sometimes called test management) is covered by the last several columns of the template and includes:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Who is responsible for writing the test? <\/strong>\n<p>Assigning an owner at this stage is only about <em>who<\/em> will be responsible for actually writing the test script. Assigning other testing activities such as running and maintaining tests long-term is covered in the test strategy.<\/p>\n<\/li>\n\n\n\n<li><strong>How high of a priority is the test?<\/strong>\n<p>If you don\u2019t have time to run all of your tests before release, knowing the priority level of each test will help you decide which tests to run first.<\/p>\n<\/li>\n\n\n\n<li><strong>Which tests are part of the same group?<\/strong>\n<p>Groups can be defined using tags\u2014or identifiers\u2014according to: (1) the groups listed in the \u201cPrimary Functionality\u201d column mentioned earlier, (2) the type of testing <em>(i.e. smoke testing, regression testing, system testing, acceptance testing, performance testing, etc.)<\/em>, or (3) any other criteria to accommodate your testing team\u2019s workflow.<\/p>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/uploads-ssl.webflow.com\/60da68c37e5767dfb65004c0\/61799d5a13599a0550b8a3ba_how-to-write-a-test-plan-7.png\" alt=\"Owner, Feature, Priority, Primary Tags, Secondary Tags, and Notes\"\/><\/figure>\n\n\n\n<p>Marking the priority level and assigning tags are part of the test writing process in Rainforest QA. This allows for a more flexible test schedule. You can select one testing type\u2014all tests with the \u2018Regression\u2019 tag or all priority one tests for example\u2014and run them simultaneously without individually selecting and running each test.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"6_Create_Rules_for_Failure_Categorization_and_Bug_Classification\"><\/span>6. Create Rules for Failure Categorization and Bug Classification<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>The last step of the test plan is about determining <em>how<\/em> your QA team will handle failed test results.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Failure Categorization<\/h3>\n\n\n\n<p>Anytime you get a failed test result, you have to figure out if the test failed because the test is broken, there\u2019s a bug in the system, or for some other error. This is called <a href=\"https:\/\/help.rainforestqa.com\/docs\/how-to-categorize-failures\" target=\"_blank\" rel=\"noopener\">failure categorization<\/a>.<\/p>\n\n\n\n<p>Each team will have a different way to categorize failures. You\u2019ll need to decide what categories you want to use and write a description of the category so there is no confusion about which category a test failure belongs in.&nbsp;<\/p>\n\n\n\n<p>A few of the categories we recommend are:&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Bug: <\/strong>An issue that needs to be addressed because the feature or function doesn\u2019t work as intended.<\/li>\n\n\n\n<li><strong>Known Bug:<\/strong> A bug that was previously identified.&nbsp;<\/li>\n\n\n\n<li><strong>Needs Refactor:<\/strong> The test needs to be updated (rewritten) to match the tested functionality.<\/li>\n\n\n\n<li><strong>System Error:<\/strong> There was a connectivity issue or incorrect test data.<\/li>\n<\/ul>\n\n\n\n<p><strong>Rainforest QA makes it easy to understand why any test fails by recording a video of every test (even ones that pass).&nbsp;<\/strong><\/p>\n\n\n\n<p>Within the test steps, you can see what <em>action<\/em> failed and<em> why<\/em> because the action gets highlighted in red and a brief message appears stating the reason it failed.&nbsp;<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/uploads-ssl.webflow.com\/60da68c37e5767dfb65004c0\/6112e9550057195cfa3a1321_rainforest-signup-flow.png\" alt=\"Rainforest Signup Flow: Element Mismatch\"\/><\/figure>\n\n\n\n<p>This allows you to see how the application performed <em>without<\/em> having to recreate the exact situation.<\/p>\n\n\n\n<p>Then, you can easily mark the failure categorization for each test.&nbsp;<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/uploads-ssl.webflow.com\/60da68c37e5767dfb65004c0\/61799d84927c54012e19a36b_how-to-write-a-test-plan-9.png\" alt=\"Passed Test 96%, Failed Tests 4%, Completed in 13 minutes.\"\/><\/figure>\n\n\n\n<p>Rainforest stores this information so you can easily create test reports from your dashboard. You can have these reports automatically sent to your email so you can stay up to date on every test phase.<\/p>\n\n\n\n<p>Another best practice related to failure categorization is deciding what to do with tests that need to be rewritten <em>(the \u201cNeeds Refactor\u201d category)<\/em>. Your team could prioritize fixing all broken tests immediately before running the suite again, or you could choose to quarantine broken tests by removing tests that were labeled \u201cNeeds Refactor\u201d from future test suites until they can be rewritten. Just make sure you get around to rewriting them soon, or else your test suite will become less and less reliable.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Bug Classification<\/h3>\n\n\n\n<p><a href=\"https:\/\/softwaretestingfundamentals.com\/defect\/#Classification\" target=\"_blank\" rel=\"noopener\">Bug classification<\/a> is about setting metrics that determine how likely it is that the bug will affect your bottom line or reputation. Criteria are based on the probability of users running into the bug and how much damage the bug will cause if users do run into it.<\/p>\n\n\n\n<p>Each company has a different testing approach and tolerance for bugs based on a variety of factors, including the industry, the expectations of the users, and the competitiveness of their market segment.<\/p>\n\n\n\n<p>In some industries, minor bugs might be so damaging to a company\u2019s reputation that it\u2019s worth delaying releases by several weeks in order to fix every bug.&nbsp;<\/p>\n\n\n\n<p>In other settings, it\u2019s much more important to get a requested feature into customers\u2019 hands by a certain deadline, even if it means fixing a few minor bugs after release.&nbsp;<\/p>\n\n\n\n<p>Either way, it\u2019s important to determine bug classification criteria so you can work on the major bugs first.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Set Up Integrations to Get Alerts for Test Results<\/h3>\n\n\n\n<p>Last, you\u2019ll need to determine how failed test results will be sent to the development team.&nbsp;<\/p>\n\n\n\n<p>Rainforest QA offers plugins to integrate with various software development tools. For example, you can integrate with Jira and send failed test results to developers automatically, including the relevant test result video recordings and HTTP logs.<\/p>\n\n\n\n<p>Developers can also use our API or CLI to kick off a suite of Rainforest UI tests along with unit tests and integration tests in a CI\/CD pipeline.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Put_Your_Test_Plan_to_Use_with_Rainforest_QA\"><\/span>Put Your Test Plan to Use with Rainforest QA<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Rainforest is a scalable, all-in-one quality assurance solution that\u2019s appropriate for small teams just getting started with automated testing projects or QA-mature teams regularly running 500+ quality software tests throughout the development life cycle.<\/p>\n\n\n\n<p><a href=\"https:\/\/www.rainforestqa.com\/talk-to-sales\">Talk to us<\/a> about setting up a personalized demo.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Learn how to write a software test plan. Get started with our practical guide and free template.<\/p>\n","protected":false},"author":32,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-358","post","type-post","status-publish","format-standard","hentry","category-qa-strategy"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/posts\/358","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/comments?post=358"}],"version-history":[{"count":16,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/posts\/358\/revisions"}],"predecessor-version":[{"id":3074,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/posts\/358\/revisions\/3074"}],"wp:attachment":[{"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/media?parent=358"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/categories?post=358"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rainforestqa.com\/blog\/wp-json\/wp\/v2\/tags?post=358"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}