Setting Up Two-way Jira Integration

For those with Jira 6.0 and higher, the Applause platform allows you to map your Jira issue statuses to ours. Status updates happen automatically in both directions.

Video Tutorial: Step-by-Step Walk-through

 

Two-way Integration Workflow

  • Changing the status of an issue in your Jira instance to a defined value such as “Ready for Testing,” triggers the associated Applause issue to be updated automatically to “Ready to Verify.”
  • From within the Applause platform, verification test cycles can then be created for issues with the “Ready to Verify” status.  
  • Bugs are verified by our testers as either fixed or failed, and are then Approved in the Applause platform.
  • Applause will update your Jira issue status to whatever state you desire.  Example: “Failed Testing” or “Verified.” 
  • Comments and screenshots from our testers will be included in your Jira issues.2wayjira_flowdiagram

Status Configuration Within Your Jira Instance

Before you set up the two-way BTS connection in the Applause Platform, make sure you have created all of the necessary statuses within your Jira instance. You will use these statuses to map to the Applause Platform bug statuses, and vice versa (See: How to create a custom Jira status). Once you have these established, you can begin configuration in the Applause Platform.

Test Jira Connection

With 2-way Jira integration allowing status updates on Issues to happen in both directions, there is a chance the customer’s Jira workflow will not support the Applause Platform when updating a ticket from Closed back to Open. Use the Test Statuses button to send a test bug update to your BTS platform. This will indicate right away if this feature will work. If not, you may need some adjustment in your Jira workflow.

Two-way Configuration in the Applause Platform

From the Product Edit/Create Screen…

  1. In step 4 (“Integrations”), after setting up your initial Jira connection and choosing field mappings for exported bugs, check the“Enable two-way Integration” box.
    • If you already have a Jira connection set up, you’ll need to click the “Refresh Connection” button in the UI to enable.
  2. Set up Jira to Applause mappings:
    • Map your appropriate Jira status (e.g. “Ready for Testing”) to Applause’s “Ready to Verify” status.  The values you see in the drop-down are being pulled directly from your Jira instance. (See: How to create a custom Jira status)
    • Then, map your next Jira status (e.g. “Verified”) to the Applause “Resolved” status.
  3. Set up Applause to Jira mappings:
    • An Applause bug which is set to “Verification – Fixed” maps to your Jira status (e.g. “Verified”)
    • An Applause bug set to “Verification – Failed” maps to your Jira status (e.g. “Failed Testing”)

enable2wayjiraWhen you click save you’ll be prompted to create a webhook on your Jira. We offer two methods for this:

  • Provide your Jira admin credentials (one-time only), and we’ll set it up for you automatically (we do NOT store your credentials)
  • OR, setup your Jira webhook manually 

Troubleshooting: If updates between the Applause Platform and your Jira are not working, the issue may be the workflow permission settings in Jira.  In some cases the “Verification failed” status in the Platform will fail to reopen a ticket in Jira. Make sure that the credentials used in our platform are given the correct workflow permissions for changing ticket status.

For a visual step-by-step walk-through of Two-way Integration in action, watch the video tutorial at the top of this page.

Bug Fix Verification

Bug Fix Verification (BFV) is the ability to confirm that you have have fixed the bugs that were discovered by the uTest community. This is done by allowing your PMs to invite any tester with matching devices/environments to verify bugs within the existing test cycle. Alternately, a standalone test cycle can be created and the original tester who submitted the bug will re-test. A second tester will verify if the bug you fixed was resolved.  Applause has fairly quick turnaround times for this, they can be done at any time, and the customer app has options to manage the BFV automatically.

BFV from the Current Test Cycle

 

 

Edit the current open test cycle or start a new, standard test cycle
Go to Step 2: Testing Scope > Known Issues and BFV
Select BFV Issues from the list of bugs and known issues. This creates a test case for the BFV and makes it available to testers who are already in the cycle. Remember to SAVE the test cycle for the changes to be implemented. 
  • BFVs, test cases and exploratory testing can all be run within the same cycle. BFVs need to be in the Known Issues list.
  • Requesting BFVs as part of a standard test cycle allows for iOS builds to be resigned.
  • Uses the same build / product version as the current test cycle.

Cloning Test Cycles

  • Does copy Regular/Generic test cases.
  • Does NOT copy the BFV test cases.
    • You can reselect in the new cycle. (Edit Test Cycle: Step 2)
  • Does copy Known Issues, unless the KIs had an NDA. Remember to reattach the NDA.

Standalone BFV Test Cycle

The action of “Verify” on either a single bug or multiple bugs can be done by kicking off a standalone Bug Fix Verification Cycle. This will create a test cycle automatically for each individual week in which you push a bug to BFV.
Reason to launch a separate BFV Cycle:
  • If there is a need to specify different builds for a BFV test case.
  • You need to guarantee a matched tester for a test case.
  • This will only allow BFV test cases. Exploratory and normal test cases cannot be included.
When you push your bug to BFV you will either attach a new build (mobile), or supply the URL for the site where the issue has been fixed.
  • Example: If you push bug #50001 to bug fix verification on January 20th, a test cycle for that week will be created and any other bugs you push for the week of Jan 20-26 will all be there. If you push bug #50020 on the 27th, it will be in a separate cycle.

Once a cycle is created, the original tester + one additional tester who has the matching environments will be sent an invitation to verify if the bug still exists. The testers will report back their findings in the form of a Pass or Fail test case. Let the testers know whether or not to submit a new bug if the verification fails, or if they should just to mark it as failed (the latter is the case 95% of the time). Upon completion the bug will be either marked Fixed or Not Fixed, based on the Pass/Fail of the test case.

BFV via Bug Tracking System

The majority of our customers prefer to take the results of our test cycles (i.e. bugs) and export them to their native BTS (e.g. JIRA). This allows your to manage the subsequent work with your development teams. In each BTS export, there will be a deep link embedded in the issue description that, when clicked on by the customer, will send an API request back to the platform to add the bug verification request as a test case to the weekly queue.
Learn how to set up your BTS.
Applause also supports Two-Way Jira Integration.

BFV by the Bug(s)

  • Within your test cycle, open the specific bug report and Select the “Options” drop-down menu. Select “Request Verification”
  • The Issues Grid/List will display all bugs. Using the check boxes, select all of the bugs you want to push to a bug fix verification cycle
    • At the top left of the list, select “Verify” from the menu
  • Follow the prompt and either attach a new build or provide the test URL, and any notes about the fix you want to tell the tester.
  • Important: For those who are iOS testing and using Applause’s resigning tool, resigning is not supported for Standalone BFV cycles.
    • Option 1: Request the BFV from the original cycle.
    • Option 2: Upload the build in a new different cycle to auto-resign, and then select that existing build for your BFV.
  • When asking for verification within the current test cycle, the test cases are created and notifications are sent out right away.
  • Standalone BFV cycles will be queued up in a scheduler and will show up about 10-15 minutes later depending on the number of bugs that have been pushed for verification.

DX – Release Notes – April 26th 2017

Here’s an update of what we’ve recently completed for DX, and a preview of other exciting things to come.

Return to Release Notes Home or Release Notes – Archive

Feature Progress

Journey Results
Viewing Task Details
This is our next step into providing you real value by presenting results in a way that is easily consumable and actionable. You can now click into any task from the Journey results to see an aggregated summary of responses across all participants, e.g., all the feedback/rating/input for a given task. And you’re one click away from downloading images and playing recordings!

Project Management

  • You can now extend the end date of a Project, and add Participants to an active project!
  • You can now add your own participants to a Project by specifying an email domain (e.g., @applause.com), so anyone who has that email domain will see the Journey via the Companion app. This way, you don’t need to invite people one-by-one.

Upcoming Work

Push Notifications
DX Companion Apps
Notifications will inform participants about new journeys for both Android and iOS Companion apps.

Video Pausing
Companion Apps
Goal:
Participants will be able to pause their screen recordings. Allowing them to avoid the recording of sensitive PII data such as payment instrument details, passwords etc.

Issue Reporting
Customer Web and Companion Apps
Goal: 
You’ll soon be able to enable Participants to report issues (aka bugs) during an Journey, so you can find important issues along with collecting general feedback.

As always, please reach out with any questions and feedback.

 

 

 

 

 

DX – Release Notes

Get the latest updates and feature improvements from the DX team.

May 11th, 2017

Web Updates

First, prepare you eyes. We now have…. COLOR  in our app!
Much more than color though, we’re rolling out an updated design which begins the process of aligning with a new Applause brand already visible on Applause.com

We understand it’s all about the results. As such, we’ve continued building out our capabilities on this front.

Building onto the previously release features showing “summary level” data of all participant inputs across a project, we now have some nice visuals:

  • Bar charts – for showing task completion, as well as showing responses from questions with multiple (checkbox) answers.
  • Pie charts – for showing % of participants who completed a journey, as well as showing responses from questions with a single choice answer (radio buttons)
  • Free text responses
  • A “gallery” view of images and video inputs from participants, allowing you to go from one to the next very easily.
  • Ability to download images/videos

 

DX Companion App Updates

iOS:

Preparation for Bug Reporting and Push Notifications (not released yet).

  • Working toward allowing bug reporting in journeys
  • Also some behind the scenes work related to receiving push notifications

Android:

Push Notification Settings:

  • Participants will soon be able to set notifications as they desire:

Pause and Restart Video

  • If a Participant has something sensitive, for example, as part of the workflow they are recording, they can pause and resume the video. We stitch it together seamlessly for you.

 

Known Issue Management

Known Issue Management (KI) was developed to save time, improve bug relevance, and provide faster turn-around time for test cycles. This feature allows you to carry over issues that are known in the platform, into new test cycles. Known Issues can also be shared with testers so they don’t report duplicate bugs. 

Video Tutorial: Step-by-Step 

 

Adding Known Issues to Test Cycles

Any issue that is Approved in the platform will be automatically flagged as a “known issue.” If an issue is Rejected the dialog box will still give you the option of marking it as a “known issue.”  
ki_approvedki_reject

In Step 2 of the Test Cycle creation (or edit) workflow in the Customer App, the user is OFFERED the ability to select Known Issues to carry into the Test Cycle. This is optional. The user can choose all, some, or none of the Known Issues to carry into the test cycle.

ki_schooskis

Even though a bug may be marked as a Known Issue, it will NOT be visible to testers unless you specifically add the bug to a particular Test Cycle.

  • A blue “bookmark” icon is used to indicate Known Issues in the title column
  • A white, or unfilled bookmark indicates an item that is no longer a known issue (but it was a known issue at the time of the particular test cycle you are viewing)

Note: If any of the Known Issues that are being carried into the new Test Cycle were originally from Test Cycles that had NDA’s, then an NDA will be required.  

Cloning Test Cycles

  • Cloning a test cycle that did not leverage known issues does NOT add any known issues to the new cycle (as expected)
  • Cloning a test cycle that had known issues in it DOES carry in those same known issues into the new cycle. In the Customer app, this means those items are pre-selected in the Test Cycle Known Issues section, but you can still choose to de-select those, and/or to select other Known Issues to be part of the new cycle.

Viewing Results

When reviewing test cycle results, known issues are separated in their own tab, so they are conveniently located, but not mixed in with new issues reported in this test cycle. Keep in mind, previously known issues are NOT included in any reporting for a given test cycle. 

Removing Known Issues

Users can manually “Unmark as Known Issue” anytime from the bugs list or bug detail page.

  • When a bug is marked as “Resolved”, the bug is automatically removed from the known issues list. Same is true if bug passes the in-Platform bug fix verification (BFV) process.
  • If a Known Issue is marked as “Won’t Fix”, then the bug remains a Known Issue, but can be unmarked manually.
  • If a bug is Resolved, and then is later marked as a Known Issue, then it will also be marked as “Unresolved”.

Bug Fix Verification

When a bug goes through the BFV process within the Platform, if it is ultimately marked as “Fixed” by the tester, the bug will automatically get removed from the known issues list. If the bug is marked as “Not Fixed”, it will remain as a known issue.

Tester View

Known Issues will be displayed along with regular Issues from the Test Cycle in the Issues tab.  A bookmark icon indicates if an issue was reported from a previous cycle. Hovering over the bookmark provides information on which test cycle the issue was originally reported in.

Clicking on a Known Issue will show the issue with a special banner to indicate it was reported in a previous cycle:

When testers try to submit an issue that is “like” (contains similar words), they receive a warning that it may be a duplicate of an already existing (known) issue.

How To Integrate With YouTrack

For basic integration information, please see:  ‘Integrating With Third-Party Bug Tracking Systems’.

Applause supports the following versions of YouTrack:

  • YouTrack Versions 6.0 or later

Integration with YouTrack Implementation

bts_integrationsetup_youtrack

Select the ‘YOUTRACK‘ option in the ‘Connector Type‘ menu.

Helpful Hint:  For easier tracking, create a new user within your user system with Applause in the name. This will help you quickly locate bugs exported from Applause into YouTrack. It is important to assign project visibility in YouTrack to the account being used for the connection in order for bugs to appear.

After selecting YouTrack for your new connector, you will be presented with a number of fields.

  • URL:  Configure your web-based access to YouTrack, The URL should end with: ‘/youtrack’.
  • User:  Case sensitive. Requires the username to have create and save permissions within the YouTrack system.
  • Password:  Case sensitive.
  • Project Key:  Case sensitive, The key of the project you wish the exported issues will be associated with.

NOTE:   We do not support two step authentication at this time, only basic authentication.

For information on further customizing your BTS integration, please see: “Working With Bug Tracking System (BTS) Integration Connectors”

New Applause Platform!

Welcome to our brand new platform which offers increased usability, refinement of existing features, and new capabilities. This update was based on extensive feedback from our customers and addresses common pain-points and feature requests. We hope you enjoy it!

 

 WHAT’S NEW?
Get familiar with new features!

Watch the video for a walkthrough of new features.

 

 

GAME CHANGING FUNCTIONALITY
2-way Jira Integration: For Jira 6.0 and higher, you can map your Jira issue status’ to ours, so status updates happen automatically, in both directions!

 

 

Known Issue Management: Any approved bug will get flagged as a “known issue,” and allow you to carry it forward into future test cycles so that testers see them, and won’t report the same bugs. Watch the video for a step-by-step walkthrough.

 

An Improved User Experience:
  • A fully responsive web page (works well on mobile!)
  • A separate chat app (also works on mobile)
  • New Issues view to enable easier bug triaging
  • New view of test case results – quickly and easily see where something failed

Better Bug Quality:

  • Define App components to define your test cycle scope and view bug results by component
  • Defining your test cycle scope is also improved with the help of a best practices template

Better Reporting with Test Cycle Summary Charts: 

  • View nice charts and graphs to see bugs by value, status, app components, etc.
  • See testing coverage (devices, environments, etc.), and export to CSV file for slicing and dicing