Common Themes and Patterns Agile Testing

This section provides a snapshot of testing problems found during a variety of consulting assignments throughout the United Kingdom and Northern Europe.

Composite TPI chart from a number of clients,2005–2008

Composite TPI chart from a number of clients,2005–2008.

Over an eighteen-month period I’ve been fortunate to have worked closely with the senior IT management of leading companies in a variety of sectors including investment banking, travel, mobile telecommunications,on-lineretail, and utilities(gas,electricity). This work includes assignments done in association with a wellknown London test house and one in Ireland.

The methodologies employed were a mix of agile, fragile andtraditional. Typically the technologies in use were mainly Microsoft-based,including Visual Studio Team System(VSTS),Team Foundation Server(TFS),SQL Server,Windows XP,and .NET with some use ofUNIX/Linux, Oracle databases,and Citrix Metaframe.Most engagements involved the ubiquitous test management tool–HP Quality Centre.

As I worked with these many companies,a pattern of behavior emerged as depicted in the composite test process improvement (TPI)chart. Essentially, where organizational and process maturity is relatively low, significantly more effort is needed to make agile methods work in practice.My observations over the past few years will probably not be a surprise to anyone working in the software testing field:

  • The first observation is that of constantly changing business priorities,which leads to frustration and demoralization within the test teams. Often a project is started as high-priority to get it moving and then as time goes by it gets forgotten a little and moved down the list. Test teams find it difficult to plan in this situation, whether using agile techniques or not.
  • Second, the often frantic demand for new functionality by the business managers seems to forget about the complexity of what’s already out there.
  • Third, with weekly and sometimes daily release cycles, the intellectual exercise required to think about likely modes of failure is compressed into a timeframe which I believe is bound to lead to problems later on in the release cycle. People just do not have the time to think and come up with that “eureka” moment anymore.
  • Finally, the test teams I have worked with were small, enthusiastic and had an important role to play as gatekeepers and firefighters, yet many seemed to have little influence over the business demands or the investment in new tools and technologies to help them improve their own career opportunities. Many groups were asked for metrics to prove their case and explain their added value,yet struggled to record even the simplest numbers due to lack of time.

In summary, many of the agile projects I have been exposed to have suffered from

  • no documented test process;
  • no formal test policy,strategy,or plan;
  • many tests,but with no formal design;
  • no test(or other)metrics;
  • no proper test environment(some tested in “live” environment);
  • no documented test basis;and
  • testing/testers not involved early enough.

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

Agile Testing Topics