Introducing automation to an existing large team

A reader on my article at infoq asked an interesting question - introducing automation to a big project which has been worked on for some time. I plan to write more posts on this topic, have a lot of thoughts, but here’s my immediate answer -

A very strong actionable technique that I have seen work well is that you create a small/minimal smoke test suite for you larger app. You can decide on what comprises a suite of smoke test -
  • Basic user actions - some 4-5 use cases without which a user cannot use your application. (for e.g. on an eCommerce site, my smoke tests would comprise of login, user registration, search, end-to-end purchase and payment).
  • Integration points - choose must-have integrations - like payment gateway (same eCommerce motif), oauth for authentication against Facebook or some such. Write smoke tests that touch these integrations to know if every build that you process is verified for these.
  • Attack a small part/feature of the application. You can choose the most important, the most buggy etc. Write tests only for this part.
  •  Concentrate on the currently “under-development” work, which will give the team immediate value in terms of coverage. This is a bit counter-intuitive as there would be a lot of changes while you work. But I have seen this work wonders at times, and your team starts worrying about test maintenance from the first step on.
You can choose more ways according to your project, better still, mix and match. But make sure you choose the most important 5-10 and not 50-100 test cases for your smoke suite. Your smoke suite shouldn’t take much time to run aim for < 5 minutes. The correct way to work with these would be to make these smoke tests as part of your CI process so that the team get immediate benefits out of the smoke tests.

Your team will start seeing value in automating regression scenarios with this smoke suite in place. From then on, you can expand your suite from smoke upwards, adding more complex or more detailed scenarios. Another thing to note on big complex applications - aim for small tests, get quick wins. Then combine to make bigger ones. This will keep your team involved and constantly working towards covering every possible nook and keep being excited about it. But do make sure everything is part of CI, because if its not, then people lose faith.

Finally, as ever, keep showing value, make sure the stakeholders understand the importance, you can do this by sending them reports, and talk about gains etc. If your team buys in with the idea, there’s no stopping.