Tester as Identity

In the interview for the first development job I applied for, I asked my potential coworkers what they thought was most wrong with their process. They admitted to a significant disconnect between them and their quality team. They felt this resulted in a lot of knocking something out and “throwing it over the wall” for it to be tested and verified. Putting testers in a separate silo allows developers not to take responsibility for the quality of the code they write, which wastes time and resources. While it was laudable that the developers recognized this, I did not accept that job offer.

There have been a number of discussions recently about what it means to be a tester and what role such a person should have in a company. Since I expect minimal disagreement that developers need to write unit and component tests for the code they write, for the purposes of this post, ‘tests’ are functional tests of a user interface (UI), and ‘testers’ are people who write those tests. If the push is merely to merge siloed departments of Quality and Development, then this is absolutely a great way to minimize the potential for the building of the aforementioned wall. My concern is the proposition that the only correct way to structure a team is to remove the distinct role of tester and to require developers to do all of the testing.

Angie Jones recently wrote an article Why Developers Should Not Lead Your Automation Efforts. She states that in her experience developers have done a poor job of creating and maintaining worthwhile test frameworks and tests. This is a legitimate observation and mostly matches my experiences to date. Her list of skills that are useful for testers that are not commonly held by developers is also worthy of consideration. Based on those two points, her conclusion that there should be distinct roles for testers and developers is reasonable and should not be summarily dismissed just because it doesn’t fit the current ideological trend.

Here are three often discussed models of Agile processes:

1. ATDD¹ Full Stack TDD (Test Driven Development)
   • The Developer thinks about what the user needs to do and writes UI tests
   • The Developer breaks down the components of what needs to be implemented and then writes component tests
   • The Developer writes unit tests for the classes that make up the components
   • The Developer implements the code and makes sure that the unit tests, then the component tests, then the UI tests are all passing
2. BDD (Behavior Driven Development)
   • Testers, Product Managers and Developers agree on the business requirements by writing all of the UI tests that need to pass in order for the feature to be considered complete
   • The Developers proceed much like with ATDD¹ the previous example, except without the UI tests
   • While the Developers are implementing the feature, the Testers are writing the tests and the associated Page Objects
   • Developers get the unit tests and component tests passing
   • Testers and Developers ensure UI tests are passing
3. Cross-functional Teams
   • Each development team is made up of members with different specialties, but with sufficient skills to help each other out and increase the team’s bus factor
   • UI testing responsibilities are not the sole responsibility of one person, but there is at least one person who has the required skill set for test automation

If this recent Twitter exchange is fundamentally about whether or not Angie is wrong to say that the first model unequivocally can not work, then I’m somewhat in agreement (though I respect her choice to make her case dogmatically). If this movement is stipulating that only the first model here can be successful, then it needs to make a much better case for why the alternatives can not be successful. If the conversation is merely about having multiple ‘classes’ of employees or an us-vs-them dynamic in the company, then getting rid of the tester role is neither necessary nor sufficient to accomplish that. Additionally, there is a certain irony to using the recently coined word “testering” (focusing on the role of the tester instead of on tests and testing) in the context of denigrating the ideas of people who disagree with you about the proper role of a tester in a company.

Questions I still have about a developer-only approach:

• Am I describing the advocated process correctly?
• Who is responsible for training the developers in the skills that they need to write tests?
• Who creates and maintains the framework?
• How well does this approach scale?

If there are relevant articles that I need to read, I would greatly appreciate links.

1^ Edit: While I’m technically describing an activity that is Test Driven Development with acceptance tests, ATDD is a technical term that has different connotations.