And they lived happily ever after
So much has been written, discussed and argued about the joint life of developers and testers. It seems whenever these two groups meet, there will be more shouting than agreements. Predictably, this is in contrast with what the people are there to do: Work together to provide value to customers.
Let’s see how this whole thing began, where we are, and what we can do better.
The Prehistoric Era
In the beginning, there were no testers, just developers. Software developers were not that different than other contributors to the business, except for one thing: They were a major cost sink. Not them specifically (although good developer skills were hard to find even then), it was the development time and resources (read: giant computers) needed to run the software. Having a tester in place did not make economic sense: Computer time was so expensive that giving a time-share to a tester seemed wasteful.
Without anybody checking their work, the software developers did their own testing. Since computer time was expensive, they made sure their software actually worked by logging and printing information and “debugging” offline. There were no IDEs to debug then, and computer time was much more expensive than going over hundreds of pages of printed data. All the people who reviewed data were also part of the development team, so everybody spoke the same language and understood the issues. It was one team going forward, albeit slowly.
Breaking Up The Party
As software boomed and computer costs lowered, software companies began to look at quality of software as a cost concern. Customers became fussy. They were no longer satisfied with the “out-of-the-box experience”, and required fixes and changes to what they paid for.
One solution offered was acceptance tests: Scenarios the customer would run on the system he received. These scenarios were like a contract between the software company and the customer: The software had to pass the tests before it was accepted.
At first, the developers were the contacts when the customer ran those tests, or ran the test themselves. But software organizations quickly realized developers were not very good at customer relationships. This led to the idea of physical separation of customers and the development team.
Client/developer interaction was not the only thing not working. Since acceptance tests sometimes failed, there was a growing feeling the developer team needed more quality supervision. This supervision could have been from other developers, but development was still considered costly, and testers didn’t need to know the intricacies of how software works. So a new profession was born.
Of course, this kind of organizational shift does not happen by itself. Organizational changes require management backing and coordination. So after a few years there were not only developers and testers, but entire teams and organizations dedicated to development, and their counter-teams in the testing field.
That’s not all, though. New professions require training and methodology, which began to evolve as more testers wanted to improve their craft. Training and certification companies saw the opportunity, and created programs for both testers and developers. As the business of methodology grew, experts took hold over the conversation. Now there were different experts in different fields, and the divide between developers and testers was formed.
A Tale of Two Cities
A developer and a tester working on the same project lead two different lifestyles. The developers see themselves as innovative creators. They create software from nothing, only to get pointed at what’s not working by the testers. On the other hand, the testers wait (and wait) until the developers give them something that usually breaks the minute they touch it. Because of the lack of quality, testers spend their time reproducing bugs on the main scenarios. This leaves most of the application untested, due to lack of time.
Developers get the sense that testers are the enemy, so they throw releases over the wall, hoping for as little communication with the testers as they can manage. Testers get the sense that developers are lesss professional then they should be, otherwise testers would not be needed. This forms distrust between the teams.
There is another problem with the two entities in the organization: The requirements and test scenarios are now coming in flavors. Since there are two departments speaking different languages, system requirements get translated, and are understood differently. This creates a gap of expectations not discovered until the testing phase. Accusations usually follow.
The final element that causes friction between the two teams is the time gap. Testers can work only if they have a product. So they wait for the developers to deliver, because only then can they start testing. While the testers test, the development team moves forward to other features in order to maintain productivity. However, development stops as bugs are reported by the testers and the developers accuse the testers of taking their time away from interesting things to fix bugs.
All the tension between the two groups flies in the face of the business goal of seeking less waste and a valuable product. Instead it creates rework, round-trips and accusations before the product sees the light of day.
The Agile Bridge
When the agile movement began, it put working software as the goal. That was a wise step: The agile manifesto signatories came from different sides of the software industry (developers, testers and management) because they saw the business value first. Everything should fit that cause.
The solution was “Whole Team.” This is an Extreme Programming practice aimed at putting the customer and the development team together, in the same room, if possible. Smart organizations also added the testers.
As developers and testers shared space together, they started doing something they had forgotten how to do: communicate.
They started talking about what the requirements were, using the same language. The language barrier disappeared, and both sides had the same expectations as to what would work and what wasn’t solved yet.
What helped most was that within the sprint, a feature was developed, tested, and whatever bugs were found; were fixed. The time gap disappeared since both the developer and tester worked inside the iteration.
When the developers and testers sat together within the iteration, they discovered something even better: The testers had some influence over the development, by catching errors early in the process and deciding what to do about them. The developers got a bonus as well: bugs that were caught and fixed within the sprint were not real “bugs”. Developers hate the idea that they write software with bugs. Tracked bugs were only those that escaped the iteration; the ones that were fixed on the way were not considered bugs.
Transformation
The agile team also had some weird sociological side effects. The borders between the developers and testers were not clear anymore. Much like specialties within the development team had started to disappearwhen developers began to do all kinds of tasks, so it was between the developer and testers. Developers started testing, and testers have learned to develop and automate. No one can do everything, but everyone learned additional skills.
Another side effect was the rise in quality. Agile says quality is everyone’s job. Developers have returned to what they did in the beginning: making sure their code works. As quality rises, the testers now get the benefit of doing exploratory testing, rather than basic sanity tests. The quality was therefore boosted twofold.
Happy End?
Agile teams seeing successes are still evolving. Smart companies are moving forward by building feature teams that consist, not only of developers and testers, but also other parts of the business.
But these companies are in the minority. Most organizations today have not made the transition into real collaborative agile development. Developers and testers are still separated by organizational borders that believe it is good business sense to separate the two. The separation causes both technical and personal resentment between the two teams.
Agile has proved through process and collaboration it is possible to break the walls between two opposing parties. But when successful agile implementation takes place it must involve melding the development and testing organizations together. Without proper re-organization, it is not possible to achieve success. Or in agile words: Working Software.
About the Author
Gil Zilberfeld is Product Manager of Typemock. With over 15 years of experience in software development, Gil has worked with a range of aspects of software development, from coding to team management, and implementation of processes. Gil presents, blogs and talks about unit testing, and encourages developers from beginners to experienced, to implement unit testing as a core practice in their projects. He can be reached at gilz@typemock.com, and on his blog.
