To learn more about the Test Designer, read our help article here.
- Specify the environment and let us know if you’re using more than one.
- Ensure that the environment is accessible 24/7 - most test writers are in different time-zones and they should be able to access the environment at any point. If there are any known limitations (for e.g. down time during weekends for maintenance), please let us know when you submit your tests.
- If required, the environment should be able to support multiple concurrent testers.
- Does the environment have any IP limitations? If yes, let us know so we can proceed accordingly.
- Communicate any major known defects in the app or test environment.
Credentials. This goes hand in hand with the point related to the environment, above - provide a working set of credentials, when required.
Good instructions. What qualifies as a good set of instructions?
- A descriptive title: Think of something that will help you identify it and use it later when you add it to a feature folder and/or run group(s).
- A brief but descriptive test outline: There should be detailed instructions on what the tester should do. If testers do not have enough information, they will make assumptions to move forward and this may not align with the desired outcome. Ensure that there is no ambiguity in the outlines and that there is a helpful indication of what the expected outcome of the test should be, so test writers know if something is working as intended or not.
- No business-specific or sector-specific jargon: To make the outlines as test writer friendly as possible, do not use business jargon in the instructions as much as possible. There’s a good chance that this will be the first time test writers are encountering the app and may not be familiar with it. Be as obvious as possible, try not to use terms that are not already reflected in the app and use business jargon only if there’s a clear explanation of what it means.
Good examples of Test Outlines that have yielded green tests on first run
- Use video, if possible: The preferred method of input is video as this provides better clarity for test writers because the video contains a visual of what the test should cover. Video walkthroughs should be a narrated recording of your screen or window that walks through the functional test you want created. To help clarify what needs to be written, be sure to narrate the actions you are taking and the expected results you need verified in the test. Verify that the video is accessible and that test writers will not have to request permission.
For more information on how video walkthroughs work, read our help article here.
An example of a video walkthrough can be found here.