I find that a lot of people are confused about the difference between developers and testers working with tests. What seems to be the root ot the confusion is one of the key differences between the two roles, namely:

• The testers main task is to provide stakeholders with sufficient evidence that the stakeholders requirements on the product are met. To do this the tester needs to help the stakeholder define how to measure each requirement. The tester then needs to prove the product satisfies said measures. Much of this work is defining the criteria that we measure against. Then there is the work creating the data and reports that presents the evidence to the stakeholder.

• The developers main task is to implement the requirements the stakeholders have on the product. In order to do so it helps if the developers has access to mentioned criteria, but often they don't. Developers use tests to document details, integrations and use cases for the product. Tests are a tool we use to ensure that a product can be continuously developed in a sustainable way. They are our lifeline when we need to refactor and re-design. They are one of our main sources of documentation.

This does not put developers and testers tests in conflict. It simply means that the guiding principles for designing both test code and test output is, in many cases, rather different. It is important that this difference is allowed to exist for a product to remain sustainably developed.

When I explain this to developers I find that testing as an activity makes more sence to them. It clarifies the usefulness of the tool. It also helps them to stay on focus for what is important with tests.

When I explain this to testers I often find that they are relived. I think this is, at least in part, because Agile do not have much on the role of testers. There is also the often touted idea that in Agile we don't need testers since developers write tests. What people who hold this opinion fail to understand is that the value added by testers is not the act of checking if a product does what it should. It is to identify the criteria needed to prove the product is working, and to try to break it once the criteria checking mechanism has been automated. The automation can, and perhaps should, be done by developers. They have the skill required to build such automation in a way that is sustainable.

I intend to write a couple more articles on the subject of tests and developer testing, about what developer tests are and for who they are. I think these are important topics and I find that I have to explain them to quite a lot of developers. So if you're interested stay tuned.