“Selling” automated testing to software engineers
You’ve just joined a new team or company. Or maybe your team starts working on a fresh project. Or maybe there is a strong business need to deliver a piece of software quickly. Whatever the situation, for some hard-to-understand reason, your squad is not doing automated tests. It might be the case of simple unit tests or it might be the case for advanced automated performance tests. You’re an experienced developer and you know the value that automated tests bring, both in the short and long term. You feel frustrated that your team doesn’t show interest in your vision. You try to persuade them, point them to articles, expert opinions, corporate blogs and many more, but nothing seems to work. In this post, I want to share several approaches that can help you convince your team. First, let’s start with the things that you should NOT do.
Arguing automated testing for past implementations
This is the easiest way to demotivate others when it comes to automated tests. When you mention creating unit tests for the past code everybody gets the picture of hard-to-achieve metrics (e.g.: 100% coverage), hundreds of classes and long running times for pipelines. It’s an instant demotivator and your team will rush to find reasons for not to going with it. If you then elaborate on smart ways for approaching this, such…
