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 menjadi satu langkah, atau mendeskripsikan hasil yang diharapkan dengan sangat longgar sehingga dua penguji yang membaca kasus yang sama akan memiliki pendapat berbeda mengenai arti “lulus”. Akibatnya: bug lolos, proses pengujian tidak dapat direproduksi, dan QA menjadi penghambat alih-alih menjadi jaring pengaman.
Menulis kasus uji yang baik lebih berkaitan dengan desain verifikasi daripada 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 menerapkan ketelitian yang sama ke dalam perangkat lunak. Kasus uji tersebut memisahkan apa yang Anda harapkan dari apa yang Anda amati, sehingga kesenjangan di antara keduanya menjadi tidak mungkin diabaikan.
Kami akan menunjukkan kepada Anda cara menulis kasus uji, mengapa hal tersebut penting, dan cara meningkatkan kualitas kasus uji seiring waktu.
Ringkasan
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 agar hasilnya dapat diverifikasi. Panduan ini mencakup proses penulisan dalam tujuh langkah, tiga contoh yang telah diselesaikan, serta cara menjaga keandalan rangkaian kasus uji seiring dengan perubahan produk.
Apa Itu Kasus Uji?
Kasus uji adalah dokumen terstruktur yang mendefinisikan langkah-langkah, input, prasyarat, dan hasil yang diharapkan secara tepat yang diperlukan untuk memverifikasi apakah suatu perangkat lunak tertentu berfungsi dengan benar. Kasus uji 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 penyusunan 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 hasil yang berbeda-beda 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 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 tempat di mana pergeseran tersebut paling terlihat, sehingga penting untuk mengetahui perbedaannya dengan kasus uji manual.
| Parameter | Kasus pengujian manual | Kasus uji otomatis |
|---|---|---|
| Pelaksanaan | Dilakukan oleh penguji manusia yang mengikuti serangkaian langkah yang terdokumentasi | Dilakukan oleh alat perangkat lunak, skrip, atau agen AI |
| Kecepatan | 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 | Sangat dapat diulang dan konsisten jika skrip pengujian dipelihara dengan baik |
| 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 manual pada dokumen setiap kali persyaratan berubah | Membutuhkan pemeliharaan teknis untuk memperbarui skrip ketika antarmuka pengguna (UI) atau logika berubah |
| Cocok untuk | Pengujian eksploratif | Pengujian berulang dan pengujian regresi |
Mengapa Kasus Uji yang Ditulis dengan Baik Sangat Penting
Anda dapat mendeteksi regresi sebelum pengguna melaporkan masalah. Setiap perubahan kode berisiko merusak fitur 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 malah 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 praktiknya: kasus pengujian adalah pembuat, penguji adalah pemeriksa, dan keduanya harus menggunakan bahasa yang sama.
Anda mengubah pengetahuan tacit menjadi aset yang dapat digunakan kembali. Di sebagian besar tim, insinyur QA senior memiliki 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 didokumentasikan dengan prasyarat dan nilai batas yang eksplisit 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 batas ambang tersebut atau bagaimana timer direset.
Anda mengisolasi kegagalan ke langkah-langkah yang tepat, bukan area umum. Ketika sebuah kasus uji menggabungkan “navigasi ke 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 malah muncul kesalahan 500.” Ketepatan tersebut secara drastis memangkas waktu debugging karena pengembang tahu persis interaksi mana yang memicu cacat tersebut, bukan sekadar area fitur mana yang harus dicari.
Anda dapat melihat apa yang sudah tercakup dan apa yang masih menjadi titik buta. Tanpa kasus uji yang terstruktur, cakupan pengujian hanyalah tebakan. Dengan kasus uji tersebut, Anda dapat memetakan setiap kasus kembali ke persyaratan dan langsung mengidentifikasi 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, beberapa permintaan) dan Anda hanya memiliki kasus uji untuk tiga skenario, celah tersebut terlihat dan dapat diukur. Visibilitas itulah yang mengubah pengujian dari “kami telah mengujinya” menjadi “inilah yang tepatnya telah kami uji, inilah yang belum kami uji, dan inilah risiko yang kami terima.”
Komponen Kasus Uji yang Baik
Kasus uji yang bermanfaat tidak hanya sekadar menjelaskan apa yang harus diuji. Kasus uji tersebut juga mencakup konteks, langkah-langkah pelaksanaan, dan perilaku sistem yang diharapkan sehingga penguji, pengembang, atau manajer produk lain 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 telah kami bagikan di atas, kasus pengujian 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 sedang 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: 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, melampirkan konteks, meminta tinjauan, lalu menjalankan dan mencatat hasilnya.
Langkah 1: Analisis persyaratan
Sebelum menulis kasus uji, pahami terlebih dahulu fungsi yang seharusnya dijalankan oleh fitur tersebut. Di tahap ini, 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 hal 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 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 belum didefinisikan? Jika ya, mintalah klarifikasi dari pemangku kepentingan yang bersangkutan
Kejelasan ini memberi Anda landasan untuk merumuskan satu tujuan yang jelas untuk kasus pengujian Anda.
Tujuan: Memverifikasi bahwa pengguna terdaftar dapat berhasil mereset kata sandi mereka melalui email.
Langkah 2: Identifikasi berbagai skenario pengujian
Selanjutnya, buat 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 menetapkan kata sandi baru
- Email yang tidak terdaftar: Uji apa yang terjadi ketika sebuah email yang tidak terdaftar di sistem dikirimkan
- Tautan kedaluwarsa: Pastikan sistem memblokir akses saat tautan reset diklik setelah masa berlakunya habis
- Tautan yang digunakan kembali: Uji apakah tautan reset yang sudah pernah digunakan tidak dapat digunakan kembali
- Kata sandi baru tidak valid: Pastikan kata sandi yang tidak memenuhi persyaratan format ditolak
- Permintaan reset berulang: Uji tautan mana yang tetap valid ketika pengguna mengajukan beberapa permintaan secara berturut-turut
Setiap skenario di sini akan diwujudkan menjadi satu atau lebih kasus uji yang mencakup input dan kondisi tertentu. Dengan membagi fitur menjadi bagian-bagian 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 QA
Langkah 3: Rencanakan pengujian dan tetapkan 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 elemen-elemen berikut:
Siapa yang akan melakukan pengujian?
Peran atau kualifikasi apa yang dibutuhkan oleh orang yang menjalankan pengujian ini? Tergantung pada kompleksitas pengujian dan intervensi manusia yang diperlukan, tetapkan peran:
- Penguji QA: Pengujian fungsional dan regresi, seperti memverifikasi alur login, validasi formulir, atau proses checkout
- Tim keamanan: Pengujian yang melibatkan otentikasi, kontrol akses, atau kerentanan paparan data
- Pengembang: Pengujian unit untuk fungsi-fungsi individual seperti hashing kata sandi atau pembuatan token
Bagaimana pengujian tersebut akan dilakukan?
- Perangkat dan sistem operasi apa saja yang akan digunakan untuk menjalankan pengujian?
- Alat atau kerangka kerja pengujian apa yang akan digunakan?
- Apakah pengujian akan dijalankan secara manual atau melalui agen AI?
- Bagaimana hasilnya akan dicatat—di alat manajemen pengujian, spreadsheet, atau pelacak bug?
Apa saja prasyaratnya?
Buat daftar 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 mampu mengirimkan pesan
- Lingkungan pengujian dapat diakses dan sedang berjalan
Data pengujian apa yang akan digunakan?
Tentukan nilai input yang tepat yang diperlukan untuk menjalankan pengujian—data yang valid, data yang 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 di bawah batas karakter minimum
- Batas: kata sandi yang tepat sesuai batas karakter minimum dan maksimum
Langkah 4: Tulis langkah-langkah pengujian dan hasil yang diharapkan
Pecah proses eksekusi menjadi langkah-langkah berurutan. Gunakan terminologi yang konsisten dan pastikan setiap langkah hanya memiliki satu tindakan. Saat mendefinisikan langkah-langkah, jelaskan juga hasil yang diharapkan serta kriteria yang menentukan apakah hasil pengujian dianggap lulus atau gagal.
Melanjutkan alur reset kata sandi, berikut ini langkah-langkah pengujian yang akan dilakukan:
| Langkah-langkah | Hasil yang diharapkan |
| Buka halaman login | Halaman login 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 tersebut | Pengguna dialihkan ke halaman pembuatan kata sandi baru |
| Masukkan kata sandi baru yang valid | Kolom kata sandi menerima input tanpa kesalahan |
| Klik “Reset Kata Sandi” | Pesan keberhasilan ditampilkan, dan pengguna dialihkan ke halaman login |
Sekarang, tentukan langkah-langkah dan hasil yang diharapkan untuk skenario alternatif (seperti 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 pengujian 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 beranotasi 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 backend saat pengujian gagal
- Dokumen persyaratan yang menghubungkan kasus uji dengan user story atau kriteria penerimaan yang diverifikasi oleh kasus uji tersebut
- Berkas data pengujian yang berisi masukan yang valid dan tidak valid, atau data yang dihasilkan secara acak 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 peninjauan, pastikan bahwa:
- Kasus uji ini bersifat komprehensif dan mencakup semua skenario yang mungkin yang berasal 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 dapat dikategorikan sebagai lulus atau gagal secara jelas, catat hal tersebut di kolom komentar untuk ditinjau lebih lanjut.
Baca Selengkapnya: Cara Menggunakan AI untuk Jaminan Kualitas
Contoh Penulisan Kasus Uji
Tiga contoh ini menunjukkan bagaimana struktur kasus uji yang sama dapat disesuaikan dengan berbagai jenis pengujian perangkat lunak. Masing-masing 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 musim liburan. Alurnya mencakup beberapa halaman: keranjang belanja → pengiriman → pembayaran → konfirmasi. Tantangan utama di sini adalah ketergantungan status: setiap langkah bergantung pada penyelesaian langkah sebelumnya secara 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: Pastikan bahwa pengguna yang sudah masuk dapat menyelesaikan pembelian menggunakan kartu kredit yang tersimpan dan pengiriman standar.
Prasyarat:
- Akun pengguna sudah ada dengan setidaknya satu kartu kredit yang tersimpan dan satu alamat pengiriman yang tersimpan
- Setidaknya ada satu item yang tersedia dan telah ditambahkan ke keranjang belanja
- Lingkungan pengujian berjalan di Chrome 128, macOS
| Langkah | Hasil yang diharapkan | Hasil aktual | Lulus/Gagal |
| Buka halaman keranjang belanja | Keranjang belanja menampilkan item, jumlah, dan subtotal yang benar | Seperti yang diharapkan | Lulus |
| Klik “Lanjutkan ke Pembayaran” | Memuat halaman pengiriman dengan alamat yang tersimpan sudah dipilih sebelumnya | Seperti yang diharapkan | Lulus |
| Pilih “Pengiriman Standar” dan klik Lanjutkan | Halaman pembayaran dimuat dan menampilkan total pesanan termasuk biaya pengiriman | Seperti yang diharapkan | Lulus |
| Konfirmasikan 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. Kesalahan tercatat: pencarian kartu yang telah ditokenisasi 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 persistensi data secara langsung. Tantangan utamanya adalah menguji kesepakatan 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.
Prasyarat:
- Lingkungan pengujian API sedang berjalan dan dapat diakses
- Token otentikasi dengan izin admin telah dibuat dan masih berlaku
- Tidak ada pengguna dengan alamat email “newuser@testdomain.com” 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 |
| Kirim permintaan POST yang sama lagi dengan alamat email yang identik | Respons mengembalikan kode 409 Konflik dengan pesan: “Pengguna dengan alamat email ini sudah ada” | 200 OK dikembalikan; pengguna duplikat telah dibuat | Gagal |
| Kirim POST dengan bidang “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 kode status 200 OK dengan detail pengguna yang sesuai dengan payload asli | Seperti yang diharapkan | Lulus |
Ringkasan hasil: Endpoint tersebut berhasil membuat pengguna dengan benar dan memvalidasi kolom yang wajib diisi, tetapi gagal memastikan keunikan alamat email di tingkat basis data. Catatan duplikat berhasil dibuat tanpa 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 pemblokiran, 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.
Prasyarat:
- Terdapat dua akun: satu dengan peran “Admin” dan satu dengan peran “Viewer”
- Setidaknya ada satu proyek di ruang kerja, yang dibuat oleh Admin
- Pengguna telah masuk ke Firefox 130, Windows 11
| Langkah | Hasil yang diharapkan | Hasil aktual | Lulus/Gagal |
| Buka halaman Proyek | Pengguna melihat daftar proyek dalam mode hanya baca; tombol “Buat Proyek” disembunyikan atau dinonaktifkan | Tombol terlihat tetapi berwarna abu-abu (tidak aktif) | Lulus |
| Cobalah mengklik “Buat Proyek” | Sistem mencegah tindakan; formulir proyek baru tidak dimuat | Formulir tidak dimuat; tooltip menampilkan pesan “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 berhasil disimpan | Gagal |
| Cobalah menghapus 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 Viewer dapat mengubah judul proyek meskipun hanya memiliki akses baca saja. Masalah telah dicatat dengan tingkat keparahan: Kritis (penghalang kepatuhan).
Alat Apa yang Paling Cocok untuk Mengelola Kasus Uji?
Kasus pengujian dapat dikelola di 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 pull request yang terkait dengannya. Platform ini bukanlah alat manajemen pengujian khusus, tetapi struktur tugasnya yang fleksibel memungkinkan tim membangun alur kerja kasus uji menggunakan status, bidang, dan jenis tugas khusus 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 terkait dengannya
- 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 QA bawaan.
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?
Berikut ini pendapat seorang pengulas di 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, bidang, 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 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 gambaran yang jelas mengenai siapa yang bertanggung jawab atas apa serta perkembangan 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 dapat dilihat 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 pengguna memperbarui status secara manual.
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 yang terpusat dengan kasus uji yang dapat digunakan kembali di seluruh 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 pelacakan persyaratan atau masalah bawaan—tim harus mengandalkan alat eksternal seperti Jira, yang dapat memecah-mecah jejak keterlacakan
- Pengorganisasian berbasis folder menjadi sulit dinavigasi saat repositori pengujian bertambah hingga ribuan
Harga TestRail
- Professional: $39 per pengguna per bulan
- Enterprise: $78 per pengguna 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?
Berikut ini pendapat 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 pengujian, 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” dari dasbor, bukan dari spreadsheet.
Lewati bagian ini jika: Rangkaian pengujian Anda terdiri dari kurang dari beberapa ratus kasus atau penguji Anda juga merangkap sebagai pengembang. Pada skala tersebut, biaya per pengguna dan login terpisah hanya akan memberi Anda laporan yang tidak akan Anda perhatikan.
Zephyr
Zephyr adalah plugin manajemen pengujian dari SmartBear untuk Jira, yang dirancang untuk menangani kasus uji langsung dari antarmuka Jira. Plugin ini mendukung pengujian manual maupun otomatis, dilengkapi dengan fitur pelaporan dan penelusuran 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
- Integrasi CI/CD dengan Jenkins, GitHub, GitLab, Bitbucket, dan Bamboo
Batasan 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)
- Standard: Mulai dari $6,81 per pengguna per bulan (11–50 pengguna)
- Advanced: Mulai dari $8,73 per pengguna per bulan (11–50 pengguna)
Peringkat dan ulasan Zephyr
- G2: 4,1/5 (lebih dari 80 ulasan)
- Capterra: Ulasan belum cukup
Apa yang dikatakan pengguna nyata tentang Zephyr?
Berikut ini pendapat seorang pengulas di G2:
Ini adalah alat terbaik untuk mengimpor kasus uji langsung dari lembar Excel. Dengan menggunakan alat ini, pekerjaan penguji menjadi lebih ringan dibandingkan mengimpor kasus uji di Jira. Fitur terbaik dari alat ini adalah kemampuannya 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 ringan 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 langkah 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 pengaturan 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
- Pengelolaan kasus uji memerlukan plugin Marketplace (Zephyr Scale, Xray) dengan biaya per pengguna tersendiri di luar langganan Jira
- Kurva pembelajaran yang lebih curam bagi pengguna non-teknis, dengan biaya onboarding 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?
Berikut ini pendapat 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 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 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 diskalakan.
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 sebaiknya dilakukan |
|---|---|
| Menulis kasus uji terlalu terlambat | Libatkan penguji dalam tahap pengumpulan persyaratan dan tahap desain 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 |
| Tidak ada postkondisi | Jelaskan bagaimana sistem seharusnya terlihat setelah pengujian selesai (pengguna pengujian dihapus, keranjang belanja dikosongkan, sesi ditutup) sehingga kasus berikutnya dimulai dari kondisi awal yang bersih |
| Hanya data jalur normal | Setiap bidang input memerlukan setidaknya satu nilai yang harus ditolak oleh sistem. Dokumentasikan bagaimana kumpulan data dihasilkan atau diambil |
| Tidak memprioritaskan kasus uji | Tetapkan prioritas untuk setiap kasus uji berdasarkan dampak terhadap bisnis, frekuensi penggunaan, dan risiko kegagalan. Hal ini membantu Anda memfokuskan upaya pengujian serta membuat keputusan yang lebih tepat terkait anggaran dan metode pengujian |
Cara Menjaga Agar Kasus Uji Tetap Berguna Seiring Berjalannya Waktu
Suatu rangkaian pengujian tetap dapat diandalkan jika setiap kasus bersifat independen, menargetkan input 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 suatu item di keranjang belanja, satu kegagalan akan memicu lima kegagalan lainnya, dan Anda akan menghabiskan waktu sepanjang pagi untuk mencari tahu kegagalan mana yang sebenarnya terjadi. Jika judul uji memerlukan kata “dan”, pisahkan menjadi dua kasus.
Lakukan pengujian di batas-batas
Bug cenderung muncul di batas-batas input yang diterima, bukan di tengah. Jika kolom kata sandi menerima 8 hingga 128 karakter, uji dengan 7, 8, 128, dan 129 karakter, 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 input acak.
Gunakan partisi kesetaraan untuk mengurangi kasus yang berulang
Kelompokkan input yang seharusnya 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
Menuliskan “enter test@example.com” secara langsung dalam sebuah langkah berarti Anda harus menulis ulang langkah tersebut setiap kali lingkungan pengujian berubah. Buatlah langkah-langkah tersebut bersifat umum (“masukkan alamat email terdaftar”) dan simpan nilai sebenarnya dalam bidang data pengujian atau berkas. Langkah-langkah yang sama kemudian dapat dijalankan pada 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 stabil dan tingkat lolosnya cacat
Kasus pengujian yang tidak stabil (flaky) sering gagal secara tidak konsisten tanpa adanya bug produk yang sebenarnya, dan setiap kasus pengujian yang tidak stabil ini membuat tim terbiasa mengabaikan hasil yang berwarna merah. Pantau seberapa sering setiap kasus berganti antara lulus dan gagal pada build yang identik. Jika suatu kasus pengujian tidak stabil lebih dari beberapa kali dalam sebulan, tulis ulang atau hapus kasus tersebut. Gabungkan hal ini dengan tingkat lolosnya cacat (defect escape rate; bug yang ditemukan di lingkungan produksi yang seharusnya terdeteksi oleh kasus pengujian) 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 adalah 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 yang didukung AI dengan penentu lokasi yang dapat memperbaiki diri sendiri di tempat elemen UI sering bergeser. Hal ini membebaskan penguji manusia untuk melakukan pekerjaan eksploratif dan jenis pengujian perangkat lunak yang membutuhkan penilaian, seperti pengujian kegunaan dan pencarian kasus tepi.
Cara Menulis dan Menjalankan Kasus Pengujian di ClickUp
Bagian alat di atas menjelaskan di mana ClickUp berperan. Bagian ini menunjukkan pengaturan sebenarnya, yang disesuaikan dengan langkah-langkah yang telah dijelaskan sebelumnya dalam panduan ini.
Susun perpustakaan kasus pengujian Anda. Buat sebuah Space untuk produk Anda, sebuah Folder untuk setiap area fitur (misalnya, Otentikasi, Pembayaran, Onboarding), dan sebuah List untuk setiap siklus pengujian atau sprint. Setiap tugas menjadi sebuah kasus pengujian tersendiri. Gunakan Bidang Kustom ClickUp untuk mencatat komponen seperti ID kasus pengujian, prasyarat, data pengujian, tingkat prioritas, dan lingkungan.
Tulis langkah-langkah pengujian langsung di dalam tugas. Gunakan deskripsi tugas untuk mendokumentasikan langkah-langkah eksekusi berurutan dan hasil yang diharapkan. Daftar periksa sangat cocok 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 akar masalahnya adalah cacat kode, Anda dapat menugaskan tugas bug tersebut ke ClickUp Codegen Agent, yang membaca deskripsi tugas, spesifikasi yang ditautkan, dan komentar, menulis usulan perbaikan, serta membuka pull request untuk ditinjau dengan kemajuan yang diposting kembali ke tugas tersebut.
Kiat Pro: Pemimpin QA dapat memperoleh gambaran instan tentang tugas apa pun dengan meminta ClickUp Brain merangkum tugas-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 proses pengujian. Tampilan Tabel berfungsi sebagai matriks pengujian tradisional saat Anda perlu memeriksa 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 yang mencakup berbagai area fitur, skenario pengujian, dan kasus tepi di 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 begitu dua orang dapat menjalankannya secara independen dan mendapatkan hasil lulus atau gagal yang sama. Semua hal 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 bersama 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 suatu persyaratan?
Satu persyaratan dapat memerlukan satu kasus uji atau sepuluh kasus uji, tergantung pada berapa banyak skenario, kasus tepi, dan variasi input yang terlibat di dalamnya. 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 eksekusi manual. Sebaliknya, skrip uji adalah versi otomatisnya: kode yang menjalankan langkah-langkah yang sama secara terprogram.
Seberapa rinci langkah-langkah pengujian harus dibuat?
Pecah pengujian menjadi langkah-langkah logis dan berurutan yang mudah diikuti tanpa memerlukan konteks sebelumnya. Jangan menggabungkan beberapa tindakan sekaligus atau menambahkan kerumitan yang tidak perlu.
Skenario pengujian menyatakan apa yang akan diuji dalam satu baris (“Verifikasi reset kata sandi”); kasus uji menentukan bagaimana caranya, dengan prasyarat, langkah-langkah, data uji, dan hasil yang diharapkan. Satu skenario biasanya menghasilkan 3 hingga 10 kasus uji yang mencakup jalur normal, masukan yang tidak valid, dan kondisi batas. Skenario didahulukan dan menjadi dasar perencanaan cakupan; kasus uji mengikuti dan menjadi dasar pelaksanaan.
Kasus uji positif menggunakan input yang valid dan mengharapkan keberhasilan: alamat email dan kata sandi yang benar akan membuat pengguna berhasil masuk. Kasus uji negatif menggunakan input 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 positif terhadap negatif sekitar 1:3 hingga 1:5, karena sebagian besar bug produksi terdapat pada jalur kesalahan, bukan jalur yang berjalan lancar.
Rencana pengujian mendefinisikan ruang lingkup, pendekatan, sumber daya, dan jadwal untuk seluruh upaya pengujian. Kumpulan pengujian adalah kumpulan kasus uji yang dikelompokkan untuk satu kali eksekusi, seperti “kumpulan pengujian 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 menentukan ruang lingkup, dan kasus menentukan hasilnya.