LDSTech Swarm

(Redirected from Swarm Tester help)

Swarm Tester is a browser-based, crowdsource testing tool used to test Church applications.


With Swarm, you can enter all your test cases and then send volunteers a link to the test cases. The volunteers can then mark each test case as pass or fail. If marked as fail, Swarm prompts the team member to add a note explaining why it failed.

For test cases that fail, Swarm creates a JIRA item with the volunteer's note about the failure. Subsequent volunteers who fail the same item will have their failures added as comments below the same JIRA item. This way Swarm organizes feedback from volunteers in a centralized way that is easy to process.

When volunteers log fail test cases, those test cases are automatically added as bugs in JIRA for the project.

Getting started

If your project is already listed on LDSTech, you simply need to edit your project settings and select the Swarm check box. Because Swarm ties in with JIRA, you must also have a JIRA instance set up for your project. Project leaders can edit their project settings.

To edit your project settings:

  1. Sign in to LDSTech.
  2. Click Projects, and then click Management on the subnavigation bar.
  3. Click edit below your project name.
  4. Update the JIRA and Swarm settings, as well as any other project information.
  5. Click Save.

If your project is not listed on LDSTech, contact one of the following LDSTech team members:

See the LDSTech Swarm page for more details on Swarm.

What does crowdsourcing mean?

Crowdsourcing chunks up work into small parts and distributes the work to a large number of people. The tasks are small enough that they can be accomplished in a few minutes. This allows volunteers to contribute as little or as much time as they can.

Displays well on any device

Swarm was built with responsive design, meaning it can display well on any device. In fact, Swarm was purposefully designed to display exceptionally well on mobile and tablet devices (in both portrait and landscape views) so that volunteers can do testing in any situation where they have a few minutes, such as standing in line, waiting for an event to begin, traveling in the car, or other situations.

The following image shows the Swarm's display on an iPhone:

These four screens are what users see when using Swarm on an iPhone.

Useful situations for Swarm

You can use Swarm in any kind of testing situation. Usually quality assurance engineers will use Swarm to test for bugs in software, but you can also test the accuracy of documentation, the user experience on a website, or other solutions you want feedback about. Swarm is simply a tool to harness and organize feedback from volunteers.

Why not just use internal testers?

Swarm provides several key advantages for your project:

Testing variety

By involving the community to test your application, you benefit from testing variety. Depending on the number of volunteers testing, you get a diversity of feedback from users, potentially covering all of the following:

  • Platforms -- iOS, Android, BlackBerry, Windows
  • Devices -- iPhone, Android, Windows, BlackBerry
  • Carriers -- AT&T, Verizon, T-Mobile
  • Callings -- clerks, bishops, stake presidents, auxiliary leaders, website administrators
  • Bandwidth -- dial-up, residential, broadband, bandwidth-limited
  • Browsers -- Opera, Safari, Chrome, Firefox, Internet Explorer 6,7,8,9
  • Locations -- South America, Africa, Europe, Asia
  • Computers -- PC, Mac
  • Operating systems -- Windows 7, Windows 98, Mac OS, Linux
  • Languages -- English, Spanish, Portuguese, Russian, Chinese, Korean),
  • Units -- branches, wards, districts, stakes, missions
  • Skill levels -- novice, intermediate, advanced, ninja

It's not likely that internal testers can replicate all the possible user experiences of an application.


When you're getting ready to release an application, you usually need to scale up your number of testers. After the release, you no longer need the same number of testers until you approach your next release. If you rely only on internal testers, you end up with resource problems for the times when you don't need a lot of testers.

With the Swarm community model, you can recruit testers for a specific project. The LDSTech community already has thousands of volunteers waiting to be engaged. Once your testing phase is over, you can generously thank the volunteer testers for their help, keeping them in place for the next period of testing but without having any obligations to fill their workload during non-testing periods.


If you have budget constaints and need a less expensive option to test your application, Swarm is the right tool for this. There aren't any costs at all for using Swarm in the LDSTech community. In fact, the LDSTech project framework automatically stands up an instance of JIRA for your project, as well as Google Groups and other project resources.

Swarm requirements

Swarm has the following requirements:

  • You must have a project set up on LDSTech to use Swarm. For more information on setting up projects, see 1. Get set up (project managers).
  • Volunteers must be a member of your project to view your Swarm test cases. See 2. Join a project (volunteers) for more information.
  • You can only have one instance of Swarm per project.
  • You must have an LDSTech instance of JIRA set up for your project to use Swarm.

Rights with Swarm

Anyone who has a role in your project other than Observer can add and edit test cases.

Accessing Swarm

To access Swarm, go to

Adding an instance of Swarm to your project

By default, your project should already have an instance of Swarm available. Go to to view the list of projects with Swarm.

If your project doesn't have an instance of Swarm, you must edit your project settings and select the Swarm check box. Because Swarm ties in with JIRA, you must also have a JIRA instance set up for your project. Project leaders can edit their project settings.

To edit your project settings:

  1. Sign in to LDSTech.
  2. Click Projects, and then click Management on the subnavigation bar.
  3. Click edit below your project name.
  4. Update the JIRA and Swarm settings, as well as any other project information.
  5. Click Save.

Adding test cases

Currently you cannot re-order test cases, so if the order matters, make sure you add the test cases in the order you want users to proceed through them. To add a test case:

  1. Go to Swarm:
  2. Click your project.
  3. Click Edit in the upper-right corner.
  4. In the Add Test Case box, type your test case, and then click Add. By default, the test case will be active. If you want to deactivate the test case, remove the check box in the Active column.
  5. Click Save at the bottom of the screen.

How should I write my test cases?

Test cases are simple statements, about the length of a tweet, that instruct the user to complete a task. For example, with Mormon Channel for Android, here are a few test cases:

  • Upgrade: Install the current version in the store, overwriting the version on your device
  • Catalog: Rotate screen; verify that the state (scroll position, etc) is preserved on rotation
  • Annotation: Create overlapping annotations -- make sure each is accesible
  • Navigation: Delete a window (multiple windows)
  • Catalog: Remove a single general conference

Currently, the maximum length for a test case is 160 characters. The character limit for test cases is purposefully short to encourage simplicity with the tests.

Note that you do not need to include step-by-step detail for each task. As you can see in the Mormon Channel for Android test cases, the test also explores whether the interface is intuitive enough for the user to figure out how to do the task without following a detailed list of how-to steps.

If you want users to test more lengthy procedures, consider breaking up the procedure into several individual test cases.

Versions for Swarm tests

You can version your Swarm tests so that all JIRA items created for failed test cases include a build number. By adding a version number, when users pass or fail test cases, the build information is included in the test case report. For failed test cases, the JIRA item includes the build number in the bug description.

To add a version for Swarm test cases, append the build number after a forward slash at the end of your swarm project URL.

For example, suppose the URL to your Swarm project is, as is the case with the Mormon Channel for Android Swarm project. You can include a build number by sending users a URL such as

When users click the link, Swarm inserts the Build number into the Build box shown on the test case screen that users see. When users pass or fail test cases, the build number that appears in that field is included in the test case report.

Note that any text you insert into the Build box is client-side only, so if users decide to change the build number, when they pass or fail test cases, the changed number will be included in the test cases.

Viewing testing stats

You can view testing statistics by clicking the Stats link at the top of your Swarm project.

Project leaders see testing stats showing the number of passes and fails for each test case. The passes and fails are shown in a bar and chart graph, with the ability to adjust the graphs based on date ranges, projects, builds, and users.

Regular users can also see testing stats, but the statistics are filtered by username, limiting the view to the user's statistics only.

Known limitations

The following are known limitations with Swarm:

  • You cannot delete test cases.
  • You cannot re-order test cases.
  • You cannot have multiple versions of test cases running at the same time.
  • You cannot have multiple instances of Swarm.

Swarm roadmap

Swarm is in early beta. Features projected for the next release include the following:

  • Categories for test cases
  • Dynamic filtering based on category selection
  • Ability to re-order test cases
This page was last modified on 4 February 2013, at 23:21.

Note: Content found in this wiki may not always reflect official Church information. See Terms of Use.