Rambo testing is somewhat of a misnomer: it’s not always about doing whatever it takes to break the new functionality. That would be too easy. It is about going off script in a thoughtful manner. The idea of Rambo testing at Kanban is to find legitimate ways that the customers or users might work with the system that are not explicitly documented in our functional spec, and thus wouldn’t be covered in our regular scripts.For example, there are some situations where we can assume that users will try to hack the system. Game players will want to cheat. Students will want to change their grades. Bloggers will want product images before they’re available to the general public. After we test certain specific methods of hacking based on security best practices, we will need to Rambo test, creatively trying to discover other ways to get around our security measures. This is best done by a software engineer who did not work on the project.
Another example is testing content entry in a content management system, or CMS. This is where we need to be especially thoughtful in our Rambo testing. It’s not fair to file a bug that says the wrapping in a narrow column fails to accommodate “fjkeowfjiwopamkverjipvjtghioweiomnweknktl” (assuming your site is not in German). But it is fair to file a bug if, for example, the narrow column could legitimately be expected to contain a URL without hyphens. This is best done by planning ahead to have as much real content available during QA as the client can provide.
In the same vein, we wouldn’t want to Rambo test the display of media with assets that are nothing like what the client would realistically upload. So what do we do if the client doesn’t have real examples yet? We don’t Rambo test it. We test against only what was specified, and we declare from the start of the project that there should be a phase after this launch where the system is refined to meet needs that we can’t know until it’s put into use.
Where Rambo testing really gets the use that its name implies is in testing a tool or application. This is a great time to get someone who wasn’t on the project to try to break your app. It’s a bonus if that person can be similar to the target audience, but it’s more important that they’re creative about testing. Does the tool work while the user is doing other things on the site? What if they click very quickly? Hit the Back button? Have the same page open in two browsers at once? We document the results of Rambo testing by having the QA tester briefly describe what they did and if it passed. From bugs filed during Rambo testing, we can see if any methods that the Rambo tester used should become a part of our normal QA process next time.
With this approach, we are consistently improving our quality assurance process while delivering precisely what our customers and users expect.