Dokumen Fundamental dalam Software Quality Assurance (QA)

1. Test Plan (Rencana Pengujian)

Ini adalah dokumen “induk” yang menentukan strategi pengujian secara keseluruhan. Anggap saja ini sebagai peta jalan (roadmap).

• Objective (Tujuan): Apa yang ingin dicapai dari pengujian ini?
• Scope (Ruang Lingkup): Fitur apa saja yang akan diuji dan mana yang tidak perlu diuji.
• Resources (Sumber Daya): Siapa pengujinya (tim) dan alat (tools) apa yang digunakan.
• Schedule (Jadwal): Kapan pengujian dimulai dan kapan harus selesai.
• Risks (Risiko): Potensi masalah yang mungkin menghambat pengujian dan bagaimana cara mengatasinya.

Contoh :

Proyek: Aplikasi Mobile Bank XYZ

• Objective: Memastikan fitur login aman dan dapat diakses oleh nasabah terdaftar.
• Scope: Login menggunakan Username/Password, Reset Password, dan Biometric Login. (Tidak termasuk pendaftaran akun baru).
• Resources: 2 QA Tester, Perangkat Android & iOS, Alat otomasi Selenium.
• Schedule: 15 April 2026–20 April 2026.
• Risks: Server sering maintenance di jam kerja yang dapat menghambat akses database testing.

2. Test Case (Kasus Uji)

Dokumen ini berisi rincian spesifik tentang cara menguji suatu fitur tertentu secara langkah demi langkah.

• Test Case ID: Identitas unik untuk setiap skenario uji.
• Precondition (Prasyarat): Kondisi yang harus dipenuhi sebelum pengujian dimulai (misalnya: user harus sudah login).
• Test Steps (Langkah Pengujian): Instruksi urutan tindakan yang harus dilakukan penguji.
• Status: Hasil akhir pengujian, biasanya diisi dengan Pass (Berhasil), Fail (Gagal), atau Blocked (Tersumbat).

Contoh :

Test Case ID: TC-LOG-01

Judul: Login dengan Kredensial Valid

Selain Pass (OK) dan Fail (Not OK), berikut adalah daftar status yang lebih profesional:

• Not Run (Belum Dijalankan): Status default saat Test Case baru dibuat. Artinya, penguji belum menyentuh skenario ini sama sekali.
• In Progress (Sedang Berjalan): Digunakan saat penguji sedang melakukan langkah-langkah di dalam Test Case tersebut namun belum selesai.
• Passed (OK): Langkah-langkah berhasil dilakukan dan hasil aktual sesuai dengan hasil yang diharapkan.
• Failed (Not OK): Ditemukan ketidaksesuaian antara sistem dengan dokumen. Biasanya status ini akan diikuti dengan pembuatan Bug Report.
• Blocked (Terhambat): Pengujian tidak bisa dilakukan karena ada masalah lain yang menghalangi. Contoh: Kamu tidak bisa tes “Transfer Uang” karena fitur “Login” sedang rusak total. Jadi fitur transfer statusnya Blocked.
• Skipped / Not Applicable (N/A): Skenario yang diputuskan untuk tidak dijalankan karena alasan tertentu (misalnya fitur tersebut dihapus dari update kali ini).

Dalam dunia QA profesional, menghapus test case secara permanen sering kali dihindari. Berikut adalah beberapa alasan utama mengapa status Skipped atau N/A lebih dipilih daripada menghapus:

1. Histori dan Audit (Jejak Rekam)

Dokumen QA adalah bukti bahwa kita telah meninjau seluruh kebutuhan. Jika sebuah fitur awalnya direncanakan (ada di Requirement) tapi kemudian dibatalkan, status N/A menunjukkan bahwa tim QA sadar akan perubahan tersebut. Jika dihapus: Nanti saat audit, orang akan bertanya, “Lho, fitur X yang diminta klien mana tesnya?” Jika tidak ada jejaknya, QA bisa dianggap lalai atau lupa membuat tes tersebut.

2. Efisiensi Jika Fitur Kembali Lagi

Dalam pengembangan perangkat lunak, fitur sering kali “ditunda” daripada benar-benar dibuang selamanya. Misal: Fitur “Bayar pakai Crypto” dihapus dari update bulan ini karena masalah regulasi, tapi mungkin akan diluncurkan 3 bulan lagi. Jika kita hanya memberi status Skipped, kita tidak perlu menulis ulang langkah-langkah pengujian yang rumit di masa depan. Cukup aktifkan kembali.

3. Integritas Nomor Test Case (ID)

Test Case biasanya memiliki ID yang berurutan (misal: TC-01, TC-02, TC-03). Jika kamu menghapus TC-02, maka urutannya akan loncat dari 01 langsung ke 03. Ini bisa membingungkan dalam laporan perkembangan (progress report) dan merusak referensi di dokumen lain (seperti di Traceability Matrix).

4. Analisis Cakupan (Coverage Analysis)

Status N/A membantu manajer memahami kenapa persentase pengujian tidak mencapai 100%. Contoh: Total ada 100 test case. 90 Passed, 10 Skipped. Laporan ini lebih jelas daripada hanya menulis “90 Passed” tanpa penjelasan ke mana perginya 10 tes lainnya. Status Skipped menjelaskan bahwa 10 tes itu memang sengaja tidak dijalankan, bukan karena tim QA malas atau kehabisan waktu.

Tentu saja ada saatnya kita boleh menghapus test case:

1. Duplikat: Jika ada dua skenario yang isinya sama persis.
2. Salah Tulis: Jika ada kesalahan logika yang fatal saat pembuatan awal.
3. Perubahan Arsitektur Total: Jika aplikasinya berubah total (misal dari Aplikasi Desktop jadi Web) sehingga semua langkah lama sudah tidak relevan sama sekali.

3. Traceability matrix (Matriks Penelusuran)

Sering disebut juga Requirement Traceability Matrix (RTM). Fungsinya adalah untuk memastikan semua kebutuhan klien sudah ada tesnya.

• Requirement ID & Description: Mencatat apa saja fitur atau kebutuhan yang diminta oleh klien/produk.
• Test Case ID: Menghubungkan setiap kebutuhan tersebut ke nomor Test Case yang relevan.
• Tujuan Utama: Menghindari ada fitur yang terlewat untuk diuji (memastikan full coverage).

Berikut adalah beberapa status cakupan lain yang umum digunakan:

1. Partial (Tercakup Sebagian)

Status ini digunakan jika satu kebutuhan (Requirement) memiliki banyak skenario, namun baru sebagian saja yang dibuatkan Test Case-nya. Contoh: Kebutuhan fitur “Pembayaran” mencakup Kartu Kredit, Transfer Bank, dan E-Wallet. Jika baru ada Test Case untuk Kartu Kredit, maka statusnya Partial.

2. Not Covered (Belum Tercakup)

Artinya kebutuhan tersebut sudah ada di daftar, tetapi belum ada satu pun Test Case yang dibuat untuk mengujinya. Risiko: Ini adalah “bendera merah” (peringatan). Jika rilis sudah dekat dan masih ada status Not Covered, berarti ada fitur yang terancam tidak teruji.

3. Descoped (Dihapus dari Lingkup)

Hampir mirip dengan Out of Scope, tapi biasanya digunakan untuk fitur yang awalnya direncanakan masuk, namun di tengah jalan dibatalkan. Alih-alih menghapus barisnya dari dokumen (agar tetap ada histori), statusnya diubah menjadi Descoped.

4. Bug Report (Laporan Bug)

Dokumen ini dibuat ketika penguji menemukan kesalahan atau cacat (defect) pada aplikasi saat menjalankan Test Case.

• Bug ID & Summary: Identitas bug dan ringkasan singkat tentang apa yang salah.
• Severity (Tingkat Keparahan): Seberapa besar dampak bug terhadap sistem (misal: Critical jika aplikasi crash).
• Priority (Prioritas): Seberapa cepat bug tersebut harus diperbaiki.
• Steps to Reproduce: Langkah-langkah detail agar pengembang (developer) bisa memunculkan kembali error tersebut untuk diperbaiki.
• Actual vs Expected Result: Perbandingan antara apa yang terjadi saat ini (salah) dengan apa yang seharusnya terjadi (benar).

Contoh :

Dibuat karena TC-LOG-01 di atas berstatus Fail.

• Bug ID: BUG-001
• Summary: Tombol Login tidak merespon meskipun data yang dimasukkan benar.
• Severity: High (Fitur utama tidak bisa digunakan).
• Priority: P1 (Harus segera diperbaiki agar tim bisa lanjut tes fitur lain).
• Steps to Reproduce:

1. Buka aplikasi.
2. Input username & password yang benar.
3. Klik tombol ‘Login’ berkali-kali.

• Actual Result: Tombol berubah warna saat diklik, tapi tetap berada di halaman login (tidak pindah ke dashboard).
• Expected Result: Pengguna diarahkan ke halaman Dashboard Saldo dalam waktu kurang dari 3 detik.

Severity (Tingkat Keparahan)

Dilihat dari sisi teknis. Seberapa besar bug ini merusak fungsi sistem?

• S1 — Critical (Kritis): Bug yang menyebabkan sistem lumpuh total (crash), data hilang, atau fungsi utama tidak bisa diakses sama sekali.
• Contoh: Aplikasi langsung tertutup (force close) saat baru dibuka.
• S2 — Major (Besar): Fungsi utama bermasalah besar, tapi sistem masih bisa berjalan. Tidak ada jalan pintas (workaround) yang masuk akal.
• Contoh: Tombol “Bayar” tidak berfungsi, sehingga transaksi tidak bisa selesai.
• S3 — Minor / Moderate (Sedang): Bug yang mengganggu fungsi tetapi ada jalan pintasnya, atau terjadi pada fitur yang tidak terlalu krusial.
• Contoh: Fitur filter pencarian tidak akurat, tapi hasil pencarian tetap muncul.
• S4 — Low / Cosmetic (Rendah): Masalah visual yang tidak memengaruhi fungsi sama sekali.
• Contoh: Salah ketik (typo), warna tombol sedikit meleset, atau gambar yang pecah.

Priority (Prioritas Perbaikan)

Dilihat dari sisi bisnis. Seberapa cepat bug ini harus diperbaiki oleh developer?

• P1 — Urgent / Immediate (Segera): Harus diperbaiki saat ini juga. Biasanya untuk bug yang menghambat tim QA lain bekerja atau bug di sistem live.
• P2 — High (Tinggi): Harus diperbaiki sebelum rilis dilakukan atau dalam sprint berjalan.
• P3 — Medium (Sedang): Bisa menunggu setelah bug prioritas tinggi selesai. Biasanya untuk fitur yang tidak terlalu sering dipakai user.
• P4 — Low (Rendah): Perbaikan bisa dilakukan kapan saja jika ada waktu luang (sering kali ditunda ke rilis berikutnya).

Mengapa Harus Dipisah? (Contoh Kasus Ekstrim)

Penting untuk dipahami bahwa bug dengan Severity tinggi belum tentu Priority tinggi, dan sebaliknya.

1. Severity Tinggi, Priority Rendah:

• Kasus: Aplikasi crash total jika user mencoba mengganti bahasa ke Bahasa Latin kuno (fitur yang sangat jarang dipakai).
• Alasan: Secara teknis parah (crash), tapi secara bisnis tidak mendesak karena hampir tidak ada user yang akan terkena.

1. Severity Rendah, Priority Tinggi:

• Kasus: Logo perusahaan di halaman depan salah atau nama bank salah ketik menjadi “Bank Malas” alih-alih “Bank Maju”.
• Alasan: Secara teknis hanya masalah teks (cosmetic), tapi secara bisnis memalukan dan merusak citra perusahaan, jadi harus segera diganti.

Biasanya dalam alat manajemen seperti Jira, kombinasi keduanya akan menentukan SLA (Service Level Agreement) atau batas waktu kapan bug tersebut harus sudah berstatus “Resolved”.

Berikut adalah gambaran bagaimana kombinasi tersebut menentukan batas waktu (SLA):

Apakah Dokumen ini Disimpan Pada File yang Sama?

secara fisik atau digital, keempat dokumen tersebut biasanya berada di file atau tempat yang berbeda karena fungsinya yang berbeda pula. Namun, mereka tetap saling terhubung.

1. File/Tempat Penyimpanan yang Berbeda

• Test Plan: Biasanya berupa dokumen teks panjang (Microsoft Word, Google Docs, atau Confluence Page). Isinya narasi dan tabel strategi. Karena jarang berubah setelah disetujui, ia disimpan sebagai dokumen referensi utama.
• Test Case & Traceability Matrix: Keduanya sering berada di dalam Microsoft Excel atau Google Sheets (biasanya beda tab). Namun, di perusahaan yang lebih mapan, keduanya dikelola di dalam Test Management Tool (seperti TestRail atau Zephyr).
• Bug Report: Dokumen ini biasanya berupa “tiket” digital di dalam Bug Tracking Tool (seperti JIRA, Trello, atau GitHub Issues).

2. Mengapa Dibedakan?

• Target Pembaca Berbeda: Test Plan dibaca oleh Manager/Stakeholder. Test Case dibaca oleh QA. Bug Report dibaca oleh Developer.
• Kecepatan Perubahan: Test Plan mungkin hanya dibuat sekali per proyek. Test Case diperbarui setiap kali ada fitur baru. Bug Report bisa dibuat puluhan kali dalam sehari.
• Kolaborasi: Developer tidak perlu melihat daftar Test Case yang berhasil, mereka hanya perlu daftar Bug Report yang gagal agar bisa langsung kerja.

3. Bagaimana Mereka Tetap “Nyambung”?

Meskipun filenya berbeda, mereka dihubungkan oleh ID atau Link:

• Di dalam Bug Report, kamu akan menaruh link atau ID dari Test Case yang gagal.
• Di dalam Test Case, kamu menaruh ID dari Requirement (Traceability Matrix).
• Di dalam Traceability Matrix, kamu mencatat semua ID Test Case yang sudah dibuat.

Jika tim masih menggunakan Excel, maka tantangan terbesarnya adalah sinkronisasi data dan kerapian. Dalam kondisi ini, kamu bisa menggabungkan Test Case dan Bug Report dalam satu file, namun tetap harus dipisahkan agar tidak berantakan.

Daripada membuat file yang berbeda-beda dan repot membukanya, sebaiknya gunakan satu file Excel dengan beberapa Sheet:

• Sheet 1: Test Plan (Berisi ringkasan strategi).
• Sheet 2: RTM (Daftar kebutuhan vs ID Test Case).
• Sheet 3: Test Execution (Daftar skenario dan hasil tes).
• Sheet 4: Defect Log / Bug Report (Daftar detail bug).

Darimana Referensi untuk Membuat setiap Dokumen?

Setiap dokumen QA tidak muncul begitu saja, melainkan ada “bahan baku” atau referensi utamanya.

1. Membuat Test Plan

• Yang Dilihat: SRS (Software Requirement Specification), PRD (Product Requirement Document), dan Project Plan.
• Kenapa? Karena di Test Plan kamu harus tahu deadline proyek (dari Project Plan) dan fitur besar apa saja yang mau dibuat (dari SRS/PRD) untuk menentukan berapa banyak tester dan alat yang dibutuhkan.

2. Membuat RTM (Requirements Traceability Matrix)

• Yang Dilihat: SRS atau Business Requirements.
• Kenapa? RTM dibuat sebelum atau berbarengan dengan Test Case. Kamu memindahkan semua poin kebutuhan dari SRS ke daftar RTM. Gunanya agar kamu punya “keranjang” untuk memastikan semua fitur nanti punya Test Case.

3. Membuat Test Case

• Yang Dilihat: Use Case, User Story, dan UI/UX Design (Figma).
• Kenapa? Use Case menjelaskan alur pengguna (misal: Jika klik A, maka muncul B). Ini adalah bahan utama untuk menulis langkah-langkah detail di Test Case. Kamu juga melihat desain (Figma) untuk memastikan tampilan yang diharapkan sudah sesuai.

4. Melakukan Test Execution (Menjalankan Tes)

• Yang Dilihat: Test Case dan Aplikasi/Sistem.
• Kenapa? Kamu menjalankan aplikasi sambil mencocokkannya dengan checklist di Test Case.

5. Membuat Bug Report

• Yang Dilihat: Hasil Temuan di Aplikasi vs Expected Result di Test Case.
• Kenapa? Bug Report muncul hanya jika ada perbedaan antara apa yang terjadi di aplikasi dengan apa yang kamu tulis di Test Case.

Visualisasi Alurnya (The Flow)

1. Analisis: Baca SRS → Tentukan strategi di Test Plan.
2. Pemetaan: Ambil daftar fitur dari SRS → Masukkan ke RTM.
3. Perancangan: Lihat Use Case & Design → Tulis langkah detail di Test Case.
4. Pelaksanaan: Jalankan Test Case di Aplikasi → Jika gagal, buat Bug Report.
5. Finalisasi: Update RTM (untuk memastikan semua fitur sudah berstatus Passed).

Kesimpulan

Penerapan empat dokumen fundamental , Test Plan, Test Case, Traceability Matrix, dan Bug Report, merupakan fondasi utama dalam menciptakan ekosistem pengujian perangkat lunak yang terstruktur, akuntabel, dan efisien. Melalui alur kerja yang disiplin, mulai dari perencanaan strategis hingga pelaporan defek yang mendetail, tim QA tidak hanya mampu menjaga kualitas produk agar sesuai dengan spesifikasi bisnis, tetapi juga memfasilitasi kolaborasi yang lebih baik dengan tim pengembang serta memastikan setiap kebutuhan pengguna telah teruji secara menyeluruh sebelum aplikasi diluncurkan ke pasar.