Agile Testers are often known as Quality Analysts (QA), Software Engineers in Test, Test Engineers and QA Leads, among other variances. I've been working as an Agile QA for a while and I would like to share my point of view about how QAs work in an agile team. In this article, I will use the term QA to represent an "Agile Tester".
Most people, even in agile teams, treat QAs as a sub-role or a separate role in the team. I believe this is an outdated conception. The difference between a QA and a Dev lies in the mindset.
But what distinguishes QAs amongst themselves? QA profiles can be sorted into three categories: Business, Technical and DevOps. I call these the “three dimensions of a QA profile”. QAs can have either one of these different profiles, or combine them according to the level of knowledge they have in each dimension.
Let's dive a little deeper to understand each one of these dimensions:
Business dimension
The QAs in this dimension are really business driven. They have skills that will help their team understand the business context given by the client. They have good communication skills that will facilitate the team to focus on the business problem during the entire project.
Extracting acceptance tests from clients is one of their specialities and BDD is one of the techniques they use to break down barriers between business context from the client side and technical context from the engineers’ side.
They pair with developers to huddle with the client before they play stories, in order to get enough information for the story to be played. During this period, they drive the pair to write acceptance tests to make sure that the story is tested before they move it forward.
These QAs usually read books such as:
Specification by Example: How Successful Teams Deliver the Right Software
Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
The Cucumber Book: Behaviour Driven-Development for Testers and Developers
Technical dimension
I relate to this dimension closely because the QAs here are really technical and have good programming skills. Ideally, there shouldn't be any difference between a QA and a dev. In an agile team, everyone is an engineer and should be treated as such.
The technical QAs pair with devs to build the application without a technical gap. They code together as well. They also support devs to do TDD, fostering good practices for clean code and design patterns, and ensuring high quality code.They have a lot of knowledge on test automation and help the team choose the best test frameworks for the project. They are also responsible for making sure the team has a good test strategy in place.
The QAs in the technical dimension may also work on performance tests and security tests, depending on how advanced their knowledge on non-functional tests is. For performance tests, they work with the client and find out SLAs (Service Level Agreement). They then create performance tests to measure and track the improvement done on the application related to these SLAs.
These QAs are also involved in security. They understand the business context from the client and analyse possibles vulnerabilities. They then create tests to ensure that the possible vulnerabilities are being covered for a security mechanism.
These QAs usually read books like:
Test Driven Development: By Example
Clean Code: A Handbook of Agile Software Craftsmanship
Selenium Testing Tools Cookbook
The Art of Application Performance Testing: Help For Programmers and Quality Assurance
DevOps dimension
How is DevOps related to testing? There are a lot of things that QAs can do to help teams through their knowledge of DevOps.
They introduce the practice of continuous delivery and help the team create a continuous integration pipeline in order to get faster feedback after each commit. This helps the team deploy new features to production more often. In some cases, each commit goes directly into production right after successfully passing through the pipeline. This pipeline will also run the build and pack code quality tool, unit tests, component tests and functional tests.
The DevOps QAs set up scripts for the team to easily run tests in their local machines. In some cases, virtual machines are required and here the tests are set up to run in parallel.
They use task runners for the team to execute repeatable tasks easier, like auto watches to run tests automatically after each time the developers save the code. It decreases the time of the feedback during development.
This QA usually reads books like:
Continuous Integration: Improving Software Quality and Reducing Risk
Continuous Delivery: Reliable Software Releases through Build, Test and Deployment Automation
The best references in portuguese are:
DevOps na prática: entrega de software confiável e automatizada
Entrega Contínua: Como Entregar Software de Forma Rápida e Confiável
What’s common for all these QAs?
QAs in all three dimensions keep the team focused on delivering the right value for the client during each development cycle. At the same time, they are concerned about the quality of the product that is being delivered.
Along with sharing ownership of the tests with the rest of the team, they share their knowledge about these tests. Through this approach, every single team member thinks about tests regardless of their role. QAs wear many hats, but their main focus should be to help their team deliver business value frequently and with quality.
Books that all Agile QAs should read (and the bible of Agile Testing):
Agile Testing: A Practical guide for Testers and Agile Teams
How about you? Where are you on these dimensions? What do you want to get better at?
Think this over...and get started!
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.