Testing in a Quasi-Agile Environment
While we were sitting around the breakfast table this morning, my wife asked me what I had to do today. I replied that I needed to write an article on “Agile Testing”. Overhearing this conversation, one of my daughters quipped:
"Agile testing??? You mean as opposed to clumsy testing?"
As I think about, I realize that her comical comment is, in fact, accurate. The way I have to test on a traditional project is rather clumsy and inefficient compared to the way I test on an agile project. I admit it. I am an agile proponent. I favor an environment where the management team, the development team and all of the stakeholders are on board with agile development. I have found that the team can produce systems not only faster, but of higher quality, when the team I am working with uses mature agile methods. But I am also a realist. Often I am faced with an environment where corporate policies and procedures prohibit the team from using agile methods “by the book.” I could choose to not work on those projects until the organization is fully agile compliant, but I find that there is value in helping software development teams “drive an agile peg in a CMMI hole.”
The reality is that most corporations are still fairly traditionally structured even though many software development teams are heading full steam into modern, highly iterative, agile software development techniques. This leaves management stuck coping with an organizational and technical paradigm shift that traditional project management practices are inadequate to handle. In the highly iterative, fast-paced environment characteristic of these modern software development projects, traditional approaches to testing, quality assurance, requirements gathering, scheduling and estimating break down. Managers trying to encourage best practices as recommended by CMMI and SPICE find themselves at odds with developers trying to adopt best practices as recommended by the agile manifesto. This article discusses practical ways for testers faced with the formal, heavy weight, process control inherent in CMMI recommendations to still achieve many of the lighter weight, more flexible practices of agile development. The goal is to produce a pragmatic, yet productive quasi-agile development environment.
In this article, I am not addressing the many additional issues that arise when an organization tries to be both agile and officially CMMI certified. Instead I am addressing the simpler question of how an agile tester can survive in a traditional organization where many policies and procedures are derived from the waterfall process and the CMMI philosophy.
I find the following three simple principles helpful in succeeding in a quasi-agile environment.
1.An attitude of multi-cultural tolerance which allows for the peaceful co-existence of processes derived from very different philosophies.
2.Barely sufficient compliance.
3.Focus on the goal of traditional control structures and show how the goal can be met in innovative agile ways
The following 2 policies are typical for a traditional organization, but not suitable for an agile development team. I will use them to illustrate how the above principles can be applied.
•All issues must be documented in an issue tracking system.
•There must be a detailed comprehensive requirements document.
Looking for the comprehensive set of services such as SCRUM,"Testing SOAs", Quasi-Agile,Object Oriented Testing, Black Box testing, SQL Testing for building quality systems. Our training provides a rigorous foundation in requirements based testing.
