Overview of Test-infecting A Development Team Agile Testing

How to get developers to willingly spend roughly half their time testing, and get the customer to see the economic benefit of this!

The Project

Cresta was an innovative company of testers. Their core business was testing and test consulting, not software development, although many of Cresta’s consultants were technical test automation specialists and some were ex-developers. The decision makers in the company were well aware of the need to develop tools to support the business and to improve the quality of project delivery. Rather than outsource this work, it made sense to do it internally, as it made use of thetechnical skills in the company and provided an excellent internal “laboratory” for research and innovation in software quality techniques. In 2004 they initiated a project to build a quality metrics dashboard, which would be called TestStrategist.

Developers and Customer

I was to be the lead software designer, but I was also doing programming, so it was important to have a customer (in the XP sense)from the business, someone who was ultimately going to be responsible for helping teams use the product and to sell it to clients. This was to be Edgar, a director and founding member of Cresta. “Pure” XP recommends a full-time customer in the team, but because the system we were building was based on an existing process that I had designed, a lot of the business knowledge was already in the team, and we relied on our customer mostly to take decisions regarding priority, so we could live with the fact that Edgar was not full-time on the team.

We also needed a good technical guy who could handle our hardware and network issues, as well as cut code–Scott was someone I knew and trusted and, although he was new to the agile way, I felt confident he would pick it up. As well as being a fine developer, he was a naturally organized team member who did the important job of setting up our team collaboration site and tooling to enable remote working.

For our main development resource we took on Monique, an external developer whose coding skill was known to us from previous dealings. When we interviewed Monique prior to joining the project we described the process we were intending to use and mentioned XP practices such as close customer collaboration, test-driven development, collective code ownership, and pair programming. She was clearly skeptical and showed classic developer defensiveness, especially at the idea of making “her” code so open to the scrutiny of others. She went home and told her husband of the extremely strange development practices that had been suggested to her, adding that we acted like we were asking her to join some sort of cult. Fortunately for us, she needed the work, and she agreed to join the team.

Testers?

Initially, it was just the three of us, all developers, as full-time members of the team. We did not assign any full-time testers since, as a testing company, we knew there would be an ample supply of those as we needed them. The strategy was to rotate test consultants through the team on a “tour of duty” to give them experience of testing in an agile environment and avoid losing a “billable” resource for the whole duration of the project. Before we could do that we needed to bed down our own process and that meant taking responsibility for all testing ourselves. This, after all, was not in any way inconsistent with accepted XP theory, which says that developers and customer are jointly responsible for testing. (The reality of most agile projects of nontrivial size is that dedicated testers add great value, since neither the developers nor the customer have sufficient bandwidth or experience to include all testing).

Good testing intentions are not enough, and our challenge was to ensure we could “drink our own champagne” and show that we were a quality-oriented development team, as dedicated to testing as we were to development. We were well aware of the risk to the company’s reputation of releasing a product that was not of the highest standard of quality. We also had to get to grips withhe new concept of test-driven development(TDD). This is a challenge for developers who might not think that testing–especially at the levels required by TDD– s a productive use of their time. It is also a challenge for management, who may take the naive view that development time on all tasks is going to double.

We were all climbing a new hill and starting from the bottom. What we had on our side is that we worked well as a team:there was mutual respect from the outset and an eagerness to learn from each other’s experience.



Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Agile Testing Topics