Why should I push my team to develop automated tests?
Imagine you are the manager of development team. Your team is writing code since several years now, they are experts, coming from the best Engineering school. You have decided to follow 2 rules:
- Develop a very good code, deliver fast to production and .. Your results are great! Your customers are happy, the team is happy.
- You have also implemented practices from software craftsmanship: You are doing pair programming and code review. Everything is under control!
Your team don’t need to develop automated tests, it will be very expensive, this will slow down the velocity of the team, you will need to create the test infrastructure, you will have to invest in hardware infrastructure. I can imagine! Once you will have created test, you will have to maintain them… Forever!! Your team will not spend time coding thing that is not in direct link with the customer experience, and new features. You have to make money! Your business is increasing, you want to run it faster.
And you have your Quality Assurance (QA) team, they are there to find bugs. This is their role. And they find sometime plenty of them. You are improving, you engaged more testers. Developers asked for them, and you had quality issues. With your fully new QA team, it is perfect, you reduced the number of bugs in production, and you came back to our initial velocity.
Go back to the Agile Manifesto for a minute:
We are uncovering better ways of developing software by doing it and helping others do it.
Helping others: This is mainly why this community of thoughts leaders meet themselves and created the agile Manifesto, to propose something new and useful for them first and then for the others. Helping others…. The purpose was to share knowledge, deliver project differently using a successful approach.
When you or your teams are writing code… you could write a super code, clean, reviewed and mastered. For sure tests are not mandatory if you have hired the super Guru of the code, if you have a stable team forever, if the guys are super fans of the craftsmanship principles.
What will happen when the Guru left the team? What will happen when a new comer will join? What will happen when another group of developers will have to jump into your code? Will you or your team still be there to explain it’s philosophy, the purpose of certain methods? The data Flows? The algorithm and the tweaks you have performed? Usually the answer is: “Yes, I know this is why we are writing documentation!”
Somebody else will use your code, somebody else will maintain and enhance it, somebody else will have to take a chance on it! In that case, this is a bet, either the new team has the same sense of the code responsibilities, the same philosophy, the same experience, and lot of courage and energy… Or not! Your super code will go on junior hands, on non-craftsman hands, on good developer hands but not on Guru hands. They will say: “Wooh, this code is super clean. The architecture is modular, all the guidance are there, this is perfect.”
Then they will start to develop new features, and still without tests, and they are in the rush like your first team was, but they have less knowledge, less experience, they are less rigorous, you are expecting lower quality from them too, because you are busy, lot of pressure, and you have to deliver faster, under customer constraints, competitor pressure…
Looking at the 4th value of the Agile Manifesto, Working Software over Comprehensive documentation. This is what the Manifesto proposes. It seems that you have right.
The 4 values of the Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Working software, this is what you are delivering. I spent time in several companies, but my best experiences in term of product development were, where I could trust my developers, when I knew that whatever the new features we will ask them, they will be able to deliver: new technical component, new micro services, so complex architecture to handle but so powerful, the re-architecture of set of components, the introduction of new technologies, the libraries upgrade… They were very efficient, and we had very few problems in production.
And do you know why? They used the software craftsmanship, collective ownership of the code, test mastering. Yes, they were using Test Driven Development and they automatized tests. They had their code under control, and they knew that without those best practices, they would not be able to fix it fast enough in case of emergency.
I never obtained features so quickly than in this kind of team using: test-driven development (TDD), unit tests, integration tests, behavior driven tests, functional tests automation…
- They were able to progress to test themselves and improve their craftsmanship expertise, thanks to those existing tests.
- They were able to refactor code and keep it simple (Agile principle)! Thanks to existing tests.
- They were able to reduce the amount of functional documentation, thanks to the Behavior Driven Development (BDD). BDD tests became the functional documentation of the software. Everybody had access to the test reports and was able to read them. Everybody was able to read the documentation and understand the behavior of a business rule.
One of the Agile Manifesto is: “Working software is the primary measure of progress.” It is very difficult to deliver quickly, accepting the change and deliver working software without risk.
Your Testing Strategy?
Doing manual tests is costly, maintain automated tests is costly too. But what are the main difference between both? With automated tests running at every commit, the developer knows that there is an issue in the code he has pushed. Every line of code is fresh in his mind. It is really easy to fix it immediately!
Having a quality engineer testing the development few days or weeks later, means that the developer will have to rebuild the story in his mind and find the bug, it requests additional time, and it introduces a delay in the delivery. With the experience, you can put in place your testing strategy, automatising the appropriate set and type of tests, limiting the number of tests. Making them just in time, and at purpose.
So please, improve your skills in well craft software and test automation, implement a software factory, add all the necessary test bench and launch them at every commit. You will see the performance of the team increasing. And in top of that if you define clearly your testing strategy, it will be even better.
Then you will be free to be concentrated on adding value!
Need More Article: Anti-Patterns of Enterprise Agile Transformation