Course 1: Best Practices for Test Cycles

Best practices that will help you get the most out of your test cycles.

Best Practices for Test Cycles

This course will provide you with information and the best practices that will help you get the most out of your test cycles. By following these, you will enable your Applause management team to set up the most thorough and comprehensive test cycles.

Copy a Previous Test Cycle

It is always recommended that you copy a cycle based on a previous cycle. Copying a cycle will carry over all scope and instructions, as well as the testing team and TTL from the previous cycle. That said, please be sure to review the cycle instructions that are carried over to make sure that the information is still relevant to the current build.

Define Clear and Specific In-Scope vs Out-of-Scope

It is very important that you provide details about what you hope to accomplish in each test cycle. Clearly defining scope guidelines for testers will enable your Applause team to test apps with a more targeted approach and deliver results that are relevant and useful to your business. For best results, be prepared to provide the following.




Testing Focus

A high-level overview of the functional areas of the application so testers can arrange and execute their testing accordingly.




New Items or Changes for The Build

This is a detailed export and description of release notes of the specific fixes or features implemented in the build to provide better testing focus and results. Please be brief and descriptive. Testers will need to understand these changes so that they are fully covering the application.




Bug Values and Examples

Provide a list of specific issues that you consider to be Exceptionally, Very and Somewhat Valuable. This shows the testers what is most valuable to you.




Known Issues

The Known Issues list should include both your internal issues and all issues submitted by Applause in previous cycles. Review the Known Issues section.




Out Of Scope

Define areas of the app that should not be tested, including areas that may still be in development that you do not want the testers touching. This helps to ensure that all bugs are relevant.

Cycle Naming Convention

Testers will frequently be invited to numerous cycles at the same time, so naming your cycle accurately helps with clarity and can attract more testers to the cycle. A good test cycle name typically includes the name of your company or product, the type of testing taking place and the start date.




Good Examples of a Test Cycle Name
  • Applause, Inc. - New Chat Features - 9/22/2020

  • Applause, Inc. - Android v2.1 - Functional testing - 9/23/2020

Activation Timing

When setting up and activating your cycle, take into consideration the duration and lead time of the cycle.




Cycle Duration

The length of a cycle will vary depending on what offering you have purchased, your specific testing goals, the maturity of your product, etc. Your Applause management team will be able to assist in determining the ideal cycle duration, but typically we recommend no more than 3-5 days for a test cycle.




Lead Time

It’s important to give your Applause management team adequate lead time before kicking off a new build so they can search for and prepare the testing team. You should consult with your team to determine the necessary lead time.

Get to Know Your Testers

Don’t be a stranger – they are real people, too. You can learn more about your testers by checking out their uTest profile — simply click on the tester’s name either in the Dashboard, the Testers tab in the left navigation bar or directly within the bug report.





Favorite Your Best Testers

Have you noticed a rock star tester in your cycle? Would you like to see them participate in future cycles? By favoriting a tester, they are more likely to appear in your future cycles.




Don’t be Afraid to Ask Testers to Provide More Information

Testers are contractors for uTest and are testing on their own will, but that doesn’t mean you can’t ask them for clarification or push them to expand (as long as it’s within scope). Treat them like they are just an extension of your own team and reach out to them through the Platform directly when you need to.