Often in the career of a QA Engineer, there comes a time on a project or in a company that we take on responsibilities that do not come within the “characteristic” QA job description. There are many examples of a QA stepping out of their comfort zone and doing things that, in most cases, shouldn't even be on their plates. This article aims to go through some of the roles or situations you might encounter on your project and hopefully help you better understand and identify those situations.
Product Owner / Product Manager
As we need to be very analytical due to our position within the team, we should be able to break large features into smaller ones and properly identify their requirements. That makes us “ideal candidates” for the position of a Product Owner, defining requirements and taking part in the ownership of the product. With the Shift Left approach to testing, a QA should be included in all processes as soon as possible, including the process of defining requirements before they are ready for the development team. We should be included in that process. However, our role should be challenging the requirement, not defining it. If we look at this from the “Six Thinking Hats” perspective, in most cases, we assume the role of a black hat (logical, negative one), where we’re cautious, judging every requirement as it comes. The idea behind this is that we need to give our team members different perspectives, even if that assumes that we go around and say “what if something goes wrong” all the time.
The additional argument would be that we’re not thinking about the future of our product all the time, potentially missing out on the big picture of our product, what features we need, and why, for example. I would go as far as to say that we should not even set the priority of the bugs that we create, simply to avoid situations where we (out of best intentions) set the priority too high or too low. Product Owners should take up that responsibility completely, own the product, and be in charge of upgrading/fixing /maintaining it.
Meetings with clients are another issue worth mentioning. In my opinion, QA Engineers should not be included in meetings with clients up until Acceptance testing. Clients usually have requests that need to be translated into requirements, which takes some time. Also, these meetings tend to have different discussions, which will not help QAs focus on what is relevant.
DevOps
Since DevOps / Site Reliability Engineer positions are very complex and require specific skills, nobody should expect a QA Engineer to assume that role completely. That does not mean that we should not participate in work necessary for (among other things) CI/CD pipelines. To accomplish that, we need to familiarize ourselves with tools used in our team for that purpose and their main features. We need to understand the what, how, and when to provide proper suggestions on incorporating our automated tests into the CI/CD pipeline.
Regarding technical skills, I rather support the opinion that QA Engineers should be able to create/modify pipeline jobs/workflows. With that skill set, we can be responsible for and own the whole flow that automated tests go through, from start (setting up framework) to finish (integrating automated tests into pipelines and setting up reporting). Also worth mentioning is the situation where QAs are responsible for code releases, the idea behind being that they are the ones guaranteeing the quality of that code. I don’t think this is a good practice, considering whether QAs can resolve issues or do a successful rollback. More often than not, the answer to that question is - QAs cannot do much in those scenarios.
Developer
Similar to the previous role, I would never expect a QA Engineer to modify the application’s source code regardless of their knowledge and/or technical skills, even if the change seems trivial. Lacking a deep understanding of the architecture of the product or not following best practices for development also comes to mind. Our mindset is different, not set to build things but rather challenge them in every way possible, and that is already a good enough reason why we should avoid these scenarios.
However, there are many principles/tools regularly used by developers we should have knowledge of. Of course, the depth of the knowledge depends on the project, situation, tools used, etc. One of the main principles we should embrace is Object-oriented programming and its four basic concepts. It goes without saying that we should familiarize ourselves with the programming language being used on the project, its advantages and disadvantages, patterns, possibilities, and so on. The greater our knowledge is, the better test scenarios will be written, giving us the possibility to dive deeper into source code and adopt white/gray box techniques for our testing.
Any tools used by our team to build the product on local machines should become our everyday tool (docker, for example). Finding bugs earlier in the process of development (in this specific case - in the lowest environment) costs us fewer resources and saves us from a lot of headaches in the future. It all comes down to having the knowledge that will help us better cover our product with tests and increase our (and our team's) efficiency.
On that note, if we have the possibility, starting testing as soon as possible (for example, when backend work is done and frontend is just starting) increases efficiency. Determining backend issues in advance requires us to have knowledge of API (basic functions, status codes, headers, params, payload, schema, and similar) and definitely knowledge of databases used on the project (at least knowledge where and how we store our data so we can find it if we need it). On the frontend side (if the project has one), we should be able to navigate through HTML, even CSS in some cases. If this skill is “nice to have” for manual UI testing, it is a must for automated tests. We need to know the structure of the page in order to use element locators in the most efficient way. Where we need automated tests, some source control tool is in order (like Git). We need to implement best practices (often used by developers) in order to maintain code quality (testing code is still code, right?).
We will not discuss whether we should be writing unit tests, as it is already covered with the article my colleague Slobodan Popovic wrote. Make sure to read it right here.
Design
We already mentioned that QA Engineers should be analytical and systematic, relying on procedures in order to guarantee quality of the product, therefore, by nature, UX/UI Designers are more aesthetically-oriented. We can and should collaborate with the UX/UI Designers, giving them another perspective and challenging the design. However, creating or modifying the designs themself should not be our cup of tea.
Conclusion
Our position in the team is often similar to a playmaker role in sports, connecting all other parts of the team and ensuring flow of information. However, it is important to know your limits, be careful not to fully reflect saying “Jack of all trades - master of none”. We should always help our team as much as we can however we can, but still, we need to keep in mind our main purpose on the project. If quality of the product is not our top priority, who will fill in our shoes?
About the author
Nikola Djordjevic is a QA engineer with 7 years of experience working at our Belgrade engineering hub.Â
Nikola is a QA engineer experienced in various testing approaches, including functionality testing, performance testing, and UI testing. He also worked in product development, questioning backend logic and mapping clients' requests with existing functionalities. Nikola is an extraordinary communicator excellent at leading and mentoring others.Â
