-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathlog_review_and_investigation_notes
More file actions
37 lines (25 loc) · 1.1 KB
/
Copy pathlog_review_and_investigation_notes
File metadata and controls
37 lines (25 loc) · 1.1 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# Log Review and Investigation Practices
When system behavior did not match expectations, investigation went beyond the UI.
Logs and backend signals were treated as primary evidence.
## When Logs Were Reviewed
Log review was typically used when:
- UI behavior was inconsistent or unclear
- Actions appeared to partially succeed or fail
- Timing or retry behavior was involved
- Data appeared incorrect after an operation
## Investigation Mindset
Log review was used to answer questions such as:
- Did the system receive the request?
- Did the action execute once or multiple times?
- Which step failed, and why?
- Was data written, rolled back, or left incomplete?
Rather than searching for errors alone, logs were used to reconstruct
what the system actually did.
## Impact on QA Artifacts
Findings from log review often resulted in:
- New negative or recovery-focused test cases
- Updated expected behavior definitions
- More precise defect reports
- Better understanding of system edge cases
This practice reinforced the habit of validating behavior at the system level,
not only through user-facing signals.