3 min read

Tips for Being a Successful UAT Tester

By Luis Machado on Jul 9, 2021 12:48:44 PM

Blogpost-DisplayImage-July_Tips for being a successful UAT tester

User acceptance testing (UAT) is a critical practice to employ for a multitude of products and processes.  For the purpose of this article most of my examples will be within the context of migrating or merging instances for Atlasssian products. Nonetheless, these tips can be used for other avenues: I actually picked up these habits working as a QA tester for a video game publisher.

Context is king

When testing a product or a process, such as a migration or a merger of two instances, if you come across any issues, the most important thing you can do is provide as much context as possible so the developer or admin whose responsibility it is to correct the issue can have as best of an understanding as possible of how the issue came about. The best way to achieve this is by telling them what you did (repro steps), telling them what you expected to happen (expected result), and then telling them what actually happened (actual result).  By providing the steps you took and giving the context of what you expected from those steps, followed by what actually happened, it paints a better picture for the team in charge of dealing with it.

Screenshot or it didn’t happen

Speaking of pictures, we used to have a saying on the QA team I worked with: “Screenshot or it didn’t happen.” If you can provide a screenshot of your issue, you increase the chance that the person responsible for resolving the issue will be able to address it without any back and fourth.  Screenshots of any errors you see on pages, or incorrect configurations or data, help identify the exact issue, with no room for interpretation.  If you’re doing user acceptance testing, a screenshot of the UAT instance where the issue lives and what it looks like in production is even better. Again we’re trying to establish context for what your expectation was and what you actually saw.

Often during migrations or mergers, the individuals who are performing the work do not have the context of what the content is and what it should look like.  This is why user acceptance testing is such a valuable tool: It gives the users a chance to scope out the changes and see if anything looks wrong.  So it is the tester’s job to provide as much information as possible to resolve any issues. Here’s an example of an issue related to a migration:

  • Summary - Write a brief summary of the issue you’ve run into, it can be a simple statement, 2-3 sentences at most. (This can be optional depending on the medium for reporting the issue, if you’re using a Jira project to track bugs this would be important. If you’re tracking things in a table, the description would probably be sufficient)
  • Description - Provide a detailed description of what you observed. Include specifics like a link to the exact page or any particular tools used. This is a situation where less is less, more is more.
  • Reproduction Steps - Give a detailed step by step walkthrough of how you achieved the result.
  • Expected Result - At the end of the reproduction steps explain what you expected to see.
  • Actual Result - Also describe what you actually saw; be sure to indicate how this is different from the result you expected.
  • Expected and Actual results can sometimes be obvious or at least seem that way, just remember that it may be obvious to you but not necessarily to someone with a different context.
  • Screenshots - Where possible, include screenshots of the errors or issue you witnessed, and provide a comparison if possible to paint that contextual picture.

The most important thing to remember when doing testing of any kind is providing context. Always assume you can’t… assume anything! Treat it like the person you’re explaining the issue to has no idea what you’re talking about.  And if you have any questions regarding UAT, or how it can make the most of your processes, drop us a line, we'd love to help you out!

Topics: atlassian migrations tips gaming user-acceptance-testing merge
2 min read

Should my Jira Service Management instance be separate from Jira Software?

By Morgan Folsom on Jan 29, 2021 2:04:24 PM

Blogpost-display-image_Should my Jira Service Desk instance be separate from Jira Software-As companies grow either organically or inorganically, many are faced with the decision of whether they should consolidate or keep their Jira instances separate. Today I'm going to address one specific flavor of this conundrum that I am often asked about, specifically with regards to separate instances of Jira Software and Jira Service Management. Some organizations choose to have separate instances for Jira Service Management and Jira Software, but I am here to tell you that is probably not necessary!

Although Jira Software and Jira Service Management are different products, there is no need to keep them separate. The most efficient companies use both in a single instance, so that teams can collaborate much more easily. As organizations adopt DevOps or start to think about it, one of the first things that is looked at is how IT interacts with the development organization. If these two groups are working in separate Jira instances, collaboration and clear understanding of ownership and handoffs is much more difficult. For example, It is much easier to link an incident that was submitted to the service desk to an associated bug if all of those tickets live in the same instance. While you can link to tickets in other instances, that requires users be licensed in both and have a clear understanding of where the work lives. Working in a single instance removes the need for potential duplicate licenses and ensures teams can communicate clearly. 

Occasionally teams use separate instances due to security considerations. However, in almost all situations your security concerns can be addressed by project permissions, application access, and issue security. There are few cases that Jira's native security features won't account for. 

Finally, let's look at this from a user experience perspective. One of the most prominent complaints that we see as organizations undertake their digital transformations are that users have to keep track of too many tools, a pain that I've felt in my career as well. Trying to remember where to log in for a specific subset of your work can be a headache. If your Jira Service Management and Jira Software instances are separate, they'll have two separate URLs that users have to navigate to. Signing into multiple locations and using different URLs adds an extra step where there need not be one.

Since you've already made the great decision to use both Jira Software and Jira Service Management, you might as well reap the benefits of the easy connection between the two so your teams can focus on what matters, rather than managing their tools. 

Are you looking to merge your Jira instances? Contact us, we know all about how to do that, and would love to help.

Topics: jira atlassian blog optimization tips integration project-management jira-core merge jira-service-management

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

atlassian-platinum-solution-partner-enterprise

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us