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.
This section answers questions related to the Applause platform.
This section answers questions related to your account and user login.
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.
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.
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.
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.
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:
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.
See this course.
Consider using the Applause SDK.
This section answers questions related to issue reports.
See the Issue Report Details course.
Yes, you can. Follow these steps:
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.
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.
You should configure your firewall or security settings to permit the following IPs for the Applause platform to access your Bug Tracking System remotely:
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: