Automating tests is one of the first practices in agile, and one of the biggest leverage that we can have in the development process, as it supports almost all of others.
Why are automated tests not a reality, even among those companies who define themselves as agile?
The difficulties are common:
- Unfriendly frameworks: Existing test frameworks usually address only specific languages, architectures, and type of tests.
- Non-adherent culture: Implement automated tests is not just add a phase on development cycle. To be successful, we need a mindset change. The system must be driven to test since the conceptual start. And this culture must be accepted and engaged from everyone in the process.
- Lack of technical support and knowledge: To implement good test scripts, we need a lot of complimentary tools and architectural approaches that is not so easy to truly learn.
- Too much legacy code: This is one of most common excuse: “We cannot test our system because there is a big legacy involved”.
- Too much time to run: From some teams that started automating tests, this is another excuse: “Automated tests are good but, as we are growing up, this practice is not sustainable because it spend much time to run all the tests and get feedback”.
This session shows a way to get over these issues, addressing every issue with real cases of automation test. Our experience comes from almost 20 years working on a legacy, critical, and giant system.
What did work? What didn’t? Where did we have to invest? What about scalability? Is there any shortcut?
It is a long history, that will benefit technical developers, managers and agile enthusiasts, since it shows how attitudes make the difference, when talking about overcoming obstacles and evolving.
In the end, we will show the little answer: Yes, we still have our first test – written in 1998 – running after every single commit!
