Connect:
Visit Agile Thoughts and register to receive free development, analysis, or leadership and management materials and learn to excel at developing software. I’ll also send information on my low cost email courses you can take via the internet.
The Test automation Pyramid series Starts on episode 1 and runs to episode 8.
Subcutaneous Tests:
Teams have found that just because acceptance criteria COULD be made into hard to maintain and unreliable UI test, many of them actually don’t need to be executed via the UI but instead in some sub layer beneath.
A flight booking service adding a new carrier, for example, doesn’t need a dozen UI tests to check if their website displays the flights from the new Shanghai Airlines feed. Instead they add one UI test into the penthouse that checks the Shanghai airlines logo comes up and the rest of the acceptance tests talk directly against the feed API itself or test the handler of the feed (we put the test near to the code that has the functionality). A lot of macro testing can be done without the UI or even without many upstream system/service dependencies. This secret middle floor is windowless as it doesn’t use the UI yet frequently requires deploying and launching a new process.
This middle floor is important. Without it, we’ll have too many UI tests in the penthouse, economics cause the pyramid to topple. The signs that your pyramid is toppling is is when more macro tests are failing than passing and people start disabling tests in order to cheat the build onto the pipeline. Subcutaneous tests are a key innovation! Because they are practically impossible to do with manual test strategies, many organizations with manual Test/QA habits have a giant blind spot in this area.
There are many tools for building subcutaneous tests: SoapUI, Rest Assured, Restito, WireMock. Other, non API example are making database connections directly to the stored procedure that contains the new functionality, and writing tests that link directly to the GUI controller. All in all, the strategy is to get the test automation as close as possible to the code that supports the new functionality.
Next episode we’ll take another holistic look at the pyramid and talk about what questions these tests are designed to answer.
