The role of a Quality Engineer

Quality Engineer. Who is he and what does he do? In plenty of companies this role might not exist and in many it is assumed to be just a different name for testers. In this article I would like to express my own opinion about it and provide some insight on what different responsibilities a Quality Engineer might have in various companies.

The reason why I am writing this is that I now work as a Quality Engineer for Red Hat and I don’t necessary take the same perspective of QE that is mostly present here. And also, I just read the article Think like a Tester and Get rid of QA by Mark Hrynczak from Atlassian, published in this September’s issue of Java Magazine, that resembles a lot of my opinions and ideas.

A Quality Engineer is a Software Engineer with a certain skill set. The required knowledge includes the knowledge of the product, the products it works with or it is based on, investigative and debugging skills for finding bugs, programming skills for the development of testing tools, writing automated tests and looking after the code quality, automation skills to provision and set up testing environments, security-related skills and so on. It is also good to have an eye for design and some knowledge of user experience design if the software has a graphical user interface. And indeed one can specialize in some areas and happily ignore others, as is the case with every profession.

In Red Hat and other companies, Quality Engineers are part of a Quality Assurance department (QA), separated from the engineering team and one of their biggest goal is to provide a safety net to developers by checking that the software works as intended. It can mean doing functional testing, smoke testing, regression testing, usability testing, performance testing, security testing, testing of internationalization and localization and so on, usually in an automated manner. What exactly is tested, how and how often is specific to the product and the team.

Typically the testing is done for a particular release. Continuous or agile testing can also be involved, but in this type of organizations, at the end of the day, there is a release signed off by Quality Engineers. They are also responsible for creating a test plan that describes the types of testing involved, description of test cases, list of things that are and that are not tested and other important things. When done right, QA is involved in feature planning and it generally acts more like a customer’s advocate than just a safety net for developers.

There are of course more models of incorporating Quality Engineers in the development process and I’d like to write a few word on the model used in Atlassian as described in the article mentioned earlier. Their model is quite different. It begins with the initials – QA stands for Quality Assistance there.

The first thing is that every developer should know how to test software and have the right testing mindset. In Atlassian programmers go through a boot camp that teaches them how to test and think about testing. The goal is to make all developers think about the quality, from the right validation logic of user inputs to performance or security.

The whole engineering team, not QA, is responsible for the quality of the software. Thinking about possible pitfalls and bugs should happen before any code is written. At the beginning, a developer works together with a Quality Engineer or more experienced developer to think about possible challenges, problems and risks. Quality Engineers are here to help, to assist. When developers mature, they take on the QA roles in the team.

After the development of a feature is done, it is tested by developers themselves, because there is no QA department to check the code afterwards. They believe that when it comes down to testing, good automation is important, but insufficient and therefore also promote exploratory testing (done by developers). That means that developers should test their code in a clever way rather than just doing some ad-hoc testing by clicking around. Basic defined test cases should still be defined and automated.

In Atlassian, the Quality Assistance focuses on big-picture quality improvements and the development of testing tools. QA is there to provide workshops to teach testing skills and to pair with developers when needed, discussing test strategies, creating test cases and giving tips.

For me, the whole article was definitely inspirational. I was thinking about those things before and some ideas resonated with me. Their approach provides more agility and it doesn’t lead to situations where developers produce a completely broken release. Whether the testing is done by developers only, or there are Quality Engineers to verify the release, I strongly believe that they should be part of the same team and work together more closely. In more traditional companies like Red Hat it is still believed that a separate department is necessary or more useful. Both approaches can produce good software, but which one makes the developers better and Quality Engineers more happy? I will leave that answer to you.

[Written when I was working as a Quality Engineer at Red Hat]

Last updated on 7.10.2015.