Agile Testing is Collaborative Testing

Testing in general, and load testing in particular, is a collaborative process when it works, and an endless source of conflict and frustration when it doesn’t.  The developers who write the code, the operations staff that configures and deploys the production system, and the QA folks who do the testing must all work together or the project is doomed to fail (or drag on forever, which is essentially the same thing). 

This workflow for testing has been followed for decades in most companies:

Dev....QA....Ops....QA

It takes place serially, in other words.  The developers do unit testing and pass off to QA. QA does functional testing and passes off to Ops (or sometimes back to Dev) for load testing. Oftentimes load testing is done by a third party because of the resources and know how required.  In any case, this “waterfall” or tag-team approach presents both interpersonal and logistical challenges that can be counter-productive at worst, time-consuming at best.  Finger pointing and blaming are common, as are delays and miscommunications. 

Collaborative testing, on the other hand, looks more like this:

Dev.... 
QA ....
Ops....

It happens at the same time, or in parallel if you will.  Not only is it true that two heads are better than one, but it often requires everybody on the team to identify, track down and fix certain kinds of issues.  There is plenty of finger-pointing going on, but fingers are pointed where they need to be (i.e., at the bugs, bottlenecks and other issues that are always lurking below the surface).  Finding and fixing these becomes a team exercise that can even be fun, a word that is rarely associated with testing.  Not only that, but it can be done in hours instead of days or weeks. 

Agile testing is a critical component of agile development but just like agile development it requires collaboration to be done successfully.  For CapCal load tests we use Skype or GotoMeeting chat windows to facilitate the collaborative process in which everybody puts on their QA hat to run tests, analyze results, make the necessary changes and repeat the process as many times as necessary.  What may seem like an enormously expensive and resource-intensive process involving anywhere from three to five people is actually a time- and money-saving procedure that reduces the development cycle by an order of magnitude.  Not only that, the chat log contains a record of everything that transpired and can be used as a point of reference going forward. Finally, since geographically dispersed teams are the norm rather than the exception nowadays, it is a necessity and not just a convenience.

Our new product, CloudLab, includes a built-in chat component that accomplishes the same thing and we are very excited about it – check back soon to find out more!