Belajar QA Tester - Defect Reporting & Lifecycle

#Pendahuluan

Setelah di episode 7 kita mempelajari exploratory testing, pada episode ini kita mempelajari defect reporting & lifecycle — bagaimana menulis bug report yang efektif dan memahami lifecycle sebuah bug dari ditemukan hingga diperbaiki. Bug report yang baik adalah k komunikasi antara QA dan developer.

Mengapa defect reporting penting? Karena bug report yang buruk akan membuat developer frustrasi, membuang waktu, dan memperlambat perbaikan. Sebaliknya, bug report yang baik akan mempercepat proses debugging dan perbaikan.

#Struktur Bug Report

Setiap bug report harus memiliki struktur yang jelas:

text

Bug Report Structure:
├── Title: Judul singkat &deskriptif
├── Environment: Browser, OS, versi aplikasi
├── Steps to Reproduce: Langkah-langkah untuk mereplikasi bug
├── Expected Result: Apa yang seharusnya terjadi
├── Actual Result: Apa yang sebenarnya terjadi
├── Screenshots/Video: Bukti visual
├── Severity: Seberapa parah bug ini
├── Priority: Seberapa mendesak untuk diperbaiki
└── Additional Info: Logs, console error, dll

#Contoh Bug Report

text

BUG-001: Tombol Checkout Tidak Responsif di Mobile
├── Environment:
│   ├── Browser: Chrome 120 (Android 14)
│   ├── Screen: 375x667 (iPhone SE)
│   └── App Version: 2.1.0
├── Steps to Reproduce:
│   1. Buka halaman cart di mobile
│   2. Tap tombol "Checkout"
│   3. Tunggu 5 detik
│   4. Tidak ada yang terjadi
├── Expected Result: Redirect ke halaman checkout
├── Actual Result: Tombol tidak responsif, tidak ada perubahan
├── Screenshots: [attached]
├── Severity: High (core flow terganggu)
└── Priority: High (fix sebelum release)

#Severity vs Priority

Banyak yang bingung membedakan severity dan priority:

Severity	Priority	Contoh
High	High	Payment crash, data loss
High	Low	Crash di fitur jarang dipakai
Low	High	Typo di halaman utama
Low	Low	Typo di halaman About

text

Severity Levels:
├── Critical: Sistem crash, data loss, security breach
├── High: Core flow terganggu, work around tidak ada
├── Medium: Fitur terganggu, work around ada
├── Low: Cosmetic, tidak mempengaruhi fungsi
└── Trivial: Typo, alignment, hal kecil lainnya
 
Priority Levels:
├── P1 (High): Fix sekarang, release blocker
├── P2 (Medium): Fix dalam sprint ini
├── P3 (Low): Fix dalam release berikutnya
└── P4 (Backlog): Fix saat ada waktu

Note

Severity dan priority bisa berbeda. Bug dengan severity rendah tapi di halaman utama mungkin punya priority tinggi karena mempengaruhi banyak pengguna.

#Bug Lifecycle

text

Bug Lifecycle States:
├── 1. New: Bug baru ditemukan
├── 2. Assigned: Bug ditugaskan ke developer
├── 3. In Progress: Developer sedang memperbaiki
├── 4. Fixed: Bug sudah diperbaiki
├── 5. Ready for Test: QA bisa mereview
├── 6. Verified: QA memverifikasi fix
├── 7. Closed: Bug ditutup
└── Reopened: QA menemukan bug masih ada → kembali ke In Progress

#Alur Lifecycle

100%

#Tips Menulis Bug Report

#DO

text

DO:
├── Gunakan title yang deskriptif
│   ├── Good: "Tombol Checkout Tidak Responsif di Mobile Chrome"
│   └── Bad: "Bug di checkout"
├── Sertakan steps to reproduce yang lengkap
│   ├── Step-by-step dengan angka
│   ├── Sertakan data input yang tepat
│   └── Sertakan URL jika applicable
├── Sertakan expected vs actual result
│   ├── Expected: "Redirect ke halaman checkout"
│   └── Actual: "Tombol tidak responsif"
├── Sertakan screenshots/video
│   ├── Anotasi area bermasalah
│   └── Sertakan console error jika ada
└── Sertakan environment info
    ├── Browser, OS, versi aplikasi
    └── Screen size untuk mobile testing

#DON'T

text

DON'T:
├── Jangan gunakan title yang ambigu
│   └── "Tidak bisa login" → Login bagaimana? Dengan apa?
├── Jangan skip steps to reproduce
│   └── Developer tidak bisa fix apa yang tidak bisa direplikasi
├── Jangan mix beberapa bug dalam satu report
│   └── Satu bug per report
├── Jangan gunakan bahasa emosional
│   └── "Developer bodoh bikin bug" → Unprofessional
└── Jangan lupa sertakan environment
    └── Bug mungkin hanya muncul di browser tertentu

#Practical: Bug Report Template

Berikut template bug report yang bisa kalian gunakan:

yaml

title: "[Component] Deskripsi Singkat Bug"
environment:
  browser: Chrome 120
  os: Windows 11
  app_version: 2.1.0
  screen_size: "1920x1080"
steps_to_reproduce:
  - Step 1
  - Step 2
  - Step 3
expected_result: Apa yang seharusnya terjadi
actual_result: Apa yang sebenarnya terjadi
severity: High/Medium/Low
priority: P1/P2/P3/P4
screenshots:
  - screenshot-1.png
additional_info: "Console error: [error message]"

Tip

Gunakan tools seperti Jira atau GitHub Issues untuk tracking bug. Pastikan setiap bug punya ID unik dan bisa dilacak dari report hingga fix.

#Penutup

Pada episode 8 ini, kalian telah mempelajari defect reporting & lifecycle.

Inti yang harus dibawa pulang:

Bug report harus: title deskriptif, steps to reproduce lengkap, expected vs actual, screenshots, environment info.
Severity = seberapa parah; Priority = seberapa mendesak. Keduanya bisa berbeda.
Bug lifecycle: New → Assigned → In Progress → Fixed → Ready for Test → Verified → Closed.
Satu bug per report. Jangan mix beberapa bug.

Di episode 9 selanjutnya, kita akan membahas API testing dasar — bagaimana menguji REST API menggunakan Postman, termasuk status codes, request methods, dan assertions. Sampai jumpa di episode 9!