Contoh Test Case: Format, Cara Membuat & Template QA

Dokumentasi pengujian sering dianggap pekerjaan administratif yang membosankan, padahal justru di situlah kualitas sebuah aplikasi ditentukan. Contoh test case yang baik membuat proses pengujian bisa diulang siapa pun, kapan pun, dengan hasil yang konsisten, tanpa bergantung pada ingatan satu orang tester. Tanpa dokumentasi terstruktur, pengujian berubah menjadi kegiatan coba-coba yang sulit diaudit dan mudah melewatkan bug penting. Pembahasan berikut menyajikan pengertian, format standar, langkah penyusunan, serta puluhan contoh nyata untuk fitur login, registrasi, e-commerce, mobile banking, hingga pengujian API dan basis data.

Apa Itu Test Case dalam Software Testing

Test case adalah dokumen terperinci berisi kondisi awal, input, langkah pengujian, dan hasil yang diharapkan untuk memverifikasi apakah sebuah fitur perangkat lunak bekerja sesuai spesifikasi.

Test case berfungsi sebagai panduan langkah demi langkah: apa yang diuji, bagaimana cara mengujinya, data apa yang digunakan, dan hasil seperti apa yang seharusnya muncul. Ketika hasil aktual berbeda dari hasil yang diharapkan, test case dinyatakan gagal dan temuan tersebut menjadi kandidat laporan bug.

Analogi yang sering dipakai praktisi Quality Assurance adalah resep masakan. Ada bahan (test data), ada tahapan memasak (test steps), dan ada gambaran hidangan akhir (expected result).

Dalam kerangka software testing modern, test case bukan sekadar daftar centang. Dokumen ini menjadi bukti bahwa sebuah persyaratan benar-benar telah divalidasi, sekaligus rujukan historis saat aplikasi berkembang.

Mengapa Test Case Penting bagi Tim QA

Beberapa alasan utama mengapa penulisan test case tidak boleh dilewati:

• Konsistensi hasil pengujian. Siapa pun anggota tim yang menjalankan pengujian akan mengikuti langkah identik, sehingga hasilnya tidak bergantung pada intuisi.
• Cakupan pengujian terukur. Test case memastikan skenario positif maupun negatif tercakup, termasuk kondisi batas yang sering luput.
• Efisiensi regression testing. Saat fitur baru ditambahkan, test case lama dijalankan ulang untuk memastikan fungsi lama tidak rusak.
• Dokumentasi hidup. Anggota tim baru dapat memahami perilaku sistem hanya dengan membaca kumpulan test case.
• Kepatuhan dan audit. Pada industri finansial dan kesehatan, dokumentasi pengujian menjadi bukti formal bahwa aplikasi sudah diverifikasi.
• Komunikasi lintas peran. Developer, product manager, dan business analyst dapat membaca dokumen yang sama tanpa salah tafsir.

Dokumen pengujian yang disusun rapi juga mempermudah pelacakan cacat. Ketika sebuah test case gagal, penyebabnya lebih mudah diisolasi karena setiap langkah sudah terdefinisi.

Perbedaan Test Case dan Test Scenario

Dua istilah ini kerap tertukar, padahal tingkat detailnya berbeda jauh. Test scenario menjawab pertanyaan "apa yang diuji", sedangkan test case menjawab "bagaimana cara mengujinya".

Test scenario adalah deskripsi tingkat tinggi tentang fungsi atau alur bisnis yang akan diuji, sedangkan test case adalah penjabaran rinci berisi langkah, data, dan hasil yang diharapkan dari skenario tersebut.

Satu test scenario umumnya melahirkan beberapa test case turunan. Contoh sederhananya, skenario "Validasi login pengguna" bisa dipecah menjadi test case login dengan kredensial benar, login dengan password salah, login dengan kolom kosong, hingga verifikasi masking karakter password.

Pemisahan ini bermanfaat pada tim agile. Test scenario dipakai saat backlog refinement untuk memperkirakan cakupan, sementara test case disusun menjelang fase eksekusi.

Contoh Hubungan Scenario dan Test Case

Ilustrasi berikut menunjukkan bagaimana satu skenario diturunkan menjadi beberapa kasus uji konkret.

Test Scenario: Verifikasi fungsi keranjang belanja.

Turunan test case-nya:

1. Menambahkan satu produk ke keranjang dari halaman detail produk.
2. Menambahkan produk yang sama dua kali dan memastikan jumlah bertambah, bukan baris baru.
3. Menghapus produk dari keranjang dan memverifikasi total harga terhitung ulang.
4. Mengubah kuantitas melebihi stok tersedia.
5. Membuka keranjang dalam kondisi kosong.

Setiap nomor di atas nantinya diberi ID unik, langkah rinci, dan hasil yang diharapkan.

Struktur dan Format Standar Test Case

Format test case bisa berbeda antarorganisasi, namun komponen intinya relatif seragam. Menggunakan format standar mengurangi pengujian ad hoc yang tidak terdokumentasi.

Komponen Wajib dalam Test Case

1. Test Case ID — pengenal unik yang mudah dicari, misalnya TC_LOGIN_001 atau PAY_TC_003. Sertakan nama modul agar penelusuran lebih cepat.
2. Modul atau Fitur — bagian aplikasi yang diuji, seperti Login, Checkout, atau Pencarian.
3. Judul atau Deskripsi — ringkasan spesifik tentang apa yang diverifikasi. "Verifikasi login berhasil dengan email dan password valid" lebih baik daripada "Cek login".
4. Prasyarat (Preconditions) — kondisi yang harus terpenuhi sebelum pengujian dijalankan, misalnya akun sudah terdaftar dan peramban sudah terbuka.
5. Test Steps — instruksi berurutan, satu aksi per langkah, menggunakan kata kerja jelas seperti buka, masukkan, klik, verifikasi.
6. Test Data — nilai input konkret, bukan placeholder samar seperti "data valid".
7. Expected Result — perilaku sistem yang seharusnya muncul, termasuk pesan atau perpindahan halaman.
8. Actual Result — diisi saat eksekusi, mencatat apa yang benar-benar terjadi.
9. Status — Pass, Fail, atau Blocked berdasarkan perbandingan hasil aktual dan ekspektasi.

Komponen Tambahan yang Sering Dipakai

Beberapa kolom opsional yang menambah nilai dokumentasi:

• Prioritas atau Severity — menentukan urutan eksekusi berdasarkan risiko bisnis.
• Requirement ID — kaitan ke user story atau acceptance criteria untuk keperluan traceability.
• Postcondition — kondisi sistem setelah pengujian selesai, misalnya waktu login tersimpan di basis data.
• Test Environment — spesifikasi peramban, sistem operasi, versi aplikasi, dan kondisi jaringan.
• Defect ID — tautan ke laporan bug bila status gagal.
• Designed By dan Executed By — nama penyusun dan pelaksana pengujian.
• Status otomatisasi — penanda apakah kasus uji sudah diotomatisasi atau masih manual.
• Lampiran — tangkapan layar, rekaman video, atau berkas log pendukung.

Menyertakan seluruh kolom tidak selalu bijak. Tim kecil lebih baik memakai enam sampai delapan kolom inti agar dokumentasi tetap terkelola.

Tabel Format Test Case Standar

Langkah Membuat Test Case untuk Pemula

Proses penyusunan test case dapat dipecah menjadi lima tahap yang berulang. Tahapan ini berlaku baik untuk aplikasi web, mobile, maupun sistem internal.

1. Pahami Requirement Terlebih Dahulu

Sebelum menulis satu baris pun, pelajari dokumen kebutuhan seperti SRS atau user story. Tester harus paham tujuan bisnis di balik fitur agar kasus uji tidak bertentangan dengan requirement yang disepakati.

Kaitkan setiap kasus uji dengan nomor requirement melalui Requirements Traceability Matrix. Praktik ini memudahkan analisis dampak ketika spesifikasi berubah.

2. Tentukan Tujuan dan Skenario Pengujian

Tetapkan secara jelas apa yang ingin dibuktikan. Tujuan yang tajam menghasilkan kasus uji yang relevan dan menghindari pengujian yang melebar tanpa arah.

Susun daftar skenario terlebih dahulu sebagai kerangka besar, baru turunkan menjadi kasus uji spesifik. Pendekatan ini menjaga struktur dokumen tetap rapi meski jumlah kasus uji membengkak.

3. Siapkan Data Uji dan Kondisi Awal

Data yang realistis membuat hasil pengujian mencerminkan kondisi produksi. Persiapkan tiga jenis data berikut:

• Data valid — input normal yang seharusnya diterima sistem.
• Data tidak valid — input yang dirancang memicu penolakan, misalnya email tanpa tanda @.
• Data batas — nilai tepat di ambang aturan, seperti password dengan panjang minimum 8 karakter.

Cantumkan pula prasyarat teknis: versi aplikasi, konfigurasi basis data, pengaturan jaringan, hingga perangkat yang digunakan.

4. Tulis Langkah Pengujian yang Jelas

Setiap langkah sebaiknya berisi satu aksi tunggal. Menggabungkan dua aksi dalam satu baris menyulitkan proses debugging saat terjadi kegagalan.

Bandingkan dua penulisan berikut:

• Kurang tepat: "Login ke aplikasi lalu buka profil."
• Lebih baik: "1) Buka halaman login. 2) Masukkan email [email protected]. 3) Masukkan password Pass123. 4) Klik tombol Masuk. 5) Klik ikon profil di pojok kanan atas."

Pemilihan bahasa juga penting karena pembaca dokumen bukan hanya sesama tester. Hindari jargon berlebihan tanpa penjelasan.

5. Definisikan Hasil yang Diharapkan Secara Spesifik

Hasil yang diharapkan menjadi tolok ukur keberhasilan. Pernyataan seperti "sistem berjalan normal" terlalu longgar dan membuka ruang tafsir.

Tuliskan perilaku konkret: pesan apa yang muncul, halaman mana yang terbuka, data apa yang berubah, dan elemen apa yang tampil atau hilang. Semakin sedikit ruang interpretasi, semakin konsisten hasil eksekusinya.

Contoh Test Case Login Sederhana

Fitur login adalah pintu masuk aplikasi sekaligus contoh paling umum dalam pembelajaran QA. Modul ini menyentuh aspek fungsional dan keamanan sekaligus.

Format Tabel Contoh Test Case Login

Contoh Test Case Login dengan Hak Akses

Aplikasi internal sering memiliki peran pengguna berbeda. Dokumen pengujian klasik untuk form login memasukkan kolom hak akses agar kombinasi kredensial teruji menyeluruh.

Pola tabel semacam ini memudahkan tim melihat kombinasi mana yang belum tercakup. Setiap baris berdiri sendiri sehingga kegagalan satu baris tidak menggugurkan baris lainnya.

Contoh Test Case Registrasi dan Validasi Formulir

Validasi form menjaga kebersihan data yang masuk ke basis data. Bug pada area ini sangat sering ditemukan saat pengujian manual.

Skenario Validasi Formulir Pendaftaran

• Kolom wajib. Mengosongkan kolom nama lalu menekan Daftar harus memunculkan pesan kesalahan berwarna kontras.
• Format email. Input test.com tanpa tanda @ harus ditolak dengan pesan "Masukkan alamat email yang valid".
• Batas karakter. Mengetik 60 karakter pada kolom nama depan berkapasitas 50 karakter harus terpotong atau ditolak.
• Kolom numerik. Memasukkan huruf pada kolom nomor telepon atau kode pos harus dicegah.
• Konfirmasi password. Password dan konfirmasi yang berbeda harus memunculkan peringatan sebelum data terkirim.
• Kekuatan password. Input 123456 harus ditolak jika kebijakan mewajibkan kombinasi huruf, angka, dan simbol.
• Email duplikat. Registrasi dengan email yang sudah terdaftar harus memunculkan pesan bahwa akun sudah ada.

Contoh Test Case Registrasi dalam Bentuk Naratif

Test Case ID: TC_REG_004 Modul: Registrasi Pengguna Judul: Verifikasi penolakan pendaftaran dengan email berformat salah Prasyarat: Halaman registrasi terbuka dan tidak ada sesi login aktif Test Data: Nama: Budi Santoso, Email: budi.santoso.mail, Password: Rahasia#2026 Langkah:

1. Buka halaman registrasi.
2. Isi kolom nama dengan Budi Santoso.
3. Isi kolom email dengan budi.santoso.mail.
4. Isi kolom password dengan Rahasia#2026.
5. Klik tombol Daftar.

Expected Result: Sistem menahan pengiriman formulir, menampilkan pesan validasi di bawah kolom email, dan tidak membuat data baru di basis data. Postcondition: Tidak ada akun baru yang tercatat.

Penulisan naratif seperti ini cocok untuk kasus kompleks yang sulit diringkas dalam satu baris tabel.

Contoh Test Case E-commerce dan Proses Checkout

Alur belanja daring melibatkan sesi, stok, harga, dan integrasi pembayaran. Karena itu kasus ujinya perlu mencakup perjalanan pelanggan secara utuh.

Pencarian dan Katalog Produk

Keranjang Belanja

1. TC_CART_01 — Menambahkan produk dari halaman detail membuat ikon keranjang menampilkan jumlah item yang benar.
2. TC_CART_02 — Menghapus item memicu perhitungan ulang total harga secara langsung.
3. TC_CART_03 — Keranjang kosong tidak mengizinkan proses checkout dilanjutkan.
4. TC_CART_04 — Kuantitas melebihi stok memunculkan peringatan ketersediaan.
5. TC_CART_05 — Isi keranjang tetap tersimpan setelah pengguna keluar dan masuk kembali.
6. TC_CART_06 — Kode voucher tidak valid ditolak tanpa mengubah total harga.

Checkout dan Pembayaran

Alur pembayaran menuntut ketelitian karena berkaitan langsung dengan uang pengguna.

Kasus uji "penagihan ganda" layak diberi prioritas tinggi karena dampaknya langsung terasa oleh konsumen.

Contoh Test Case Mobile Banking

Aplikasi perbankan menuntut standar dokumentasi lebih ketat. Soal technical test untuk posisi QA di sektor ini bahkan kerap meminta kandidat membuat test case manual untuk fitur tarik tunai tanpa kartu.

Tarik Tunai Tanpa Kartu

Test Scenario: Verifikasi fitur tarik tunai tanpa kartu pada aplikasi mobile banking.

Top-Up E-Wallet Melalui Mobile Banking

Skenario integrasi antar sistem lebih menantang karena melibatkan pihak ketiga. Pendekatan Gherkin membantu menjembatani komunikasi antara QA, developer, dan tim bisnis.

Scenario: Top-up e-wallet melalui mobile banking
  Given pengguna sudah login di aplikasi mobile banking
  When pengguna melakukan top-up ke akun e-wallet dengan nominal 100000
  Then sistem mengirim permintaan API ke penyedia e-wallet
  And aplikasi menampilkan notifikasi transaksi berhasil
  And saldo rekening berkurang sesuai nominal ditambah biaya admin

Sintaks Given, When, Then membuat perilaku sistem mudah dibaca pihak nonteknis. Format ini juga menjadi jembatan alami menuju otomatisasi berbasis Behavior Driven Development.

Contoh Test Case Aplikasi Mobile

Pengujian aplikasi mobile menghadapi tantangan yang tidak ada di web: fragmentasi perangkat, variasi versi sistem operasi, dan kondisi jaringan yang berubah-ubah.

Skenario Khas Perangkat Mobile

• Rotasi layar. Membuka aplikasi dalam mode potret, memutar ke lanskap, lalu kembali ke potret tanpa kehilangan data formulir.
• Perpindahan jaringan. Beralih dari Wi-Fi kuat ke data seluler lemah saat memuat konten harus memicu indikator loading dan penanganan error yang wajar.
• Mode luring. Membuka fitur yang membutuhkan koneksi tanpa jaringan harus menampilkan pesan informatif, bukan layar putih.
• Interupsi panggilan. Menerima telepon saat transaksi berlangsung tidak boleh menyebabkan aplikasi menutup paksa.
• Notifikasi push. Menekan notifikasi harus membuka halaman yang relevan, bukan sekadar beranda.
• Konsumsi memori. Penggunaan berulang selama beberapa jam tidak menunjukkan pertumbuhan memori terus-menerus.
• Izin perangkat. Menolak izin kamera harus menampilkan penjelasan, bukan menghentikan aplikasi.

Prinsip Repeatability Lintas Platform

Kasus uji yang baik menghasilkan kondisi hasil sama di seluruh platform yang diuji. Bila pada Android setelah login muncul halaman profil, hasil serupa harus muncul pada iOS kecuali spesifikasi menyatakan lain.

Perbedaan hasil antarplatform tanpa dasar spesifikasi merupakan indikasi cacat, bukan variasi yang bisa diabaikan.

Contoh Test Case API dan Basis Data

Pengujian lapisan belakang memerlukan format berbeda karena tidak ada antarmuka visual yang diamati.

Pengujian API

Waktu respons layak dicatat sebagai bagian dari hasil pengujian, terutama untuk endpoint yang sering diakses.

Pengujian Basis Data

1. Insert. Menjalankan perintah penyisipan data uji lalu memverifikasi seluruh nilai kolom sesuai input.
2. Constraint. Mencoba menyisipkan data duplikat pada kolom unik harus memicu penolakan dan rollback.
3. Update. Memperbarui satu baris tidak boleh memengaruhi baris lain.
4. Delete. Penghapusan data induk harus mengikuti aturan relasi yang ditetapkan.
5. Query gabungan. Menampilkan nama pelanggan, nama barang, harga satuan, alamat, kota, dan nomor telepon melalui perintah SELECT dengan relasi tabel yang benar.
6. Akses bersamaan. Dua transaksi simultan pada baris sama tidak menimbulkan data tidak konsisten.

Soal-soal seleksi QA di Indonesia kerap menggabungkan kemampuan menulis test case manual dengan kemampuan menyusun query SQL dasar. Penguasaan keduanya memberi nilai lebih pada proses rekrutmen.

Contoh Test Case Keamanan dan Performa

Aspek nonfungsional sering terlambat diuji padahal dampaknya besar.

Pengujian Keamanan

• Pencegahan SQL injection. Memasukkan string seperti admin'; DROP TABLE users;-- pada kolom username tidak boleh memengaruhi basis data.
• Perlindungan XSS. Menyisipkan tag skrip pada kolom komentar harus disanitasi sebelum ditampilkan ulang.
• Manajemen sesi. Sesi harus berakhir setelah periode tidak aktif tertentu dan token lama tidak dapat dipakai kembali.
• Kebijakan password. Password lemah ditolak saat registrasi maupun saat penggantian.
• Kontrol akses. Pengguna dengan peran terbatas tidak dapat mengakses URL khusus administrator melalui pengetikan alamat langsung.
• Transmisi data. Data sensitif dikirim melalui koneksi terenkripsi, bukan protokol polos.

Panduan dari OWASP dapat menjadi rujukan saat menyusun daftar kasus uji keamanan yang lebih lengkap.

Pengujian Performa

Teknik Desain Test Case untuk Cakupan Maksimal

Menulis kasus uji tanpa teknik desain berisiko menghasilkan ratusan dokumen dengan nilai deteksi rendah. Beberapa teknik berikut membantu memilih kasus uji paling efektif.

Equivalence Partitioning

Equivalence partitioning membagi rentang input menjadi kelompok yang diperkirakan menghasilkan perilaku sama, sehingga cukup satu perwakilan data per kelompok yang diuji.

Contohnya, kolom usia yang menerima nilai 18 sampai 60 memiliki tiga kelompok: di bawah 18, antara 18 dan 60, serta di atas 60. Menguji satu nilai dari tiap kelompok sudah mewakili perilaku sistem.

Boundary Value Analysis

Cacat paling sering muncul di batas rentang. Untuk kolom usia 18 sampai 60, nilai yang diuji adalah 17, 18, 19, 59, 60, dan 61.

Teknik ini menghemat waktu sekaligus meningkatkan peluang menemukan bug logika perbandingan.

Decision Table Testing

Cocok untuk aturan bisnis dengan banyak kombinasi kondisi. Diskon yang bergantung pada status keanggotaan, nilai transaksi, dan periode promo lebih mudah dipetakan dalam tabel keputusan daripada dijelaskan naratif.

State Transition Testing

Berguna pada fitur dengan status berurutan, misalnya pesanan yang berpindah dari dibuat, dibayar, dikirim, hingga selesai. Kasus uji dibuat untuk transisi sah maupun transisi terlarang.

Pengujian Positif dan Negatif

Skenario positif memverifikasi jalur ideal, sedangkan skenario negatif memastikan sistem menolak input keliru dengan anggun. Dokumen pengujian yang matang selalu memuat keduanya, lengkap dengan hasil yang diharapkan untuk masing-masing kondisi.

Tips Menulis Test Case yang Efektif

Kualitas dokumentasi menentukan seberapa berguna kasus uji tersebut enam bulan ke depan. Prinsip-prinsip berikut dipegang praktisi berpengalaman.

Sederhana dan Transparan

Langkah pelaksanaan harus jelas dan tidak ada yang terlewat. Bila prosesnya panjang, sebagian kondisi seperti login dapat dipindahkan ke bagian prasyarat agar langkah utama tetap ringkas.

Satu Kasus Uji, Satu Tujuan

Menguji beberapa hal sekaligus membuat identifikasi penyebab kegagalan menjadi sulit. Pisahkan login berhasil, login dengan password salah, dan login dengan email tidak terdaftar ke dalam kasus uji berbeda.

Berpikir sebagai Pengguna Akhir

Tester perlu menempatkan diri sebagai pengguna nyata yang tidak memahami arsitektur sistem. Kemudahan penggunaan ikut diuji, bukan sekadar kebenaran fungsional.

Jangan Berasumsi

Asumsi bahwa pembaca memahami maksud penulis adalah sumber inkonsistensi paling umum. Jika suatu langkah menyebut "masukkan data valid", definisikan data valid tersebut secara eksplisit.

Konsisten dalam Penamaan

Menggunakan istilah "Login" di satu tempat lalu "Sign In" di tempat lain menyulitkan pencarian. Konsistensi penamaan mempermudah pelacakan dan pemeliharaan jangka panjang.

Sertakan Bukti Eksekusi

Untuk kasus uji yang gagal, lampirkan tangkapan layar, rekaman, atau berkas log. Bukti ini mempercepat developer memahami penyebab kegagalan.

Pastikan Kasus Uji Independen

Setiap kasus uji sebaiknya dapat dijalankan sendiri tanpa bergantung pada hasil kasus uji lain. Ketergantungan berantai menyebabkan satu kegagalan menjatuhkan banyak pengujian sekaligus.

Bersihkan Lingkungan Setelah Pengujian

Kasus uji yang baik mengembalikan lingkungan pengujian ke kondisi semula. Data sampah yang menumpuk membuat pengujian berikutnya tidak dapat diandalkan.

Lakukan Peer Review

Meminta rekan meninjau dokumen membantu menemukan langkah ambigu atau redundan sejak awal. Sudut pandang baru sering menangkap celah yang luput dari penulis aslinya.

Perbarui Secara Berkala

Kasus uji usang lebih berbahaya daripada tidak memiliki kasus uji sama sekali, karena memberi rasa aman palsu. Tinjau ulang setiap kali fitur berubah atau bug baru ditemukan.

Kesalahan Umum dalam Membuat Test Case

Beberapa pola keliru berikut sering muncul, bahkan pada tim yang sudah berpengalaman.

Menghindari delapan pola di atas sudah cukup meningkatkan kualitas dokumentasi secara signifikan.

Template dan Alat Bantu Manajemen Test Case

Format dokumentasi memengaruhi kecepatan tim dalam menyusun, mengeksekusi, dan melaporkan hasil pengujian.

Pilihan Format Dokumentasi

Alat manajemen pengujian populer di kalangan praktisi mencakup TestRail dan Zephyr yang terintegrasi dengan alur kerja pelacakan isu. Pilihan berbasis spreadsheet tetap layak selama tim menjaga disiplin penamaan dan versi.

Kriteria Template yang Baik

Template yang membantu memiliki ciri berikut:

• Memandu proses pengujian dari awal hingga pelaporan.
• Memuat kolom penting tanpa memaksa pengisian data yang tidak relevan.
• Mudah disesuaikan dengan ukuran dan kebutuhan tim.
• Mendukung penyaringan dan pengurutan berdasarkan prioritas atau modul.
• Memungkinkan pelacakan status eksekusi secara ringkas.

Tim yang mengelola banyak produk sekaligus membutuhkan template lebih terstruktur dengan dukungan tampilan beragam. Sebaliknya, tim yang hanya menguji satu produk per tahun cukup memakai lembar kerja sederhana.

Matriks Ketertelusuran sebagai Pelengkap

Template pengujian sering dilengkapi matriks ketertelusuran berisi kolom persyaratan, ID kasus uji, status, pemblokir, kriteria keberhasilan, total tes selesai, tingkat kelulusan, dan pemberi persetujuan. Struktur ini memudahkan pemangku kepentingan menilai kesiapan rilis secara cepat.

Contoh Test Case dalam Format Gherkin

Pendekatan BDD menuliskan perilaku sistem dalam bahasa yang dekat dengan percakapan sehari-hari. Formatnya terdiri dari kondisi awal, aksi, dan hasil.

Feature: Autentikasi pengguna

  Scenario: Login berhasil dengan kredensial valid
    Given pengguna berada di halaman login
    When pengguna memasukkan email terdaftar dan password yang sesuai
    And pengguna menekan tombol Masuk
    Then sistem mengarahkan pengguna ke halaman dashboard

  Scenario: Login gagal karena password salah
    Given pengguna berada di halaman login
    When pengguna memasukkan email terdaftar dan password keliru
    And pengguna menekan tombol Masuk
    Then sistem menampilkan pesan kesalahan kredensial
    And pengguna tetap berada di halaman login

Keunggulan format ini terletak pada keterbacaannya bagi tim bisnis. Sintaksnya juga langsung dapat dijadikan dasar skrip otomatisasi menggunakan kerangka kerja seperti Cucumber.

Kekurangannya, penulisan Gherkin untuk kasus uji yang sangat teknis bisa terasa bertele-tele. Kombinasi tabel untuk kasus detail dan Gherkin untuk alur bisnis utama biasanya memberi keseimbangan terbaik.

Praktik Dokumentasi Pengujian yang Berkelanjutan

Dokumen pengujian bernilai selama tetap relevan dengan produk yang berjalan. Beberapa kebiasaan berikut menjaga nilainya dalam jangka panjang.

Gunakan Kontrol Versi

Simpan dokumen pada repositori atau alat yang mencatat riwayat perubahan. Kemampuan menelusuri versi lama membantu saat terjadi perdebatan mengenai perilaku sistem yang disepakati.

Kaitkan dengan User Story dan Bug ID

Setiap kasus uji sebaiknya menunjuk ke persyaratan asalnya. Bila ditemukan cacat, nomor laporan bug dilampirkan agar riwayat masalah terdokumentasi.

Kelompokkan Berdasarkan Fitur atau Alur

Pengelompokan logis memudahkan navigasi pada suite pengujian besar. Struktur berbasis modul juga mempermudah identifikasi celah cakupan.

Tandai Kandidat Otomatisasi

Kasus uji dengan langkah stabil, input terprediksi, dan hasil yang jelas merupakan kandidat kuat untuk diotomatisasi. Menandainya sejak awal mempercepat perencanaan otomatisasi.

Otomatisasi tidak menggantikan seluruh pengujian manual. Skenario eksploratif, penilaian pengalaman pengguna, dan verifikasi visual tetap membutuhkan penilaian manusia.

Ukur Efektivitas Suite Pengujian

Beberapa indikator yang layak dipantau:

• Persentase requirement yang tercakup kasus uji.
• Jumlah cacat yang ditemukan per siklus pengujian.
• Rasio kasus uji yang gagal karena bug nyata dibanding karena dokumen usang.
• Waktu rata-rata eksekusi satu siklus regresi.
• Proporsi kasus uji yang sudah diotomatisasi.

Angka-angka tersebut membantu tim memutuskan kapan dokumen perlu dirampingkan atau diperluas.

Pertanyaan yang Sering Muncul seputar Test Case

Kapan test case sebaiknya ditulis?

Penyusunan dimulai setelah requirement difinalisasi dan sebelum fase pengujian berjalan. Menulis lebih awal membantu menemukan ketidakjelasan spesifikasi sejak tahap perencanaan.

Berapa jumlah test case ideal untuk satu fitur?

Jumlahnya bergantung pada kompleksitas. Panduan praktis yang umum dipakai adalah tiga sampai lima kasus positif dan dua sampai tiga kasus negatif per fitur utama, ditambah kasus batas serta skenario integrasi.

Apakah test case wajib memakai alat khusus?

Tidak wajib. Spreadsheet masih memadai untuk tim kecil, meski alat manajemen pengujian memberi keuntungan berupa pelaporan, kolaborasi waktu nyata, dan ketertelusuran otomatis saat volume dokumen bertambah.

Bagaimana membedakan test case gagal karena bug atau karena dokumen keliru?

Periksa kembali langkah dan hasil yang diharapkan terhadap spesifikasi terbaru. Bila spesifikasi sudah berubah namun dokumen belum diperbarui, temuan tersebut merupakan dokumen usang, bukan cacat perangkat lunak.

Apakah satu test case boleh menguji beberapa hasil sekaligus?

Sebaiknya tidak. Pemisahan berdasarkan satu tujuan membuat kegagalan mudah diisolasi dan mempercepat proses perbaikan.

Apa peran test case dalam regression testing?

Kumpulan kasus uji lama dijalankan ulang setiap kali ada perubahan kode. Praktik ini memastikan fitur yang sebelumnya berfungsi tidak rusak akibat penambahan atau perbaikan baru.

Kesimpulan

Kekuatan sebuah contoh test case terletak pada kejelasannya, bukan pada panjangnya. Dokumen dengan ID unik, prasyarat yang tegas, langkah atomik, data konkret, dan hasil yang terukur akan menghasilkan eksekusi yang seragam siapa pun pelaksananya. Struktur semacam itulah yang membedakan pengujian terencana dari sekadar mencoba-coba fitur.

Rangkaian contoh pada modul login, registrasi, keranjang belanja, tarik tunai tanpa kartu, hingga validasi API menunjukkan satu pola yang konsisten: skenario positif saja tidak pernah cukup. Kombinasi input keliru, nilai batas, gangguan jaringan, dan percobaan akses tidak sah justru menjadi tempat cacat paling sering bersembunyi. Teknik desain seperti equivalence partitioning dan boundary value analysis membantu memilih kasus uji berdaya deteksi tinggi tanpa membengkakkan jumlah dokumen.

Nilai dokumentasi pengujian juga ditentukan oleh perawatannya. Penomoran yang konsisten, keterkaitan dengan user story, tinjauan berkala, serta penandaan kandidat otomatisasi menjaga suite pengujian tetap relevan saat produk terus berubah. Prinsip-prinsip pengujian mendasar yang dirangkum dalam glosarium ISTQB dapat menjadi rujukan bersama agar seluruh anggota tim memakai istilah yang sama.

Langkah paling masuk akal bagi tim yang baru memulai adalah memilih satu fitur berisiko tinggi, menyusun delapan hingga sepuluh kasus uji lengkap dengan skenario negatifnya, lalu menjalankannya sebagai pilot. Dari sana, template dapat disempurnakan sesuai kebutuhan nyata proyek, bukan sekadar meniru format orang lain.

Referensi

Software Testing Help. (2026). Test Case Template, Examples & Format.

Binar. (2026). Test Case & Test Scenario: Perbedaan, Contoh, Template.

Dibimbing. (2026). Panduan Lengkap Cara Membuat Test Case untuk Pemula.

Qaqna. (2026). Cara Menulis Test Case yang Efektif: Panduan Lengkap untuk QA Pemula hingga Profesional.

Scribd. (2026). Panduan Lengkap Test Case.

Guru99. (2026). Cara Menulis Kasus Uji dengan Contoh.

Anita Auliani. (2026). Day 9 — Test Case & Scenarios.

Scribd. (2026). Contoh Test Case dan Pengujian QA.

TestGrid. (2026). Test Case Template: Free Examples & Formats.

ClickUp. (2026). 10 Templat Kasus Uji yang Penting untuk Pengujian Perangkat Lunak dan Produk.

TestQuality. (2026). Sample Software Test Cases: 15+ Examples & Templates.