-
-
-
-
URL copied!
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.
Top Insights
Manchester City Scores Big with GlobalLogic
AI and MLBig Data & AnalyticsCloudDigital TransformationExperience DesignMobilitySecurityMediaTwitter users urged to trigger SARs against energy...
Big Data & AnalyticsDigital TransformationInnovationRetail After COVID-19: How Innovation is Powering the...
Digital TransformationInsightsConsumer and RetailTop Authors
Top Insights Categories
Let’s Work Together
Related Content
If You Build Products, You Should Be Using Digital Twins
Digital twin technology is one of the fastest growing concepts of Industry 4.0. In the simplest terms, a digital twin is a virtual replica of a real-world object that is run in a simulation environment to test its performance and efficacy
Learn More
In testing, think – risk analysis and not shapes!
When it comes to testing software projects, the industry is obsessed with shapes. The Testing Pyramid is the most recognisable of these testing shapes. It describes how test suites should follow an ideal ratio of test types, typically, many unit tests, some integration tests, and a few end-to-end or user interface (UI) tests. The core … Continue reading Testing Pattern: Developers Write First Automated Functional Test →
Learn More
A Kickstarter for the Test-driven Development Python Django Approach
In their simplest form, test cases are the set of conditions under which a tester determines whether the software satisfies requirements and functions properly. In layman’s terms, these are predefined conditions to check that the output is correct.
Learn More
Share this page:
-
-
-
-
URL copied!