Embedded QA Engineer in the team


I have been working in Agile environments for a long time, but in the last 6 months I have experienced what is working with a QA engineer as part of the “development team” and not as a “separate department”. I was quite surprised that I had not experienced it before because since the first minute I saw the great advantages it brings to the team.

But before listing them, let me add some context about my actual team. It is formed by a Product Manager, a Tech Manager, four developers and one QA engineer. We work practicing pair programming and sometimes the QA engineer is with a pair doing a kind of mob programming but he does not code. In addition, we are relatively new in the company (≤ 2 years) except for the QA engineer, he has been in the team for the las 5 years. He has seen a lot of different teams that has been passed for the project in those years, and also he has a lot of business knowlegde and experiments that the project has had in the past.

So, having this context we can see at a glance the advantages that this has. For example, he is a vital part of ensuring that the onboarding of a new team member is done in a more optimal period of time. Also, he can explain the behaviour of some part of the application meanwhile the developer is working in a related task that she never had seen, nor even the code, etc.


As we can see in the image, there are a lot of places where the QA engineer can contribute. Here are some examples:

Planning / discovering / refinement sessions

In these sessions, we are reviewing the tasks that we are going to do for the next sprint/s. The whole team is usually there.

Occasionally, a story will seem simple, but the QA engineer knows in advance that it will actually be very difficult or maybe the product manager is not aware that a side effect might occur.

Tech refinement sessions

These sessions are done only with the technical team to avoid wasting time for the product team.

Sometimes, we have found a simpler technical solution to implement and to test it just having a little chat with the QA Engineer.


In other occasions, we have found some problems that we did not see in previous sessions because they were found while checking the “pre-development testing notes” that the QA Engineer made for the development team.

Demo (Dev / QA)

Once the developers are satisfied that they have completed a story, they invite the QA engineer for a demo session.

For example, this allow the QA Engineer to understand the implementation details of the story, down to the code level. This informs their decisions on risks, what testing needs to be added, and what testing is unnecessary.

The demo is a discussion between equals, and not a test that the developer or story can “pass” or “fail”. However, sometimes concerns will be noticed during the demo and these are quickly noted as comments on the story.

Maybe, some teams don’t need this role as a part of their team because in their scenario does not apply. But in scenarios where there is a long-standing legacy that few people know about, it is quite useful.

Finally, even if the QA Engineer is a new team member or does not have so much experience in the project, I think this practice must be done because in a few months, she will have multiple points at which to provide input on how the story is refined, developed and tested.

TOGETHER we will be able to deliver software with better QUALITY