NOTE: This post is a part of the “Brutal facts of testing” blog series, in which our experts will try to distill their knowledge and experience into a collection of articles on some painfully true facts about software testing.
Software as a crucial business component: the need for speed
Over the last few years, the market has put great effort into delivering solutions as fast as possible. The software has transitioned from having a supportive role in business to becoming a crucial part of the business itself. For instance, e-banking platforms have enabled clients to complete the job on their own. For many companies, this meant building new layers of software applications on top of the previous system of record, like CRMs or ERPs.
So, what’s the motivation behind this? Firstly, they are trying to differentiate themselves from the competition with faster and more flexible solutions. Secondly, they are disrupting the market with new innovative solutions. To go back to the banking example, many financial institutions are nowadays creating new brands (companies, applications, services, etc.) to target new segments of the market or even to create new niche markets.
The problem: Excessive focus on the system of innovation (and disregard for other systems)
On the one hand, utilizing the systems of records to create a new service can be challenging to facilitate a quality release in a short period of time. For example, systems of record can be heavily impacted by regulatory mandates or using legacy technologies with old software architecture patterns.
Then, companies have rolled out the Agile Delivery Frameworks used in the systems of innovation, expecting to have the same outcome. But is this really possible? Are all the organizations able to become the next Spotify? In our experience, it’s not so easy. There are some serious challenges that need to be overcome:
- The systems coexist, but some of our clients do not even notice that.
- The same Agile Delivery framework does not suit all the systems, even in the same company or organization.
Source: Envato
The solution: Orchestrating testing between all systems
On the other hand, a new app can be done overnight within system innovation. Thus, time constraints, as well as the level of dependencies, are crucial attributes for a faster release among the three system classifications.
So, what do we do? Should we slow down the innovation to onboard the systems of differentiation and record onto our model? Definitely not!
Sixsentix’s approach is to use QA and specially the test architecture discipline as the orchestrator between systems. The main purpose of test architecture is to prepare the systems of differentiation and record to keep up with the pace of the system of innovation or even increase it!
Our client portfolio consists of mid-sized and large companies from diverse business domains with one thing in common - most of them have developed new systems of differentiation and innovation very quickly. Here are some of the crucial lessons we’ve learned so far:
- Risk-based testing brings two main benefits when testing applications within the system of record. On one side, it plays the role of guardian of quality for the system of record. On the other side, it helps the system of innovation to get faster evidence and, consequently, make early decisions whether to release to production or not.
- Each system needs a different type of testing strategy, and each test strategy must consider the coexistence with the other systems. One testing strategy (i.e., approach, infrastructure, tooling) does not fit all the systems.
Source: Sixsentix’s adaptation of Gartner’s Pace-Layered Application Strategy
The Sixsentix way: Using test architecture service to bridge the gaps
To further illustrate these ideas, let us consider the situation at one of our client companies, where we identified a lot of dependencies between the system of innovation (i.e., mobile apps) and the system of record (i.e., core business CRM).
Before implementing our test architecture service, we spotted the following symptoms:
- Overload of delivery backlogs
- Dependencies between agile teams consumed almost all the development capacity
- Delivery objectives (time to market) could not be accomplished
- Detection of side-effects in production environment
- Huge effort on consolidating test evidence for audit-relevant systems
But after implementing the service, we could observe a number of improvements:
- Quality Assurance supports faster releases with risk-based testing
- Test automation degree was massively improved, allowing Continuous Testing
- Audit-relevant test evidence is delivered efficiently thanks to methodological test coverage
- Throughout business-facing testing, the dependencies are better understood and therefore the backlogs of all three systems are better aligned and prioritized
- On an organizational level, shift-left has been enabled
Source: Envato
This perspective on frequent SDLC challenges is the result of Sixsentix experience in consulting and operationalizing QA solutions at large scale organizations. The article is also created as a part of our company’s promotional activities at the EuroSTAR conference. To find out more about our test architecture service, visit this link or stop by our booth at the EuroSTAR conference in Antwerp from 13. to 16. June 2023.