Applying UX techniques to the case of a process-less Quality Assurance team
I recently joined the QA team of my current company. Within a week of joining, I found out that what was expected of me as a QA Test Analyst was to test software when it’s ready to be tested. And that’s all about it.
Having had varied QA experiences, I found the process of my current QA team too passive. Surely, as QA people we’d have more things to do to ensure the quality of software, don’t we? I wanted to find out more whether that simplistic process was enough or needed some improvement. If it’s the latter, what sort of improvement did our team need?
User Interviews: the great problem finder
Having gone through months of the Coursera Interaction Design course, I knew that I had to start my quest of process investigation and improvement by doing interviews.
I set out an interview plan which included identifying the stakeholders whom QA interacts with. And with a set of interview questions, I interviewed representatives from each stakeholder group and simply listened. The stories flowed and the problems surfaced.
The Problems
There were two major issues that I gathered during the interviews:
- delayed deployment of software features because testing took a long time
- buggy software deployed in production
The Recommendations
My work didn’t stop in identifying the problems and simply presenting them to management. As a UX Designer at heart, I wanted to create and present solutions. I studied the existing software development process and the identified problems, and thought of possible solutions.
I came up with a recommendation that was a combination of:
- process — when QA would do our work, what QA’s involvement in defect raising is, stakeholders’ change in ways of working to accommodate the new QA process
- tool — a test management tool to facilitate QA’s work
- and commitment — QA being active contributors in the entire development process rather than passively waiting for work to be given
I presented to the stakeholders a slide show outlining the problems, the opportunities, the recommended solutions, and the benefits of adopting the recommended solutions. I got support that we’d try my recommendations.
The Progress
I’d been in the company for 5 months now. Since we’ve adopted my recommendations, the QA team had invested on a tool to aid in our work, grown the team to 4 people to build our test library and increase our productivity, and tried, tested, dumped, and changed some of our processes.
As we are still in the very early stages of our new process, we’ve adopted a try and evaluate approach so that we can quickly change any process that doesn’t serve us. In the case of defect raising, for example, the recommendation I made was tried for one project; however, rather than help our productivity, it seemed to be counter to our development process and only meant that more work was needed for the other stakeholders to do. By talking to them and doing a bit more research on Agile best practices, I understood why that process wouldn’t be sustainable. We had to revert to the old way of defect raising as that proved more suitable than my recommendation.
Reflection
The UX skills that I acquired from my studies is not only for apps. They come handy for any sort of problem solving as evidenced to what I’d done in our QA team.
Furthermore, it is important to try solutions and drop them if they’re not working; to keep evaluating until the right solution is found. It’s all right to fail, we just need to fail fast and move on to the next alternative solution.