Dokumentasi Catatan Teknik
Wawasan, tutorial, dan catatan mendalam seputar QA automation dan rekayasa perangkat lunak.
Memahami Sinkronisasi SDLC & STLC Secara Mendalam dalam Quality Engineering
Dalam pembuatan aplikasi modern, kualitas produk tidak tercipta secara kebetulan. Kualitas adalah hasil kerja sama yang erat antara tim pembuat aplikasi (SDLC - Software Development Life Cycle) dan tim penguji (STLC - Software Testing Life Cycle) yang berjalan berdampingan sejak hari pertama proyek dimulai.
📌 Konteks Cara Kerja: Tradisional (Waterfall) vs. Modern (Agile)
Sebelum membahas cara mengetes aplikasi, kita perlu tahu dua cara kerja yang paling sering dipakai oleh perusahaan teknologi:
- Waterfall (Gaya Lama): Kerjanya berurutan seperti air terjun. Mulai dari desain, menulis kode (coding), sampai selesai, barulah aplikasi diserahkan ke tim QA untuk dites. Kelemahannya: kalau ada masalah, baru ketahuan di akhir dan perbaikannya sangat mahal.
- Agile (Gaya Modern): Kerjanya dicicil dalam siklus pendek (biasanya 2 minggu) yang disebut Sprint. Perencanaan, pembuatan kode, dan pengujian berjalan bersama-sama di setiap siklus.
1. Bagaimana Tim Pembuat dan Tim Penguji Bekerja Bersama?
Berikut adalah gambaran sederhana bagaimana tahapan pengujian (STLC) langsung menempel pada proses pembuatan aplikasi (SDLC) di setiap langkahnya:
📊 Alur Kerja SDLC & STLC yang Berjalan Bersamaan
2. Isi dari Tahapan Pengujian (Sesuai Standar ISTQB)
Sebagai standar industri yang matang, tim QA memiliki aturan tegas kapan sebuah pekerjaan boleh dimulai (Syarat Mulai) dan kapan dianggap selesai (Syarat Selesai).
| Tahapan Pengujian (STLC) | Syarat Mulai (Entry Criteria) | Syarat Selesai (Exit Criteria) | Hasil Akhir (Deliverables) |
|---|---|---|---|
| 1. Test Planning (Perencanaan) |
Dokumen ide/kebutuhan awal fitur sudah tersedia. | Rencana jadwal, target uji, dan pembagian tugas disetujui. | Dokumen Test Plan (Rencana Pengujian). |
| 2. Test Analysis (Analisis Risiko) |
Rencana pengujian disetujui dan buku panduan fitur sudah jelas. | Tim paham bagian mana saja yang paling rawan rusak atau berisiko tinggi. | Daftar Target Fitur (Kondisi yang wajib dicek). |
| 3. Test Design & Implementation (Persiapan Skenario & Sistem) |
Analisis risiko selesai dilakukan. | Skenario (Test Case) sudah ditulis, data untuk mengetes disiapkan, dan server uji sudah nyala. | Dokumen Test Case & Skrip otomatisasi (bila ada). |
| 4. Test Execution (Eksekusi / Mulai Mengetes) |
Aplikasi sudah bisa dibuka dan lingkungan server siap dipakai. | Semua fitur selesai dicoba, dan semua kendala (bug) sudah dilaporkan ke developer. | Laporan Temuan Bug (Defect Report). |
| 5. Test Completion (Rapor Kelayakan Akhir) |
Pengujian selesai dan tidak ada bug parah yang dibiarkan. | Semua pihak (termasuk manajer) setuju bahwa aplikasi siap diluncurkan. | Test Summary Report (Rapor Kelayakan Aplikasi). |
3. Contoh Penerapan Nyata STLC (Studi Kasus: Sprint 1 - Fitur Adding & Editing Contact)
Agar lebih terbayang, mari kita lihat bagaimana tim QA menjalankan fase STLC dalam 1 siklus Sprint berdurasi 2 minggu yang berfokus pada 2 fitur utama: Adding Contact dan Editing Contact. Perencanaan pengujian hanya berfokus pada Sprint ini, dan akan disesuaikan kembali pada Sprint berikutnya sesuai kebutuhan fitur baru:
- 1. Test Planning (Hari 1-2): QA Lead menganalisis kebutuhan fitur Adding Contact & Editing Contact khusus untuk Sprint 1 (2 minggu). Dibuat strategi pengujian yang berfokus pada Sprint ini, menentukan target waktu, serta alat uji (Jira untuk bug tracking dan Playwright / Postman untuk otomatisasi). (Hasil: Test Plan khusus Sprint 1 disetujui).
- 2. Test Analysis (Hari 2-3): Tim QA membedah alur Tambah dan Edit Kontak untuk mencari skenario kritis dan batas (edge cases): "Bagaimana jika membuat kontak tanpa mengisi nama?", "Bagaimana jika nomor telepon diisi huruf?", atau "Bagaimana jika koneksi terputus saat menyimpan perubahan edit?". (Hasil: Daftar skenario & kondisi uji Sprint 1).
- 3. Test Design & Implementation (Hari 3-5): QA menyusun Test Cases positif & negatif untuk kedua fitur (misal: penambahan kontak berhasil, validasi format email/HP, dan pembatalan edit kontak). Di saat bersamaan, QA Engineer mulai menyiapkan skrip otomatisasi Page Object Model di Playwright. (Hasil: Test Case & Skrip Otomatisasi Siap).
- 4. Test Execution (Hari 6-9): Setelah developer merilis fitur Tambah & Edit Kontak di server staging, QA menjalankan pengujian manual dan otomatisasi. Ditemukan bug: "Field nomor telepon pada fitur Edit Contact tidak memvalidasi batas jumlah karakter". QA langsung mencatat tiket laporan bug di Jira. (Hasil: Laporan Bug di Jira & Hasil Eksekusi Uji).
- 5. Test Completion (Hari 10): Developer memperbaiki bug dan QA melakukan re-testing serta regresi singkat. QA menutup Sprint 1 dengan memberikan laporan kelayakan (Sprint Test Summary) bahwa fitur Tambah & Edit Kontak sudah stabil dan siap dirilis sebelum lanjut ke Sprint berikutnya. (Hasil: Rapor Kelayakan Sprint 1).
4. Perbandingan Gaya Pengujian: Waterfall vs Agile
Penerapan STLC sangat bergantung pada cara kerja tim. Berikut adalah perbandingan langsung antara pengujian di gaya tradisional (Waterfall) dan modern (Agile):
| Perbedaan | Gaya Lama (Waterfall STLC) | Gaya Modern (Agile STLC) |
|---|---|---|
| Kapan QA Mulai Bekerja? | Mulai di akhir, menunggu semua kode selesai ditulis oleh programmer. | Mulai sejak Hari Pertama, ikut rapat dan memeriksa desain sebelum dikerjakan. |
| Siklus Pengecekan | Dicek sekaligus dalam skala besar menjelang akhir proyek. Sangat memakan waktu. | Dicek terus-menerus dalam siklus pendek (biasanya setiap 2 minggu). |
| Robot Otomatisasi | Seringkali dilakukan secara manual di akhir. Robot otomatisasi baru dibuat belakangan. | Skrip otomatisasi dibuat berbarengan dengan aplikasi, langsung berjalan otomatis tiap ada kode baru. |
| Penanganan Bug (Cacat) | Bug ditemukan terlambat. Biaya memperbaikinya sangat mahal dan bikin jadwal peluncuran molor. | Bug ditemukan dan langsung diperbaiki di minggu yang sama (Timbal balik instan). |
5. Mengetes Sejak Dini (Shift-Left Testing)
Kesalahan terbesar dan termahal dalam pembuatan aplikasi adalah: baru melibatkan QA saat aplikasinya sudah jadi. Dalam pendekatan yang benar, QA sudah bekerja sejak awal (Shift-Left). QA ikut membaca dokumen persyaratan dari klien untuk mencari aturan yang membingungkan atau berisiko, jauh sebelum programmer menulis baris kode pertamanya. Prinsip utamanya adalah Mencegah penyakit lebih baik daripada mengobati (Defect Prevention).
6. Keuntungan Bekerja Secara Berdampingan
Dalam metode kerja Agile yang serba cepat, kerja sama antara pembuat (SDLC) dan penguji (STLC) terlihat seperti ini:
- Perencanaan Bersama (Test Planning): Dibuat bersamaan dengan rapat awal desain fitur. Tim QA membantu menentukan batas pekerjaan agar target pengujian masuk akal.
- Persiapan Sambil Menunggu (Test Design): Disusun saat developer sedang mengetik kode. QA langsung membuat panduan skenario dan menyiapkan alat pengujian otomatisnya.
- Saling Lempar Bola (Test Execution): Berjalan aktif begitu aplikasi siap. Jika QA menemukan kendala, langsung dilaporkan dan diverifikasi ulang di hari atau minggu yang sama.
Kesimpulan
Memahami dan menyelaraskan kerja antara pembuat (SDLC) dan penguji (STLC) ibarat membangun rumah dengan pengawas yang mengecek setiap lapisan semen, bukan menunggu rumahnya jadi baru diperiksa. Cara disiplin ini terbukti menghemat biaya perbaikan kerusakan hingga 70%, mempercepat peluncuran produk, dan menjamin aplikasi stabil (Enterprise-grade quality).