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. Continue reading