Final sequences of Agile Approach Agile Testing

Developers became great advocates of testing and helped to advance the state of test automation in a testing services company. We observed extremely low rates of field defects. The product was sold to many blue-chip companies and won an Innovation award.

Product Success

The first version of TestStrategist was brought to market after six months of development, and the first sale made soon afterwards to a large multinational company. We settled into a regular rhythm of bringing out a new release every three months. Only once did we have to delay a release, by one week. It was surprising how disappointed we were as a team over this “slip”–a sign of how proudly we regarded our record of delivering working software on time.

Edgar, as our internal customer, had the excellent idea of strengthening this concept by establishing a Client Advisory Board, where one key user representative from each of our clients could attend a quarterly lanning meeting. This was partly a customer relationship exercise, but it was also a genuine opportunity for our clients to influence the ongoing design and development of the product, as well as get a preview of the features in each new release. This regular obligation to “face the buyers” lent a great sense of importance to each release and certainly heightened the team’s commitment to quality and testing.

The product continued to enjoy success in the market and sold at a healthy price to big-name companies, including four in the U.K. FTSE top 10. It was also being used internally as a delivery dashboard on several of our company’s test consultancy engagements. In 2005 the product won the Information Age award for “Most Effective Use of IT in Professional Services.”

Test Infected

The proof of the success of the process was that we were delivering valuable software to paying customers and satisfying their new requirements regularly. Customer satisfaction was high and we had very low rates of field defects.

However, the most remarkable sign of agile success was how we worked as a team and how it changed our view of what was important in software development. As a development team, we had made a genuine transition where we no longer thought of testing as someone else’s job. It was part of how we created good software.

We treated our growing test suites as genuine assets that returned real value on our investment. They served as both a guidance system during development and a reassuring safety net during refactoring. Quality was no longer optional, and the “cost” of writing tests was an essential element that was factored into the estimate to develop each feature.

We didn’t think about writing code without writing unit tests first. We found TDD not only a natural way to develop, but also a safe way to develop. It was likened to the habit of putting on a seat-belt before driving:once you’ve formed that habit, it feels unsafe not to do it. We were test-infected, to borrow Erich Gamma’s phrase [63].

Converting Unbelievers

Not only that, we were developers surrounded by a company of testers, and we wanted to be the advocates of this new age of collaboration-for-quality. We were convinced that the more developers learned about testing, and the more testers learned about development(especially the tools and processes that support developer testing), the better the software industry would become.

Monique, who had at first been the most vociferous skeptic, became a proud ambassador of agile and TDD. From joking to her husband that she was joining a cult, she would later be trying to teach him(and anyone else who would listen)the virtues of the agile way of working. Owen–who had cycled his roles through tester, Build Captain, UI designer, and developer–showed that his abilities and the opportunities offered by an agile project were not just a natural fit, but a virtuous cycle of reinforcement. It seemed that the more he learned, the more opportunities arose for us to improve, and the better and more agile we became as a team.

Parting

All true agile projects blur the line between development and maintenance–releasing live software early and following it with regular incremental feature releases. Rather than having a fixed project end date, the product owners can “call time” on the project when the expected returns to be gained from further development do not exceed the development team cost.

While it is one thing to draw the line on product development economics, it is more difficult to account for the value that accrues in a high-performing team. Over and above turning out software, our team was adding value to the company in the form of new skills, innovative ideas, advanced research, high morale, and leading-edge development and testing techniques.

When the time finally came for the management to take the decision to wind down the project and disband the team, the sense of loss ran deep. The team had been through a great deal and had bonded closely. What should have been a fond and celebratory farewell to the project instead felt like an unceremonious and rather sudden breakup, where cold economics had taken priority over human concerns, without any consideration for how the investment made in the team could be retained.


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