Waterfall Test Automation – Be Nimble without Being “Agile”
By Nick Olivo
Sr. Sales Engineer
Test driven development, stakeholder involvement, extensive collaboration between developers and testers, those are some of the hallmarks of agile development.
And none of that applies to you.
You’re still stuck on in the land of waterfall methodology, where a program is written and then “thrown over the wall” to the test team. The developers don’t talk to the testers, and they don’t want to. Developers don’t do any testing because “that’s what the QA team is for”. If the release goes out the door and it works well, the developers are heralded as heroes. If the release is a steaming pile of crap, QA gets blamed.
Unfortunately, a lot of software development shops still work like this, and getting tests automated in this kind of an environment can be challenging. So where do you start?
Automation is not a Side Project
The first thing to know here is that you cannot consider automation a side project. If you are constantly abandoning your automated testing efforts because other work has come up, because you have too many manual tasks to do, or because your schedule is too tight, then you’re never going to get anything automated. Managers and team leads need to understand that automation is just like any other part of the development process; you can’t do it when you feel like it or you’re never going to see any payoffs from your automated efforts. If you’re the manager, be sure to build the time into your test cycles to develop automated tests. If you’re a tester, make sure your boss understands the commitment automation will require.
Automation will Require a Dedicated Resource, with a Different Skill Set
TestComplete makes it possible for people with limited technical skills to automate tests. However, my experience has always been that you need at least one person on your QA team who’s tech savvy to help others out when a technical challenge arises. This will give you one person who can focus exclusively on test automation, help other people out when they get stuck, and provide a liaison between QA and development. Make sure this person either has a scripting/programming background, or get one person on your team trained so that they can fill this role.
Look for the Pain Points
It’s tempting to just grab the first test case you see and start automating it. Resist that. Instead, look for those tests that are most time consuming, or most prone to human error. Automate those first, and then look for other tests. Note that this does not necessarily just mean test execution; sometimes the things that take the most time are preparing an environment for testing, installing the application itself, or generating data for use in a test. Find ways to automate those tasks, and you’ll save your test team a lot of time in the long run.
Start Small and Build Up
Ok, so you’ve isolated the first test plan that you want to automate. It’s a forty six page monster smoke test. Take a breath and step back. Don’t try to record it start to finish. Instead, break the test into smaller pieces. Maybe the first six pages of the test focuses on your application’s admin functionality, and the next eight focus on its reporting capabilities. Automate the first six pages of the test, and then get those running every night. Then automate the next logical section, and the next. By doing this, you’ll do two things. You’ll be building up some confidence and “street cred” with automation, and you’ll be able to show your boss that the automation is actually doing something.
These suggestions are just the tip of the automation iceberg. For additional reading, 6 Tips to Get Started with Automated Testing, is a nice free resource.
Sound off in the comments with other tips & techniques you’ve found helpful as you first implement automation.