Crash logs, Memory logs, Charles logs, and other similar files contain raw technical data about the app you are testing. While they may look complex, they are extremely valuable tools for developers when investigating issues.
Logs provide behind-the-scenes information that is not visible in videos or screenshots. In many cases, they are essential for identifying the root cause of a bug.
What is a Crash Log?
A crash log is a file automatically generated when an application unexpectedly stops working, force closes, or freezes.
It captures detailed technical information about the app and device at the exact moment the crash occurred. This allows developers to understand what went wrong and why.
When are Crash Logs required?
Crash logs are mandatory whenever you report:
App crashes
Force closes
Freezing issues
Sudden clean restarts
Always refer to the Tester Spec Document for step-by-step instructions on how to collect crash logs for your specific platform or device.
Make sure you attach the correct crash log file to your report.
Why are Crash Logs important?
Troubleshooting: They help developers quickly locate the technical cause of the crash.
Reproduction Support: Some crashes cannot be reproduced consistently. In these cases, the crash log may be the only reliable evidence.
Prioritization: Frequent or critical crashes highlighted in logs help teams identify high-impact issues affecting user experience.
Note: Crash logs may contain sensitive information. Never share them outside the official reporting platform.
What are Memory Logs?
Memory logs record how an app uses device memory (RAM) over time. They track how memory is allocated, used, and released during app operation.
These logs help detect problems such as:
Memory leaks (memory that is allocated but never released)
Excessive memory consumption
Inefficient memory handling
Why are Memory Logs important?
Diagnosing Crashes: Many crashes, especially “Out of Memory” (OOM) errors, are caused by memory mismanagement.
Optimizing Performance: Continuous memory growth can slow down the app or cause instability.
Identifying Leaks: Developers can pinpoint exactly where memory is not being released properly.
What are Charles Logs?
Charles logs are generated using Charles Proxy, a network debugging tool that records and analyzes network traffic between an app and its backend services.
These logs capture:
HTTP and HTTPS requests
WebSocket traffic
API calls and responses
Headers and payload data
Latency and error messages
They provide a detailed view of what data is being sent and received while the app is running.
Why are Charles Logs important?
Debugging Network Issues: Identify failed API calls, slow responses, or authentication problems.
Checking Data Integrity: Verify that the data being sent and received matches the expected behavior.
Diagnosing Security Concerns: Detect unexpected or sensitive data transmission.
Validating Error Handling: Analyze app behavior under timeouts, gateway errors, or unstable connections.
How to collect Charles Logs
Install Charles Proxy on your computer.
Configure your device to use your computer as a network proxy.
Start recording in Charles before reproducing the issue.
Perform the steps that trigger the bug.
Stop recording and save the session as a
.chlsfile.Attach the file to your bug report as instructed.
Always stop recording after reproduction and review the log for sensitive information if required by your organization’s privacy guidelines.
Final Reminder
Detailed instructions for collecting all required logs are always available in the Tester Spec Document. It is essential to review this document before each test cycle.
Obtaining logs may feel overwhelming at first, but if you carefully follow the instructions step by step, the process becomes straightforward. With practice, generating and attaching the correct logs will become a routine part of professional bug reporting.
Comments
0 comments
Please sign in to leave a comment.