That’s a question you won’t hear from most software developers who do not know where to start when thinking about doing software test automation! To put you in context, I’m currently a continuous improvement initiatives leader in a large non-software company (doing a lot of software). I faced a lot of resistance in adopting practices and processes to improve our software quality. Automated testing is by far the most difficult practice I had to put in place, even in my own team; Now imagine when you have to convince 1000+ developers you don’t even work with directly! This article is about the most important reason why tests do not get written.

First act: The excuses

We (our improvement team) were all given the classic excuses for not doing tests:

• I don’t have enough budget, it will cost too much
• I don’t have time, the customer expect a release tomorrow
• I will do it later
• There is no bugs in my code, it works on my machine
• It’s useless, I do not see the value
• etc.

It was typical, people (developers as much as management) were not convinced about the benefits of automated software testing. So we worked hard to prove them wrong by working with selected strong software developers who demonstrated real benefits when doing automatic tests. The key people now convinced, we thought that the practice would improve rapidly… and… huh… no! almost a complete status quo.

Second act: The excuses (take 2)

Instead of the expected improvement trend, we then got a second round of excuses:

• I will start when I get some working examples
• There is not enough documentation available
• It doesn’t apply to my code, my use case is different, my software is different
• My code is not testable, I do real-time code
• etc.

We thought it would be easy for us to fix that, after all, we got some gains after the first round of excuses. So with a team of firm believers, we wrote a series of guidelines on how to do proper automated tests; we put in place a forum, a wiki, documented some more processes and tools, and developed examples for different contexts and programming languages. With that made available to all, you won’t believe what happened next… We got back to square one with the same old excuses! There was some improvement but it didn’t really show on our indicators. We asked ourselves what we did wrong until I got a moment of truth!

Third act: The moment of truth

On a typical workday, one developer (a strong one) came to me and said : “Hey Max, can you show me how to do a unit test, I don’t know where to start?”. It only took me 1 hour to get him started. He came back to me a month later and said : “I’m now doing TDD and it’s great, I save so much time debugging my code. Thanks for helping me out”. I then realized that the key was in the people: Human always have an ego with a dignity to preserve. It must have taken this developer a lot of humility to ask me that question but it paid for him in the end. I wish I had found

Why are we embarrassed to admit the we don’t know how to write tests? article from Misko Hevery sooner. It would have saved us a lot of time. As shown on this picture, developers are just embarrassed to admit they do not know how to write automated tests. Assuming that every developers/engineers would be able to start writing tests by themselves was our biggest mistake. And like Misko pointed out in his article: even if they learned how to write a test doesn’t mean that they know how to write testable code.

Last act: The Results

Based on the fact that our developers’ population was heterogeneous in terms of experiences, autonomy, knowledge and expertise, we decided to developed training material and prepare hands-on training sessions. After a couple of sessions, we saw the adoption raising quite rapidly and more experienced developers were now able to coach others in their respective teams. The most common comment that we got from developers who took the courses is that it was exactly what was missing to get them started. We now have couple hundreds of trained developers who adopted the practice and actually write automated unit and system tests daily. Yes, some struggle trying to test “

hard to test code” and some are using TDD and BDD techniques to help them writing testable code and make sure tests get written. But in the end, the is a progression every day now.

Final thoughts

From all the articles and books about automated software testing describing the best techniques, processes and tools available, almost none I found is talking about the human factors and change management. It is in my opinion the first thing we need to work with daily to get a practice adopted. I felt like I needed to write about it so it benefits others trying to institute changes in their organizations. Working with human psychology is not an easy task when you want to change behaviours to get things to improve. The “no excuse, just do it way” is not a solution but this is often the first one we use. There will always be exceptions, some developers tend to self-educate themselves and try new things or improve the way they code. Some might say I’m exaggerating… In this particular case, even though the company was sitting on 100M+ lines of code, for various historic and cultural reasons, it did not considered itself a software company. Most of the developers’ population is composed of people who comes from the system engineering world. They aren’t developers who code systems, they are system engineers writing software. It’s a completely different paradigm and it is somehow difficult to get a system engineer to think like a software developer but still, the company needs both, so better equip them with the right tools/techniques/processes to do good testing. Remember that no matter how good the documentation, the processes or the tools are, you will always have to put more effort in the people than on anything else (the rest will follow). Testing is no magic, you have to master that skill and you won’t do it in one day. It takes time… like many things in life!