QA bukan hanya soal testing di akhir — ini tentang membangun budaya kualitas sejak baris kode pertama hingga software berjalan di tangan pengguna.
Detection (reaktif): Mencicipi roti di akhir proses dan membuang yang gosong. Boros, mahal, sudah terlambat.
Prevention (proaktif): Memastikan oven diatur suhunya dengan benar SEBELUM memanggang. Mengecek bahan baku SEBELUM digunakan. Melatih koki SEBELUM mulai bekerja. Hasilnya: hampir tidak ada roti yang gagal!
QA yang baik menggabungkan keduanya — tapi prioritas utama adalah prevention.
Mencegah defect sejak awal. Meliputi: review requirements, desain standar coding, pelatihan developer, audit proses, checklist kualitas di setiap fase. Biaya rendah, efek besar.
Menemukan defect yang sudah ada melalui testing, code review, dan inspeksi. Tetap diperlukan, tapi jangan jadikan satu-satunya strategi QA.
Ini adalah fakta paling penting dalam QA: menemukan bug di fase requirements 10x lebih murah dibanding di testing, 100x lebih murah dibanding di production.
📍 Titik QA ditempatkan di setiap fase:
💰 Biaya relatif memperbaiki bug:
Standar QA memberikan panduan yang sudah teruji oleh industri global. Anda tidak perlu "menemukan kembali roda" — ikuti standar yang sudah ada.
ISO 25000 = Buku panduan resep standar internasional (produk akhir harus memenuhi standar tertentu). CMMI = Sistem manajemen dapur yang menentukan bagaimana staf bekerja (proses yang matang). IEEE 730 = SOP tertulis yang harus diikuti setiap karyawan dapur (rencana QA yang terdokumentasi).
Menganalisis produk (kode, dokumen, desain) tanpa menjalankannya. Seperti proof-reading naskah buku sebelum dicetak — Anda bisa menemukan kesalahan hanya dengan membacanya.
Menganalisis produk dengan menjalankannya dan mengamati perilakunya. Seperti mencicipi masakan untuk mengecek rasanya — Anda harus "menjalankan" masakan tersebut melalui indera.
| Teknik | Deskripsi | Siapa yang Terlibat | Contoh Temuan |
|---|---|---|---|
| Code Review | Developer lain membaca kode untuk mencari bug, masalah desain, atau pelanggaran standar coding | Developer (peer review) | Variabel tidak diinisialisasi, logika if-else terbalik |
| Walkthrough | Penulis kode/dokumen "membacakan" hasil kerjanya kepada tim, sambil tim mengajukan pertanyaan | Tim kecil, informal | Requirements ambigu, skenario yang terlewat |
| Inspection (Fagan) | Review formal yang terstruktur dengan roles (moderator, author, reader, reviewer) dan proses yang terdefinisi | Tim formal, ada moderator | Defect serius, pelanggaran standar |
| Static Analysis | Tool otomatis menganalisis kode tanpa menjalankannya — mencari pola berbahaya, kerentanan, dan masalah kompleksitas | Otomatis + developer | SQL injection, null pointer, dead code, complexity tinggi |
Tools Static Analysis populer: SonarQube (multi-language), ESLint (JavaScript), Pylint (Python), FindBugs (Java), Checkmarx (security)
Menguji satu fungsi/method secara terisolasi. Seperti mengecek setiap baut mesin satu per satu sebelum merakit. Tools: pytest, JUnit, Jest.
Menguji interaksi antar modul/komponen. Seperti mengecek apakah baut-baut yang sudah diuji cocok satu sama lain ketika dipasang. Fokus: interface, data flow, API calls.
Menguji sistem secara keseluruhan terhadap requirements. Seperti test drive mobil setelah sepenuhnya dirakit. Mencakup functional & non-functional testing.
Pengguna/klien memvalidasi bahwa sistem memenuhi kebutuhan bisnis mereka. Seperti pemilik mobil menyetujui bahwa mobil yang dipesan sesuai spesifikasi. Final gate sebelum rilis.
Waktu dan sumber daya testing selalu terbatas. Tidak mungkin menguji semua hal dengan mendalam. Risk-Based Testing (RBT) menjawab: "Bagian mana yang paling penting untuk diuji terlebih dahulu?"
Dokter tidak memeriksa semua bagian tubuh Anda setiap hari — itu tidak mungkin. Mereka fokus pada bagian yang paling berisiko berdasarkan riwayat Anda: jantung lebih diprioritaskan untuk pasien hipertensi, gula darah untuk pasien diabetes. Risk-Based Testing bekerja sama: prioritaskan pengujian pada area risiko bisnis tertinggi.
Setiap fitur dinilai dari dua dimensi: Kemungkinan gagal (Likelihood) × Dampak jika gagal (Impact)
| Fitur | Likelihood Gagal | Impact Bisnis | Risk Level | Prioritas Testing |
|---|---|---|---|---|
| Transfer dana | Medium | Critical (uang hilang) | CRITICAL | 🔴 Uji pertama, paling menyeluruh |
| Autentikasi login | High | High (akses tidak sah) | CRITICAL | 🔴 Uji keamanan ekstensif |
| Riwayat transaksi | Low | Medium (ketidaknyamanan) | MEDIUM | 🟡 Uji standar |
| Ubah foto profil | Low | Low (tidak kritis) | LOW | 🟢 Uji minimal |
| Notifikasi push | Medium | Medium (informasi penting) | HIGH | 🟠 Uji menyeluruh |
Shift-left testing berarti memulai aktivitas QA sedini mungkin dalam SDLC — bahkan sebelum ada kode yang ditulis. Artinya testing tidak lagi hanya tanggung jawab tim QA di akhir, tapi menjadi tanggung jawab semua orang sejak awal.
Prinsip Shift-Left: "Test early, test often" — Semakin awal defect ditemukan, semakin murah dan mudah diperbaiki. Requirements yang ambigu sudah bisa "diuji" melalui review sebelum satu baris kode pun ditulis.
Tulis test terlebih dahulu, baru tulis kode. Red → Green → Refactor. Memaksa developer berpikir seperti QA sejak awal menulis kode.
Tulis skenario dalam bahasa alami (Gherkin: Given-When-Then) yang dapat dipahami oleh developer, QA, dan bisnis. Menghilangkan gap komunikasi.
Model waterfall tradisional: testing dilakukan di fase akhir, satu kali, oleh tim terpisah. Agile/DevOps merevolusi ini: testing adalah aktivitas berkelanjutan yang terintegrasi di setiap sprint dan pipeline CI/CD.
Waterfall QA = Pengrajin yang membuat seluruh produk lalu mengeceknya di akhir. Jika ada masalah di awal, semua pekerjaan mungkin perlu diulang.
Agile/DevOps QA = Pabrik modern dengan quality checkpoint di setiap stasiun produksi. Masalah langsung ditangkap dan diperbaiki sebelum berlanjut ke stasiun berikutnya.
Setiap tahap pipeline memiliki quality gate — jika tidak lolos, proses berhenti dan developer harus memperbaiki sebelum melanjutkan:
Tim engineering TokoKita menghadapi tantangan: setiap hari ada 3-5 release baru, 200+ developer, dan kesalahan kecil bisa berarti jutaan rupiah kerugian. Bagaimana strategi QA mereka?
Setiap PR wajib: code coverage ≥80%, zero critical SonarQube issues, semua unit test hijau, code review oleh 2 developer. Jika satu syarat tidak terpenuhi → otomatis ditolak.
Fitur payment selalu mendapat CRITICAL priority. Tim QA dedicated 40% waktunya hanya untuk payment flow. Fitur UI/UX minor mendapat LOW priority dan sering diserahkan ke automated visual testing.
QA engineer terlibat sejak story refinement untuk menulis acceptance criteria yang testable. Developer tidak bisa "done" tanpa test yang lulus.
Setiap rilis besar dilakukan bertahap: 1% traffic → 10% → 50% → 100%. Tim QA memantau error rate, latency, dan conversion rate di setiap tahap. Jika ada anomali → rollback otomatis.
Hasil: Escaped defect ratio turun dari 18% ke 3% dalam 6 bulan. Waktu deployment dari 2 minggu sekali menjadi 3× sehari. Customer complaints turun 60%.
Jelaskan mengapa "prevention" lebih baik dari "detection" dalam QA. Berikan contoh konkret dari sudut pandang pengembangan aplikasi mobile banking.
Apa perbedaan utama antara ISO 25000, CMMI, dan IEEE 730? Jika Anda memimpin startup software baru (5 developer), standar mana yang akan Anda terapkan pertama dan mengapa?
Buat matriks risiko untuk aplikasi sistem informasi akademik (SIAKAD) kampus. Identifikasi minimal 6 fitur, nilai likelihood dan impact-nya, tentukan risk level, dan prioritas testing.
Sebuah startup fintech baru saja mendapat pendanaan dan akan merilis aplikasi pinjaman online dalam 3 bulan. Rancang strategi QA komprehensif mereka — mencakup teknik statis, dinamis, risk-based testing, dan integrasi dalam pipeline CI/CD.
Bandingkan peran QA dalam model waterfall vs Agile. Apa tantangan terbesar mengimplementasikan QA dalam sprint Agile 2 mingguan? Bagaimana mengatasinya?
Prevention > Detection — Mencegah bug 10-1000× lebih murah daripada memperbaiki setelah rilis
ISO 25000 (produk) + CMMI (proses) + IEEE 730 (dokumentasi) = tiga pilar standar QA
Statis (review, static analysis) dilakukan tanpa menjalankan kode — temukan bug lebih awal
Risk-Based Testing = fokus effort terbesar pada area dengan risiko bisnis tertinggi
Shift-left = mulai testing dari requirements, bukan tunggu sampai ada kode
CI/CD pipeline = QA terotomasi berjalan setiap ada perubahan kode — quality gate di setiap tahap