Paul Grizzaffi joined at DFW Scrum last night to go over the topic above. Too often, automation has to be justified and bought into before we spend resources on it. I like how Paul compared it to an Insurance Policy. No one likes to pay for insurance unless of course the tornado takes your house down or the car is totaled. Look at automation in that it will save us from potential catastrophes and customer implications of bad software. However, unlike insurance, automation can make us more efficient and “Agile” at the same time.
I like to say that being “Agile” in software development, simply means that you can ship software when you want. If a feature was demo’d and thought it was good to release to customers, could you do it? Or is it a lengthy / painful process to push code from our developers’ machines to production?
Automation is definitely a specialized skill set at this time, we all know it would be better and a good idea to do, but how do we go about doing it? Paul’s message was clear that you can’t template an approach to automation, but he can share with you some good practices / questions to ask. Other valuable lessons are what NOT to do.
Quality is everyone’s job, automation is everyone’s job. How do we fit it into our development processes? Paul’s presentation is available for download, check it out and hit him up for questions if you have any.
- Don’t try to automate a broken process (garbage in and garbage out)
- Must know your process and job before you can automate
- Think of your automation as a safety net / alarm system (confidence in making changes)
- Test cases are your contract between the requirements and the interface
- Try not to change Test Cases for your automation unless the contract changes
- Automation is an insurance policy, you want a high deductible you get low cost (risky)
- Discuss automation in context of opportunity cost (not ROI)
- A human used to do x now its automated they can go to y
- Exploratory testing is opportunity cost, computers are good at repetitive tasks, humans are not