This is guide is an overview to testing the Mandala suite of tools. Use it in conjunction with the Testing Checklist, which includes specific items to check, for best results. 

There are two situations in which you'll have to test: 

  1. Developers assign specific features for testing on an as-needed basis
  2. Developers have released major updates, and need you to test major functions before a release

Bug report best practices

Before reporting

Make sure the bug hasn't already been reported by searching through pre-existing JIRA issues. If the bug has been reported, you can add a comment to the existing issue (if you think the specific context in which you encountered the bug is useful to developers, or if you think the bug should be a higher priority. If the bug hasn't been reported, make a new JIRA issue.)

Useful JIRA guides

Report content

A bug report should include: 

  • Your operating system and browser, including versions.
  • A summary of the issue. 
  • The steps developers should take to reproduce the bug. Be as explicit as possible, and assume the reader has never used the tool before. 
  • The results you expect to see in the absence of the bug. 
  • What actually happens if you take the steps to reproduce. 
  • The URL of the page where you're encountering the bug. You should copy and paste this from your browser's address bar. 
  • Any screencaps or videos as needed. This is especially important for visual issues or animation issues. 

To keep things organized, you can copy and paste the template below into the ticket text: 

*Operating System and Browser:* 
 
*Summary:*
 
*Steps to Reproduce:* 
 
*Expected Result:* 
 
*Actual Result:* 
 
*URL:*
 

Make sure your new ticket is in the "Mandala United" project. You should also add the appropriate "Component" (usually the tool name) to your bug. Here's an example of the report form: 

 

 

Assigning tickets

If we're testing major functions on stage or prod, you should usually assign issues to Than Grove, who will then distribute the bug to the rest of the developers. If you're testing a specific feature from a specific developer outside a major testing push, you should assign the bug to the original developer. 

Linking tickets

Make sure the bug hasn't already been reported by searching through pre-existing JIRA tickets. If the bug has been reported, you can add a comment to the existing issue (if you think the specific context in which you encountered the bug is useful to developers, or if you think the bug should be a higher priority. If the bug hasn't been reported, make a new JIRA ticket.)

Useful JIRA guides

You should link your new bug to the original testing request JIRA issue, if one exists. This helps people see all the bugs that resulted from that test at once. 

After reporting

Don't ignore the ticket! Keep an eye on comments – developers might need more information from you. Once developers have fixed the bug, you'll need to retest to make sure it's been fixed on your end. 

Broad-scale testing

Procedure

Than Grove will define the scope of the test. In general, this means telling us which of the Mandala tools need to be tested, and which development stage should be tested. There are three stages of development: 

  1. dev (development) on https://mandala-dev.shanti.virginia.edu/: this is where developers experiment and develop the code. Most testing on here will be as-needed. 
  2. stage on https://mandala-stage.shanti.virginia.edu/: this is where developers push the code after the development phase. This triggers a major testing phase to make sure the entire site is free of bugs before it goes out to the public. 
  3. prod (production) on https://mandala.shanti.virginia.edu/: this is the public-facing Mandala site. Ideally, is this site should be bug-free.

Most major testing phases will happen on stage. The development team may have deadlines or goals for when they "push" the code to move on to the next stage, and all testing should be done before the push.  

Rennie Mapp will usually assign JIRA testing issues to the testers. This lets us know the area and task we need to test. Sometimes, however, Rennie will only assign a few tools to start, and testers can pick up more tools as they finish testing their assigned tools. When you assign a new tool to yourself, just make sure to link it to the original testing issue Than created, and assign it to the "Testing" component. 


Example

Here's an example of an issue Than creating for Mandala release 7.x-1.4, MANU-4072. You'll see that all bugs and testing issues are linked to that issue. You can also see the sorts of bugs that turn up during testing. You can also see that some of the bugs are marked "Testing." That means the developers have fixed the issue, and are ready for the original reporter to recheck that it has been fixed.   

  • No labels