🐛 Reading: Jira Tickets & Bug Reports

Line 142 in checkout.js — extracted from the console error:

The bug report console error reads: "TypeError: Cannot read property 'length' of undefined at checkout.js:142"

This tells a developer exactly where to look:

• Error type: TypeError — a type mismatch or unexpected null/undefined
• Operation: trying to read the length property
• Problem: the value was undefined instead of an array or string
• Location: checkout.js, line 142

Bug report reading: where is the most actionable information?

• Title → brief summary of what's broken and where
• Environment → which setup reproduces it (OS, browser, version) — critical for intermittent bugs
• Steps to Reproduce → how to recreate it from scratch
• Expected vs. Actual → the core of what's wrong
• Console errors / attachments → often the most technically useful section for developers

Key vocabulary: reproducibility (100% = always happens), console error, stack trace, attachment

iPhone 14 Pro + Safari 17.3 — the specific affected environment:

The Environment section of the bug report specifies: Device: iPhone 14 Pro (iOS 17.3.1), Browser: Safari 17.3, Reproducibility: 100% on affected device/browser combination.

This is important for triage:

• The bug may or may not affect other iPhone models, other iOS versions, or other browsers — the report doesn't tell us
• The developer should test on additional environments to determine the scope
• It might be a Safari + iOS-specific WebKit bug, or specific to the device GPU/memory

Reading "Reproducibility: 100%":
This means the reporter saw it succeed every single time they tried on that specific device. This is helpful — intermittent bugs (e.g., 10% reproducibility) are much harder to investigate.

Steps to Reproduce vs. Environment:
The steps say "Add 3 OR MORE items" — this is a condition to trigger the bug, not the defining environment. The bug happens because of the Safari/iOS environment, which can't handle whatever logic runs at 3+ items.

Unauthenticated users are prompted to log in or register:

Acceptance Criterion 6 states explicitly: "Unauthenticated users attempting to save an item are prompted to log in or register."

This is a precise decision that avoids common UX mistakes:

• ❌ Hiding the button entirely → users don't know the feature exists
• ❌ Silently ignoring the action → confusing for the user, no feedback
• ❌ Saving then prompting at checkout → could lose the data
• ✅ Prompting immediately → clear, honest, converts visitors to registered users

User story format: As a… I want to… So that…

• As a registered user → who the persona is
• I want to save items to a wishlist → what they want to do
• So that I can purchase them later without searching again → the business value / reason

Acceptance Criteria vs. Definition of Done:

• Acceptance Criteria → functional requirements: what the feature must do from the user's perspective
• Definition of Done → quality requirements: tests written, cross-browser verified, etc.