Chaos Testing
Chaos testing with Aiqaramba is about letting agents be creative. Instead of telling them exactly what to do, you tell them to explore your application and try to break things. Enter weird inputs, click things in unexpected order, use special characters, submit empty forms, navigate back and forth rapidly.
This is surprisingly effective because agents will try patterns and combinations you would never think of yourself. They do not have the mental model of "how the app is supposed to work" so they interact with it like a confused or adversarial user would.
How we would set it up
Unlike functional QA where you want many specific journeys, chaos testing works best with just a few broad ones. You are not testing whether a specific flow works. You are testing whether your application holds up when someone uses it in ways you did not anticipate.
Create one journey per major area of your application: one for the dashboard, one for the settings page, one for whatever your core product surface is. Each journey should tell the agent to stay on that page and try everything. Click every button, fill every input with garbage, submit forms with missing fields, use the back button aggressively.
The important thing is to design your journeys so that the result is green if nothing significant is broken. If you make the bar too low, your chaos tests will fail constantly and you will start ignoring them. A good chaos journey reports failure only when something actually crashes, throws an unhandled error, or becomes unusable. Minor cosmetic issues or validation messages are expected, not failures.
- Run on a schedule. Chaos tests are great candidates for scheduled runs. Set them to run daily or after deploys. They function as a general stability check for your application.
- Keep the count low. Three to five chaos journeys covering your main pages is usually plenty. More than that and you are spending compute on redundant exploration.
- Set the bar high. Tell the agent to only report failures for crashes, unhandled errors, or completely broken functionality. A validation error on a bad input is working as intended, not a failure.