You should review these questions first if you have questions about the Applause platform. Whenever you need assistance, please open and fill out the contact support form with all the relevant details and we will get back to you shortly.
Applause Platform
This section answers questions related to the Applause platform.
What browsers is the Applause platform supported on?
- Chrome 39 and above
- Firefox 34 and above
- Safari 7.1 and above
Account and User Management
This section answers questions related to your account and user login.
How do I reset my password and fix login issues?
- Navigate to platform.applause.com.
- Click the “Forgot password” link.
- Open the email you received from Applause and click the link to change your password. Your password will be saved and the platform dashboard will be displayed.
This process needs to be done completely from a regular browser tab, not the private/incognito mode. This includes requesting the password reset email and opening the reset link/URL.
What can cause the reset password link to expire?
- More than 2 hours have elapsed since the password reset email was requested
- You have navigated to the password reset link URL more than one time
Try copy-pasting the provided URL into a new browser tab. Do not click the email’s hyperlink as some email clients have been known to alter the URL when clicking the link directly.
Once you’ve set or reset your password and you click the link to login, some users will see this error: We're sorry. An error occurred, please login again through your application.
To solve the issue, go to the login page and login with the password you just set. Try a private/incognito browser tab if a regular one isn’t working.
Click the checkbox “Disable all email notifications” in the Account Preferences page.
Getting emails for a product / team that I am no longer a part of. How do I update that?
- Log in to the Applause platform and navigate to “Account & Settings”.
- Click “User Management”.
- Navigate to the team that you want to update, then click on the “Edit” button.
- Change the role option for your user to “None” from the “Team members and roles” section.
- Click the “Save” button.
If you still have any problems, contact your SDM or TA/TSM they should be able to help you with that.
Follow the appropriate section in the User Management course.
Follow the appropriate section in the User Management course.
See this course.
Products
This section answers questions about your products.
If your website, Android or iOS app is not accessible from the outside, we recommend white-listing the Applause proxy, so that testers can access your test product for the project’s duration.
You should configure your firewall or security settings to permit the following IPs for the Applause testers to access your test object: 100.26.65.148. If you do this, please make sure to let your Applause Delivery team know, as instructions will need to be provided to testers.
See this course.
Whether you are interested in a lightweight automated sanity check or full-blown automated regression testing, contact us or your account manager to learn more. You can also check out our eBook 5 Ways to Win with Mobile Automation.
Test Cycles
This section answers questions related to test cycles.
When you draft a test cycle, you will have the option to set different test cycle types under the Details section, with radio buttons for a Single Test Cycle or Continuous Test Cycle.
In many cases, you’ll want to have a targeted focus for your testing, which is what a Single Test Cycle is for. This type of cycle allows you to design and refine your testing goals to align with a single specific goal – whether reproducing a specific type of problem, or focusing in on a particularly troublesome feature, or trying to squeeze out the last remaining showstopper bugs on a final build. Ultimately, the goal of a single test cycle is up to you.
While a single test cycle is valuable for all kinds of customers, in our experience we’ve discovered that groups that develop with a Waterfall methodology, or within longer sprint or agile cycles, find the single test cycles especially beneficial to their product.
Conversely, the idea of a continuous test cycle is to set up for testing the same application or product over and over again. With a continuous cycle, developers can upload new iterations of builds to the active test cycle, which allows for a more rapid turnaround time on bug fix verifications or feature iterations.
Another benefit is that your cycle prep is quite limited – you’ll use consistent messaging and a persistent defect tracking database, meaning your verifications will occur within the same cycle with little lost, as opposed to closing an old cycle and opening a new one.
There are some downsides to a continuous cycle – major changes to your testing focus or scope during a cycle should be avoided as it can cause confusion for your test team for example. But in our experience we’ve found that customers who develop in an iterative agile model of less than 1-week increments, or for when recurring regression testing is needed, that the benefits are substantial.
As testing is executed by the Applause Community, the testers will be submitting issues when encountered. The triage process ensures issues are documented at the right level of detail that will allow your teams to attend, prioritize and ultimately fix them. “Good” issues are approved, “bad” or irrelevant issues are rejected, questionable issues are returned to the testers for clarifications and so on until all issues are triaged.
First, it is important to acknowledge that prolonged triage time is the symptom, not the cause. Clearly, when noticing that you may want to get right to completing triage, however at the same time it is worth spending time understanding the reasons for the increase in triage completion time in order to improve for future testing.
Here are a few directions to further investigate slow triage time:
- Have the responsibility for triage recently moved from your Applause team to your team? Quite commonly your Applause team will be used to deliver a fast triage, and shift in responsibilities may have introduced a learning curve.
- Was there a recent change in personnel - specifically whomever is responsible for triage in your team - that may have resulted with lost knowledge of your product, triage process and/or bring different subjective views on what are relevant issues? Changes are inevitable, yet documentation and knowledge transfer are key to ongoing success.
- Were there any competing priorities and/or resource difficulties preventing your team to complete the trige at the pace you normally do? Will you classify such challenges as temporary or permanent? Granted, long-lasting stretching of resources may impact future testing.
- Was there a temporary personnel matter, such as vacations, sick leaves or holiday, that may have prevented whomever is responsible for triage to complete it on time? Make sure resources are covered in such cases, and ensure awareness with your Applause team.
- Whatever the issue, you are advised to collaborate with your Applause team to further troubleshoot the causes for the prolonged triage time, and identify improvement opportunities in your processes and testing strategy.
For the most part, your TTL will be reviewing the submitted issue first and provide you with their triage recommendation. This integral step in the Applause crowdtesting model is aimed to reduce the “noise” and ultimately make your work more efficient by working with the testers on perfecting the issue reports, ensuring issues are reproducible and revisiting the assigned severity level.
The TTL recommendations are, indeed, recommendations and you are able to rule them out as you see fit. Such disagreements, obviously, only introduce more “noise” to the process and it is thus important to revisit them when they occur as a great opportunity for improvement.
How to investigate disagreements with your TTL’s recommendations?
- How clear are the release notes provided to the Applause team in describing how the product and/or new functionality will be used by the end users? Value, severity and relevance of issues might be subjective at times and members of your Applause team need to understand what you care about
- Can the list of Known Issues provided to the Applause team be improved (or updated) to better reflect all issues your team is already aware of? When you reject the issues approved by the TTL it often means they were unaware of previously-found issues you already prioritized
- Was there a recent change in personnel – specifically in the interface between you and the Applause team – that may have resulted in lost knowledge about the triage process and/or bring different subjective views on what are relevant issues? Changes are inevitable, yet documentation and knowledge transfer are key to the ongoing success
- Whatever the issue is, you are advised to collaborate with your Applause team to further troubleshoot the causes for frequent disagreements with your TTL recommendations and identify improvement opportunities in your processes and testing strategy
See this course.
Consider using the Applause SDK.
Issue Reports
This section answers questions related to issue reports.
See the Issue Report Details course.
Yes, you can. Follow these steps:
- Open the test cycle you want the tester to provide more info, by default the list will hide all closed test cycles.
- To show the closed test cycles check the box next to "Show Closed Cycles".
- Click the Issues tab and open the issue report.
- Send a message to the tester via the tester messenger.
Follow the Issue Export course.
Issues that can not be reproduced at a later time, should be approved as “Won’t Fix” or should be rejected as WAD (Works as designed). Also remember that you can ask for more information from the tester to verify if the issue still exists or not or to provide more info if needed.
Bug Tracking System (BTS)
This section answers questions related to BTS.
Jira API only returns the fields that are visible on the form when adding a new issue of a specific type to the given project so the list of fields is configurable for each individual project and issue type combination, plus proper permissions need to be in place.
To show an example from JIRA using the Reporter field, when creating a new issue, we have this screen without the Reporter field.
- Click on “Configure fields” in the top right corner and click the link “Where is my field?“.
- In the popup, enter the field name to discover where the problem is.
You should configure your firewall or security settings to permit the following IPs for the Applause platform to access your Bug Tracking System remotely:
- 23.21.127.192/28 (CIDR notation)
- 23.21.127.192 to 23.21.127.206 (range notation)
Our platforms rely on customElements. Some versions of browsers do not support this by default (i.e. Firefox v59-62 and others listed here).
You can enable this by going to about:config in your browser’s URL box and enabling the following:
- Enabled through the dom.webcomponents.enabled preference in about:config
- Enabled through the dom.webcomponents.customelements.enabled preference in about:config