In American pop culture, Sasquatch (also known as Bigfoot) is likely a non-existent, ape-like, creature infrequently seen in the Pacific Northwest of North America. In the software realm, we have our own version of Sasquatch: that irritating, "intermittent issue" occurring in the system. These kinds of issues are typically difficult to find and often blamed on anything other than a product defect.
We typically run our automated tests on event boundaries, i.e. when we have a successful build and deployment; we look for problems when we think we may have introduced problems. Logically, these points of change are when we expect to have injected new issues, so, we only look for issues at those times. This approach alone, however, only gives us limited opportunities to reproduce our intermittent issues. If we also ran our automation periodically, we would have additional opportunities to reproduce these types of issues; we simply call this approach periodic automation.
Using a real-world example from his own experience, Paul Grizzaffi will explain how this periodic automation can help hunt down these elusive targets. For additional context, he will explain how this approach relates to High-Volume Automated Testing (HiVAT), as well as some HiVAT basics and examples. He will also explore some considerations of which we need to be mindful when implementing periodic automation in order to avoid desensitisation to failures.
Though we may never find “the real” Sasquatch, applying periodic automation increases our chances of finding our own intermittent issues.
- The complexity of most current software systems all but guarantees intermittent issues.
- Running automation on non-event boundaries can help catch intermittent issues.
- While periodic automation evolved from academic-research, it also has real-world applications.
- We must be mindful of “failure fatigue” when adding automation runs