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

Insight 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.

Author

Software architect hero.jpg

Author

Shrikant Vashishtha

View all Articles

Trending Insights

If You Build Products, You Should Be Using Digital Twins

If You Build Products, You Should Be Using...

Digital TransformationTesting and QAManufacturing and Industrial
Empowering Teams with Agile Product-Oriented Delivery, Step By Step

Empowering Teams with Agile Product-Oriented Delivery, Step By...

AgileProject ManagementAutomotiveCommunicationsConsumer and RetailMedia

Top Authors

Lavanya Mandavilli

Lavanya Mandavilli

Principal Technical Writer

Oleksandr Fedirko

Oleksandr Fedirko

Senior Solution Architect

Mark Norkin

Mark Norkin

Consultant, Engineering

Deborah Kennedy

Deborah Kennedy

Associate Vice President,Client Engagement

Randy Merry

Randy Merry

Chief Technology Officer, Medical Technology & Healthcare

All Categories

  • URL copied!