The Complete Quality Engineer
Traditionally, Quality Assurance was mainly manual testing. Testers worked in silos, testing software from an end user's point of view. Over the past 20 years (or maybe longer), the Quality Assurance field and the "tester" role morphed due to the shift to Agile methodology, technological advancement, and more engineering-focused work.
The Quality Engineer role was introduced to find a better approach to testing to keep up with these changes. The ultimate goal was to show how effective an end-user and technical approach to quality assurance can be.
Everyone has their definition of what makes an outstanding Quality Engineer, including me. Through experience, working at companies of different sizes and maturities, as well as folks with varying backgrounds and opinions, I've come to define what I call the Complete Quality Engineer.
What's a Complete Quality Engineer? It's a Quality Engineer, QA, tester, or whatever quality-focused role with multiple interconnected skills and characteristics that bring immense value in the new Agile and technical landscape.
While there are many skills and characteristics for a testing role (such as "possesses excellent communication skills"), we will not focus on generic soft skills.
Let's dive in.
Product Expert
A QE must be an expert on the product they are testing. They should be highly versed in almost all the features, existing issues, and workarounds for those issues. They should be the next person after the Product Manager for product-related questions.
User Focused
A Complete QE is an end-user's best advocate. They understand the user, think from their perspective, and always advocate for their best interests. They steer all conversations towards quality. Being a product expert is helpful here since they understand the features, their connections, and the workarounds.
Technical
There is a reason this is mentioned high in the list. To put it bluntly, for a QE to be effective, they must have strong technical skills. They don't need to be masters. They'll probably never be as strong technically as a developer. But that's ok. They need to know enough to be dangerous (borrowing this term from a website I used to learn Ruby on Rails).
They know how to read and write code. They can provide input during code reviews. They can write automated tests. They have a good breadth of technical knowledge for engaging and fruitful discussions with their peers.
That goes for their product as well. Knowing the product is great, but knowing how the product works under the hood is even better. They should have a good understanding of the breadth of technologies and technical implementations across the product. This helps with debugging, knowing what/how to test, and providing improvement suggestions for better quality.
Knows What/How To Test
This goes without saying, but you'd be surprised 😅 A QE doesn't need to know every technology and feature. They should, however, learn enough to have an engaging conversation and understand enough to carry out the task most of the way.
Having the product and technical expertise is key. The QE would know how the product works and can make connections between the features. The technical knowledge completes that understanding and helps them with the testing activities and engaging in meaningful discussions with Developers.
Breadth of Testing Skills
A QE will come in contact with many testing types, tools, and technologies. It's not enough to know just UI testing or just Cypress. They should have a breadth of testing skills and experience to be effective across the product and organization.
They should at least know UI, functional, API, and performance testing. And they should know at least 1 of the common tools and the common implementation patterns for each.
To take this a step further, knowing how to test data systems is becoming more critical. I hesitated to mention it earlier because it's relatively new within the quality assurance field. It is quickly gaining popularity, so having this skill will propel a QE's value.
Want more breadth? Know security and accessibility testing. Learn multiple tools for each testing type and know their pros and cons and when to use them.
Understands Testing Scope
Some know this as unit/integration/end-to-end tests. Others, small/medium/large. Or the Test Pyramid. Whatever you call it, the ability to differentiate what should be a unit test vs an integration test vs an E2E test is vital.
Testing responsibility can be split between QE and Developers, balancing automated tests at different granularity levels. Knowing this also helps decrease duplicate tests.
A Complete QE is comfortable lowering the scope of a test to achieve higher reliability and speed. They are ok with not covering every single scenario in an E2E test. They know which granularity is best.
Empowers Delivery
This one is often overlooked, yet in my opinion, it is one of the most essential characteristics besides strong testing and technical skills.
Regarding Agile, the QE should know the basics for all the ceremonies. In backlog refinement, they come prepared with questions and ensure that the acceptance criteria are clear and consistent. They complement the Product Manager, Scrum Master, and Tech Lead. They shed light on the testing needed for each story. In sprint planning, they ensure the stories are pointed, including the testing activities. They keep the team honest about their estimates and sprint commitments.
Beyond that, they know how to balance testing activities against timelines and priorities. Sometimes, a QE must sacrifice an automated test and rely on manual testing so the team can quickly deploy a hotfix. Or they bridge a communication gap between teams to resolve a problem quickly.
They help the team progress and resolve impediments. They drive the product forwards. Yes, quality and testing take time, but a Complete QE helps the team balance everything against timelines.
DevOps Expertise
Having DevOps expertise means a QE doesn't need to rely on others to plug their automated tests into a pipeline or to deploy code to a test environment. Also, they can help the team when there is a deployment or pipeline failure. Or even help with the original setup — another skill to complement the team and be of higher value. Better yet, they can shape tests for DevOps and infrastructure.
Balances Perfect vs Good Enough
This one is tough. QEs see their role as the ultimate gatekeeper for quality. However, that vision can sometimes cloud their judgment and hinder their relationships with their teammates.
A Complete QE can balance perfection against good enough. This can relate to the product, how to solve a problem, how the team operates, and more. They don't let perfect stand in the way of their relationships or the team's progress. It doesn't mean they sacrifice quality and always concede their opinion.
They keep an open mind and know which battles to take on, both with others and with themselves 😀
Friend To All
An effective QE makes friends with all roles on the team. They don't isolate themselves or constantly try to be heroes. These relationships can pay dividends in fostering teamwork and better work culture. Ultimately, this leads to a better product. Isn't that the QE's end goal?
They work directly with a Developer when they find an Acceptance Criteria is not met. They advocate for good design to build rapport with UX Designers or bring the Customer Support team into conversations to help them stay up-to-date with what's coming. These are just some of the examples.
Final Thoughts
Did you notice how interconnected all the various skills were? That's what makes a Complete Quality Engineer. Each skill can help the QE conquer another. This is backed by hard work, experience, emotional intelligence, and soft skills.
With this in mind, venture forth and look for these nuggets of gold. Or strive to be one. You'll be pleasantly surprised by the value they bring to the team (hint: it's more than just "testing" or "quality").