Has anyone here followed a model whereby a test engineer is embedded in the development organization? We are thinking of following a model where:

  1. Test engineer is embedded in the development organisation
  2. Works with the feature owner for a sprint, and gets the functional unit test done for the feature. Also works on QA tests whilst embedded.
  3. Takes these tests and runs them as part of the QA process also.

Has anyone else followed the model, and have any suggestions/gotchas based on their experiences?

  • In this context, does "unit test" mean "automated unit test"? Would the test engineer be responsible for all automated tests?
    – user246
    May 26, 2015 at 11:53
  • define "embedded in dev org". Reports to same manager as developers do? How many developers? Any other testers (manual/automation)? Not sure what is the goal - solving intra-company politics? Improve quality of product? May 26, 2015 at 20:24
  • Unit Tests are part of the projects source code used to verify a function works. The dev(s) can also piece these together to make integration tests. Generally, QA automated testing takes place on the UI level and in its own suite. Although, the line can be blurred with a tool like MS Test Manager.
    – kirbycope
    May 27, 2015 at 16:18

4 Answers 4


I did and do now, but you didn't go far enough with your model. The test engineer is part of a team, not a stranger dropped into it. Some, like Microsoft, take it to extreme and drop the "test" title altogether but let's focus on the more conservative case.

As an integral part of a team the test engineer is part of the whole development cycle, not only for Agile teams but also when doing iterative or waterfall-ish development.

Zooming in and out of features shouldn't be the special case but the routine, the same as code-writers do.


I have been in this scenario quite a few times. Depending on your skill level and personality you can be either the weak link or the driving force of the team.


Talk to the product owner. Understand the requirements. Clarify the stories. Ensure that everyone is on the same page with the exact same expectations. Your primary task should be as an advocate between the Development team and the users. Ensuring that neither Dev nor Users is chasing any golden gooses and that everyone knows their role.

Find defects before they exist

Talk through every story. Allow the product owner and the Developer to discuss how they envision the end product. Develop a list of potential issues or tricky areas and ensure that they are covered prior to development. Make it clear that the developer not only can come to you for any questions but that you will happily assist them in any way through the process in order to create the best possible solution.

Study study study

Know your product, inside and out. If you have dev experience, do code reviews regularly. If not, learn how each piece functions (do this with dev experience as well). Learn the people on the team. Learn how to manage the Users/Owners expectations. Learn your Developer's strengths and weaknesses. Work closely with everyone and earn their respect.

Take charge

Once you have established yourself within the team as someone that can be relied on people will naturally look to you for the solutions to their problems. This opens up the ability to ensure that issues are corrected properly prior to their creation which is a huge win for everyone.


Expect a lot of work early on depending on the status of the project. Your main goal currently should be to take the knowledge from everyone in the team and consolidate it while learning the patterns and abilities of your colleagues. This will usually mean long days and potentially nights as well but if you achieve it, it will become one of the best jobs you've ever had and is extremely rewarding when you start getting consistent and constant successes.


Many different approaches will work it the people involved want them to work.

And vice versa, arrangements which will work in one company will not work in another if people involved do not want them to work.

It is called "company politics", and is better answered in workplace subforum.

  1. Test Engineer should be part of the (development) team imho. That way they can "test" early and often, starting by asking questions during refinement of a feature from a test/risk perspective (that others might not think of), like how to deal with unhappy flows or failures. Discussing these before starting on the implementation of a feature will prevent bugs that might otherwise surface in situations that were not considered during refinement, or where any misunderstanding between business and developers goes unnoticed.

  2. In addition to working with the business stakeholders (what is the expected behavior or the system), they will also need to work with the developers. How it is implemented, what is already unit tested / integration tested by the developers, what is the quality and coverage of those tests (i.e. identify and close gaps).

Side note: Working with developers can be hard, depending on the technical skill and experience level of the tester and how clearly they can communicate in terms the developer can understand. And the willingness of the developers to meet them half way (how much they want to understand, even if you might not speak the same technical language).

  1. Ideally the tests should run as part of the build and/or deploy pipeline to find bugs as soon as possible, making them easier/cheaper to fix. In addition, the tester might do exploratory testing to discover more about the product. Especially where automation might not make sense (yet).

Personally I find BDD (Behavior Driven Development) very helpful to create a common understanding of the features. BDD scenarios can be automated using tools like Cucumber.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.