1. Say no to repetitive tasks
The real step toward automation happens before you even write a single automated test! Let’s face it: manual testing is haunted by repetitiveness. And anyone will eventually be bored by doing the same thing over and over again. Some people will mitigate this challenge by automating single bits and pieces of their work. The result of the whole automation team “fighting” repetitiveness, will be a collection of small scripts and utilities, for example: a utility to check resource availability, a script to import test data into a database, etc.
2. Find a place for your scripts and utilities
Those helper scripts and utilities will be used by most of your team and changed by more than one engineer. Therefore, you must store them in a centralized and accessible location, a source control system will be perfect for that! Remember, utilities without a source code, written by someone who’s already left the company, will only add up to your technical debt.
3. Start small but successful
Now it’s time to actually automate those repetitive test cases. It’s tempting to start out a broad initiative with a whole lot of planning to allocate lots of resources for automation. However, I would argue that even if you do have the resources, it’s the minimal tangible results that are the most important in software development and test automation. One test providing reproducible results is much better than a huge matrix of “traffic light” tests of green, red and yellow. At this point, the tools and platforms don’t matter as much as a single stable automated test. My recommendation is to pick scenarios that regularly catch regression bugs. What could describe a success story better than your automated tests finding bugs from day one?
4. Don’t separate the automation team from the functional testing areas
While this might be somewhat of a controversial statement, in my experience, the quality of automated tests and their development speed are higher when those writing tests also gain the expertise in the functional testing areas. If the manual testers are separated from engineers who write the test code, then you lengthen the feedback loop which makes the work less effective.
5. Zero tolerance to red tests
Just as testers refuse to be content with failing manual scenarios, automation engineers should not tolerate red automated tests. Most importantly, if the test fails due to a known bug, at some point you can’t be sure if there’s no bug beyond that point, and such an uncertainty might be bad and make the whole thing useless.
6. Classify failures – Automatically
In my previous blog post I argued that you might want to classify your test failures automatically. One additional point is that classifying test outcomes will let you build additional logic on top of your tests. For example, for your continuous integration you might want to treat your “known issues” as passed tests and retry tests in cases of brief infrastructure unavailability.
7. Make developers your allies
Needless to say that your colleagues developers should be aware of your bugs! The only way to build the organizational testing advocacy, is to ensure developers are comfortable with the bugs you submit. Every test should be clear on what feature is tested, how, what are the inputs and what are the expected and actual results.
By this time, most of the tests have been rewritten multiple times. If not, ask yourself why. Do these tests still find bugs? The test code is just like the product code, so the changes are inevitable. Since this is not a post on automated test refactoring, I will only stress that the amount of refactoring should be healthy: too much and you’ll refactor instead of writing new tests, too little and you risk being overwhelmed by the technical debt.
9. Connect everything together
We did it! The tests are running, they are stable, they find bugs and everyone likes our test team (hopefully). Naturally, we don’t want to keep configuring our tests manually. Let’s do the final push and connect our test system to the build system so that the whole build runs in several clicks with tests each time you build your product.
Please join the discussion in the comment section below, and let me know if you think of any more helpful steps! 😎