Testing practice: For Record the last actions, define a reproducible starting state, perform one controlled change at a time and record the result. Good testing evidence helps another person repeat the same path without guessing what happened.
Evidence quality: A useful report separates observation from theory. Record version, device context, steps, expected result and actual result while removing passwords, authentication codes and unrelated personal information from evidence.
Record the last actions
Write the exact steps immediately before the crash.
Small details such as rotation, permission denial or backgrounding can be critical.
Note build and device
Capture app version, Android version and device model.
Crash behaviour can depend on a specific build or platform.
Repeat carefully
Try the same steps again if doing so is safe and non-destructive.
Report whether the crash is consistent or intermittent.
Use logs responsibly
Developer logs and crash tooling can identify exception information.
Remove tokens, personal data and secrets before sharing logs outside the authorized team.
Do not guess from the final screen
The visible screen before termination may not reveal the actual code path that failed.
Keep observation separate from technical diagnosis.
Common mistakes to avoid
- Reporting only app crashed.
- Sharing logs with secrets.
- Guessing the cause from the last visible screen.
Practical checklist
- Record exact steps.
- Record version.
- Record device.
- Check repeatability.
- Redact diagnostics.
Frequently asked questions
Should a tester reproduce every crash repeatedly?
Only when it is safe and not destructive; one good report can be enough to start investigation.
Why is version important?
The crash may be specific to one build.
Can logs contain secrets?
Yes. Logs must be reviewed before sharing.