Everything SQA

Do Automated Test Tools Impede Agile Groups? [QA/opinion/review]

I have touched on this before in a previous post and I know that most Agile environments relish the goal of eliminating silos, but automated tools are a part of QA, and can be embraced into the fold of any Agile process. I say this because I have biased view of how these tools can assist the testing effort with a positive outcome, no matter the process.

I have expanded my career by becoming a subject matter expert on implementing tools like LoadRunner for a variety of corporate and even start-up company projects. Performance testing has a foundation that Agile processes cannot entirely overlook, and in my understanding, it does not. Interestingly, I came across an article that debates the concern of how traditional automated test tools add strife to the Agile process…and interestingly, this debate is raised by Elisabeth Hendrickson – a person who I highly admire as a “test obsessed” QA evangelist. She has said this before, and I raised my response here on this blog.

By Elisabeth’s summary, she states the following:

Why Traditional, Record-and-Playback, Heavyweight, Commercial Test Automation Solutions Are Not Agile

Three key reasons:

1. The test-last workflow encouraged by such tools is all wrong for Agile teams.

2. The unmaintainable scripts created with such tools become an impediment to change.

3. Such specialized tools create a need for Test Automation Specialists and thus foster silos.

These statements are true, but then she omits the fact that automated performance test tools (which may sit in another category) are defined by there need to have…

1. Knowledge experts that specialize in building test scenarios to properly identify bottlenecks in the network, server, and application.

2. A separate scripting environment, since these tools contain their own IDE for development.

3. Does not impede workflow, since performance tests should be conducted once reaching code completion.

In review, I know that Elisabeth is focusing her opinion on tools like TestComplete, QuickTest, SilkTest, etc. These applications may have an almost antiquated feel to them, especially when comparing their usability against the forging and enterprising Agile process. However, you really can’t beat the regression test solutions that these tools provide when time is a critical factor in a given project life cycle.

This is my opinion. But there are others that may disagree, especially Elisabeth (please watch her video. She’s delivers her opinion well and admirably so). Some may feel that test tools do not fully answer the need to support the paradigm of Acceptance Test-Driven Development (ATDD), which has become the tool for any Scrum Master in training. But it includes includes automated testing. So does this square up with what Elisabeth says? It does. It supports the “Automated Test First” mantra. See the graphic below. This is ATDD from the 1000 foot view.

But all is not lost.

Elisabeth gives a great conclusion to how these automated test tools can be included, by identifying the need for collaboration between all involved in the Agile/Test Tool environment. I believe that performance testing stands apart from this still, but I know that Borland’s SilkTest and HP’s LoadRunner will eventually bridge that gap soon.

Elisabeth closed with the following quotes:

Agile teams need test automation tools/frameworks that:

• Support starting the test automation effort immediately, using a test-first approach.
• Separate the essence of the test from the implementation details.
• Support and encourage good programming practices for the code portion of the test automation.
• Support writing test automation code using real languages, with real IDEs.
• Foster collaboration.

Link: Test Driven Developer
Link: Why Traditional Test-Automation Tools Stifle Agility