Memahami bagaimana QA berkontribusi dalam framework Agile/Scrum termasuk QA dalam sprint, definition of done, dan kolaborasi tim

Setelah di episode 11 kita mempelajari cross-browser & mobile testing, pada episode ini kita mempelajari Agile QA & Scrum — bagaimana QA berkontribusi dalam framework Agile/Scrum yang menjadi standar industri. Dalam Agile, QA bukan fase terakhir tapi bagian integral dari setiap sprint.
Mengapa Agile QA penting? Karena di Agile, semua orang bertanggung jawab atas kualitas, bukan hanya QA. QA harus terlibat sejak awal sprint, bukan hanya saat development selesai. Dengan memahami peran QA dalam Agile, kalian bisa berkontribusi lebih efektif.
QA Activities per Sprint:
├── Sprint Planning:
│ ├── Review user stories
│ ├── Identifikasi test scenarios
│ ├── Estimasi testing effort
│ └── Identifikasi test data needs
├── Sprint Execution:
│ ├── Review & approve user stories
│ ├── Design test cases
│ ├── Execute tests
│ ├── Report & track bugs
│ └── Verifikasi bug fixes
├── Sprint Review:
│ ├── Demo fitur yang sudah diuji
│ ├── Report quality metrics
│ └── Feedback dari stakeholder
└── Sprint Retrospective:
├── Apakah yang bisa diperbaiki?
├── Process improvement
└── Tooling improvementDaily Scrum - QA Update:
├── "Yesterday I tested login flow, found 2 bugs"
├── "Today I'll test checkout with e-wallet"
├── "Blocker: waiting for staging environment"
└── "Risk: payment API not ready yet"Definition of Done (QA):
├── All test cases executed
├── All P1/P2 bugs fixed
├── Regression suite passed
├── Code reviewed by peer
├── Documentation updated
├── Performance acceptable
├── Security scan clean
└── Product owner approved| Concept | Deskripsi | Contoh |
|---|---|---|
| Definition of Done | Kapan work item selesai | Semua test passed, bug fixed |
| Definition of Ready | Kapan work item bisa mulai | Spec jelas, design ready |
Note
DoD harus disepakati oleh seluruh tim, bukan hanya QA. Jika developer tidak setuju dengan DoD, implementasinya akan sulit.
QA-Developer Collaboration:
├── 1. Pair testing: QA & developer test bersama
├── 2. Bug triage: QA & developer review bugs
├── 3. Test review: developer review test cases
├── 4. Code review: QA review kode untuk testability
└── 5. Knowledge sharing: QA share bug patternsQA-PO Collaboration:
├── 1. Story refinement: QA review acceptance criteria
├── 2. Sprint planning: QA estimasi testing effort
├── 3. Bug prioritization: QA & PO prioritaskan bugs
├── 4. Demo: QA demo fitur yang sudah diuji
└── 5. Release decision: QA berikan quality assessmentAgile Testing Quadrants:
├── Q1: Technology-facing, Business-facing
│ ├── Unit tests
│ └── Component tests
├── Q2: Business-facing, Technology-facing
│ ├── Functional tests
│ ├── Story tests
│ └── Prototype simulations
├── Q3: Business-facing, Supporting
│ ├── Exploratory testing
│ ├── Usability testing
│ └── Alpha/beta testing
└── Q4: Technology-facing, Supporting
├── Performance tests
├── Load tests
└── Security testsScrum Workflow - QA Perspective:
├── Sprint 5, Day 1: Sprint Planning
│ ├── QA review 5 user stories
│ ├── Estimate: 3 hari testing
│ └── Identify: 2 stories need early testing
├── Sprint 5, Day 2-4: Development
│ ├── Day 2: QA design test cases
│ ├── Day 3: QA test story 1 (early completion)
│ └── Day 4: QA test story 2
├── Sprint 5, Day 5-8: Testing
│ ├── Day 5-6: Execute functional tests
│ ├── Day 7: Regression testing
│ └── Day 8: Bug verification
├── Sprint 5, Day 9: Sprint Review
│ ├── QA demo: 4/5 stories passed
│ └── Quality report: 2 bugs found, 1 P1
└── Sprint 5, Day 10: Retrospective
├── QA feedback: "Need more test data"
└── Action: Setup test data generatorTip
Dalam Agile, QA harus bekerja paralel dengan development, bukan sesudahnya. Mulai test design saat developer mulai coding, dan mulai testing segera setelah story selesai di-develop.
Pada episode 12 ini, kalian telah mempelajari Agile QA & Scrum.
Inti yang harus dibawa pulang:
Di episode 13 selanjutnya, kita akan membahas test data management — bagaimana menyiapkan, mengelola, dan memanage test data secara efektif. Sampai jumpa di episode 13!