In this post I will describe my heuristic for web page cache testing that failed and why it failed.
Web page cache is mechanism that stores parts of web page that does not change a lot in browser local storage. Hard part is to figure which part of page is not changing very often. A lot of scientific effort have been put in this problem.
I got a Jira card that clearly stated a story with cache usage.
During the creation of business object, cache all referenced data so when user will edit that object, all referenced data is already available.
I did exploratory test around this story, using my brain, eyes, ears and fingers. There were two paths to feature create business object. First path worked as described in user story, but second path did not. When I opened the create business object feature, all data had already been cached.
My first heuristic was that this is an issue. But after I explored the pull request connected with this card and discovered that all code changes were in one place I realized that my cache heuristic failed. Developers are using framework that helps them to write DRY code.
As create business feature component was reusable, first path to that feature already filled cache with data.
If you are in doubt how to enhance your testing craft, BBST is excellent starting point.