What do organizations do when they are trying to create an agile shop? I have been making this one of my main goals for the past few years, helping to transform a hardware focused, waterfall driven, stacks & queues organization into an effective agile software organization. We've had some success and challenges along the way. I'm a firm believer in the agile way, but what does that mean for the group that came from the waterfall way? People assume they are being led to the water, but in fact the leader may or may not know what they are doing. Over the last few years I have had opporunities to work with people that thought tools were the way to salvation. The reality (as I see it) goes a lot deeper than that.
Education is one of the keys.
If you give people tools, they may or may not know how to use them. If you give them a tool in context of what they are doing, I think then you can bridge the gap between how tools are useful for evolving the job. For a software company, I think we are interested in reducing long term costs, maturing processes and intellectual property value of regression testing. Some of this is related to automation, and some of it is not.
Think of a hammer - at some point in history, people used rocks to bang things (I assume they were banging open coconuts... I don't know why, that's just the image I have), then the introduction of the fulcrum allowed for more energy transfer to the hammer. Context: it made bashing things easier.
Same is true in software, but not always so obvious. Automation is a bad term because it takes the critical thinking out of process. A recent post talked about test automation and the snake oil (I'm hugely paraphrasing). To summarize, test automation as a concept was wildly adopted but often not understood. It can't be treated in the same way as other project because of its nature, to be curious and to find things outside the norms. You can't take the person out of the equation and I think that's where the term makes it sounds like people aren't important.
In a related post, Corey Goldberg had a different slant on the idea (and he says it better than I do) -
"When I say "this test can be automated", I don't mean a computer can magically replace a sapient process to create a useful test. All test design and methodology is devised using a sapient processes (obviously). However, testcase generation, data generation, test execution, results analysis, etc, can often be done without human interaction. This has been described using terms like: "Automated Testing, "Test Automation", etc. Among some of the more vocal people in the testing community, these terms are considered confusing, inaccurate, harmful, or just a cover up for what is actually a non-scripted test"Goldberg coins the term called "programmatic tested" as opposed to "computer assisted testing"; I'm a fan of using this term instead and have been trying to get people to use it at work.
So, are you an Agile shop... I think the real question is are you an Agile in your job? Do you know what it means to be Agile? I'm still figuring it out. I think its about focusing on people and how they use the software as opposed to the whether or not development is complete. Automation needs to be a part of this vision (this is my stake in the ground), but remember that it is just a tool, not the end-game.
