Similar to the solution I consider in my post on single-function roles, the Braidy Tester has a provocative new post entitled, "Let's Go Bust Some Silos"
wherein he asks what happens when you get rid of the test/dev silos and
have everyone work together under one roof. Instead of having one
group write dev code and not test it much and another team who wrote
tests but didn't understand it much, have a single team which writes and
tests fluidly.
One of his commenters, Jim Bullock, raises some good concerns about such an arrangement. Is it really possible for someone focused on the creation to be objective enough to test? Do we need someone tasked with breaking things to get over the tendency to see ones own success? He also suggests that having test/dev silos help different sorts of personalities get along. There might be some merit to this. On a team where test and dev are integrated, a non-coding tester is likely to be treated as inferior. On a test-only team, their value is probably more highly regarded. This need not be so, but too often it is.
In considering this question, it is interesting to consider why we have separate testing teams to begin with. How did they come about? At one point all you had were developers. They tested their own stuff. Later, independent testers came into the picture and organized on independent teams. Why was that? If anyone was there for this formation or knows of books which speak of it, let me know.
I suspect that this happened because developers were found too busy to give sufficient time over to testing. The desire for more features made it hard to take the time to test. In a day without unit tests, the time it took to test was very large. Stopping to do so might mean missing a deadline. Based on that, it makes sense to bring in someone whose whole time is taken up by testing. There is no pressure for that person to add features at the expense of testing. Today, however, when we have automated tests and unit tests which can give us a lost of testing without a lot of time, do we still need this separate role?
http://blogs.msdn.com/b/steverowe/archive/2007/04/07/breaking-down-the-test-dev-barrier.aspx
One of his commenters, Jim Bullock, raises some good concerns about such an arrangement. Is it really possible for someone focused on the creation to be objective enough to test? Do we need someone tasked with breaking things to get over the tendency to see ones own success? He also suggests that having test/dev silos help different sorts of personalities get along. There might be some merit to this. On a team where test and dev are integrated, a non-coding tester is likely to be treated as inferior. On a test-only team, their value is probably more highly regarded. This need not be so, but too often it is.
In considering this question, it is interesting to consider why we have separate testing teams to begin with. How did they come about? At one point all you had were developers. They tested their own stuff. Later, independent testers came into the picture and organized on independent teams. Why was that? If anyone was there for this formation or knows of books which speak of it, let me know.
I suspect that this happened because developers were found too busy to give sufficient time over to testing. The desire for more features made it hard to take the time to test. In a day without unit tests, the time it took to test was very large. Stopping to do so might mean missing a deadline. Based on that, it makes sense to bring in someone whose whole time is taken up by testing. There is no pressure for that person to add features at the expense of testing. Today, however, when we have automated tests and unit tests which can give us a lost of testing without a lot of time, do we still need this separate role?
http://blogs.msdn.com/b/steverowe/archive/2007/04/07/breaking-down-the-test-dev-barrier.aspx
No hay comentarios.:
Publicar un comentario