In the previous post I wrote about a lecture I did in Utrecht. It was about that companies decide that they “should be doing automated tests”, but are unaware of what that really means. Often the idea is triggered because it becomes apparent that even though a lot of money is spent on (manual) testing and testers, the quality of the releases does not really increase, and automated testing is seen as the answer. Which it is, at least partially.

In my lecture I stressed that automated testing is more than just rolling out JUnit. Automated testing involves careful consideration on what and when to test; a good testing landscape consists of several types of test, from unit tests, to integration tests and UI tests. And more importantly those should be in the correct ratio’s, ideally resulting in the famous testing pyramid (and hopefully not the dreaded testing cone).

Understanding these different types of tests, and realizing that you continuously need to consider which tests to write and, more importantly, which not, is a very important aspect that needs to be coached in an organisation. It is too easy to just roll out an expensive UI testing tool, and start creating tests by recording some scripts; quick results, low threshold and doomed to fail.

But continuous coaching is not only important on the technical side of testing. The often strict roles in an organisation may need some blurring. After all, developers need to write tests as part of their new “definition of done”, but they are not testers. So maybe testers should coach developers on how to write good tests, and maybe even should be signing off on them in code reviews. The other way around, since we need frameworks that both developers and tester are able to use, chances are testers will start to write automated tests in a code like fashion. So it may be required that testers write a bit code as well; frameworks like Cucumber certainly require some coding now and then. Maybe testers can even fix a simple bug. Why not? That is what code review and the automated tests are there for, right?

And about those changing roles; what are testers going to do once everything is automatically tested? Will they be out of a job? Fear not! It is quite the opposite! Testers will stop being human script robots, and can finally start doing what they should be doing in the first place; pretending to be the evil user, and finding innovative ways to break the software. So bugs for once are found and fixed before a release.

And last, but certainly not least, even if you have developers faithfully writing tests, and testers faithfully putting the software through its paces, then the coaching still is not done. Because writing test is the easy part of testing. The real challenge lies in writing testable code. Or in other words: writing the code in such a way that pieces can be isolated. And that is a whole different animal, worth many blog posts on its own.

I really enjoy the 2 hours that the people were willing to listen to me ranting about the implications of automated testing. Oh, and the pizza of course.