The ITS Team will be performing maintenance on Confluence beginning at 6:00 pm Tuesday, May 6. During this time the service may go offline. It should be available again by 8:00 pm. Please refrain from editing pages during this time to avoid losing your work.
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:
- Developers assign specific features for testing on an as-needed basis
- 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:
Useful JIRA guides
Making screencaps and screencasts
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:
- 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.
- 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.
- 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.
Useful JIRA guides
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.