In my organization we cherry pick test cases from our integration and systems testing efforts, which are stored in Jira/Zephyr. We then download/compile/finesse them into a coherent “UAT Test Script” in MS Excel format and distribute them to end users for acceptance testing. I suspect that other organizations either buy a sufficient number of Jira/Zephyr licenses to accommodate UAT testers, or have some other process similar to what I described above. Do other organizations have UAT Testers (end users) access their test cases directly in Jira? What does UAT look like in your organization and what tools do you use to support UAT?
Any suggestions for improved processes or tools would be welcome.
Interesting that you have explicit test cases that your users are willing to run for you.
UAT for my current organization is really a pre-production/integration environment. We push new releases to the UAT environment, publish some release notes (which when there’s no external changes will just say it’s internal bug fixes or what not), and let it soak for a few days before promoting to prod.
Asking end users to do actual testing for us would be difficult I think (e.g. most likely our customers would wonder why they’re having to test the product). We’re also trying to increase our release velocity, with the pie-in-the-sky goal being CD.
We don’t have bespoke behavior/customizations, so in general, don’t need to ask customers to verify behavior (there are often configuration differences, but those are pretty quickly resolved).
We have started to use Test Rail, which is much better than Excel, (which we were using before). It can integrate into JIRA. It tracks who tests, who makes changes. you can have various kinds of test case layouts. You can do a test run, from your test suite. It gives an overview of % passed, failed, n/a. Great for status updates. You can have your Jira defect linked to the failed test case.
Hope that is helpful @chris_qa
Sure there are other solution, but this is my experience.
In the past when I’ve let internal users/stakeholders loose on the software it has been via a curated demo and exploratory session.
The demo would consist of me running through the features of the application which had been delivered, or were relevant to the people in the room (eg. someone who works only on account management doesn’t care to see the background finance system).
The second half of the session would be a set of scripts for them to run through the features I’d just demonstrated, and instructions to generally explore. I would observe their use of the application and record any feedback.
The above worked quite well for me as it generated higher quality feedback. This is because during the demo I was able to explain areas which may not be working or polished. This prevents the “why are you wasting my time giving me something that’s broken” feedback loop.
And finally, my colleague added an extra element to this process, which I felt was genius. He recorded the session. This completely stopped people getting on their soap boxes to shout their own agenda and focused them on the task at hand.