There is a stigma that Quality Assurance specialists are “just testers”. This mindset is limiting and disregards all of the other value-add activities that QAs do on a regular basis. We reached out to our in-house QA experts and asked them to help shed some light on the subject.
I think that QA can add a lot of value to their projects by being involved early in planning meetings. Often times, a QA will have a unique perspective on usability and functionality that isn’t immediately apparent to other members on the team (mostly due to thinking “how could I break that”). The QA can then guide the team past potential issues before they are even coded into the app thus making the development cycle more efficient.
QA team members add value to projects and teams by being an active participant in the whole process. If you are using Scrum, then one way to do this is making sure during the planning and refinement sessions QA’s are engaged. By being engaged, they are giving their input into the acceptance criteria and the details of the Product Backlog Item. A QA’s experience of testing lends very well with what is quality and can easily point out things before work is being developed. Another great way of adding value is reaching out to developers and possibly doing pair programming or working on Test Driven Development together. This allows for bugs to be addressed and quality built in before the code is even checked in. These are just two ways that QA members add value besides executing tests, there are many more!
Exploratory testing guided by testing charters is a great way for QA people to go beyond simply writing test cases and executing them by using their unique skillset to help the team improve quality. What exactly is a testing charter? Well, it’s a sentence or two which will be used to guide what will be explored during a focused testing session. This could be something as simple as “The latest API endpoint needs to be properly tested” to “All pages in which the new drag and drop functionality has been implemented.”
These charters can then be executed/prioritized by the team (or just the QA person) and ran as needed. They also give a great opportunity for swarming and pairing while testing.
If a QA team member is cross functional there are many ways to add value other than executing tests. If they are not cross functional, I recommend trying to become more cross functional. One of the best ways to become more cross functional is by pairing with other team members. Pair with the PO when they are with stakeholders to better understand what stakeholders want and how they think. Learn how your PO thinks and why they do what they do. Pair with the UX expert and learn why they are making designs the way they are. Do you do user experience feedback sessions? If you do, pair on these events to see how users use your application. Pair with a developer and learn how things work under the covers. Find out what is hard for developers. These are areas to focus testing on in the future.
When pairing with other team members look for things that make their job difficult. How can the team make the difficult things easier and add quality to the product at the same time? This helps the team bake quality into the product at every stage.
As a QA your job is typically to break things after they are built, but what if you spent some of your time trying to break things while they are still on the drawing board? Get involved early and be a part of the plan. Sit with your developers when they are designing and tasking. If you think something is missing, bring it up. Share you test plan for anything not “happy-path” and see if they think they have those cases covered. Ask questions about regression, integration, and even future iterations. It will save the team a lot of time and effort from responding to a bug if it is never there in the first place! Getting involved as early as possible in the design process will give you a more detailed understanding of how the finished product will work and give the team a stronger sense of confidence in the software that was built.