Testing Pattern: Developers Write First Automated Functional Test

In automation testing, even though testers create the actual automation tests, developers help in laying the foundation to create those test cases

URL copied!

Categories: Testing and QA

In automation testing, even though testers create the actual automation tests, developers help in laying the foundation to create those test cases.

Sometimes this demarcation doesn’t work in a smooth way. While developing the automation tests, a tester may discover that some basic but essential pieces are missing, which eventually hampers the testers in developing those tests. For instance, a tester may need to access the servers and update user data files so that the test starts with a clean slate. If testers work on these technicalities, they end up reinventing the wheel, which may consume a lot of time.

To help avoid this situation, one of my teams recently came up with a norm that helped the testers a lot. The developers wrote the first functional test of the user-story themselves, which laid the foundation and provided all the required resources to build further tests. While creating those tests, the developers identified many issues that otherwise would have blocked the testers. Since developers are the ones who have to eventually fix these issues anyway, it made much more sense that they themselves discover those issues.

Based on this basic foundation, testers would then further elaborate the test cases and create more automation tests. The norm worked pretty well for the team and also helped developers understand the issues that testers face on a daily basis.

Analysis

Ideally, any hand-off (e.g., between developers and testers) is a known Lean waste. Frameworks like Scrum address it by relying on generalising specialists (“T-shaped” people). Test automation is a skill that modern developers should have in an iterative, incremental world – where most software development nowadays happens. In many teams, specialist testers transfer testing skills to end-to-end developers.

In practice though, I rarely find a cross-functional team that consists of generalists instead of pure specialists. There are various reasons why it doesn’t happen. Some teams do not practice pair-programming as their default way of working; there may be resistance from developers and testers to become generalists; or team members may be mature in their respective fields. In those cases and for those teams, this pattern works well. Furthermore, a team of generalists or a team that does cross-functional pair-programming may not require to use this pattern at all.