to write or not to write, this is the question — src
In every team I was part of, a debate started on this point: should the developers write automation tests as part of the development process? They’ve just finished implementing the requirements and wrote some unit tests; now, should they also write automated tests?
Well, the answer, “it depends”.
Depending on the people’s skillset, teams’ structure. When you have manual/exploratory testers with no skills/time/resources/etc. to write automated tests, you can rely on developers. Thus it is much more productive if developers write the tests for the new feature they’re developing.
Suppose your testing team has the skills and resources to develop automated tests. Each group uses different libraries and design patterns. Obviously, in that case, it is more practical for developers to create new features and testers to produce the tests.
Having said that, the more important question to be asking is if it is okay for the developer to be the only person writing automated tests for the feature they are working on?
The answer depends greatly on your organization, your resources, the likelihood of missing a defect, the kind of automated test being written, the development style, who’s time is better utilized on which task, and of course, office politics (which alas are unavoidable). Generally speaking, there should be at least one other person who tests the code along with the developer.
It’s all too easy for a developer to assume, “this one area can’t possibly cause any problems, so I don’t have to test it.” or “I already tested this last week, so it has to be okay.” This called inattentional blindness, where familiarity with the code through development causes potential problems to be missed.
Still, this doesn’t mean they shouldn’t create those tests. They may still be the best person to write the automation. For example, if the rest of the development team is occupied. The testing team consists mainly of manual testers. The developer who wrote the feature is the best person to write the automation. Because of this, I would suggest that the most effective practice is to have a tester assist in identifying which test cases offer the most value and specify the parameters. From there, the developers can implement those test cases.
To sum up
My experience has been that developers must write automated tests for their features, especially when those types of tests require an intimate knowledge of the application’s internals, which testers may not have access to.
Though it creates a conflict since, on the one end, you’d like someone to write unbiased tests, while on the other end, developers will write quality tests quicker, and it will empower their sense of ownership. Furthermore, keep in mind, not every team has the benefit of recruiting dedicated tests engineers, so eventually, developers have to join the party.
On the contrary, It would be more effective to employ testers for this task if those tests do not require any internal knowledge, like in the case of functional, API, or GUI tests. In addition, the development team’s time constraints would come into play, like when a new project is starting, hence it’s wiser to spread the effort to prevent bottlenecks.
No matter who writes the automated tests, someone else should review them to check for code quality, missed scenarios, and high code coverage.
Remember that the ultimate goal is to create high-quality software. Anything you do that gets you closer to that goal will be great.
Top comments (0)