This case takes place at a small organization that develops software for higher education institutions (universities and colleges). They are currently moving from working project-based and waterfall to adopting Agile, with the ultimate goal of becoming capable of practicing Continuous Delivery.
The team and the product
There are three development teams (or rather ‘feature teams’) that all work on different parts of the main product that this organization offers. Each team consists of front end developers, back end developers as well as one or more dedicated testers and a scrum master.
The testing process
Because of the size and the complexity of the releases (the teams used to release once every three months), testing has until now been a long-winded process. Another complicating factor is the fact that, apart from the core product, all kinds of customizations are being developed and delivered to cater to individual customer’s needs. This means that various versions of the product are in use (and need to be supported) at any given moment in time.
In this case, virtually no test automation has been implemented, yet. The teams are struggling to get started, especially because nobody in the organization has experience with implementing a test automation strategy from the ground up.
Some experiments are carried out with low code test automation tools, because these provide the most gentle learning curve for the teams. These tools serve them well, but the teams are still in doubt whether or not it is all worth it. Building and maintaining the test automation takes a lot of their time and results are coming slow. The fact that the teams keep being under pressure from management to make deadlines (they haven’t gotten rid of those yet, unfortunately) and the many customizations they need to test do not help, either.
Still, they do see that without a solid test automation strategy, they will likely not be able to reach their goal of Continuous Delivery.