A short history of agile testing
Fundamentally this means that policy, processes, and even beliefs are developed and derived from the ideas and influences that exist at the time of their creation. And they carry that lineage. Couple this with the fact that no one can predict what the problems of the future will be, any more than the Wright Brothers could have worried about airframe vibration in jet aircraft at supersonic speed. This means that whether we like it or not, every idea, process and procedure will become obsolete at some point in time.
Unfortunately groups, and particularly group leadership, usually doesn’t understand this. To paraphrase Eric Hoffer, it is the desire of power to give its edicts the force of natural law. We see this sort of thing all the time in the political arena, where the legislature passes laws in an attempt to use police power to “solve” psychosocial issues.
This same sort of mentality of, “impose a policy and that will solve it,” can be seen in the corporate world as well. It is a dramatisation of the desire for simple solutions and easy answers when the universe is anything but simple and answers are hard to find.
This “corporate mentality” got along fine back in the days when doing any worthwhile number crunching required a computer the size of the Johnson Space Center. That is, way back in the good old days of the horse and buggy and the IBM 701.
Today, however, with the rapid advancement of software applications, not to mention the miniaturisation and portability of the hardware that runs those applications, the old systems like Waterfall and others are simply too cumbersome.
That’s why agile testing was developed. In the old style of testing, goals are set and that’s it. Testing was done using procedures developed within the framework of “edict with the force of natural law.”
In agile testing, goals emerge from self organising groups that form in response to conditions. In the old way, testing was just the last procedure before release. In agile testing, the testing team acts as the “headlights” of the group, pointing the way forward through interface with end users.
While the old methods of testing won’t be thrown away any time soon, they do contain some glaring unwarranted assumptions. Among those assumptions are the idea that requirements won’t evolve from those presented in the original requirements documentation.
Another critical problem is that testing procedures take place on the completed software, this forces the testing unit to operate on a “surprise to crisis” basis as new builds and bug fixes cause a cascade of problem that result in massive retests, delays in launch and most importantly the resultant financial implications.
Agile testing, on the other hand, takes place directly in contact with the client, and the application is created in small increments that allow for easier testing. It is also easier to integrate tested and functioning units than to reinvent the wheel every time changes are made.
The whole idea of agile testing is to provide a system of software testing that operates as a front line endeavor. The purpose is to bring testing down out of the ivory tower and run it as a real-world operation controlled by real people and not edicts from on high.