Sebagian besar kasus uji gagal sebelum berhasil mendeteksi satu bug pun. Kasus-kasus tersebut ditulis sebagai daftar periksa yang tidak jelas, tidak mencantumkan prasyarat, menggabungkan beberapa tindakan ke dalam satu langkah, atau mendeskripsikan hasil yang diharapkan dengan begitu longgar sehingga dua penguji yang membaca kasus yang sama akan berbeda pendapat mengenai arti dari “lulus”. Akibatnya: bug lolos, eksekusi pengujian tidak dapat direproduksi, dan jaminan kualitas (QA) justru menjadi hambatan alih-alih menjadi jaring pengaman.
Menulis kasus uji yang baik lebih berkaitan dengan desain verifikasi daripada sekadar keterampilan pengujian. Industri jasa keuangan menyebutnya sebagai proses "maker-checker". Komando nuklir menyebutnya sebagai "aturan dua orang". Prinsipnya sama: pekerjaan kritis tidak boleh bergantung pada satu tindakan yang tidak diverifikasi. Kasus uji yang ditulis dengan baik menanamkan ketelitian yang sama ke dalam perangkat lunak. Kasus uji tersebut memisahkan apa yang Anda harapkan dari apa yang Anda amati, sehingga kesenjangan antara keduanya menjadi tidak mungkin diabaikan.
Kami akan menunjukkan kepada Anda cara menulis kasus uji, mengapa hal ini penting, dan bagaimana meningkatkan kualitas kasus uji seiring berjalannya waktu.
TL;DR
Kasus uji mendefinisikan langkah-langkah yang tepat, input, dan hasil yang diharapkan yang diperlukan untuk memverifikasi bahwa suatu fitur berfungsi dengan benar. Setiap kasus uji memerlukan ID unik, prasyarat, dan hasil yang diharapkan yang ditulis dengan jelas agar hasilnya dapat diverifikasi. Panduan ini mencakup proses penulisan tujuh langkah, tiga contoh terperinci, dan cara menjaga keandalan rangkaian kasus uji seiring dengan perubahan produk.
Apa Itu Kasus Uji?
Kasus uji adalah dokumen terstruktur yang mendefinisikan langkah-langkah yang tepat, masukan, prasyarat, dan hasil yang diharapkan yang diperlukan untuk memverifikasi apakah suatu perangkat lunak tertentu berperilaku dengan benar. Ini bukanlah rencana pengujian (yang menguraikan strategi pengujian) atau skrip pengujian (kode otomatis yang menjalankan langkah-langkah tersebut secara terprogram). Kasus uji adalah spesifikasi yang menjadi dasar bagi kedua hal tersebut.
Contoh: Anda sedang menguji fungsi login pada sebuah aplikasi web. Kasus uji untuk fitur ini akan mendefinisikan elemen-elemen berikut:
- Tindakan yang menggambarkan langkah-langkah yang dilakukan pengguna dan respons sistem yang diharapkan
- Kondisi yang mendefinisikan aturan yang harus dipenuhi agar sistem dapat melanjutkan ke setiap langkah
- Masukkan data dengan nilai contoh untuk menguji berbagai hasil dan memverifikasi skenario keberhasilan maupun kegagalan
Perbandingan Kasus Uji Manual dan Otomatis
AI kini menjadi bagian dari sebagian besar alur kerja pengujian. Sebanyak 76,8% profesional pengujian menggunakan AI dalam jaminan kualitas (QA), dengan pembuatan kasus uji (69,6%) dan pemeliharaan skrip (59,6%) sebagai dua penggunaan yang paling umum, menurut Laporan Kondisi Pengujian 2026 dari PractiTest. Kasus uji otomatis adalah bidang di mana pergeseran tersebut paling terlihat, sehingga penting untuk mengetahui perbedaannya dengan kasus uji manual.
| Parameter | Kasus uji manual | Kasus uji otomatis |
|---|---|---|
| Pelaksanaan | Dilakukan oleh penguji manusia yang mengikuti serangkaian langkah yang terdokumentasi | Dilaksanakan oleh alat perangkat lunak, skrip, atau agen AI |
| Kecepatan | Prosesnya lambat dan memakan waktu, karena manusia harus memasukkan data dan memverifikasi hasil secara manual | Dapat menjalankan ratusan kasus uji secara bersamaan |
| Repeatabilitas | Rentan terhadap kesalahan manusia dan interpretasi langkah-langkah yang tidak konsisten | Skrip pengujian yang terawat dengan baik akan menghasilkan pengujian yang sangat dapat diulang dan konsisten |
| Integrasi CI/CD | Sulit diintegrasikan ke dalam alur kerja pengiriman yang bergerak cepat karena hambatan yang disebabkan oleh faktor manusia | Terintegrasi langsung ke dalam pipeline CI/CD untuk menjalankan pengujian pada setiap build |
| Pemeliharaan | Membutuhkan pembaruan dokumen secara manual setiap kali persyaratan berubah | Membutuhkan pemeliharaan teknis untuk memperbarui skrip ketika antarmuka pengguna (UI) atau logika berubah |
| Cocok untuk | Pengujian eksploratori | Pengujian berulang dan pengujian regresi |
Mengapa Kasus Uji yang Ditulis dengan Baik Penting
Anda dapat mendeteksi regresi sebelum pengguna mengajukan tiket. Setiap perubahan kode berisiko merusak sesuatu yang sudah berfungsi. Kasus uji yang ditulis dengan baik menjadi titik pemeriksaan tetap yang dijalankan setelah setiap deployment. Ketika seorang pengembang melakukan refactoring pada kode login Anda setahun kemudian dan secara tidak sengaja merusak penanganan sesi, kasus uji itulah yang akan mendeteksinya di lingkungan staging.
Anda menjadikan lulus/gagal sebagai fakta, bukan opini. Hasil yang diharapkan yang tidak jelas seperti “sistem merespons dengan tepat” memaksa setiap penguji untuk menafsirkan apa arti “tepat” itu. Dua penguji menjalankan kasus yang sama, satu menandainya lulus, yang lain menandai adanya cacat, dan kini tim sibuk memperbaiki ketidaksepakatan tersebut alih-alih memperbaiki perangkat lunak. Ketika hasil yang diharapkan berbunyi “sistem menampilkan pesan kesalahan: ‘Kata sandi tidak valid’ dan mempertahankan pengguna di halaman login,” tidak ada ruang untuk interpretasi. Hasilnya cocok atau tidak. Itulah penerapan aturan dua orang dalam praktik: kasus uji adalah pembuatnya, penguji adalah pemeriksanya, dan keduanya harus menggunakan bahasa yang sama.
Anda mengubah pengetahuan tak tertulis menjadi aset yang dapat digunakan kembali. Di sebagian besar tim, insinyur QA senior menyimpan peta tak terlihat mengenai setiap kasus tepi, setiap solusi alternatif, dan setiap “oh, pastikan Anda juga memeriksa X.” Ketika orang tersebut cuti atau pindah tim, peta tersebut ikut hilang bersamanya. Kasus uji yang terdokumentasi dengan prasyarat dan nilai batas yang jelas melestarikan pengetahuan tersebut secara terstruktur. Seorang penguji baru yang bergabung dengan tim dapat langsung mengambil TC_LOGIN_005 dan menguji alur "akun terkunci setelah lima kali percobaan" pada hari pertama, tanpa perlu bertanya kepada siapa pun mengenai ambang batasnya atau bagaimana timer tersebut diatur ulang.
Anda mengisolasi kegagalan ke langkah-langkah yang tepat, bukan area umum. Ketika sebuah kasus uji menggabungkan “buka halaman, masukkan kredensial, dan klik kirim” menjadi satu langkah dan pengujian gagal, yang Anda ketahui hanyalah “ada sesuatu yang rusak dalam alur login. ” Ketika setiap tindakan menjadi langkah tersendiri dengan hasil yang diharapkan masing-masing, kegagalan tersebut terjadi pada langkah ke-4: “Klik ‘Kirim Tautan Reset’ → seharusnya muncul pesan berhasil, tetapi muncul kesalahan 500. ” Ketepatan tersebut secara drastis memangkas waktu debugging karena pengembang tahu persis interaksi mana yang memicu cacat tersebut, bukan hanya area fitur mana yang harus dicari.
Anda dapat melihat apa yang telah tercakup dan apa yang menjadi titik buta. Tanpa kasus uji yang terstruktur, cakupan pengujian hanyalah tebakan belaka. Dengan kasus uji tersebut, Anda dapat memetakan setiap kasus kembali ke persyaratan dan langsung menemukan celah. Jika fitur reset kata sandi Anda memiliki enam skenario (reset berhasil, tautan kedaluwarsa, tautan yang digunakan kembali, email yang tidak terdaftar, format tidak valid, permintaan ganda) dan Anda hanya memiliki kasus uji untuk tiga skenario, celah tersebut menjadi terlihat dan dapat diukur. Visibilitas itulah yang mengubah pengujian dari sekadar “kami telah mengujinya” menjadi “inilah tepatnya yang telah kami uji, inilah yang belum kami uji, dan inilah risiko yang kami terima.”
Komponen Kasus Uji yang Baik
Kasus uji yang berguna tidak hanya sekadar mendeskripsikan apa yang akan diuji. Kasus uji tersebut juga mencakup konteks, langkah-langkah pelaksanaan, dan perilaku sistem yang diharapkan sehingga penguji lain, pengembang, atau manajer produk dapat mengulangi pengujian tersebut dan memverifikasi hasilnya.
Komponen-komponen dari sebuah kasus uji adalah:
- Pengidentifikasi unik
- Tujuan atau deskripsi
- Prasyarat
- Langkah-langkah pelaksanaan
- Hasil yang diharapkan
- Hasil aktual untuk perbandingan
Untuk contoh fungsi login situs web yang kami bagikan di atas, kasus uji Anda harus mencakup:
ID Kasus Uji: Setiap kasus uji memerlukan pengenal unik. Saat menguji suatu fitur, tim QA sering kali membuat beberapa kasus uji yang memvalidasi kondisi serupa. ID kasus uji membantu melacak, mengatur, dan merujuknya dengan mudah selama proses debugging atau pelaporan.
Contoh: TC_LOGIN_001
Deskripsi: Bagian ini menjelaskan fungsi apa yang diverifikasi oleh kasus uji tersebut. Bagian ini memberikan ringkasan singkat sehingga siapa pun yang membaca kasus uji tersebut dapat langsung memahami tujuannya.
Contoh: Pastikan bahwa pengguna terdaftar dapat berhasil masuk ke aplikasi menggunakan kredensial yang valid.
Prasyarat: Prasyarat menggambarkan kondisi sistem yang diperlukan sebelum menjalankan kasus uji. Tanpa prasyarat ini, penguji mungkin menjalankan tes yang sama dalam kondisi yang berbeda dan mendapatkan hasil yang tidak konsisten.
Contoh:
- Akun pengguna harus sudah ada di sistem
- Akun pengguna harus aktif dan tidak terkunci
- Halaman login harus dapat diakses
Langkah-langkah: Ini adalah tindakan yang dilakukan oleh pengguna atau penguji untuk menjalankan kasus uji. Setiap langkah harus jelas dan berurutan sehingga siapa pun di tim dapat mengulangi pengujian tersebut.
- Pengguna membuka halaman login
- Pengguna memasukkan alamat email yang terdaftar
- Pengguna memasukkan kata sandi yang benar
- Pengguna mengklik tombol Login
Hasil yang diharapkan: Ini mendefinisikan apa yang seharusnya dilakukan sistem jika fitur tersebut berfungsi dengan benar.
- Jika kredensialnya valid, sistem akan mengautentikasi pengguna
- Pengguna dialihkan ke dasbor
- Sesi pengguna berhasil dibuat
Jika kredensial tidak valid, sistem harus menampilkan pesan kesalahan yang sesuai.
Hasil aktual: Hasil ini mencatat pengamatan penguji setelah menjalankan kasus uji. Jika perilaku yang diamati berbeda dari hasil yang diharapkan, masalah tersebut dicatat sebagai cacat.
Contoh pengamatan:
- Sudah memasukkan kredensial yang valid, tetapi menerima pesan kesalahan “Kata sandi tidak valid”
Sekarang, mari kita terapkan keterampilan Anda dalam menulis kasus uji.
Tahukah Anda? Hanya 2,1% tim yang menggambarkan praktik pengujian AI mereka sebagai praktik yang telah dioptimalkan, sementara lebih dari 85% masih berada pada tahap awal atau tahap percobaan. Penggunaan yang paling umum adalah pembuatan kasus uji (69,6%), bukan pekerjaan strategis seperti identifikasi risiko (19,9%).
Cara Menulis Kasus Uji (Proses Langkah demi Langkah)
Menulis kasus uji memerlukan tujuh langkah: menganalisis persyaratan, membuat daftar skenario, merencanakan struktur, menulis langkah-langkah beserta hasil yang diharapkan, menyertakan konteks, meminta tinjauan, lalu menjalankan dan mencatat hasilnya.
Langkah 1: Analisis persyaratan
Sebelum menulis kasus uji, pahami terlebih dahulu apa yang seharusnya dilakukan oleh fitur tersebut. Di sinilah Anda meninjau dokumen-dokumen yang tersedia—PRD (dokumen persyaratan produk), user story, spesifikasi fitur, dan dokumen desain—serta mengidentifikasi setiap fungsi yang perlu diverifikasi.
Contoh: Anda sedang mengembangkan fitur yang memungkinkan pengguna mereset kata sandi mereka melalui email. Untuk membuat kasus uji terkait fitur ini, Anda perlu memahami:
- Masalah apa yang diselesaikan oleh fitur ini, misalnya, apakah pengguna dapat mengakses kembali akunnya jika lupa kata sandi?
- Tindakan apa saja yang dapat dilakukan pengguna, misalnya, meminta tautan reset, menerimanya melalui email, dan mengatur kata sandi baru?
- Apa yang seharusnya terjadi ketika tindakan-tindakan tersebut dilakukan, yaitu, apakah sistem mengirimkan tautan reset dan memungkinkan pengguna untuk memperbarui kata sandi mereka dengan sukses?
- Apakah ada batasan, misalnya, apakah tautan tersebut akan kedaluwarsa setelah waktu tertentu atau menjadi tidak valid setelah digunakan sekali?
- Apakah ada validasi atau aturan, misalnya, apakah kata sandi baru harus memenuhi persyaratan format atau panjang tertentu?
- Apakah ada fungsi yang tidak jelas atau tidak didefinisikan? Jika ya, mintalah klarifikasi dari pemangku kepentingan yang bersangkutan
Kejelasan ini memberi Anda landasan untuk merumuskan satu tujuan yang jelas bagi kasus uji Anda.
Tujuan: Memverifikasi bahwa pengguna terdaftar dapat berhasil mereset kata sandi mereka melalui email.
Langkah 2: Identifikasi berbagai skenario pengujian
Selanjutnya, buatlah daftar skenario pengujian yang perlu Anda validasi. Skenario pengujian adalah situasi tingkat tinggi—yang biasanya akan terbagi menjadi beberapa kasus uji yang mencakup masukan dan hasil yang berbeda-beda.
Untuk fitur reset kata sandi, skenario Anda mungkin terlihat seperti berikut:
- Reset berhasil: Pastikan bahwa pengguna terdaftar dapat meminta tautan reset dan mengatur kata sandi baru
- Email yang tidak terdaftar: Uji apa yang terjadi ketika sebuah email yang tidak ada dalam sistem dikirimkan
- Tautan kedaluwarsa: Pastikan sistem memblokir akses saat tautan reset diklik setelah masa berlakunya habis
- Tautan yang digunakan ulang: Uji apakah tautan reset yang sudah pernah digunakan tidak dapat digunakan lagi
- Kata sandi baru tidak valid: Pastikan kata sandi yang tidak memenuhi persyaratan format ditolak
- Permintaan reset berulang: Uji tautan mana yang tetap valid saat pengguna meminta beberapa tautan secara berturut-turut
Setiap skenario di sini akan diuraikan menjadi satu atau lebih kasus uji yang mencakup input dan kondisi tertentu. Dengan menguraikan fitur secara terperinci seperti ini, Anda memastikan cakupan pengujian mencakup baik perilaku yang diharapkan maupun kasus-kasus ekstrem yang pasti akan dihadapi oleh pengguna nyata.
Baca Selengkapnya: Cara Membuat dan Menerapkan Daftar Periksa Jaminan Kualitas
Langkah 3: Rencanakan pengujian dan tentukan struktur kasus uji
Untuk pengujian regresi yang berulang, Anda memerlukan struktur yang memungkinkan Anda mendokumentasikan kasus uji dan hasilnya secara konsisten. Template kasus uji yang terdefinisi dengan baik memberikan konsistensi tersebut dan memungkinkan penggunaan ulang tanpa harus memulai dari awal setiap kali.
Rencanakan pelaksanaan pengujian Anda dengan memperjelas unsur-unsur berikut ini:
Siapa yang akan melakukan pengujian?
Peran atau kualifikasi apa yang dibutuhkan oleh orang yang menjalankan pengujian ini? Tergantung pada kompleksitas pengujian dan tingkat intervensi manusia yang diperlukan, tetapkan peran sebagai berikut:
- Penguji QA: Pengujian fungsional dan regresi, seperti memverifikasi alur login, validasi formulir, atau proses checkout
- Tim Keamanan: Pengujian yang melibatkan kerentanan terkait otentikasi, kontrol akses, atau paparan data
- Pengembang: Pengujian unit untuk fungsi-fungsi individual seperti penghashing kata sandi atau pembuatan token
Bagaimana pengujian tersebut akan dilakukan?
- Perangkat dan sistem operasi apa saja yang akan digunakan untuk menjalankan pengujian ini?
- Alat atau kerangka kerja pengujian mana yang akan digunakan?
- Apakah pengujian akan dilakukan secara manual atau melalui agen AI?
- Bagaimana hasilnya akan dicatat—di alat manajemen pengujian, spreadsheet, atau pelacak bug?
Apa saja prasyaratnya?
Sebutkan setiap kondisi yang harus terpenuhi sebelum langkah 1, dan pastikan setiap kondisi tersebut dapat diverifikasi oleh penguji:
Contoh:
- Akun pengguna dengan alamat email “test@example.com” sudah ada
- Pengguna telah keluar dari sistem
- Layanan email aktif dan dapat mengirimkan pesan
- Lingkungan pengujian dapat diakses dan sedang berjalan
Data pengujian apa yang akan digunakan?
Tentukan nilai masukan yang tepat yang diperlukan untuk menjalankan pengujian—data valid, data tidak valid, dan nilai batas.
Contoh:
- Valid: alamat email terdaftar “test@example.com”, kata sandi yang memenuhi persyaratan format
- Tidak valid: alamat email belum terdaftar, kata sandi kurang dari batas karakter minimum
- Batas: kata sandi yang tepat sesuai batas karakter minimum dan maksimum
Langkah 4: Tulis langkah-langkah pengujian dan hasil yang diharapkan
Pecahlah proses eksekusi menjadi langkah-langkah berurutan. Gunakan terminologi yang konsisten dan pastikan setiap langkah hanya berisi satu tindakan. Saat mendefinisikan langkah-langkah, jelaskan juga hasil yang diharapkan serta kriteria apa yang menentukan lulus atau gagal.
Melanjutkan alur pengaturan ulang kata sandi, berikut adalah langkah-langkah pengujian yang akan dilakukan:
| Langkah-langkah | Hasil yang diharapkan |
| Buka halaman login | Halaman masuk dimuat dengan tautan “Lupa Kata Sandi” yang dapat diklik |
| Klik “Lupa Kata Sandi” | Pengguna dialihkan ke halaman permintaan reset kata sandi |
| Masukkan alamat email di kolom Email | Email diterima tanpa kesalahan validasi |
| Klik “Kirim Tautan Reset” | Pesan keberhasilan ditampilkan: “Tautan reset telah dikirim ke test@example.com” |
| Buka tautan reset dari email | Pengguna dialihkan ke halaman pembuatan kata sandi baru |
| Masukkan kata sandi baru yang valid | Kolom kata sandi menerima masukan tanpa kesalahan |
| Klik “Reset Password” | Pesan keberhasilan ditampilkan, dan pengguna dialihkan ke halaman login |
Sekarang, tentukan langkah-langkah dan hasil yang diharapkan untuk skenario alternatif (yang telah dibahas sebelumnya). Jelaskan apa yang terjadi jika pengguna memasukkan alamat email yang tidak valid atau kata sandi tidak sesuai dengan kriteria yang telah ditentukan sebelumnya.
Bonus: Berikut ini cara mengotomatiskan dokumentasi menggunakan AI untuk semua kasus uji Anda.
Langkah 5: Sertakan lampiran yang relevan
Sertakan dokumen atau lampiran yang relevan yang akan membantu penguji menjalankan kasus uji dengan konteks yang lengkap dan tanpa ambiguitas. Hal ini dapat mencakup:
- Tangkapan layar berlabel dari Antarmuka Pengguna pada langkah-langkah penting
- Rekaman layar yang menunjukkan cara menjalankan pengujian dalam berbagai skenario dan hasil apa yang diharapkan
- Log sistem atau berkas konfigurasi untuk membantu mendiagnosis masalah pada bagian backend ketika pengujian gagal
- Dokumen persyaratan yang menghubungkan kasus uji dengan cerita pengguna atau kriteria penerimaan yang diverifikasinya
- Berkas data pengujian yang berisi masukan yang valid dan tidak valid, atau data yang dihasilkan seperti nomor kartu kredit, alamat acak, atau kredensial pengguna
- Siapkan dokumentasi yang mencakup versi perangkat lunak tertentu, perangkat keras yang diperlukan, sistem operasi, dan izin keamanan yang diperlukan
- Untuk pengujian API, spesifikasi OpenAPI atau dokumentasi titik akhir yang merinci metode permintaan, parameter, dan kode status yang diharapkan
Langkah 6: Mintalah kasus uji tersebut ditinjau
Bagikan kasus uji yang telah ditulis kepada rekan kerja atau pimpinan QA senior sebelum menjalankannya. Selama proses tinjauan, pastikan bahwa:
- Kasus uji ini bersifat komprehensif dan mencakup semua skenario yang mungkin yang diturunkan dari persyaratan
- Langkah-langkahnya jelas dan secara berurutan menggambarkan alur eksekusi yang sebenarnya
- Setiap hasil yang diharapkan menyebutkan hasil yang dapat diamati (sebuah pesan, pengalihan, kode status), bukan kualitas seperti ‘berfungsi dengan benar’
- Data pengujian dan prasyarat sudah lengkap dan akurat
- Setiap asumsi yang dibuat selama penulisan didokumentasikan secara eksplisit
Langkah 7: Jalankan dan catat hasilnya
Lakukan pengujian dan catat hasil aktual dibandingkan dengan setiap hasil yang diharapkan. Tandai pengujian sebagai lulus atau gagal pada setiap langkah. Untuk setiap langkah yang gagal, laporkan bug segera dan tautkan kembali ke kasus uji tersebut. Selain itu, jika terjadi perilaku yang tidak terduga yang tidak jelas apakah lulus atau gagal, catat hal tersebut di kolom komentar untuk ditinjau lebih lanjut.
Baca Selengkapnya: Cara Menggunakan AI untuk Jaminan Kualitas
Contoh Penulisan Kasus Uji
Tiga contoh berikut ini menunjukkan bagaimana struktur kasus uji yang sama dapat disesuaikan dengan berbagai jenis pengujian perangkat lunak. Masing-masing contoh menggunakan komponen dan format langkah yang telah dijelaskan sebelumnya dalam panduan ini, namun tingkat kompleksitas, data uji, dan mode kegagalan akan bervariasi tergantung pada apa yang Anda verifikasi.
Contoh 1: Alur pembayaran e-commerce (UI, alur kerja multi-langkah)
Sebuah tim QA di sebuah toko online sedang menguji pengalaman checkout menjelang penjualan liburan. Alurnya mencakup beberapa halaman: keranjang belanja → pengiriman → pembayaran → konfirmasi. Tantangan utama di sini adalah ketergantungan status: setiap langkah bergantung pada penyelesaian langkah sebelumnya yang benar, dan data pengujian (isi keranjang belanja, alamat pengiriman, metode pembayaran) harus tetap terjaga di seluruh langkah tersebut.
Penguji: Rahul D.
Tanggal pengujian: 09/03/2026
ID Kasus Uji: TC_CHECKOUT_003
Deskripsi: Verifikasi bahwa pengguna yang sudah masuk dapat menyelesaikan pembelian menggunakan kartu kredit yang tersimpan dan pengiriman standar.
Persyaratan awal:
- Akun pengguna sudah ada dengan setidaknya satu kartu kredit yang tersimpan dan satu alamat pengiriman yang tersimpan
- Setidaknya ada satu barang yang tersedia dan telah ditambahkan ke keranjang belanja
- Lingkungan pengujian berjalan di Chrome 128, macOS
| Langkah | Hasil yang diharapkan | Hasil sebenarnya | Lulus/Gagal |
| Buka halaman keranjang belanja | Keranjang belanja menampilkan barang, jumlah, dan subtotal yang benar | Seperti yang diharapkan | Lulus |
| Klik “Lanjutkan ke Pembayaran” | Memuat halaman pengiriman dengan alamat yang disimpan sudah dipilih sebelumnya | Seperti yang diharapkan | Lulus |
| Pilih “Pengiriman Standar” dan klik Lanjutkan | Halaman pembayaran dimuat dengan menampilkan total pesanan termasuk biaya pengiriman | Seperti yang diharapkan | Lulus |
| Konfirmasikan detail kartu kredit yang telah disimpan, lalu klik “Lakukan Pemesanan” | Halaman konfirmasi pesanan ditampilkan dengan nomor pesanan, ringkasan barang, dan perkiraan tanggal pengiriman | Halaman pembayaran dimuat ulang dengan pesan kesalahan: “Tidak dapat memproses pembayaran” | Gagal |
Ringkasan hasil: Alur checkout menangani proses dari keranjang belanja ke pengiriman dengan benar, tetapi pemrosesan pembayaran gagal pada kartu kredit yang tersimpan. Masalah yang tercatat: pencarian kartu yang telah di-tokenisasi mengalami timeout ketika gateway pembayaran membutuhkan waktu lebih dari 3 detik untuk merespons.
Contoh 2: Titik akhir REST API (tanpa antarmuka pengguna, validasi masukan/keluaran)
Seorang insinyur backend sedang menguji titik akhir API “Create User” sebelum digunakan oleh tim front-end. Tidak ada antarmuka yang perlu diklik: kasus uji ini memvalidasi muatan permintaan, kode respons, dan penyimpanan data secara langsung. Tantangan utamanya adalah menguji kontrak antar sistem, bukan pengalaman pengguna.
Penguji: Sarah S.
Tanggal pengujian: 09/05/2026
ID Kasus Uji: TC_API_USER_001
Deskripsi: Pastikan bahwa permintaan POST ke /api/v1/users berhasil membuat pengguna baru dan mengembalikan respons yang benar.
Persyaratan Awal:
- Lingkungan pengujian API sedang berjalan dan dapat diakses
- Token otentikasi dengan izin admin telah dihasilkan dan masih berlaku
- Tidak ada pengguna dengan alamat email “newuser@testdomain.com” yang terdaftar dalam basis data
| Langkah | Hasil yang diharapkan | Hasil aktual | Lulus/Gagal |
| Kirim permintaan POST ke /api/v1/users dengan payload yang valid: { "name": "Test User", "email": "newuser@testdomain.com", "role": "viewer" } | Respons mengembalikan kode status 201 Created dengan isi JSON yang berisi ID pengguna, nama, email, dan peran | 201 dikembalikan dengan isi yang benar | Lulus |
| Kirimkan permintaan POST yang sama sekali lagi dengan alamat email yang sama | Respons mengembalikan kode 409 Conflict dengan pesan: “Pengguna dengan alamat email ini sudah ada” | 200 OK dikembalikan; pengguna duplikat telah dibuat | Gagal |
| Kirim POST dengan kolom “email” yang kosong | Respons mengembalikan kode status 400 Bad Request dengan kesalahan validasi: “Email wajib diisi” | 400 dikembalikan sesuai harapan | Lulus |
| Lakukan permintaan GET ke /api/v1/users/{id} menggunakan ID dari langkah 1 | Respons mengembalikan 200 OK dengan detail pengguna yang sesuai dengan payload asli | Seperti yang diharapkan | Lulus |
Ringkasan hasil: Endpoint ini berhasil membuat pengguna dengan benar dan memvalidasi kolom yang wajib diisi, tetapi gagal memastikan keunikan alamat email di tingkat basis data. Catatan ganda berhasil dibuat tanpa munculnya kesalahan. Cacat telah dicatat dengan tingkat keparahan: Tinggi.
Contoh 3: Kontrol akses berbasis peran (keamanan, batasan izin)
Sebuah tim keamanan sedang menguji apakah aplikasi membatasi tindakan dengan benar berdasarkan peran pengguna sebelum audit kepatuhan. Tantangan utamanya adalah Anda tidak menguji apakah suatu fitur berfungsi; Anda menguji apakah suatu fitur ditolak dengan benar. Hasil yang diharapkan untuk sebagian besar langkah adalah penolakan, bukan keberhasilan.
Penguji: Marcus L.
Tanggal pengujian: 09/08/2026
ID Kasus Uji: TC_RBAC_002
Deskripsi: Pastikan bahwa pengguna dengan peran “Viewer” tidak dapat membuat, mengedit, atau menghapus proyek.
Persyaratan Awal:
- Terdapat dua akun: satu dengan peran “Admin”, satu dengan peran “Viewer”
- Setidaknya ada satu proyek di ruang kerja, yang dibuat oleh Admin
- Pengguna sedang masuk di Firefox 130, Windows 11
| Langkah | Hasil yang diharapkan | Hasil sebenarnya | Lulus/Gagal |
| Buka halaman Proyek | Pengguna melihat daftar proyek dalam mode hanya baca; tombol “Buat Proyek” tersembunyi atau dinonaktifkan | Tombol terlihat tetapi berwarna abu-abu (tidak aktif) | Lulus |
| Cobalah mengklik “Buat Proyek” | Sistem mencegah tindakan; formulir proyek baru tidak dimuat | Tidak ada formulir yang dimuat; tooltip menampilkan “Anda tidak memiliki izin” | Lulus |
| Buka proyek yang sudah ada dan coba edit judulnya | Kolom judul tidak dapat diedit, atau sistem memblokir penyimpanan | Kolom judul dapat diedit; perubahan telah disimpan dengan sukses | Gagal |
| Coba hapus proyek melalui menu tiga titik | Opsi hapus tersembunyi, atau tindakan diblokir karena kesalahan izin | Opsi "Hapus" tidak terlihat di menu | Lulus |
Ringkasan hasil: Izin buat dan hapus telah dibatasi dengan benar untuk pengguna dengan peran Viewer, tetapi izin edit tidak diterapkan pada tingkat bidang. Seorang pengguna dengan peran Viewer dapat mengubah judul proyek meskipun hanya memiliki akses baca saja. Cacat telah dicatat dengan tingkat keparahan: Kritis (penghalang kepatuhan).
Alat apa saja yang paling baik untuk mengelola kasus uji?
Kasus pengujian dapat dikelola menggunakan alat QA khusus (TestRail, Zephyr), alat manajemen proyek umum (ClickUp, Jira), atau spreadsheet; pilihan yang tepat bergantung pada apakah Anda memerlukan fitur eksekusi bawaan atau hanya pelacakan.
ClickUp
ClickUp for Software Teams adalah platform manajemen proyek tempat kasus uji disimpan sebagai tugas bersama dengan sprint, bug, dan permintaan pull yang terkait dengannya. Ini bukanlah alat manajemen pengujian khusus, tetapi struktur tugasnya yang fleksibel memungkinkan tim membangun alur kerja kasus uji menggunakan status, bidang, dan jenis tugas kustom tanpa perlu alat terpisah.
Fitur utama ClickUp
- Hierarki yang fleksibel untuk mengatur kasus uji di seluruh Spaces, Folder, dan Daftar dengan bidang kustom untuk jenis pengujian, prioritas, dan lingkungan
- 15+ Tampilan ClickUp (Papan, Daftar, Tabel) untuk melacak pelaksanaan pengujian berdasarkan status, penanggung jawab, atau sprint
- Dokumen untuk menyimpan PRD, rencana pengujian, dan panduan pengaturan lingkungan di samping kasus uji yang didasarkan padanya
- Fitur obrolan bawaan untuk komunikasi antara tim QA dan pengembang tanpa perlu beralih ke Slack atau email
- Ringkasan tugas yang didukung AI melalui ClickUp Brain untuk konteks cepat selama tinjauan sprint
Batasan ClickUp
- Tidak ada mesin eksekusi pengujian bawaan
- Laporan khusus pengujian (cakupan berdasarkan persyaratan, tingkat kelulusan per siklus) memerlukan dasbor khusus, bukan laporan jaminan kualitas yang sudah tersedia secara default
Harga ClickUp
Peringkat dan ulasan ClickUp
- G2: 4,6/5 (lebih dari 14.100 ulasan)
- Capterra: 4,6/5 (lebih dari 4.600 ulasan)
Apa yang dikatakan pengguna nyata tentang ClickUp?
Inilah yang dikatakan oleh seorang pengulas G2:
Hal yang paling saya sukai dari ClickUp adalah kemampuannya untuk menyatukan semuanya dalam satu tempat. Tugas, jadwal, catatan, dan pembaruan semuanya berada dalam sistem yang sama, sehingga mengurangi bolak-balik antar alat. Saya juga menghargai fleksibilitasnya. Kami dapat menyesuaikan status, kolom, dan tampilan agar sesuai dengan cara kerja tim kami yang sebenarnya. Hal ini memudahkan kami untuk tetap terorganisir dan memberikan visibilitas yang jelas mengenai siapa yang bertanggung jawab atas apa serta status proyek pada waktu tertentu.
Hal yang paling saya sukai dari ClickUp adalah kemampuannya untuk menyatukan semuanya dalam satu tempat. Tugas, jadwal, catatan, dan pembaruan semuanya tersimpan dalam sistem yang sama, sehingga mengurangi bolak-balik antar alat. Saya juga menghargai fleksibilitasnya. Kami dapat menyesuaikan status, kolom, dan tampilan agar sesuai dengan cara kerja tim kami. Hal ini memudahkan kami untuk tetap terorganisir dan memberikan gambaran yang jelas mengenai siapa yang bertanggung jawab atas apa serta di mana posisi proyek pada waktu tertentu.
Cocok untuk: Seorang pemimpin tim QA yang ingin agar pengujian yang gagal dapat langsung diubah menjadi tiket bug bagi pengembang hanya dengan satu klik, dengan PR, langkah-langkah pengujian, dan sprint semuanya terlihat dari tugas yang sama.
Lewati bagian ini jika: Siklus pengujian Anda sebagian besar sudah otomatis. Jika 80% rangkaian pengujian Anda dijalankan melalui pipa CI, Anda memerlukan alat yang dapat mengimpor hasil eksekusi, bukan alat yang mengharuskan manusia memperbarui statusnya.
TestRail
TestRail adalah platform manajemen pengujian khusus yang dirancang untuk tim QA yang membutuhkan kontrol terstruktur atas seluruh proses pengujian mereka. Platform ini menangani seluruh siklus penulisan, pelaksanaan, dan pelaporan kasus uji, dengan integrasi DevOps dan CI/CD yang menyalurkan hasilnya.
Fitur utama TestRail
- Manajemen kasus uji dan rangkaian uji terpusat dengan kasus uji yang dapat digunakan kembali di berbagai proyek
- Rencana pengujian dan tonggak pencapaian untuk mengatur dan menjadwalkan pelaksanaan pengujian di seluruh sprint dan rilis
- Pelaporan terperinci dengan analisis cakupan, pelacakan kemajuan, dan riwayat eksekusi
- Integrasi dengan Jira, GitHub, Jenkins, Azure DevOps, dan lebih dari 20 alat DevOps lainnya
- REST API untuk mengotomatisasi tugas dan menyinkronkan data pengujian dengan sistem eksternal
Batasan TestRail
- Tidak ada fitur bawaan untuk manajemen persyaratan atau pelacakan masalah—tim harus mengandalkan alat eksternal seperti Jira, yang dapat memecah-mecah jejak keterlacakan
- Pengorganisasian berbasis folder menjadi sulit dinavigasi seiring bertambahnya jumlah repositori pengujian hingga ribuan
Harga TestRail
- Profesional: $39 per kursi per bulan
- Enterprise: $78 per kursi per bulan
Peringkat dan ulasan TestRail
- G2: 4,4/5 (lebih dari 600 ulasan)
- Capterra: 4,3/5 (lebih dari 160 ulasan)
Apa yang dikatakan pengguna nyata tentang TestRail?
Inilah yang dikatakan oleh seorang pengulas di G2:
Hal yang menurut saya paling berharga dari TestRail adalah platform ini menyediakan lingkungan yang aman dan terorganisir dengan baik bagi tim QA kami untuk mengelola rencana pengujian, kasus uji, dan eksekusi pengujian. Saya menghargai betapa mudahnya menyusun dan menerapkan rangkaian pengujian, serta menggunakan kembali kasus pengujian yang telah dibuat sebelumnya. Integrasi dengan Jira dan alat CI/CD telah membuat alur kerja kami lebih terpadu dan lebih mudah dilacak. Kemampuan untuk memantau kemajuan dan cakupan pengujian secara real-time sangat membantu dalam perencanaan dan pelaporan sprint. Dalam pekerjaan sehari-hari saya sebagai Insinyur QA, penggunaan TestRail juga telah menghemat banyak waktu saya.
Hal yang menurut saya paling berharga dari TestRail adalah platform ini menyediakan lingkungan yang aman dan terorganisir dengan baik bagi tim QA kami untuk mengelola rencana pengujian, kasus uji, dan eksekusi pengujian. Saya menghargai betapa mudahnya menyusun dan menerapkan rangkaian pengujian, serta menggunakan kembali kasus pengujian yang telah dibuat sebelumnya. Integrasi dengan Jira dan alat CI/CD telah membuat alur kerja kami lebih terpadu dan lebih mudah dilacak. Kemampuan untuk memantau kemajuan dan cakupan pengujian secara real-time sangat membantu dalam perencanaan dan pelaporan sprint. Dalam pekerjaan sehari-hari saya sebagai Insinyur QA, penggunaan TestRail juga telah menghemat banyak waktu saya.
Cocok untuk: Tim QA yang terdiri dari lima orang atau lebih yang menjalankan siklus pengujian formal per rilis, di mana seorang manajer perlu menjawab pertanyaan “berapa persentase dari Rilis 2.0 yang telah dijalankan dan lulus” melalui dasbor, bukan spreadsheet.
Lewati bagian ini jika: Kumpulan kasus pengujian Anda kurang dari beberapa ratus kasus atau penguji Anda juga bertindak sebagai pengembang. Pada skala tersebut, biaya per pengguna dan login terpisah hanya akan memberi Anda laporan yang tidak akan Anda periksa.
Zephyr
Zephyr adalah plugin manajemen pengujian dari SmartBear untuk Jira, yang dirancang untuk mengelola kasus pengujian langsung dari antarmuka Jira. Plugin ini mendukung pengujian manual maupun otomatis, dilengkapi dengan fitur pelaporan dan jejak audit yang kuat untuk tim agile dan perusahaan.
Fitur utama Zephyr
- Integrasi Jira bawaan—buat, tautkan, dan jalankan kasus uji langsung dari masalah Jira
- Pustaka pengujian hierarkis lintas proyek untuk menggunakan kembali dan mengatur kasus uji dalam skala besar
- Lebih dari 70 laporan siap pakai yang mencakup cakupan pengujian, kemajuan pelaksanaan, dan pelacakan cacat
- Dukungan BDD dengan sintaks Gherkin untuk alur kerja pengembangan berbasis perilaku (BDD)
- Integrasi CI/CD dengan Jenkins, GitHub, GitLab, Bitbucket, dan Bamboo
Keterbatasan Zephyr
- Lisensi per pengguna Jira, bukan per penguji
- Repositori pengujian yang besar (ribuan kasus) bisa terasa lebih sulit dinavigasi dibandingkan dengan alat mandiri seperti TestRail
- Dukungan disalurkan melalui Atlassian Marketplace, yang menambahkan lapisan tambahan bagi tim yang terbiasa dengan dukungan langsung dari vendor
Harga Zephyr
- Essential: Mulai dari $5,99 per pengguna per bulan (11–50 pengguna)
- Standar: Mulai dari $6,81 per pengguna per bulan (11–50 pengguna)
- Tingkat Lanjut: Mulai dari $8,73 per pengguna per bulan (11–50 pengguna)
Peringkat dan ulasan Zephyr
- G2: 4,1/5 (80+ ulasan)
- Capterra: Ulasan belum cukup
Apa yang dikatakan pengguna nyata tentang Zephyr?
Inilah yang dikatakan oleh seorang pengulas di G2:
Ini adalah alat terbaik untuk mengimpor kasus uji langsung dari lembar Excel. Dengan menggunakan alat ini, pekerjaan penguji menjadi lebih mudah dibandingkan mengimpor kasus uji ke Jira. Fitur terbaik dari alat ini adalah kemampuan untuk menandai kasus uji sebagai lulus atau gagal serta menambahkan lampiran.
Ini adalah alat terbaik untuk mengimpor kasus uji langsung dari lembar Excel. Dengan menggunakan alat ini, pekerjaan penguji menjadi lebih mudah dibandingkan mengimpor kasus uji di Jira. Fitur terbaik dari alat ini adalah kemampuannya untuk menandai kasus uji sebagai lulus atau gagal serta menambahkan lampiran.
Cocok untuk: Tim yang tunduk pada regulasi atau sering diaudit (seperti di bidang fintech dan kesehatan) yang membutuhkan setiap pengujian dapat dilacak ke persyaratan Jira dan setiap cacat dapat dihubungkan kembali ke pengujian yang menemukannya, semuanya dalam satu instance Atlassian.
Lewati bagian ini jika: Instans Jira Anda besar dan tim QA Anda kecil. Sebuah instans Jira dengan 200 lisensi yang memiliki 10 penguji akan menghabiskan biaya untuk 190 lisensi Zephyr yang tidak pernah dibuka; alat mandiri yang dihitung per penguji justru lebih murah.
Jira
Jira adalah platform manajemen proyek dan pelacakan masalah dari Atlassian, yang banyak digunakan oleh tim teknik dan QA untuk mengelola sprint, bug, dan alur kerja pengembangan. Meskipun bukan alat manajemen pengujian khusus, banyak tim menggunakannya bersama solusi seperti Zephyr Scale atau Xray untuk menangani manajemen kasus uji dalam konfigurasi Jira yang sudah ada.
Fitur utama Jira
- Papan Scrum dan Kanban untuk mengelola sprint, backlog, dan alur kerja pengujian Agile
- Alur kerja, jenis masalah, dan kolom yang dapat disesuaikan agar sesuai dengan cara tim Anda melacak pekerjaan
- Peta Jalan Lanjutan untuk perencanaan lintas tim dan pelacakan ketergantungan (Premium)
- Lebih dari 1.000 integrasi marketplace, termasuk GitHub, Confluence, Slack, dan alat CI/CD
- Aturan otomatisasi untuk memicu tindakan di seluruh proyek berdasarkan pembaruan masalah atau perubahan status
Keterbatasan Jira
- Manajemen kasus uji memerlukan plugin Marketplace (Zephyr Scale, Xray) yang memiliki biaya per pengguna tersendiri di luar langganan Jira
- Kurva pembelajaran yang lebih curam bagi pengguna non-teknis, dengan biaya adaptasi yang dapat membengkak untuk tim yang lebih besar
Harga Jira
- Gratis
- Standar: $7,91 per pengguna per bulan
- Premium: $14,54 per pengguna per bulan
- Enterprise: Harga khusus
Peringkat dan ulasan Jira
- G2: 4,3/5 (lebih dari 7.900 ulasan)
- Capterra: 4,4/5 (lebih dari 15.400 ulasan)
Apa yang dikatakan pengguna nyata tentang Jira?
Inilah yang dikatakan oleh seorang pengulas G2:
Jira adalah salah satu program digital favorit saya untuk melacak dan memvisualisasikan kinerja semua proyek kerja saya bersama seluruh anggota tim kerja saya, karena program ini menawarkan kemampuan kinerja virtual terbaik di kelasnya, sehingga memudahkan saya dalam mencapai semua tujuan profesional saya.
Jira adalah salah satu program digital favorit saya untuk melacak dan memvisualisasikan kinerja semua proyek kerja saya bersama seluruh anggota tim kerja saya karena program ini menawarkan kemampuan kinerja virtual terbaik di kelasnya, sehingga memudahkan saya dalam mencapai semua tujuan profesional saya.
Cocok untuk: Tim teknik yang sedang mengevaluasi apakah mereka benar-benar membutuhkan manajemen pengujian khusus. Melakukan beberapa siklus pengujian dengan menggunakan jenis masalah Jira khusus terlebih dahulu dapat menunjukkan apakah volume pengujian tersebut cukup untuk membenarkan penggunaan plugin.
Lewati bagian ini jika: Anda sudah tahu bahwa Anda membutuhkan manajemen pengujian. Langsung beralih ke plugin atau alat mandiri akan menghindari proses migrasi ketika jenis masalah khusus tidak lagi dapat ditingkatkan skalanya.
Kesalahan Umum yang Harus Dihindari Saat Membuat Kasus Uji
Hindari kesalahan-kesalahan dalam penulisan kasus uji ini yang dapat mengurangi efektivitasnya secara keseluruhan.
| Kesalahan | Apa yang harus dilakukan sebagai gantinya |
|---|---|
| Menulis kasus uji terlalu terlambat | Libatkan penguji dalam tahap pengumpulan persyaratan dan perancangan untuk mengidentifikasi potensi masalah sebelum proses pengkodean dimulai |
| Tidak memperbarui kasus uji | Perbarui kasus uji segera setelah fitur tersebut mendapatkan pembaruan, perubahan fungsionalitas, atau perubahan antarmuka pengguna |
| Tanpa postkondisi | Jelaskan bagaimana kondisi sistem seharusnya setelah pengujian selesai (pengguna uji dihapus, keranjang belanja dikosongkan, sesi ditutup) sehingga kasus berikutnya dimulai dari kondisi yang bersih |
| Hanya data jalur normal | Setiap bidang input memerlukan setidaknya satu nilai yang harus ditolak oleh sistem. Dokumentasikan bagaimana kumpulan data tersebut dihasilkan atau diambil |
| Tidak memprioritaskan kasus uji | Tentukan prioritas untuk setiap kasus uji berdasarkan dampak bisnis, frekuensi penggunaan, dan risiko kegagalan. Hal ini membantu Anda memfokuskan upaya pengujian serta membuat keputusan yang lebih bijak terkait anggaran dan metode pengujian |
Cara Menjaga Agar Kasus Uji Tetap Berguna Seiring Berjalannya Waktu
Suatu rangkaian pengujian tetap dapat diandalkan jika setiap kasusnya bersifat independen, menargetkan masukan yang paling mungkin menyebabkan kegagalan, dan dihentikan begitu kasus tersebut tidak lagi menghasilkan hasil yang dapat diandalkan. Enam praktik ini membedakan rangkaian pengujian yang mampu mendeteksi bug selama bertahun-tahun dari rangkaian pengujian yang diabaikan setelah sprint kedua.
Tulis pengujian yang independen dan bersifat atomik
Sebuah kasus uji harus menetapkan kondisinya sendiri dan tidak boleh bergantung pada kasus lain yang telah dijalankan terlebih dahulu. Ketika TC_CHECKOUT_003 mengasumsikan bahwa TC_CHECKOUT_002 meninggalkan barang di keranjang belanja, satu kegagalan akan memicu lima kegagalan lainnya, dan Anda akan menghabiskan pagi hari untuk mencari tahu kegagalan mana yang sebenarnya terjadi. Jika judul kasus uji memerlukan kata “dan”, pisahkan menjadi dua kasus.
Uji di batas-batas
Bug cenderung muncul di batas-batas masukan yang diterima, bukan di tengah. Jika kolom kata sandi menerima 8 hingga 128 karakter, uji 7, 8, 128, dan 129, bukan hanya kata sandi 12 karakter yang umum digunakan. Analisis nilai batas adalah teknik formal dalam standar desain pengujian ISO/IEC/IEEE 29119-4 tepatnya karena alasan ini: teknik ini menemukan kesalahan "off-by-one" yang terlewatkan oleh masukan acak.
Gunakan partisi kesetaraan untuk mengurangi kasus yang berlebihan
Kelompokkan masukan yang harus diperlakukan sama oleh sistem, lalu uji satu contoh representatif dari setiap kelompok. Setiap format email yang valid berperilaku sama dalam formulir login, jadi satu email yang valid sudah cukup. Menguji user@example.com, jane@company.com, dan bob@domain.org sebagai tiga kasus terpisah akan melipatgandakan beban pemeliharaan Anda tanpa menambah cakupan pengujian.
Pisahkan data pengujian dari langkah-langkah pengujian
Menulis kode secara langsung “enter test@example.com” dalam sebuah langkah berarti harus menulis ulang langkah tersebut setiap kali lingkungan pengujian berubah. Buatlah langkah-langkah tersebut bersifat umum (“masukkan alamat email yang terdaftar”) dan simpan nilai sebenarnya dalam bidang data pengujian atau berkas. Langkah-langkah yang sama kemudian dapat dijalankan di lingkungan staging, QA, dan pra-produksi tanpa perlu diedit, dan mengganti dataset baru untuk pengujian negatif hanya memerlukan perubahan satu baris kode.
Lacak pengujian yang tidak konsisten dan tingkat lolosnya cacat
Kasus uji yang tidak stabil (flaky) gagal secara tidak konsisten tanpa adanya bug produk yang sebenarnya, dan setiap kasus uji yang tidak stabil mengajarkan tim untuk mengabaikan hasil yang gagal. Pantau seberapa sering setiap kasus uji berganti antara lulus dan gagal pada build yang identik. Jika suatu kasus uji tidak stabil lebih dari beberapa kali dalam sebulan, tulis ulang atau hapus kasus tersebut. Gabungkan hal ini dengan tingkat lolosnya cacat (bug yang ditemukan di produksi yang seharusnya terdeteksi oleh kasus uji) untuk melihat di mana cakupan pengujiannya tipis, bukan hanya di mana cakupannya berisik.
Otomatiskan pengujian yang paling sering Anda jalankan
Kasus regresi, smoke, dan fungsional frekuensi tinggi merupakan kandidat otomatisasi yang paling kuat karena dijalankan pada setiap build dan jarang berubah. Pindahkan kasus-kasus tersebut ke skrip dalam pipeline CI/CD Anda, dan gunakan alat bantu AI dengan penentu lokasi yang dapat memperbaiki diri sendiri di tempat elemen UI sering bergeser. Hal ini membebaskan penguji manusia untuk melakukan pekerjaan eksplorasi dan jenis pengujian perangkat lunak yang membutuhkan penilaian, seperti pengujian kegunaan dan pencarian kasus tepi.
Cara Menulis dan Menjalankan Kasus Uji di ClickUp
Bagian alat di atas menjelaskan peran ClickUp. Bagian ini menunjukkan pengaturan sebenarnya, yang disesuaikan dengan langkah-langkah yang telah dijelaskan sebelumnya dalam panduan ini.
Atur perpustakaan kasus uji Anda. Buat Ruang untuk produk Anda, Folder untuk setiap area fitur (misalnya, Otentikasi, Pembayaran, Onboarding), dan Daftar untuk setiap siklus pengujian atau sprint. Setiap tugas menjadi satu kasus uji tersendiri. Gunakan Bidang Kustom ClickUp untuk mencatat komponen seperti ID kasus uji, prasyarat, data uji, tingkat prioritas, dan lingkungan.
Tulis langkah-langkah pengujian langsung di dalam tugas. Gunakan deskripsi tugas untuk mendokumentasikan langkah-langkah eksekusi secara berurutan dan hasil yang diharapkan. Daftar periksa sangat berguna untuk alur langkah demi langkah di mana penguji perlu menandai setiap tindakan, sementara deskripsi berisi konteks seperti prasyarat dan data pengujian.
Lacak pelaksanaan dan hasilnya. Buat Status Kustom yang mencerminkan alur kerja pengujian Anda: Belum Dimulai → Sedang Berjalan → Lulus → Gagal → Terblokir. Saat pengujian gagal, ubah menjadi tugas bug atau buat tugas tertaut yang ditugaskan kepada pengembang, lengkap dengan prioritas, ketergantungan, dan tenggat waktu. Integrasi GitHub dan GitLab memungkinkan Anda menautkan bug tersebut langsung ke PR yang menyebabkannya. Jika penyebab utamanya adalah cacat kode, Anda dapat menugaskan tugas bug tersebut ke ClickUp Codegen Agent, yang membaca tugas, spesifikasi yang ditautkan, dan komentar, menulis perbaikan, serta membuka pull request dengan kemajuan yang diposting kembali ke tugas tersebut.
Tips Pro: Pemimpin QA dapat memperoleh gambaran instan tentang tugas apa pun dengan meminta ClickUp Brain untuk merangkum tugas bug yang masih terbuka. Dengan cara ini, mereka memiliki semua konteks yang dibutuhkan untuk tinjauan sprint tanpa perlu menelusuri setiap tugas satu per satu untuk menyusun gambaran keseluruhan.
Jalankan siklus pengujian dengan tampilan. Gunakan Tampilan Papan yang dikelompokkan berdasarkan status untuk melihat distribusi lulus/gagal secara sekilas selama pengujian berlangsung. Tampilan Tabel berfungsi sebagai matriks pengujian tradisional saat Anda perlu meninjau hasil dari puluhan kasus. Saring berdasarkan penugas untuk menyeimbangkan beban kerja, atau berdasarkan prioritas untuk memfokuskan pengujian awal pada jalur kritis terlebih dahulu.
Template Manajemen Pengujian ClickUp memberi Anda cara terpusat untuk mengelola seluruh alur kerja pengujian di berbagai area fitur, skenario pengujian, dan kasus tepi dalam satu tempat. Gunakan template ini untuk melacak umpan balik pengguna, mengelola jadwal pengujian, memantau kemajuan pengujian Anda, dan mengevaluasi hasil lulus/gagal tanpa perlu berpindah-pindah antar alat.
Kelola Alur Kerja Pengujian Anda Secara Efektif
Sebuah kasus uji dianggap valid saat dua orang dapat menjalankannya secara independen dan mendapatkan hasil lulus atau gagal yang sama. Semua yang dijelaskan dalam panduan ini (satu tindakan per langkah, prasyarat yang jelas, hasil yang diharapkan tanpa ruang untuk interpretasi) bertujuan untuk memenuhi standar tunggal tersebut. Jika Anda sudah merencanakan sprint di ClickUp, pengaturan yang dijelaskan di atas memungkinkan Anda menulis, menjalankan, dan melacak kasus uji bersamaan dengan bug yang terdeteksi, tanpa perlu menambahkan alat lain.
Daftar ke ClickUp secara gratis
Pertanyaan yang Sering Diajukan Tentang Kasus Uji
Berapa banyak kasus uji yang seharusnya dimiliki oleh sebuah persyaratan?
Satu persyaratan dapat memerlukan satu kasus uji atau sepuluh, tergantung pada berapa banyak skenario, kasus tepi, dan variasi masukan yang terlibat. Tujuannya adalah untuk mencakup semua jalur yang realistis, memberikan cakupan yang memadai tanpa redundansi.
Apa perbedaan antara kasus uji dan skrip uji?
Kasus uji mendokumentasikan apa yang akan diuji dan hasil apa yang diharapkan, yang ditulis untuk pelaksanaan manual. Sebaliknya, skrip uji adalah versi otomatisnya: kode yang menjalankan langkah-langkah yang sama secara terprogram.
Seberapa rinci langkah-langkah pengujian seharusnya?
Pecah pengujian menjadi langkah-langkah logis dan berurutan yang mudah diikuti tanpa konteks sebelumnya. Jangan menggabungkan beberapa tindakan menjadi satu atau menambahkan kerumitan yang tidak perlu.
Skenario pengujian menyatakan apa yang akan diuji dalam satu baris (“Verifikasi reset kata sandi”); kasus pengujian menentukan bagaimana caranya, dengan prasyarat, langkah-langkah, data pengujian, dan hasil yang diharapkan. Satu skenario biasanya menghasilkan 3 hingga 10 kasus pengujian yang mencakup alur normal, masukan yang tidak valid, dan kondisi batas. Skenario dibuat terlebih dahulu dan menjadi dasar perencanaan cakupan; kasus pengujian dibuat selanjutnya dan menjadi dasar pelaksanaan.
Kasus uji positif menggunakan masukan yang valid dan mengharapkan keberhasilan: alamat email dan kata sandi yang benar akan membuat pengguna berhasil masuk. Kasus uji negatif menggunakan masukan yang tidak valid atau tidak terduga dan mengharapkan sistem gagal dengan lancar: kata sandi yang salah akan menampilkan pesan “Kata sandi tidak valid” tanpa membuat sesi. Rangkaian uji yang matang memiliki perbandingan kasus uji positif dan negatif sekitar 1:3 hingga 1:5, karena sebagian besar bug produksi terdapat pada jalur kesalahan, bukan jalur normal.
Rencana pengujian mendefinisikan ruang lingkup, pendekatan, sumber daya, dan jadwal untuk seluruh upaya pengujian. Kumpulan kasus uji adalah sekumpulan kasus uji yang dikelompokkan untuk satu kali eksekusi, seperti “kumpulan kasus uji regresi untuk rilis 2.1.” Kasus uji adalah unit terkecil di dalamnya: satu pemeriksaan yang terdokumentasi dengan satu hasil lulus/gagal. Rencana menentukan strategi, kumpulan kasus uji menentukan ruang lingkup, dan kasus uji menentukan hasilnya.