Composable Test Automation in a Composable Commerce World
A quick Google search for ‘Composable Commerce’ will also throw up some complementary results such as ‘Composable Enterprise’, ‘Composable Business Model’, ‘Composable Architecture’ and ‘Composable Technology’.
‘Composable Enterprise’ was a term brought to the forefront by Gartner describing a modular approach for software development in the delivery of digital services to customers.
‘Composable Commerce’ takes this concept and applies it specifically to the Omnichannel world - the delivery of a seamless in-store and online browsing, purchasing, customer support and order management experience for an organisation and its customers.
In this article, we will consider how a company’s test strategy needs to adapt and flex to support the successful delivery and maintenance of a ‘Composable Architecture’.
So what exactly is Composable Commerce?
Composable commerce is a very modern flavor of Omnichannel commerce architecture that focuses on the use of flexible, modular components, allowing businesses to build and customize their digital commerce solutions dynamically.
Unlike the older monolithic commerce platforms of 10 years ago, composable commerce splits the e-commerce stack into individual, interchangeable building blocks or services. These services provide various commerce-related features such as product catalog management, checkout processes and payment gateways for example.
A core attribute of composable commerce is its enablement of businesses to select, combine, and deploy these modular components based on their specific needs. This approach offers never-before-seen flexibility, scalability, and agility in adapting to changing market demands, customer expectations and service providers.
Organizations can integrate best-of-breed solutions for different aspects of their commerce ecosystem, fostering innovation and rapid development.
Composable commerce uses APIs (Application Programming Interfaces) to drive seamless communication between these components. This empowers businesses to create a tailored and differentiated e-commerce experience, delivering a more efficient and customer-centric digital commerce strategy with huge competitive advantage.
Why is Composable Architecture popular and what are the main benefits?
When we start to think about our supporting test strategy for composable platform delivery, we should always consider why Businesses are opting for it in the first place. What benefits do companies hope to realise through its implementation? Let’s look at the most commonly cited factors.
Flexibility and Customization - Businesses can select and integrate individual components, tailoring the e-commerce solution to specific needs.
Scalability - Components will scale independently, accommodating demand fluctuation without impacting the entire system.
Agility and Innovation - Composable architecture accelerates development cycles, allowing businesses to quickly adopt new technologies and respond to market shifts.
Cost-Efficiency - Organizations pay only for the specific components they use, reducing unnecessary monolithic platform overheads.
Reduced Vendor Lock-In - Composable commerce minimizes the risk of vendor lock-in, allowing businesses to switch out individual components without rearchitecting the entire solution.
Distributed ownership of business responsibilities - Enables companies to adopt a cross-functional production-line approach to the development of their solution. Low code tooling platforms can enable business users to ‘develop’ and make changes and updates on their own.
How does an agile test approach support Composable Commerce delivery?
An agile testing approach will work seamlessly for composable commerce delivery by sharing the principles of flexibility, iterative development and continuous integration. Here's how agile testing fits into a composable commerce program:
Iterative Development - Agile testing is inherently iterative, with frequent code releases to test environments and continuous feedback loops to the development team. Composable commerce's modular structure allows the testing of individual components in parallel with development, ensuring each iteration is fit for purpose.
Cross-Functional Teams - Agile encourages cross-functional teams that include developers, testers, business analysts and product owners. In composable commerce, these teams can collaborate on testing specific components and the integrations between them as part of a more holistic testing approach.
Continuous Integration/Continuous Deployment (CI/CD) - Agile testing aligns well with CI/CD practices, ensuring that automated tests are integrated into the development pipeline and frequently executed. Composable commerce benefits from this approach by allowing for the continuous testing of individual components as well as the integrated solution across multiple test environments.
Adaptability to Change - Both agile testing and composable commerce emphasize adaptability to change. As requirements evolve or new features are added, agile testing allows for the quick adjustment of test cases, ensuring that the testing process keeps pace with the dynamic nature of composable commerce development.
Test-Driven Development (TDD) and Behavior-Driven Development (BDD) - Organisations employing agile testing often use TDD and BDD practices, where tests are written before or in tandem with development. In composable commerce, this approach helps define the expected behavior of individual components, building a clear understanding of requirements and driving the development process.
Regression Testing - Automated regression testing is crucial in composable commerce to ensure that ongoing changes to individual components or the integrations between them, do not introduce new bugs.
Is Composable Commerce testing hard and what are some of the challenges?
Testing of composable commerce solutions presents several unique challenges due to the modular and interconnected nature of the architecture. These can include:
Complexity of Interactions - Composable commerce relies on many modular components that interact with each other via REST APIs. Testing the complex interactions between these modules, ensuring seamless communication and managing data state can be taxing.
Dependency Management and Versioning Challenges - Components in a composable commerce environment are likely to have dependencies on specific versions of other components or third-party services. Managing and coordinating these dependencies during testing to ensure compatibility along with different versions of components and ensuring backward compatibility is not easy. Changes in one component may impact others, requiring a robust versioning strategy and thorough testing.
Dynamic Configurations - Composable commerce systems often involve dynamic configurations where components can be swapped in and out on demand. Testing configurations and ensuring that the system behaves correctly with different combinations of components require a well planned testing approach.
End-to-End Testing Complexity - While modularity brings flexibility, end-to-end testing across various components requires meticulous planning. Coordinating and executing end-to-end tests to cover the entire customer journey from product selection to checkout must be a top priority.
Data Consistency and Integrity - Ensuring data consistency and integrity across different components also takes considerable cross team management. Each component may handle data differently, and changes in one component should not adversely affect data in another. Testing data flows and consistency is crucial.
Scalability Testing - Composable commerce solutions need to handle varying levels of traffic and demand. Testing scalability and performance of isolated components and the integrated solution as a whole, under different conditions, including peak loads, is crucial to ensure the entire system can scale appropriately.
Security Concerns - The distributed nature of composable commerce introduces potential security vulnerabilities and attack surfaces at different integration points. Comprehensive security testing is strongly recommended to identify and address potential vulnerabilities, protecting sensitive customer data and financial data.
Skill Set Requirements - Testing composable commerce may require testers with a diverse skill set, including knowledge of various testing tools, API testing and a deep understanding of the specific components and their interactions. You may need to augment your current testing team with composable architecture testing leads for a smooth journey.
With so many 3rd party microservices in use, what does this do to my risk and test effort?
The use of third-party microservices in a composable commerce solution introduces both opportunities and challenges, influencing the testing effort in various ways.
The impact on testing effort can be influenced by factors such as the complexity of integrations, the reliability of third-party services and the criticality of the microservices to your application.
May increase your testing effort:
Integration Complexity - Integrating multiple third-party microservices can increase testing effort, especially if these services have complex interfaces or dependencies. Comprehensive integration testing is necessary to ensure seamless communication and data flow.
Dependency Management and Compatibility Testing - Coordinating and managing dependencies and versions between your application and third-party microservices may require additional testing efforts. Changes or updates to third-party services may impact your application necessitating thorough regression testing.
Security Concerns - The use of third-party microservices introduces potential security risks. Comprehensive security testing is crucial to identify and mitigate vulnerabilities in the interactions between your application and external services. You may also require an external team to undertake a penetration testing cycle on your behalf.
Service Level Agreements (SLAs) - If your application relies on specific performance or availability guarantees from third-party microservices, testing efforts may increase to validate that these SLAs are met and to plan for scenarios when services may be unavailable.
May reduce your testing effort:
Outsourced Maintenance - When relying on third-party microservices, you may benefit from outsourced maintenance and updates. This can potentially reduce testing efforts related to routine maintenance tasks, as the responsibility for maintaining third-party services lies with the service provider.
Specialized Functionality - Leveraging third-party microservices for specialized functionalities (e.g., payment processing, geolocation) can reduce testing effort for these specific features. Third-party services that are well-established and widely used often come with a track record of reliability.
Service Provider Testing - Established third-party microservices providers typically conduct their own testing to ensure the reliability and functionality of their services. Relying on reputable providers may reduce the testing effort needed for certain aspects of your application.
Faster Development Cycles - The use of third-party microservices can expedite development cycles by allowing you to leverage pre-built, well-tested components. This can reduce the time and effort required for certain aspects of development and testing.
How does your test automation strategy need to adapt to support Composable Commerce Delivery?
Automated testing done well, plays a crucial role in supporting composable commerce by providing repeatable, reliable and fast testing of the modular components and the integrated solution as a whole.
If you run a search for ‘Composable Commerce Test Automation’ right now, you’ll find only a handful of appropriate results. That’s either because the composable architecture world is still relatively new or because testing teams haven’t yet fully appreciated how they may need to update their former monolith automation approach and bring it into the 2020s.
Most of the ‘Composable Commerce Test Automation’ content that does currently exist, by and large misses the point in our opinion. Articles refer to writing automation code with ‘modular building blocks encompassing groups of test steps’ without elaborating much further. We read how composable automation ‘enables testers to create a library of reusable test assets’. We’re told that ‘individual steps can be designed as reusable components that can be used across multiple test cases’. In truth, that’s just good practice test automation coding clearly referencing a Selenium flavoured ‘Page Object Model’. It doesn’t really give us a true insight as to what ‘composable test automation’ really is or should be.
In another example we read how ‘the logging-in part of a web app test is standalone in this case but is a common function that could be copied over to dozens, even hundreds of other tests.’ Again, just good practice sensible D-R-Y (don’t-repeat-yourself) automation coding. It’s not new and it certainly hasn’t just arrived with Gartner’s ‘Composable Enterprise’ concept in the late 2010s/early 2020s.
A final example proposes a ‘composable automation’ example where the test runs, ‘each time just changing the contents of the search box entry and the name of the item clicked on.’ This is simply data driving a test or parameterising it for re-use. We’ve been doing that for 20 years.
So where does that leave us?
Well in our humble opinion..as providers of a testing ‘service’ to our customers (product owners), we should be looking to help the business realise their ‘Composable Commerce’ aims of Flexibility, Scalability, Agility, Innovation and Cost Efficiency with an agile automated testing strategy that facilitates them. What does this mean?
We suggest that ‘Composable Testing’ and ‘Composable Test Automation’ are not new or unique approaches to testing but more so a chance to review and overhaul your agile testing strategy to ensure that it is ‘Composable Enterprise Ready’ or ‘Composable Commerce Ready’.
And what does it take to be ‘Composable Commerce Ready’? Well, if you can implement the following, we believe you are ready as a testing practice to support the delivery of a complex Composable Commerce Omnichannel solution.
Embracing Agile and Shifting Testing Left - A waterfall testing strategy is not going to cut it in the Composable commerce world. Things will move rapidly and requirements may change at late notice. Detailed documentation may be lacking. Your testing practice needs a seat at the table for all feature and functionality discussion, requirements elicitation and design. You will wish to automate a significant chunk of all testing, upwards of 60-70% with manual testing reserved for exploratory user led sessions, not slow tedious cycles of regression testing.
The majority of your testing team will need to be able to contribute to the automation effort and in agile sprints, you will want a code first mindset coupled with your manual exploratory testing. This serves two purposes. The quick exploratory testing and raising of bugs provides the fastest feedback loop to developers. The code-first automation approach from Day 1 provides an ever growing suite of modular and end-to-end API and UI automated tests that will continue to run multiple times a day.
Adopt a test automation framework that facilitates API, desktop and mobile browser testing - Many members of the MACH alliance are leading players in the delivery of Composable Enterprise.
MACH stands for Microservices based, API-first, Cloud-native SaaS and Headless. This should tell you a great deal about the amount of REST service testing you will need to undertake for a Composable delivery. You will require the tooling to run manual and automated API, desktop/mobile browser and native apps.
Now ideally, you’ll select a single framework that enables all of those rather than employ a disparate collection of tools. With a composable commerce delivery, it’s highly likely there’ll be no UI at the start of the project but there will be multiple REST microservices deployed to enable differing commerce-related functionality.
Your functional testing and automated regression test pack creation will start with these. Further down the line, the UI and maybe an app will come into play and then you can start to layer in your UI tests. This is all far easier to manage with a single centralised tooling selection.
Multiple Touch Points and True end to end testing - It is a common misconception that a composable solution or modular system make-up means that we only need to test at an isolated modular level. Of course, nothing is further from the truth.
Multiplier providers with multiple integrated microservices mean that true end to end testing is more important now than ever. In a composable commerce world, you will likely have a mix of external user storefronts, in store applications and also back office applications for things like inventory management, order management and the wholesale purchasing process amongst many others.
You’ll realise that you also have different customers to satisfy as a result of this application mix. So your tooling and your strategy must support this and stay in step with the different teams within the delivery program to understand clearly when these integrations between sub-systems and UI enablement takes place. Consider the below example:
Customer hits the storefront website, browses and orders a product
Order is managed through to point of dispatch
Customer phones contact centre to check their delivery status
Customer finds fault with product and returns it to store for refund/replacement
The above flow is very common and demonstrates a multi touchpoint journey where data integrity is paramount and the ability to test different types of applications via the UI and services layer, as part of a single flow, is critical to prove the full end-to-end journey.
CI/CD Pipeline - Test Execution On Demand and On Build, Multiple environments - As with any agile way of working, with composable commerce, expect to receive multiple builds of code from different cross-functional teams, multiple times per week if not per day, to multiple test environments. You will need to ensure that your CI/CD pipeline is able to pull your latest code from the project test automation repository and execute your tests against a given application and automation configuration.
Subsets of tests, tagged for flexible inclusion/exclusion as required - As the delivery progresses, the team will be amassing a vast collection of API and UI automated tests. On occasion, you may run all of them against the most production-like environment, maybe UAT for example, but more often than not, you will need to be able to target subsets of tests for different reasons. Some examples are below:
There are changes to the REST API layer only
Only certain API or UI changes deployed to specific environments
You determine a set of ‘critical’ tests that run in 30% of the time
You wish to target tests buy business or functional vertical
You only want to run UI tests for non-functional cross browser or device reasons
You need a set of tests that can complete within 5 minutes or less
You wish to run a limited set of tests for narrow functional breadth but data parameterisation for deep coverage within that function.
Real-time reporting - Wide audience - With so much testing being undertaken, across environments, by business/application/customer vertical and with so much potential change, your reporting strategy needs to be first class and preferably real-time. Test coverage and up to the minute results sharing for the testing of components, integrated modules and full end-to-end customer journeys is critically important.
Regardless of application type, delivery model or technical test approach, the number one most important responsibility of any testing practice is to provide the quickest and most accurate view of current requirements based quality to its stakeholders.
Conclusion
So, yes, Composable Enterprise as an industry concept is still relatively new but certainly warrants a deeper dive into your current levels of agile test maturity. Does it mean you test differently? Not necessarily - maybe you’ll be more API focused than you have been in the past. Does it require you to think carefully about your tooling? Absolutely. This is a big success factor. Do you need outstanding test reporting? Without a doubt. So even if you are not involved in a composable enterprise delivery right now, setting yourself up for success in the future would be a worthwhile exercise in everybody’s interest.
