Inside a team, a bug usually starts as one sentence: “The app closes when I tap that.” What comes after is the long part. Someone tries to reproduce it on their own phone, writes the steps out again, looks for a screen recording, asks which version it was.
This post is about making that long part short. The example comes from RideGo, our own demo app. Tapping a cancelled trip closes the app.
1. The issue starts with one sentence
We opened an issue on GitHub and wrote two lines:
The app closes when I tap a cancelled trip on the Your Trips screen.
/testsafe please test this
The second line is the important one. With the TestSafe GitHub app connected, that comment starts a test. You don’t switch to another screen, write a scenario or upload a build. The agent reads the sentence in the issue and decides for itself what to try.
A few seconds later the bot leaves a short comment in the same thread: it has the issue, the result will land here.
2. The agent tries it on a phone
Behind the scenes, an Android device in the cloud is reserved, that version of the app is installed, and the agent starts using the app the way a person would.
In our case it did this, in order:
- Opened the app and signed in with the test account.
- Went to Your Trips from the side menu.
- Found the trip marked Cancelled in the list.
- Tapped it.
On step four the app closed and Android showed its “RideGo has stopped” dialog.
Worth noting: the agent is not replaying a script someone wrote. It looks at what is on screen and decides. If the menu moved, or the list came back in a different order, it would still get there.
3. Evidence piles up while it runs
The screen is recorded, every step is timed, and the device’s own logs are collected. The moment the app crashes, the crash record Android produces goes into the report too.
Here is what we saw in the report:
- Result: Failed.
- Warning: The app crashed when the cancelled trip was tapped.
- Crash record:
java.lang.NullPointerException, from the app’s trip history screen, line 34. - Video: One click takes you to the second where it crashed.
So not “something happened”, but “it happened on this screen, at this moment, for this reason”.
4. The report comes back to the conversation
When the test ends, the bot leaves a second comment on the same issue. It has a plain summary and a table of criteria. Each row is one expectation, with the result next to it and the seconds of the video where it was seen:
| Criterion | Result | Video |
|---|---|---|
| Your Trips must open | Passed | 1:05 → 1:59 |
| The list must have a cancelled trip | Passed | 1:59 → 2:03 |
| Tapping the trip must not crash the app | Warning | 2:03 → 2:29 |
Whoever reads the report doesn’t have to go anywhere else. Checking whether the bug is real takes ten seconds: you open the video at that second.
Why the order matters
Most testing tools set this up backwards. First you write the scenarios, then you run them, then you follow the results on a separate dashboard. Over time that dashboard becomes a place nobody visits.
Here the starting point is where the team already works: an issue, a comment. The result comes back to the same place. The same goes for Slack and Jira: a notification arrives in the channel, an issue is opened in Jira, and the video and steps are attached to it.
If you want to try the same thing
- Upload your app.
- Connect GitHub from the Integrations screen.
- Write the bug in one sentence on an issue and add the
/testsafecommand.
The report arrives in the same thread a few minutes later. The steps, with screenshots, are on the Quick Start page.