Dokumentasi Catatan Teknik
Wawasan, tutorial, dan catatan mendalam seputar QA automation dan rekayasa perangkat lunak.
Membangun Arsitektur E2E Test Automation dari Nol dengan Playwright & POM
Terakhir diperbarui: 14 Agustus 2026Memahami Sinkronisasi SDLC & STLC Secara Mendalam dalam Quality Engineering
Terakhir diperbarui: 12 Agustus 2026Alur End-to-End QA Process: Dari Risk Analysis, Test Plan, hingga Eksekusi
Terakhir diperbarui: 10 Agustus 2026Mengapa PRD Sangat Penting: Menghindari Lingkaran Setan "Back-and-Forth" Development
Terakhir diperbarui: 08 Agustus 2026Integrasi Playwright ke CI/CD Pipeline dengan GitHub Actions & Docker
Terakhir diperbarui: 05 Agustus 2026Memanfaatkan Claude Code & MCP untuk Akselerasi Pekerjaan QA
Terakhir diperbarui: 03 Agustus 2026Memahami Sinkronisasi SDLC & STLC Secara Mendalam dalam Quality Engineering
Dalam rekayasa perangkat lunak modern, kualitas produk tidak tercipta secara kebetulan. Kualitas adalah hasil dari kolaborasi erat antara SDLC (Software Development Life Cycle) dan STLC (Software Testing Life Cycle) yang berjalan berdampingan sejak hari pertama proyek dimulai.
📌 Konfiks Metodologi: Waterfall vs. Agile
Sebelum menyelami teknis pengujian, penting untuk memahami perbedaan fondasi dari dua metodologi pengembangan perangkat lunak yang paling sering digunakan:
- Waterfall (Tradisional): Pendekatan linier dan sekuensial. Setiap tahap (Requirement → Design → Coding → Testing → Deployment) harus selesai sepenuhnya sebelum tahap berikutnya dimulai. Pengujian (STLC) diletakkan di ujung sebagai satu fase masif tersendiri.
- Agile (Modern): Pendekatan iteratif dan fleksibel. Pengembangan dipecah ke dalam siklus-siklus kecil bernama Sprint (biasanya 2 minggu), di mana perencanaan, pengkodean, dan pengujian berjalan secara berkelanjutan di setiap siklusnya.
1. Diagram Alur Integrasi Paralel SDLC & STLC (Model Agile)
Visualisasi bagaimana tahapan pengujian (STLC) terikat langsung secara paralel dengan setiap fase pembangunan produk di dalam siklus Agile:
📊 SDLC & STLC Synchronization Flow
2. Anatomi Fase STLC: Entry Criteria, Exit Criteria, & Deliverables
Sebagai standar industri *Quality Engineering* yang matang, tahapan STLC memiliki aturan tegas kapan sebuah fase boleh dimulai (Entry Criteria) dan kapan dianggap selesai (Exit Criteria) sebelum lanjut ke fase berikutnya.
| Fase STLC | Entry Criteria (Syarat Mulai) | Exit Criteria (Syarat Selesai) | Deliverables (Hasil Akhir) |
|---|---|---|---|
| 1. Requirement Analysis | Dokumen PRD / SRS / User Story tersedia. | Dokumen dipahami, *testable points* teridentifikasi. | RTM (*Requirement Traceability Matrix*), Automation Feasibility Report. |
| 2. Test Planning | RTM dan Dokumen Requirement final. | Estimasi effort dan jadwal disetujui (*signed off*). | Test Plan / Test Strategy Document. |
| 3. Test Case Development | Test Plan telah disetujui. | Test case direview, Test data siap digunakan. | Test Cases, Test Scripts (Automated), Test Data. |
| 4. Environment Setup | Test Plan & Arsitektur sistem tersedia. | Environment sukses melewati *Smoke Test*. | Test Environment Ready, Smoke Test Results. |
| 5. Test Execution | Environment siap, Test Data tersedia. | Semua tes dieksekusi, cacat (*defect*) ditriase. | Test Execution Report, Bug/Defect Report. |
| 6. Test Closure | Test Execution selesai, tidak ada *critical bug* tersisa. | Laporan ringkasan rilis ditandatangani. | Test Summary Report, QA Sign-off, Test Metrics. |
3. Sinkronisasi di Tahap Awal (Shift-Left Testing)
Kesalahan terbesar dalam pengembangan software adalah baru melibatkan QA setelah kode selesai ditulis. Dalam pendekatan yang matang, STLC dimulai sejak fase *Requirement Analysis* SDLC. QA memeriksa dokumen persyaratan untuk mendeteksi ambiguitas atau potensi cacat logika sebelum developer mengetik baris kode pertama (*Defect Prevention vs Defect Detection*).
4. Perbandingan STLC: Pendekatan Waterfall vs Agile
Penerapan STLC sangat bergantung pada metodologi pengembangan software yang digunakan. Berikut adalah perbandingan langsung antara eksekusi STLC dalam model tradisional (Waterfall) dan modern (Agile):
| Parameter | Waterfall STLC (Sequential) | Agile STLC (Iterative) |
|---|---|---|
| Waktu Mulai QA | Dimulai belakangan setelah fase coding/implementasi SDLC selesai sepenuhnya. | Dimulai sejak hari pertama (*Shift-Left*), terlibat aktif dalam *grooming* dan *requirement analysis*. |
| Siklus Eksekusi | Eksekusi pengujian dilakukan sekali dalam skala besar menjelang akhir proyek (*End-of-Cycle*). | Eksekusi dilakukan secara terus-menerus dan berulang dalam setiap *Sprint* (biasanya 2 minggu). |
| Otomasi Pengujian | Biasanya fokus pada *End-to-End* manual di akhir, otomasi dibuat di tahap paling akhir. | Otomasi (seperti Playwright/API tests) dibangun paralel dan diintegrasikan langsung ke dalam pipeline CI/CD. |
| Manajemen Cacat (Defect) | Bug ditemukan terlambat, sehingga biaya perbaikan lebih mahal dan berisiko menunda rilis. | Bug ditemukan dan diperbaiki dengan cepat di dalam *Sprint* yang sama (*Immediate Feedback Loop*). |
5. Keterkaitan Erat Fase STLC terhadap SDLC dalam Praktik Agile
Dalam metodologi Agile, siklus SDLC dan STLC berjalan sangat cepat (biasanya dalam siklus 2 minggu *Sprint*). Hubungannya terjadi seperti ini:
- Test Planning: Dibuat bersamaan dengan fase perancangan sistem (*Design Phase*), menentukan ruang lingkup sprint, alokasi resource, dan mitigasi risiko.
- Test Design: Disusun saat developer melakukan coding, memastikan kasus uji (*test cases*) dan kerangka skrip otomasi Playwright sudah dibuat berdasarkan Mock/API Contract.
- Test Execution: Berjalan aktif ketika fitur dideploy ke *Staging*, di mana bug dilacak di JIRA, dilaporkan, dan langsung diverifikasi ulang (*re-tested*) dalam sprint yang sama.
Kesimpulan
Memahami dan menyelaraskan SDLC dan STLC secara sinkron, dilengkapi dengan penerapan *Entry/Exit Criteria* yang disiplin, memungkinkan tim menekan biaya perbaikan bug hingga 70%, mempercepat waktu rilis (*time-to-market*), dan memastikan produk akhir (*deliverable*) memiliki stabilitas tingkat tinggi (Enterprise-grade quality).