Testing at MACH Speed: H is for Headless

Like the Headless Horseman, the frontend and backend are decoupled in headless ecommerce. This means that testers no longer have to wait for both the frontend and the backend to be completed before they start testing. But this also means that they have to, in a sense, test the same feature three different times. So how do you do this?
Testing headless

As a kid, I loved Walt Disney’s retelling of Washington Irving’s The Legend of Sleepy Hollow. So, it should come as no surprise that when I think about H, for Headless in the MACH acronym, I think of Ichabod Crane being chased by the Headless Horseman through the woods of Sleepy Hollow.

Like the Headless Horseman, testing headless applications can be mysterious. And like we did in my last article in this series, let’s demystify it!

Traditional eCommerce VS Headless

In a traditional ecommerce website, the frontend and backend are tightly coupled. This makes testing relatively straightforward, as testers can simply use a web browser to interact with the website and verify that all of the functionality is working as expected. But this also means testing has to wait until everything is ready before it can be tested. So when bugs are found, the impact on the project’s timeline is huge.

With headless ecommerce, the frontend and backend are decoupled. This means that headless testing no longer needs to wait for both the frontend and the backend to be done before they start testing. But this also means that they have to, in a sense, test the same feature three different times. So how do you do this?

Let’s start with how to sequence headless testing starting with:

  1. Backend alone – via the APIs we talked about in Attack of the APIs
  2. Frontend alone – via the browser using the UI Design Mockups
    • You’ll want to focus your testing on these during your development sprints. You can test the Backend via API. For the Frontend, you’ll need to “mock” the data that will be supplied from the APIs since they aren’t ready yet.
    • I tend to run as many browser and device breakpoint tests at this point on as many browser/device combinations as possible since my integration testing will be focused on the most commonly used combinations, as reported by the Product Owner.
  3. Combined Backend/Frontend to confirm that the connections are working as expected (when we ‘Snap’ the Legos, I mean putting Backend/Frontend together).
    • You’ll want to do the combined testing during the integration testing phase as well as during any End-to-End/User Acceptance Testing phases you have planned. As mentioned, you’ll want to focus on your most commonly used browser and device combinations (think 80/20 rule), as your testing time will be limited.
    • A great way to kick off an integration, as well as an End-to-End test cycle, is with a particular stress test designed to run every possible combination of a feature’s data requirements in a single test, outlined below.

Here is an example of a customer order stress test that was built for a luxury retailer:

  1. A hazardous material item (these have specific shipping rules)
  2. An item that had to be signed for
  3. A food item (these have a different set of shipping rules)
  4. An item with a serial number
  5. 100 of one single item (the max number of a single item an order allowed at one time)
  6. An item that was out of stock
  7. An item that is on backorder
  8. An item that will be shipped to a different address
  9. An item that needed to be shipped overnight

Keep in mind this test is nowhere close to a realistic test. But I do like to run it at the very start of the Integration Test Phase to shake everything down and see where my initial issues are at.

Conclusion

At the end of The Legend of Sleepy Hollow, Ichabod’s fate is unclear. Some say he was yet another victim of the Horseman, while others say he moved on to another town. As for me, this will be my last post in this series.

As we wrap up, here is my last MACH testing tip: Involve business users throughout the testing process. Have the business users review your test cases and even help with testing. This will help to ensure that the testing process is aligned with the business goals of the system you are testing. As I like to say, “I’m only testing the system to see if it meets requirements, but you’re going to live with it every day after it goes live. So be sure it works the way you want it to work because that can get missed in requirements.”

Is your business looking for MACH experts and composable solutions? Contact Aries today!