Daniel Doubrovkine bio photo

Daniel Doubrovkine

aka dB., @awscloud, former CTO @artsy, +@vestris, NYC

Email Twitter LinkedIn Github Strava
Creative Commons License

One of the central topics of my AgileDC 2012 talk was barriers to test automation and how to remove them. If you aren’t doing test automation, are trying to, and failing, let go your QA team.

Test automation is not a management problem. In my experience it cannot be mandated, directed or ordered. Telling people that automation is the solution to all their problems and then asking them to write automated tests is the equivalent of commanding a child to go to sleep or to behave in a restaurant. Test automation is not a money problem either, where hiring external resources to “catch up” with test automation can never achieve a state of parity. It’s also not a great problem to address with experienced consultants – they easily ramp-up a system, but the poor state of affairs will be rapidly restored when the engagement is over. Test automation fits poorly into an educational problem, too, because by the time someone sees the light, they will want to work elsewhere.

After misguided attempts at test automation fail, a team is often left with a bothersome feeling of anxiety. The symptoms are very human – growing, almost unachievable expectations with every new attempt of change accompanied by a painful fear of repeated disappointment. This usually leads to a total paralysis and complete inability to motivate anyone within the team to try anything. Many get stuck in this state, feeling lack of control over the situation, witnessing individuals pointing fingers at each-other or hiding in their cubicles. This is the state of many companies: they do “some” test automation, “some” brave individuals do write unit tests, while “some” software can barely install.

You need a radical change.

If you have a proper QA team, let it go. Move those resources under the development managers to hire more developers and make the people in charge directly responsible for deploying or shipping the applications. You will have removed the safety net. You will end up with one person and their team in charge of delivering working software. If you think you got the right people, they will build the systems necessary to ensure the software’s high quality and the only way I, personally, know how to do that is with test automation.

Test automation is a team culture problem. Create an environment of ownership and individual responsibility. Don’t hang a safety net underneath it and call it QA.