True Test Engineers don’t write Tests
“You know, we will give up the QA position in our team. Since we hired our Test Engineer, developers simply stopped testing and things are going worse”
That was a team lead speaking the other day.
“What happened?” I asked. Well, developers welcomed their new Test Engineer and wondered how he could help them. As they never had the time to create a good test coverage (you know, deadlines, urgent requests, etc.), they naturally asked him to start writing tests.
Oh, for sure, developers kept writing unit tests, but they needed good acceptance tests, performance tests, e2e tests, etc. So, they started asking him to write tests for each feature they were implementing and of course, to test every task they finished.
With time, developers stopped validating by themselves their code on pre-production and were merely testing it locally.
Why bother, when you have a dedicated person in the team for that?
Soon the Test Engineer was spending most of his time testing, often manually, finding defects and reporting problems to developers. He became quickly the bottleneck of the team and time was missing to focus on writing new automation tests.
He started feeling very poorly about it and finally quit. It was the end of the QA story for this team.
The Quality Gatekeeper
The best analogy I can think of, when it comes to QA, is with a soccer game (even though I’m not passionate about the sport!). In this game, a team is composed of 10 “regular” players and one goalkeeper.
In soccer, it’s the job of defenders to prevent opponents from reaching goals. The goalkeeper is the last chance the team has, when the defense failed.
A successful team is one with a good defense. You can tell it when the goalkeeper is doing almost nothing during the game.
Does it mean goalkeepers are useless?
The goalkeeper is considered the last bulwark in front of the nets. But it’s much more than that. Have you ever seen how he tells players how to position themselves for a corner? Have you ever seen him yell at players when they let the attacker pass? It’s because he is the one organizing the defense. He is the owner of the defense strategy.
Organizing the defense
As you have understood, when it comes to software engineering, it’s the job of developers to prevent bugs and regression from reaching Prod.
The Test Engineer job is to organize the QA strategy of your team.
The most common error is to involve your QA during or even after development is done. In software engineering in particular, QA is not just a step in your delivery pipeline. Quality is everyone’s concern, at every step.
Project specifications
The Test Engineer must be involved during the definition of features, and the technical analysis. He needs to understand the business behind the project, and the purpose of the requested features. He needs to be part of it, so he can design the test strategy and create his plan for Quality.
Let me illustrate with a few examples :
- During the project, we will need a script to migrate some clients from an old interface to a new one (the old one will be decommissioned after). As it will be used only once, a manual validation of the script should be enough. To do this, the QA will make sure for example that a dry-run mode will be included.
- The marketing will start a massive advertisement campaign for this new product and expect a high number of subscriptions. The QA will make sure that the project manager includes some tasks to create/run performance tests against the subscription application.
- The software architect explains that the back-end API will be rewritten in a new language (for whatever valid reason you like). The QA will ask for the API specification and make sure non-regression tests exists. The validation will include that these tests shall run successfully.
Examples are endless. The point is, the QA Engineer is making sure that the product owner, scrum master, project manager or whoever is responsible for the backlog definition will include the necessary work in line with the QA strategy.
Test, actually
Let’s make it clear : developers have to write tests, and developers have to run tests against their code. The QA Engineer works with them to define the kind of tests to write and the test scenarios to implement.
The main concern of the Test Engineer should be to make Quality visible and measurable.
An important job of a QA Engineer is to collaborate with the team lead to create metrics on the quality of the applications, and be able to react fast to any regression.
Our experience showed that you get the best results when you pair your QA with a DevOps Engineer. Together, they have the skills to create the most appropriate tools for automation testing, like on-demand cloud environments, where integration tests can be performed.
They should be responsible for the setup of a CI/CD tool like Jenkins, Bamboo, Travis etc. Together with the team, they define a work process where code is pushed frequently, tests are triggered and the result is clearly displayed. I like for example when teams have a big monitor showing their Jenkins radiator.
Daily job
Now that we highlighted the importance of having developers being responsible to test their code, and the need of building a quality strategy, let’s see what the daily job of your QA Engineer should be.
In case you started having some doubts : Yes, the Test Engineer is also doing tests! And in practice, it’s not unusual to have him contributing to write tests. But I insist : contributing. They will also spend a significant amount of time to fix or evolve existing tests. Entropy applies to your tests, no exceptions, and time must be spent to keep them clean.
When a developer tests a new feature, he tests in general the happy path, i.e. checking that the feature works as specified. The QA will typically try to apply corner cases and see how the application behaves.
The best QA I worked with were often surprising me by testing a case I never thought could happen. They were challenging our assumptions on how our business works. Therefore, they needed a deep understanding of the business. To do that, they were spending time with the business owners and stakeholders, asking questions, understanding how the project impacts their business.
If you are going to hire a QA Engineer, think about these soft skills. Check for their curiosity, interest for your business, autonomy. There is no training on Pluralsight for these!
QA Engineers are members of the team. Make sure they participate in all team ceremonies (daily stand-up, grooming, retro, etc.). You should avoid having a Testing team, or even a Test Department: that creates silos.
Grow the community
Building metrics, defining quality standards and processes or developing test frameworks is something that you probably don’t want to limit to the scope of your team.
Help your Test Engineer join or build a QA community. You need to have a global QA strategy for your company. Test Engineers should meet, share their experience, create work-groups, etc.
I have to say this was harder than I thought, and we failed a couple of times to build such community. A good way to start, is let them already define a common vocabulary for your company. For example, what does Acceptance test, Integration Test, System Test or e2e Tests mean for you. Then, finding subject for a work-group, like building a common Jenkins Pipeline could be a good topic. And if you have an experienced QA Engineer, make sure he organizes workshops and training sessions.
Final note : I used in this article Test Engineer, QA Engineer or simply QA to refer to the same role. Depending the size of your team, it could be one person, or 2, or the role could be granted to some developer that has interest for QA. But someone has to be owner of your QA strategy!
Did you like what you read? Join me at Swissquote:
https://careers.smartrecruiters.com/Swissquote/tech-jobs
