Lessons agile automation approach Agile Testing

The change program progressed more slowly than expected.This was in part due to a very flat organizational structure,which meant that it took longer than anticipated to get everybody onside with suitable tools for unit test and code analysis automation and configuration management.

The release testing team pressed ahead with automation of testing and reduction of the release testing window to four weeks but found it difficult to deliver in the four weeks because the development and configuration management changes had not been implemented.This led to lengthy integration delays caused in the most part by a lack of continuous integration by the developers.

What worked well included

  • the drive for greater tool usage in development;
  • the adoption of configuration management disciplines,which enabled greater control over the increasing complexity of the product configuration;and
  • the closer working relationship between developers and testers,which produced a measurable increase in quality.

It could be argued that these disciplines could have been adopted anyway,regardless of whether an agile method,such as XP,was adopted.

There is always a danger with testing or quality-driven improvement programs that the rest of the organization does not take them seriously.There was a feeling that with this “testing-driven” change program,the changes were tolerated as long as they didn’t cause any harm to the basic operating model of the company.

Additionally as the company grew and became established in the marketplace,it was observed during the sales process that potential customers were performing a more rigorous review of the development approach.There was a view that City Street Traders’ management was keen to wear the agile badge as a way of giving credibility to some of their established development practices.

What I would have done differently,with the benefit of hindsight,would have been to work harder to make the change self-propagating.Although the development team was already relatively small,I would have started with a smaller development team, let them establish the benefits,and then sell them onto their colleagues.Thus,a momentum for change would build up,mitigating against resistance and halfhearted adoption.The learning point from that experience is that just because the company is small,you do not have to change it all in one go.

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

Agile Testing Topics