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.
Credits to PXFuel
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 as analyzing recent bugs and support issues, or identifying the hot path, everybody will still have the sticky mental image of 100% coverage and people will continue to reject your idea, regardless of your counter-arguments. If your team truly needs tests for components implemented in the past, first make sure that tests are part of the development process or the definition of done. It’s easy to get started with writing tests for small bugs and support issues. After an initial win with this, you can suggest tests for the new features and then for past features. You want to introduce it gradually, one step at a time, instead of dropping it like a rock.
Technical debt is one of those weird words that management has a hard time understanding. You know that automated tests increase the development speed by catching bugs early in the process and by saving time with regression testing, but for whatever reason when you use the term technical debt it might be the case that your team starts rolling their eyes. And it might be for good reasons. Technical debt is very difficult to explain and measure. It’s better to stay away from this term if your team doesn’t like it.
Emotional involvement
Another pitfall that will set you up for failure is getting emotionally involved when it comes to automated testing. You might think it’s the holy grail of software development and you preach this in every meeting and encounter. Or it might be the case that whenever someone argues against it, you counter it immediately and don’t try to understand and actively listen. Don’t attach yourself to ideas and try to be objective. This being said, let’s see how to approach automation successfully.
Demonstrate leadership
Go the extra mile and practice what you preach. It’s the easiest way for showing results and it doesn’t require engaging others. You can just start doing it with whatever tools you have, be it a simple unit test framework or just plain code. From my experience, you can create any kind of test for your code, be it a unit test, functional test or performance test. It’s not as easy as it is with a specialized framework, but it can be done with creativity and a little extra effort. The benefits will show up in a short time when you will cover multiple use cases in less than a few minutes and surface issues for your team. As your development speed improves, you can work on more stuff and you will spark your colleagues’ interest. Once that happens, it will be easy to get others on-board with automation. If you want to tease a little, you can be mysterious about your process and say that you have super-powers. This will create even more interest and once you demonstrate how automation works, everybody will be engaged with it.
Untested code is broken code
Or everything not tested will break. This is the fundamental principle of computer programming that engineers use every day, even without knowing it. You don’t deliver untested code to your QA or your customer, you always test your code. So why not test your code with other code? It’s the easiest argument that you can bring in a debate about automated tests. Of course, there will be people saying that manual testing is faster, but that is a limited case. For example, when it comes to testing APIs and interactions with APIs, manually testing can be slower than writing code for testing. Also, manual testing can not be reused. You test your code now; you send it to QA and QA finds a bug. You put a fix and you need to test your feature again — manually. These are very simple examples that your team can understand and it can support you with the transition to automated testing.
Measurable situations
The last method that I want to present is about showing people the benefits of automated tests at the right time. It’s a little difficult to put in practice because you need to coach your squad. Whenever bugs appear or customers report issues, make sure that automated tests could’ve prevented the situation from happening and ask your team if they feel the same. Frame it simple: “I think some functional tests could’ve caught this before reaching the customer. What are your thought about this?” Or pay attention when others do regression testing, ask them how much it took them to finish the regression and if automation might have made their life easier “You spent 3 hours retesting the feature. Do you think automated tests might save us this effort in the future?”. It’s important to not transform these questions in long debates but to use the answers as a reminder about how things can be improved. Over time, the idea will catch roots and everybody will understand how it all goes.
In my opinion, these are the easy ways of convincing your team to automate their work. It works with junior engineers who are just getting started with unit tests, but also with senior developers who are too busy to write performance tests to simulate the load of many users. If you have your own story about how you “sold” automated testing, don’t keep it to yourself, share it with the world. It will surely help.
“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 as analyzing recent bugs and support issues, or identifying the hot path, everybody will still have the sticky mental image of 100% coverage and people will continue to reject your idea, regardless of your counter-arguments. If your team truly needs tests for components implemented in the past, first make sure that tests are part of the development process or the definition of done. It’s easy to get started with writing tests for small bugs and support issues. After an initial win with this, you can suggest tests for the new features and then for past features. You want to introduce it gradually, one step at a time, instead of dropping it like a rock.
Which is More Promising: Data Science or Software Engineering? | Data Driven Investor
About a month back, while I was sitting at a café and working on developing a website for a client, I found this woman…
www.datadriveninvestor.com
Explaining technical debt
Technical debt is one of those weird words that management has a hard time understanding. You know that automated tests increase the development speed by catching bugs early in the process and by saving time with regression testing, but for whatever reason when you use the term technical debt it might be the case that your team starts rolling their eyes. And it might be for good reasons. Technical debt is very difficult to explain and measure. It’s better to stay away from this term if your team doesn’t like it.
Emotional involvement
Another pitfall that will set you up for failure is getting emotionally involved when it comes to automated testing. You might think it’s the holy grail of software development and you preach this in every meeting and encounter. Or it might be the case that whenever someone argues against it, you counter it immediately and don’t try to understand and actively listen. Don’t attach yourself to ideas and try to be objective. This being said, let’s see how to approach automation successfully.
Demonstrate leadership
Go the extra mile and practice what you preach. It’s the easiest way for showing results and it doesn’t require engaging others. You can just start doing it with whatever tools you have, be it a simple unit test framework or just plain code. From my experience, you can create any kind of test for your code, be it a unit test, functional test or performance test. It’s not as easy as it is with a specialized framework, but it can be done with creativity and a little extra effort. The benefits will show up in a short time when you will cover multiple use cases in less than a few minutes and surface issues for your team. As your development speed improves, you can work on more stuff and you will spark your colleagues’ interest. Once that happens, it will be easy to get others on-board with automation. If you want to tease a little, you can be mysterious about your process and say that you have super-powers. This will create even more interest and once you demonstrate how automation works, everybody will be engaged with it.
Untested code is broken code
Or everything not tested will break. This is the fundamental principle of computer programming that engineers use every day, even without knowing it. You don’t deliver untested code to your QA or your customer, you always test your code. So why not test your code with other code? It’s the easiest argument that you can bring in a debate about automated tests. Of course, there will be people saying that manual testing is faster, but that is a limited case. For example, when it comes to testing APIs and interactions with APIs, manually testing can be slower than writing code for testing. Also, manual testing can not be reused. You test your code now; you send it to QA and QA finds a bug. You put a fix and you need to test your feature again — manually. These are very simple examples that your team can understand and it can support you with the transition to automated testing.
Measurable situations
The last method that I want to present is about showing people the benefits of automated tests at the right time. It’s a little difficult to put in practice because you need to coach your squad. Whenever bugs appear or customers report issues, make sure that automated tests could’ve prevented the situation from happening and ask your team if they feel the same. Frame it simple: “I think some functional tests could’ve caught this before reaching the customer. What are your thought about this?” Or pay attention when others do regression testing, ask them how much it took them to finish the regression and if automation might have made their life easier “You spent 3 hours retesting the feature. Do you think automated tests might save us this effort in the future?”. It’s important to not transform these questions in long debates but to use the answers as a reminder about how things can be improved. Over time, the idea will catch roots and everybody will understand how it all goes.
In my opinion, these are the easy ways of convincing your team to automate their work. It works with junior engineers who are just getting started with unit tests, but also with senior developers who are too busy to write performance tests to simulate the load of many users. If you have your own story about how you “sold” automated testing, don’t keep it to yourself, share it with the world. It will surely help.
Archives
Categories
Archives
Recent Post
Using decision trees to map out Architectural decisions
February 23, 2024Moving Beyond Code: From Software Engineer to Architect
June 23, 2023The three perspectives of a software engineering manager
June 4, 2021Categories
Meta
Calendar