We can see more Quality Assurance Engineer (QAE) or Quality Engineer (QE) opening positions.
This made me wonder what is expected from this emerging QE role across different organizations.
I had sometimes the feeling that it was about a company career’s marketing, only adding “Engineer” to the existing QA role.
Looking at various positions, the QE is in fact a specific role that companies are looking for.
A Quality Engineer can be seen as a chameleon for its various set of skills required from other disciplines.
I decided to share with you its various facets clarifying first the why.
Why would we need a Quality Engineer?
We can reflect another way, what happens without a QE?
We have traditional roles such as Product Owner, QA, Software Engineer, DevOps working together on a product, partially to fully allocate in terms of availability.
This is a reality for most organizations that are investing in their product and software lifecycle.
Quality Engineers are making sense to streamline even more the collaboration, automation and performance of the teams.
Why hiring and organizing three roles if you can have one doing everything with less overhead?
One reason could be that you want continuity of activity in case of absence or that you don’t even find this hybrid profile.
Combining the skill set of various positions, they need to be ideally with good Quality Assurance foundations and experience, completed by other facts we will see thereafter.
The Quality Assurance Facet
In its roots, the QE needs Quality Assurance perspective, mindset and skills.
This is in fact where he can have obtained a transversal view across product development, from analysis, requirements, specifications, testing and defects management.
The knowledge of the test discovery and test techniques also enable to have an holistic view of possible verifications mechanisms that can be used, while securing the test strategy and test plans.
Its main value is to translate the business, customer and product requirements into the concrete product that will be built, making sure the reality is tailored to the true needs.
We can sum up the main responsibilities in the following points:
- Review requirements, specifications, and technical design documents to provide timely and meaningful feedback;
- Create detailed, comprehensive, and well-structured test plans and test cases;
- Estimate, prioritize, plan and coordinate testing activities;
- Identify, record, document thoroughly, and track bugs;
- Develop and apply testing processes for new and existing products to meet client needs;
- Track quality assurance metrics, like defect densities and open defect counts.
The Test Automation Facet
Quality Assurance and Test Automation have common characteristics, but still differ in particular aspects.
The usual focus on Automation enables us to develop strong skills and expertise of testing across the various technical environments, such as web, mobile, API, IoT, …
They do require a significant capacity to architect reliable, reusable and maintainable automated tests they can deliver (hopefully configure in low-code).
The core of Quality Assurance is helping to know what should be automated or not, at which level of effort, and which test techniques (e.g. black box or white box).
The expectations of the test automation facet are:
- Design, develop and execute automation scripts using the necessary tools ensuring their requirements of reliability, reuse, maintainability and performance;
- Automate API, UI and System Integration tests to validate functional and non-functional requirements;
- Perform thorough regression testing when bugs are resolved;
- Analyzing automation coverage to find the most valuable area to focus on.
The Quality Enabler Facet
A Quality Engineer requires communication skills to influence, help and support the teams in the quality enablement journey.
Depending on the product and team priorities, a QE can create, share and maintain tools whose users are directly the team.
They can also act as the quality ambassador, sharing regularly in open talks format news about competition, benchmark and how the industry is using quality.
Like an architect, they can also suggest structural product improvements from their end-to-end vision of the product quality requirements and software engineering.
The responsibilities of the quality enabler facet can be listed as follows:
- Creating services that monitor for risky coding patterns, and providing insights to the developer before merging their work to master;
- Convincing a team to architect their code in a different way to make it more testable
- Work daily with the product, software and operations teams to promote continuous improvement and quality mindset in product development.
The Quality Peer Facet
With more proximity, contact and sharing with team members, they can act as the de-facto quality peer reviewers.
They can review at various stages of the product development, making a strong difference in the alignment they can provide.
For example, they can use their requirements engineering skills from the initial business and product vision, asking key questions early.
They can then follow up the requirements and their translations across the lifecycle: functional specifications, technical specifications, coding, testing, releasing.
Their hybrid skill set enables them to perform specific testing techniques such as exploratory and help in troubleshooting with the team.
The following quality peer responsibilities are key, as peer review mechanisms is a strong mechanism for improved quality:
- Liaise with internal teams (e.g. developers and product managers) to identify system requirements;
- Work together with internal teams, troubleshooting and debugging issues in production and other environments;
- Pairing with developers to train them on efficient testing techniques (including exploratory testing).
The DevOps Facet
This fact aims to transform quality into the software development lifecycle (SDLC) leveraging automation.
We will find the implementation of traditional CI/CD mechanisms that most probably will integrate quality gates by design from their QA background.
Their dual perspective of quality and software engineers also enable them to directly evaluate the branching strategy between development and test artifacts.
Complementary, their test automation facet made them suffer and so they will think about dealing with test data and test environment management (TDM & TEM).
Thinking about operations, quality and risk reduction, designing the product for A/B test, gradual releases and feature flags would be a reflex to also have.
Its DevOps facet contains those main responsibilities:
- Maintain and improve the CI/CD processes and configuration;
- Analyze and compile deployment configuration guidelines based on performance, stability and other end to end testing activities;
- Maintain and provide the necessary environments for development (integration and user acceptance testing environments), including test data management;
- Augmenting a team’s build pipeline with the right environment to test platform changes.
The Operations & SRE Facet
This last facet is a subset of Operations and SRE focused on quality assurance.
They should have to deal with the infrastructure and operations management, but surely they need to know how the product operates.
If the customer experience availability requirements is 99.99%, they had to check in the technical specifications the translation into infrastructure configuration, such as multi-region deployments.
Even if this was not a stated requirement, service availability and other metrics of Accelerate such as lead-time for changes, change failure rate are strong indicators to be measured by any team.
We could even see the responsibilities as of a QA :
- Analyzing incidents to identify the optimal point to prevent recurrences in the future;
- Building a heat map of the complete picture of monitoring, performance and security testing results against certain product offerings and their requirements.
The QE facets must be assigned within the organization
We understand that a Quality Engineer is a complete hybrid profile.
A QE role is about enabling, implementing and improving end-to-end product quality and collaboration.
Antoine Craske
It can be hard to find such profiles. It’s future could be more about training the other profiles to create this mix of competencies.
The skills mentioned can take years to acquire and more essentially to practice in a different set of environments to be strong enough.
In organizations that are flat, cloud-native, modern stack and with a capacity to attract best talent, can directly hire QE engineers.
For other organizations, the path of composing the various responsibilities across different roles can be the first step : a strong QA advocate, a QA becoming a QAE focusing on automation, a DevOps engineer.
From my perspective, the most important point is to have the various responsibilities defined, implemented and improved in organizations.
Then if you have one, two or three persons composing those skills, with different composition per team, this would be secondary. Maintaining an alignment with communities of practice will be more important, for instance.
Anyway even if you find a very good one, you will need another one to avoid a Single Point of Failure (SPOF) in your organization.
Your organizational design and continuity is also about quality right?
References
https://cloudybt.medium.com/what-does-a-software-quality-engineer-do-eb7b4c9a7f95
https://medium.com/slalom-build/quality-engineer-learning-roadmap-fddfcb77409e
https://world.hey.com/joaoqalves/on-hiring-qa-engineers-75dfa472
https://www.smartrecruiters.com/GuidanceSoftwareInc/80602474-software-quality-assurance-engineer