Here at Microsoft, the majority of our engineering groups are broken down into test development teams and product development teams.  Generally the test teams develop test frameworks and test cases to validate functionality of products.  Developers are usually responsible for unit and method based tests.  Often times, these teams end up writing very similar test frameworks and to some extent duplicate functionality in code.  The old adage, Great Minds Think Alike, applies here but unfortunately teams are unknowingly duplicating each other’s work.  Here’s an approach to unifying the work and getting both teams on the same page.

Step 1 - Talk to the Testers and Talk to the Developers!

Talk about what you’re testing.  If you’re a developer, meet with the test team to share your test design strategy.  Get the unit test plan and unit test tools reviewed.  If you’re a tester, get the test framework reviewed by the development team.  Highlight points where you can share code and how you plan on using the product code. 

By talking, teams get on the same page for what work is being done and what is already covered.  The last thing engineering teams need to do is waste time running duplicate tests or changing duplicate code during crunch mode!

Step 2 - Draw the Boundaries

Meet as an engineering team and make sure that each group knows what test features they’re developing.  If the development team is building a system of mock objects for their unit tests, the test team should use them.  If the test team is developing an in-depth logger, the developers should use it instead of some other solution.  If it is clear who is developing each component and there’s a dependency the amount of duplication should be minimized.  Test code is often thought of after the fact, especially during busy development cycles.  Teams need to get together and work together so that the test infrastructure that is being developed solves both dev and test needs.

This also applies to what tests engineers are writing.  If the developers are writing more functional tests, testers can write more edge case or scenario tests.  When the ownership is clear, teams can quickly determine the test coverage of their product and similar tests aren’t being simultaneously being written and executed.

Step 3 - Work Together!

Remember to that the end goals of the engineering team is to ship and awesome product.  People work really hard and focus on the actual product code, but remembering to work together on the test infrastructure will help teams meet their goal.  Again, talk about test development as an important part of the development cycle.  Get test code and test projects treated like the product.  By talking about the test code, working on the test code and running tests as a team you can minimize the amount of duplication that happens. 

Summary

Duplicating test code can be costly and unnecessary.  By working together and getting people vested in the test infrastructure, teams will have more reliable test frameworks and hopefully higher quality code!