Implementing Tdd: the Developing Tester’s Role
There are two things that need to be said about Test Driven Development (TDD). It is a good thing (especially from a tester’s perspective), but it is only a good thing if it is done properly. The key to success in agile processes is a strong reliance on experience, and on the fact that this is passed on. One of the roles in such a team is dedicated to testing, and this article wants to put a case for having technical testers for agile start-ups in order to ensure that TDD is done properly.
When using an agile methodology, testing is never far behind. Yet testing is something that does not come naturally to a developer.
It is a skill that has to be triggered, nourished and sustained. A more traditional developer will show eagerness to start his coding, while an agile developer will typically start with thinking his software design over and spending an adequate amount of time on his functional and technical test design. Only then will he start coding. It is this difference that an agile start-up should try to eliminate as fast as possible, and here lies the opportunity for skilled software testers.
Dubinsky and Hazzan (2004) break a good agile team down to members with dedicated roles (aside from coding): customer, tracker, coach, tester, etc. Specifically on the testing role, the authors stress that it should be attributed to a developer. His responsibility essentially lies in guiding team members by example.
I would like to turn this argument around: a software tester with a sound background in development will have a much bigger impact on an agile team than a developer with a testing role.
The developing tester
Of course, this seems like a discussion on mere semantics: the developing tester versus the testing developer. The main difference between these two is in their mindsets. While a developer sees parameters in methods, an experienced software tester sees opportunity for
When using an agile methodology, testing is never far behind. Yet testing is something that does not come naturally to a developer.
It is a skill that has to be triggered, nourished and sustained. A more traditional developer will show eagerness to start his coding, while an agile developer will typically start with thinking his software design over and spending an adequate amount of time on his functional and technical test design. Only then will he start coding. It is this difference that an agile start-up should try to eliminate as fast as possible, and here lies the opportunity for skilled software testers.
Dubinsky and Hazzan (2004) break a good agile team down to members with dedicated roles (aside from coding): customer, tracker, coach, tester, etc. Specifically on the testing role, the authors stress that it should be attributed to a developer. His responsibility essentially lies in guiding team members by example.
I would like to turn this argument around: a software tester with a sound background in development will have a much bigger impact on an agile team than a developer with a testing role.
The developing tester
Of course, this seems like a discussion on mere semantics: the developing tester versus the testing developer. The main difference between these two is in their mindsets. While a developer sees parameters in methods, an experienced software tester sees opportunity for