Abstract: 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 is this not a reality, even among those companies who define themselves as agile?
The difficulties are very similar:
- 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”.
- And so on...
This session will show 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 the first test, written in 1998, and running after every single commit!
Lessons Learned from Your Experience: - The problem of scaling automated tests is quite common in large systems. This report addresses this issue with a great success case. Moreover, it is a great story to see how automated testing are fundamental, demystifying the fallacy of complexity and legacy. Moreover, it is a good example of how automated testing is fundamental in order to demystify the fallacy of complexity and legacy.
- During the presentation, we will answer some questions, such as:
- How to deal with complex scenarios where the solution depends upon the evolution of a virtual clock?
- How to improve performance of tests that depends on data population?
- How to deal with integrated tests and external systems?
- How much of each kind of test should be implement, considering unit, functional, integrated, and UI?
- Where could you have the biggest increase of quality?
- How to obtain a better execution efficiency, considering processing, memory, threads, and order.
- What about when running on a single machine is not an option?
- How to scale more and more?
- What happens if you decide to change the development language along the way?
- How to deal with intermittent test results?
- How to handle testing concurrency?
- How to automate tests with production data, combining performance and production settings?
Attachments:
