QA beyond automation
My story with technology begins alongside my story as a QA. Seven years ago, I started out as a mere intern, and now, here I am as QA. There has been a dramatic change in the way I work during these years: from exhaustive, giant manual and exploratory tests to the dynamic and speedy (well, not always) automated testing.
It’s interesting that my perception of how a QA developer works has changed significantly as I start working within an agile team, where tasks are not the sole responsibility of one person, but that of the whole team. Yet, if quality is no longer my full responsibility, what is then the true role of the QA?
I believe that the role of QA functions as an interface between business roles and devs in itself. It’s a given knowing that in an agile team, everyone should speak with transparency, and must know the each other’s needs, without the necessity of a messenger to delivering demands from one side to another. However, the role of a facilitator between what is code and what is written or designed falls heavily on a QA; He is expected to have good technical knowledge to understand what is being developed, addition to still a critical sense with product knowledge to know what is being designed.
This is the main difference between waterfall models working with agile. Traditionally, testing is the last step of a project, yet in agile, we run tests all throughout the product composition, knowing it from head to toe.
Have a critical sense
With the popularization of automated testing, some have left out important features to evaluate a product as the critical sense. Quoting a wonderful text about a QA that became PM:
A great tester finds gaps in the user experience that defy the product’s purpose. Sometimes this might be a bug, but often it’s a missing feature.
Criticism of the product should come in the early stages when stories begin to be written. It is very important, for example, that the QA participate in discoveries and refinings, especially since that role, alongside the POs and UX designers, can extract raw material from customer insight, making it useful and beneficial to the project.
Being critical is also very helpful in the distribution of tests between the different layers of the test pyramid. Knowing where and how each scenario can be implemented gives you time to run the tests, especially as communication with devs is developed, thus together defining which scenarios can be done in unit tests.
Another important quality a QA should have is empathy, and this is indeed essential. If I do not have the ability to put myself in someone else’s shoes, I urgently need to train this skill. I believe that assuming different personas is what good QAs do. Generally during the design of the product, we receive information of who the users of our product will be — so use this to your advantage.
Who are my users? A middle aged gentleman using an Android or a teenager using an iOS? Or maybe a mother of two using Windows Phone (yes, these people exist)? What will be the posture of each of these people when using my product? Learn to navigate and understand the needs of each of these personas to find gaps not just in code, but in user experience. This is essential.
Also, go beyond user empathy. Empathize first with your team, with your colleagues. When you put yourself in different people’s shoes, you begin to see paths that you could have not otherwise seen yourself, and the more paths and scenarios you visualize, the more quality you will add to the product.
Predict what can happen
No, I’m not suggesting that you be the type of Paul the octopus (btw, I discovered during the writing of this text that he died. RIP). But I’m suggesting that you use your critical sense and experience to find the darkest spec’s tips.
When I write scenarios, use cases, or test cases, I have to keep in mind that they should serve both living documentation to be automated for the project, and also as a basis for product development. It takes a great deal of effort to discover as many possible paths as the product can achieve.
Know how to prioritize
We can’t win all battles. I’ve been in a situation where I was the only QA for 8 devs in a sprint. I knew that I would not be able to deliver the scenarios and code for everything that was being developed. I sat down with my PO and defined what was most important for the product at that time.
Sometimes, in the willing urge to deliver code, we often fail to specify enough. We need to develop a sense that asks at which stages of the project is it more necessary to have well-defined scenarios or complete regression tests? I’m not saying that you shouldn’t code (not at all), but that you develop the perception of how the project is going to contribute long-term in the best way possible.
But don’t do it alone. The quality of the product is not the sole responsibility of the QA, but of the whole team. That being said, the scenarios do not belong to you and must be readily available to all team members and to your stakeholder.
During many years of my career I was taught that I was the “keeper” of quality, and I brought that mentality with me when I began working in an agile environment. The mindset change required was that I needed to constantly check what I was writing with the PO and the UX designer, so that I could receive ideas and share things that they may not have foreseen.
Sharing with the development team is equally important so that the documentation can be used as a reference to code, also going through all scenarios so as devs are able to give their ideas. The sooner you share the scenarios with the devs, the less rework you will have, since fewer bugs will be detected when the stories are ready.
Sailing is necessary
Where I work today, I have been very close to the PO and the UX designer. I have felt significant improvement both in the backlog that is written, and in the screens that are drawn within the scenarios I write. Also, I always try to keep track of the developing work on branches that are still under development (usually the dev will tell you that it is not ready yet) attempting to detect bugs or gaps between what was designed/written as fast as possible.
But do not confuse this communication with demanding something. Don’t be a boss — this should not be the anyone’s role. Share your ideas, your opinions and get others’ in return. Remember, it is part of having empathy too, not only with the user, but with your team and each others’ different visions. There are no bosses within the agile framework (or at least shouldn’t have).
My intention here is to criticize the role of QA as a dev at all, he who is a great coder and automates. I find it essential to automate, and I do this every day in order to optimize my time. What I want to point out here is that our role must go beyond just automating or writing scenarios. Use your time to prioritize better, considering how you can improve your test coverage, to be critical, creative, communicative with your team, empathic with everyone, and in fact help in building a better product.
We’re currently hiring a QA Engineer at OnTruck. In order to choose wisely the best candidate, we wrote down a list of…medium.com