Log Analysis with AI: Read Logs and Stack Traces as a Tester

Logs can look like a wall of strange text. Once you know what to look for, they become a timeline of what the system did. In this lesson you will practise log analysis with AI, learn to read a stack trace and turn a confusing error into a useful test finding.

📖 What You’ll Learn

  • What logs and log levels mean
  • How to read a stack trace
  • How to share only safe, relevant lines
  • How to confirm a possible cause

💡 What Is a Log?

Explain Like I’m 5: Logs

Imagine: A detective follows muddy footprints across the floor to see where someone went.

What it really means: A log is a timed record of what software did.

In testing: It shows which request arrived and where it failed.

Log levelMeaningExample
INFONormal activityRequest received
WARNSomething looks unusualA service responded slowly
ERRORAn operation failedThe order could not be saved
DEBUGExtra technical detailValues used by developers

🔍 How to Do Log Analysis with AI Safely

Explain Like I’m 5: Finding the Right Page

Imagine: You do not read a whole storybook to find one picture. You go to the right page.

What it really means: Share only the small part of the log that matters.

In testing: Find the time of the failure and copy nearby lines.

Follow these steps:

  1. Note the time and test action that failed.
  2. Find the same request ID or nearby timestamps.
  3. Copy only the relevant lines.
  4. Replace secrets and personal data with placeholders.
  5. Ask for possible explanations, and how to check them.

Remember the rules in AI Data Privacy for Testers. Use only approved tools, and never paste unsanitised production logs.


🌍 Real-Life Example: A Failed Order

This made-up log shows one request.

10:15:02 INFO  [req-42] POST /api/orders received
10:15:03 WARN  [req-42] inventory-service took 4800 ms
10:15:05 ERROR [req-42] Order failed: TimeoutException from inventory-service
10:15:05 INFO  [req-42] Response status 500

Read it from top to bottom. The same ID, req-42, connects each line. The order service asked the inventory service for help, that service became slow, and the request failed with an HTTP 500.


🛠️ How to Read a Stack Trace

Explain Like I’m 5: Stack Trace

Imagine: One child asks another for a toy, who asks a third. When the third child cannot find it, the message travels back along the line.

What it really means: A stack trace lists the chain of code that was running at the failure.

In testing: It helps developers find where the failure surfaced.

java.util.concurrent.TimeoutException: inventory-service did not respond
    at com.shop.InventoryClient.reserve(InventoryClient.java:88)
    at com.shop.OrderService.place(OrderService.java:41)
    at com.shop.OrderController.create(OrderController.java:23)

In a Java stack trace, start at the top. It gives the error type and message, followed by the most recent code that was running. Python is different. Its traceback puts the error on the last line. If you see “Caused by” in Java, read that part too, because it can reveal the original problem.


📌 From Possible Cause to Evidence

Explain Like I’m 5: Possible vs Proven

Imagine: The cookie is gone and your brother has crumbs on his shirt. That is a clue. It is not proof until you check.

What it really means: AI gives possible explanations, and evidence confirms one.

In testing: A timeout may come from a slow service, a network issue or bad configuration.

For our example, a tester could check:

  • Does the failure repeat when the inventory service is healthy?
  • Are other requests slow at the same time?
  • Does the problem happen with only some products?
  • Did a recent deployment or configuration change happen?

A symptom is not always the cause

The final error may be only the last thing to break. Look at what happened earlier in the timeline, and ask a developer to confirm the root cause.


🔑 Automation Failures

The same approach helps with failed UI tests. Combine the error message with the screenshot and trace. Our Playwright Trace Viewer lesson shows how to inspect a failed test step by step.


🧪 Try It Yourself

  1. Copy the made-up log from this lesson.
  2. Before using AI, write what you think happened.
  3. Run the prompt below.
  4. Mark each answer as confirmed by the log, or as a guess.
  5. Write a short finding for a developer, using only what you can support.

📋 Ready-to-Copy Prompt

You are a senior QA engineer helping me understand a failure.

What I was testing: [test action]
Expected result: [expected result]
Actual result: [actual result]

Sanitised log or stack trace:
[paste only relevant lines, with no secrets or personal data]

Please provide:
1. A plain-language timeline of what happened
2. The first line that looks unusual, and why
3. Up to 3 possible causes, each marked Low, Medium or High likelihood
4. For each cause, one check that could confirm or reject it

Rules:
- Separate facts from the log and your guesses.
- Do not claim a root cause without evidence.
- Tell me what other information you need.

⚠️ Common Mistakes

  • Pasting an entire log file into a chat
  • Sharing tokens, emails or customer data
  • Reporting AI’s guess as the root cause
  • Reading only the final error line
  • Ignoring the timestamps and request IDs

🎯 Key Takeaways

  • Logs are a timeline of system behaviour.
  • A request ID can connect related lines.
  • Stack trace reading order depends on the language.
  • AI suggests possibilities, and evidence confirms them.

🎤 Interview Questions

1. How do you investigate a failed test using logs?

Model answer: I find the time or request ID of the failure, review the related lines in order and look for the first unusual event. I compare this with the test evidence, then check likely causes or involve a developer.

2. What is a stack trace?

Model answer: A stack trace shows the sequence of function calls active when an error occurred. It helps identify where the failure surfaced. Reading order differs by language, so in Python the final line contains the error.

3. What are common log levels?

Model answer: Common levels are DEBUG, INFO, WARN and ERROR. DEBUG gives detailed diagnostics, INFO records normal events, WARN marks unusual conditions and ERROR records failed operations.

4. How can you safely use AI to analyse logs?

Model answer: I use an approved tool, send only the relevant lines and replace sensitive values before sharing. I ask for possible causes and checks, then verify them with real evidence.

5. How do you tell the difference between a symptom and a root cause?

Model answer: A symptom is the visible failure, such as an HTTP 500. A root cause explains why it happened. I trace events back in time, test possible explanations and confirm the cause with evidence and developers.


📝 Assignment

Create a made-up log with at least eight lines, two request IDs and one hidden problem. Ask a friend or an AI assistant to find the problem. Check whether the answer separates facts from guesses, and improve your prompt if it does not.


❓ FAQ

Do testers need to read code to use logs?

No. You can learn a lot from timelines, error messages and request IDs. Basic code reading will help as you move into automation.

Are AI log tools always accurate?

No. Treat any accuracy claim with care, and verify results against the raw evidence.


🚀 Next Steps

Well done on finishing this lesson. Complete the assignment, then continue with Risk-Based Regression Testing with AI: Choose What to Test.