Roughly speaking, ‘fuzzing’ is testing without an oracle, i.e. testing without knowing what a specific outcome should be. When fuzzing, we don’t necessarily know what should happen, but we have a good idea of some things that shouldn’t happen, such as 404 errors and server or application crashes. We generally apply fuzzing to produce these kinds of errors when we’re testing text boxes, but why should textboxes have all the fun?
Websites created today are highly interconnected, multi-server applications that include connections to out-of-network servers that are controlled by neither the applications nor the team. This situation makes it difficult to both enumerate and control all the possible combinations of paths through our system. Even if we could identify all the possible paths, most organizations would not have the time to test all of these scenarios, regardless of whether or not they apply automation to help with that testing.
During this session, we explore how expanding our automation approach by using randomization can help mitigate the risks associated with hard-to-enumerate application scenarios. By using random clicking, we can provide testers with additional information via exploring paths through the application which are not intuitive, but which are still valid. We’ll discuss why creating a random clicker doesn’t have to take a lot of effort, how this approach is rooted in the facets of High Volume Automated Testing (HiVAT), and some considerations of which to be mindful when using randomization.