Agile is a dynamic and efficient approach to software development. However, with frequent changes comes the necessity for test automation. Unfortunately, many test frameworks falls in terms of effectiveness.
Test automation can be tedious...
Test scripts are often expensive to build and maintain. Consequently, coverage is frequently limited, leaving critical business scenarios unchecked.
This leaves the team operating under a cloud of risk. When bugs do slip through, they require immediate and time-consuming fixes, disrupting the flow of agile development.
Drawing from a wealth of lessons learned from automation projects, I can help you design and build a cost-effective test framework.
Our job is to innovate and make it work.
While modular, robust test code can keep maintenance costs under control, it alone doesn't guarantee success. To tip the cost-efficiency equation in favor of benefits, a test framework should have the following key characteristics:
Utility – The framework should aid team members in their everyday tasks, not just execute a static test suite.
Accessibility – It's important that domain experts can intuitively use and extend the framework, without support from developers.
Extensibility – Extending coverage to new application shouldn't require a major overhaul.
As benefits surpass costs, the test framework gains traction within your team. Transforming into a central hub, it sparks collaboration for building a comprehensive test suite.
With this in place, the cloud of uncertainty lifts, freeing your team to really get into the rhythm of agile development, confident in the quality of their work.
AXA transitioned from an old Cobol application to a modern Java-based system. The new platform is built on top of a third-party contract administration system, which has been customized and seamlessly integrated with in-house developed applications such as a CRM software and an offer system. Updates roll out bi-weekly.
From the start, it was clear that we needed to automate most of the testing; otherwise manual testing costs would have skyrocketed.
The test framework started as a development project. But, because the business processes were complex and still changing, we required support from business analysts. Yet, it was understood that support from business would wane if they have to invest heavily upfront without seeing swift returns.
To deliver tangible value, our first step was automating test data generation. The test framework was able to input complex contract data into the stable third-party application. This feature enabled business analysts to establish a clean initial state for their manual testing.
Business enthusiastically embraced this approach, recognizing it's speed and ability to prevent errors. They swiftly captured all the relevant contract constellations into the new test system.
Subsequently in partnership with the business unit, we integrated the modification and verification steps that execute after contract creation. Gradually, we fully automated all essential regression tests.
As of now, there is an expert group consisting of business analysts and developers dedicated to extending and maintaining the automated test suite. While maintenance remains a task, it's efficiently managed through established procedures.
My first encounter with test automation was during my master's thesis, as I worked on a unit-tested C application. It felt liberating to change code without the dread of unintended consequences.
Intrigued, I entered the field, but soon grew weary of repeatedly creating new frameworks. In response, I founded a company to develop a universal test framework.
However, I realized that businesses favored custom frameworks, given the unique nature of each project. Although a setback, it refined my ability to create targeted solutions.
Many years later, the delight I observe in my clients exploring test automation takes me back to that initial excitement during my thesis days.