Make a test plan

- Each feature should have an associated test plan. and edge case scenarios to describe how a feature should function, examining it from many angles. During the definition phase, a QA engineer will start to create a test plan for the feature. This way there is ample time for it to be completed, reviewed, and executed before the test plan is over. The test plans I create have four main parts. First there is the scenario, which explains the steps or action that will be executed. Then there is the expected result, which describes what the outcome will be for a given action. Next there is the latest result, and last, there is a field for whether or not the scenario will be automated. This will either be true or false. There is one unique scenario per row. Let's go through an example now. Say I'm working on a new feature for user management. This feature provides the ability to add and delete users, or edit a user's profile. If I focus on each of these user management areas, I can brainstorm a long list of scenarios. I'll first dive into defining scenarios for adding a user. Say I want to click a button to add a new user. Once I click, the expected result will be that the create user modal opens and has two required fields for username and email. There is a create user button that becomes enabled once the fields are populated. After the feature is implemented, I'll check if this passes or fails based on the expected result. It's likely that each scenario will be checked multiple times or by different individuals. So every time the check is done, the latest result can be updated. The last part of the scenario is whether it should be automated. Adding a new user sounds like an important feature, and likely something we're going to want to know always works. Therefore, this is a good candidate for automation. After defining one scenario, I can move onto other scenarios for adding a user, and then editing and deleting users. Once a test plan is complete, I end up with anywhere from 10 to 100 scenarios. The number doesn't really matter so much. What's more important is that the test plan identifies all the possible actions the user can take when using a feature. When a test plan is complete, have a review meeting Send out the test plan to attendees to asynchronously read through the scenarios and identify gaps or fill uncertainties. Once all the feedback has been addressed and the test plan is solidified, it can then be referred to later when testing individual components or stories of the feature as they become complete. In addition to reviewing the test plan as a group, I've seen great success when a team does group or mob testing together for 30 minutes to run through each scenario in the test plan. This happens in advance of the release and can give team members the chance to use the feature across different browsers, platforms, or devices. across different browsers, platforms, or devices. A test plan is a living document that should be updated A test plan is a living document that should be updated as scenarios change and as tests are executed. as scenarios change and as tests are executed. It is a valuable artifact to have for every feature It is a valuable artifact to have for every feature of an application. of an application.