Skip to content
Testing Complex Multi-Systems is a Major Challenge: The QSR Case
Api Testing·

Testing Complex Multi-Systems is a Major Challenge: The QSR Case

Shachar Landshut
by Shachar Landshut
Testing Complex Multi-Systems is a Major Challenge: The QSR Case

Testing complex multi-systems in quick-service restaurants (QSRs) presents a formidable challenge. Recent incidents at major brands like Greggs, and McDonald's, underscore the critical importance of robust testing practices in ensuring seamless operations and customer satisfaction. By addressing challenges such as cross-device flows, verification mechanisms, live tracking features, and billing/payment integrations, QSRs can enhance the reliability and resilience of their digital systems, ultimately delivering a superior customer experience.

Understanding the complexity of muti-systems Architecture of QSR Apps

The landscape of quick-service restaurant (QSR) apps encompasses a diverse array of types and use cases. At the forefront, we encounter the customer app—a versatile platform enabling users to order food, track deliveries, and manage personal preferences and payments seamlessly. Typically, these apps seamlessly integrate web and mobile functionalities, offering users a cohesive experience across devices. Moreover, many QSR companies extend their reach through dedicated web interfaces, augmenting accessibility for a broader audience.

When placing an order through a QSR app, the journey traverses multiple layers of specialized applications. Initially, the order submission funnels through the restaurant app, where it is received and processed. This pivotal step often involves distinct applications tailored for different purposes, such as point-of-sale (POS) systems or desktop applications installed on dedicated devices like tablets. These backend systems play a crucial role in orchestrating order acceptance, rejection, and comprehensive order tracking.

Upon preparation, the baton transitions to the courier app, where the logistics of delivery management unfold. Here, a unique "partner" model akin to platforms like Uber may come into play, where independent individuals collaborate with the QSR entity to fulfill delivery obligations. These couriers, poised on standby, receive orders, navigate to designated stores, and embark on delivery journeys, all while their statuses and locations are meticulously tracked. This intricate synchronization facilitates real-time updates to the customer app, ensuring transparency and facilitating seamless communication throughout the delivery process.

In essence, the complexity of QSR apps transcends the boundaries of singular applications. Rather, it manifests as an interconnected ecosystem of applications, spanning diverse devices and interfaces. Yet, amidst this complexity, a unifying thread emerges: the utilization of APIs as the linchpin of communication. Through these APIs, QSR apps establish a conduit to a centralized backend, enabling seamless data exchange and workflow orchestration. From the initial order placement to its final delivery, every interaction is mediated through this robust API infrastructure, underscoring its pivotal role in the QSR digital ecosystem.

The Challenges in Testing QSR Systems:

Navigating Cross-Platform Scenarios in QSR Testing

Imagine running a test scenario that initiates on the web, where a customer places an order, seamlessly transitions through a point-of-sale (POS) application, and culminates in the courier app—a diverse journey spanning distinct platforms and technologies. Undertaking end-to-end UI testing for such multi-system interactions presents formidable challenges, given the disparate technologies involved. However, leveraging the Testing Pyramid paradigm and harnessing the omnipresent APIs offer a robust solution for navigating these cross-device flows.

Given the interconnected nature of QSR applications facilitated by APIs, asynchronous API testing emerges as the optimal strategy for validating cross-platform scenarios. By interfacing with the basic customer API to initiate orders and trace their progression through the restaurant API, testers can simulate end-to-end interactions without delving into backend intricacies. While dedicated UI testing remains imperative for each application, decoupling UI testing from backend dependencies ensures comprehensive coverage of the UI aspects across all dedicated apps. Ultimately, adopting an API-driven approach not only streamlines testing processes but also yields a substantial return on investment (ROI) by constructing end-to-end scenarios grounded in API interactions.

Overcoming Email & SMS Verification Challenges in QSR Testing

Incorporating email and SMS verification into customer apps is a common practice among QSR establishments. Some of these apps solely rely on mobile platforms, omitting website counterparts and traditional password logins. Consequently, navigating test automation amidst such verification methods poses significant challenges. However, a viable solution to this hurdle lies in the utilization of ephemeral inboxes.

An ephemeral inbox serves as a dedicated testing platform equipped with an API for seamless access to received emails. By registering users with ephemeral inbox emails or utilizing text messaging services like Twilio, testers can intercept verification codes and extract them using a dedicated API. Subsequently, these codes are employed to facilitate login procedures in subsequent steps of the testing process. While this approach may initially present complexities, leveraging appropriate tools streamlines the process, rendering it a manageable task within the QSR testing framework.

Addressing Live Tracking Challenges in QSR Testing

Live tracking features have become a staple in delivery services, integrated into many QSR apps. Testing such functionalities demands proficiency in geolocation calculations due to the reliance on coordinates provided by APIs. Testers must be well-versed in latitude-longitude coordinates and may need to conduct distance calculations during the testing process.

Moreover, obtaining real-time order status data involves two primary methods: traditional HTTP polling and modern WebSocket communication. While HTTP polling entails repetitive requests for order status updates, WebSocket technology enables direct communication between servers and apps, eliminating the need for continuous polling. In the context of testing QSR systems, familiarity with WebSocket testing is paramount for comprehensive testing coverage.

QSR2

Traversing Billing and Payment Challenges in QSR Testing

One common obstacle encountered in QSR testing revolves around billing and payments. Completing any scenario necessitates a functional payment mechanism — whether it's the customer's payment or the restaurant's acceptance of it.

Understanding the intricacies of payment vendors like Stripe or other service providers is crucial. These vendors typically offer dedicated test environments and cards for testing purposes. Ensuring connectivity to the appropriate test API, such as Stripe's, is imperative to process payments correctly.

Furthermore, testing scenarios extend beyond the confines of the testing environment, often encompassing acceptance testing in production. This underscores the need for caution and sensitivity when conducting tests involving billing and payments. While dedicated company cards may facilitate testing in such scenarios, safeguarding their security remains paramount.

QSR

Some recent incidents faced by major brands

The complexity of testing multi-systems in quick-service restaurants (QSRs) was starkly evident in recent disruptions faced by major brands:

  • Greggs Payment Problem:

    The bakery chain "Greggs" faced a significant challenge when a payment problem caused some of its shops to close temporarily. This issue followed card payment outages at Sainsbury's and Tesco, as well as similar disruptions at McDonald's. Greggs resolved the technical issue affecting its tills, but the incident underscored the vulnerability of QSR systems to disruptions.

  • McDonald's Global Outage:

    McDonald's experienced a global technology system outage due to a configuration change by a third-party provider. This led to stores in multiple countries, including the UK, Australia, and Japan, being unable to take orders.

QSR5

  • UK supermarket Sainsbury's

    encountered significant challenges as it grappled with technical issues, resulting in the inability to fulfill the "vast majority" of online deliveries. This disruption stemmed from an error with an overnight software update, exacerbating the situation as the same system handles communications, rendering the company unable to inform customers about their order statuses. Furthermore, the outage extended to physical stores, causing disruptions in contactless payments. While customers can still use cash or chip and pin, those relying on mobile payments are unable to complete transactions, highlighting the extent of the impact on both online and in-store operations.

Integrating API Testing for Efficient End-to-End Flow Testing for QSR Applications

Integrating API testing offers a more efficient approach for creating end-to-end flow testing that spans across multiple systems. The complexity of QSR apps, involving various applications across web, mobile, desktop, and headless platforms, means that relying solely on UI testing can lead to increased challenges. Each platform requires its own UI testing framework, which can be time-consuming and difficult to synchronize for comprehensive coverage. Furthermore, UI tests are much slower, less stable, and more sensitive to interface changes, potentially impacting the overall efficiency of the testing process.

API testing, on the other hand, allows testers to focus on the interactions between these varied systems at a more fundamental level - testing the logic. Since these apps heavily rely on API interactions for processes like order placement, tracking, and delivery, API testing enables a streamlined evaluation of these critical functions. It facilitates a more efficient creation of end-to-end scenarios, covering the entire order process from the customer's order placement to the final delivery. This method provides faster execution, greater stability, and better integration capabilities across different components of the app. By combining API testing with necessary UI tests, teams can achieve a more balanced and thorough testing strategy. This blended approach ensures not only the functionality and interoperability of the back-end systems but also maintains the integrity and user experience of the front-end interfaces, leading to a more robust and reliable food delivery app.

Leveraging Loadmill's AI-Driven Approach

Loadmill's AI for API testing unlocks the potential for testing multi-system applications in the quick-service restaurant (QSR) sector. It captures API traffic from mobile and web-based apps, POS systems, tablets, desktops, and headless applications, transforming this data into automated test code. This API-driven approach is advantageous for managing the complexities of QSR app testing. It's faster and more stable compared to traditional UI testing tools, efficiently tackling the unique challenges presented by these multifaceted applications. See it in action and book a session to learn more about AI for API testing.

QSR6

Conclusion:

Testing the intricate web of systems within quick-service restaurants (QSRs) stands as a daunting task. The recent disruptions faced by industry giants like Greggs and McDonald's serve as stark reminders of the pivotal role robust testing methodologies play in maintaining operational fluidity and customer contentment. By tackling challenges ranging from cross-device flows to verification mechanisms, live tracking features, and billing/payment integrations head-on, QSRs can fortify the reliability and endurance of their digital infrastructure. Through these concerted efforts, they can elevate the caliber of service offered to customers, ensuring a seamless and gratifying experience at every touchpoint.