What it means to be a QA at REA
When I first joined REA, I soon realised that the QA role at REA is very different from a typical QA role and the roles that I had done previously in my career.
Some of the highlights of being a QA at REA for me are:
- The entire team owns the quality of the work we do. You are not the Quality Gatekeepers
- QA at REA is not defined as Quality Assurance but Quality Analyst
- You are free to venture into previously unknown territory like BA or Ops and it is encouraged
- You are not meant to test every card that gets developed
- Your role is not limited to the testing column on the Kanban board
- If you are passionate about the work, you have a voice in determining what work you actually do
- Your efficiency is not measured or based on the number of test cases you create/execute
- You are trusted with access to most critical production systems, so you can learn and contribute more
- You are not meant to document each and every test case you execute
- You can get help in finding bugs. E.g. Bug bashes
- You can pair with developers on testing
- QA effectiveness is not measured based on the numbers of bugs that you discover
- You can do pretty much anything on Hack Days, be it on a project or your personal project to improve your automation skills
- You can attend a countless number of external training or conferences
- You have a vast array of internal training available, including technologies like AWS and Docker.
- You can be part of the QA Guild where you can bounce ideas off other QAs in the building and share ways of working
- You can get an REA T-shirt just for QAs!
While the role came with a lot of benefits there were some challenges too. Understanding what other QAs at REA do was not easy. This made it hard to learn from each other.
To help increase visibility I decided to come up with a QA Strategy initiative which first will enable us to talk about and understand what QAs at REA really do, and then help us come up with strategies to improve.
The first cut of a mind map I created to capture the QA role looked like this:
As you can see the activities have been classed into 5 categories:
1. Story/Card/Task level
2. Epic/Project level
3. Sprint/Iteration level
4. Team/Squad/Tribe level
5. Company level
Our QA guild brainstormed ideas and everything that was not already captured was added to the Mindmap.
Finally we looked at how many QAs actually do the activities listed in the Mindmap and this is what we came up with:
A score of 5 was assigned to activities that most of the team did.
A score of 3 was assigned to activities that half of the team did.
A score of 1 was assigned to activities that fewer than three members of the team did.
As the image suggests, there is no clear pattern. While this is not intrinsically bad, it is a clear indicator of an opportunity that is present — an opportunity to gain insights into what key skills a QA can bring to the team
1. Talk through each of the activities and share the knowledge on how we are doing them
2. Use that information to learn from each other
3. Analyze this information to improve on how we do things at REA