Skenario Pengujian vs Kasus Pengujian: Perbedaan Utama Dijelaskan

“Test scenario” dan “test case” sering digunakan seolah-olah memiliki arti yang sama. Padahal tidak. Mencampuradukkan keduanya adalah bagaimana rencana pengujian berakhir menjadi terlalu samar untuk dieksekusi atau terlalu rinci untuk dibaca. Salah satunya menjelaskan apa yang harus diuji; yang lain menjelaskan bagaimana tepatnya. Pahami hubungan ini dengan benar dan cakupan Anda akan menjadi auditable dan runnable.

Panduan ini mendefinisikan setiap istilah, memaparkan perbedaannya secara berdampingan, dan menunjukkan bagaimana keduanya bekerja sama dalam alur kerja pengujian API nyata menggunakan Apidog.

Apa itu skenario pengujian?

Skenario pengujian adalah pernyataan tingkat tinggi tentang sesuatu yang layak diuji. Ini menyebutkan perilaku atau kondisi tanpa menentukan langkah-langkah, masukan, atau nilai yang diharapkan secara tepat.

Anggap saja sebagai judul. Untuk proses checkout e-commerce, skenario mungkin berbunyi:

• Verifikasi checkout untuk pengguna terdaftar dengan kartu tersimpan
• Verifikasi checkout untuk pengguna tamu
• Verifikasi checkout ketika suatu item kehabisan stok di tengah pembelian
• Verifikasi checkout ketika pembayaran ditolak

Setiap baris memberi tahu Anda apa yang harus divalidasi dan mengapa itu penting bagi bisnis. Tak satu pun dari mereka memberi tahu Anda endpoint mana yang harus dipanggil atau payload apa yang harus dikirim. Skenario ditulis dari sudut pandang pengguna atau persyaratan, sehingga tetap dapat dibaca oleh manajer produk maupun insinyur.

Skenario menjawab satu pertanyaan: apakah kita sudah memikirkan segala sesuatu yang seharusnya berfungsi? Mereka adalah peta cakupan. Jika sebuah skenario hilang, tidak ada jumlah test case yang rinci akan menutupi celah tersebut.

Apa itu test case?

Test case adalah pemeriksaan konkret yang dapat dijalankan yang berada di bawah sebuah skenario. Ini menentukan masukan yang tepat, prakondisi, tindakan, dan hasil yang diharapkan, dengan presisi yang cukup sehingga dua orang yang menjalankannya mendapatkan hasil yang sama.

Ambil skenario “verifikasi checkout untuk pengguna tamu.” Ini dipecah menjadi case seperti:

• POST /orders dengan payload tamu yang valid mengembalikan 201 dan order_id
• POST /orders tanpa alamat pengiriman mengembalikan 400 dan validation_error
• POST /orders dengan SKU yang kehabisan stok mengembalikan 409 dan error: out_of_stock

Setiap case menyebutkan endpoint, body, status yang diharapkan, dan bidang respons yang diharapkan. Ini cukup spesifik untuk diotomatisasi. Jika Anda ingin anatomi case secara rinci per bidang, cara menulis test case API mencakup template secara detail, dan test case vs test script mengklarifikasi di mana kode yang dapat dijalankan cocok.

Ciri khas test case adalah presisi. "Checkout berfungsi" adalah fragmen skenario yang terbaik. "POST order tamu yang valid, harapkan 201 dengan order_id yang tidak kosong" adalah sebuah test case.

Perbedaan utama

Kedua konsep ini berbeda di beberapa dimensi. Tabel ini adalah versi singkatnya.

Hubungan ini bersifat hierarkis. Satu skenario menghasilkan beberapa case. Skenario mengontrol luasnya cakupan; case mengontrol kedalaman dan ketelitian. Mode kegagalan umum adalah menulis lusinan case rinci tanpa peta skenario di atasnya, yang membuat tidak mungkin untuk mengetahui apakah fitur tersebut sepenuhnya tercakup atau hanya diuji secara intensif di satu sudut.

Cara lain untuk melihatnya: sebuah skenario dapat ditandai “tercakup” atau “tidak tercakup.” Sebuah test case hanya dapat ditandai “lulus” atau “gagal.” Anda memerlukan kedua status ini untuk mengelola kualitas.

Bagaimana skenario dan case bekerja sama

Alur kerja praktis bergerak dari umum ke spesifik dalam lima langkah.

1. Identifikasi skenario dari persyaratan. Baca spesifikasi atau dokumentasi API dan daftarkan setiap perilaku yang layak diverifikasi, termasuk unhappy paths. Di sinilah cakupan yang hilang dapat terdeteksi, jadi luangkan waktu nyata di sini.

2. Definisikan tujuan setiap skenario. Nyatakan apa arti “selesai”. Untuk “verifikasi checkout tamu,” tujuannya adalah agar tamu dapat melakukan pemesanan dan menerima konfirmasi, sementara pesanan yang tidak valid ditolak dengan bersih.

3. Tulis test case di bawah setiap skenario. Kembangkan setiap skenario menjadi case konkret dengan masukan dan hasil yang diharapkan. Cakup happy path, setiap kegagalan validasi, dan kondisi edge yang relevan.

4. Tinjau kelengkapan. Telusuri kembali pohonnya. Apakah setiap skenario memiliki setidaknya satu happy-path case dan satu negative case? Apakah setiap status code yang didokumentasikan muncul dalam beberapa hasil yang diharapkan? Celah yang ditemukan di sini murah; celah yang ditemukan di produksi tidak.

5. Eksekusi dan lacak hasil. Jalankan case, catat lulus dan gagal per case, dan gabungkan hasilnya ke tingkat skenario sehingga pemangku kepentingan melihat cakupan, bukan hanya hitungan tanda centang hijau.

Untuk tim yang digerakkan oleh perilaku, skenario secara alami sesuai dengan format Given-When-Then Gherkin; panduan Gherkin untuk pengujian API BDD menunjukkan bagaimana struktur tersebut membuat skenario tetap mudah dibaca sambil tetap dapat dieksekusi.

Contoh kerja: dari skenario ke case

Ambil sebuah API untuk aplikasi catatan, dengan satu perilaku yang layak diuji: seorang pengguna dapat membuat catatan. Itu adalah skenarionya.

Skenario: seorang pengguna dapat membuat catatan. Satu baris. Ini termasuk dalam rencana pengujian, dapat dibaca oleh siapa saja. Ini tidak menyebutkan endpoint, payload, atau status code, dan memang seharusnya tidak.

Sekarang kembangkan menjadi case. Setiap case adalah satu pemeriksaan yang dapat dijalankan dengan masukan yang tepat dan hasil yang diharapkan yang tepat.

• Case 1, happy path. POST /notes dengan {"title": "Groceries", "body": "milk, eggs"} dan token yang valid. Harapkan 201, body respons dengan id yang tidak kosong, title sama dengan Groceries, dan timestamp created_at. Respons di bawah 600 ms.
• Case 2, bidang wajib hilang. POST /notes dengan {"body": "milk, eggs"} dan token yang valid. Harapkan 400, error sama dengan validation_error, dan details menyebutkan bidang title.
• Case 3, tidak terautentikasi. POST /notes dengan body yang valid dan tanpa token. Harapkan 401 dan tidak ada id di respons.
• Case 4, payload terlalu besar. POST /notes dengan body 2 MB. Harapkan 413 dan pesan kesalahan yang jelas.

Satu skenario, empat case. Skenario memberi tahu Anda apa; case memberi tahu Anda bagaimana, dengan presisi yang cukup sehingga penguji atau runner otomatis mana pun menghasilkan putusan yang sama. Jika Anda kemudian menambahkan "seorang pengguna dapat melampirkan file ke catatan," itu adalah skenario baru, dan itu akan menghasilkan serangkaian case-nya sendiri. Rencana tumbuh secara terstruktur dan dapat diaudit daripada menjadi tumpukan pemeriksaan yang datar.

Membangun skenario dan case di Apidog

Apidog memodelkan hierarki ini secara langsung, sehingga struktur dalam rencana pengujian Anda sesuai dengan struktur dalam tooling Anda.

Skenario pengujian di Apidog adalah urutan permintaan API yang terurut, masing-masing dengan assertion-nya sendiri. Anda membangunnya secara visual: tambahkan endpoint yang terlibat dalam perilaku tersebut, rangkai sehingga keluaran satu permintaan menjadi masukan untuk permintaan berikutnya (login mengembalikan token, permintaan berikutnya menggunakannya), dan atur assertion di setiap langkah.

Setiap blok permintaan-plus-assertion secara efektif adalah test case. Anda menegaskan status code, bidang body respons, kesesuaian skema, dan waktu respons dengan mengklik, tanpa menulis skrip. Pengujian berbasis data memungkinkan satu case dijalankan terhadap banyak baris masukan dari file CSV atau JSON, sehingga satu negative case mencakup setiap kombinasi yang tidak valid.

Skenario kemudian dikelompokkan ke dalam test suites untuk menjalankan pengujian yang terorganisir dan berulang di seluruh API. Anda dapat menjalankan suite secara lokal, sesuai jadwal, atau di dalam CI, dan Apidog menghasilkan laporan yang menunjukkan hasil baik di tingkat case maupun tingkat skenario. Tampilan ganda itu adalah hasilnya: insinyur melihat case mana yang gagal, dan pemimpin melihat skenario mana yang sekarang berisiko.

Unduh Apidog untuk membangun skenario pertama Anda dan melihat penggabungan case ke skenario dalam praktik.

Mengapa Anda membutuhkan keduanya, bukan salah satunya

Terkadang tim mencoba melewati satu lapisan. Melewati skenario dan hanya menulis case akan menghasilkan daftar panjang yang datar tanpa peta cakupan; Anda tidak dapat menjawab “apakah kami menguji guest checkout sepenuhnya?” tanpa membaca ulang setiap case. Melewati case dan hanya mempertahankan skenario menghasilkan rencana yang tidak dapat dieksekusi secara konsisten oleh siapa pun, karena “verifikasi checkout” berarti sesuatu yang berbeda bagi setiap penguji.

Kedua lapisan juga melayani pembaca yang berbeda. Manajer produk membaca skenario untuk memastikan hal yang benar sedang diuji. Insinyur otomatisasi membaca case untuk membangun runner. Laporan pengujian yang hanya menunjukkan case yang lulus tidak memberi tahu apa pun kepada kepemimpinan tentang cakupan; laporan yang menggabungkan case ke dalam skenario memberi tahu mereka fitur mana yang aman untuk dirilis.

Jaga agar skenario stabil dan case tetap mutakhir. Skenario berubah hanya ketika tujuan fitur berubah. Case berubah setiap kali kontrak API berubah. Ketika Anda memperlakukan keduanya sebagai artefak terpisah dengan siklus hidup terpisah, rencana pengujian Anda tetap akurat dan dapat dipelihara.

Pertanyaan yang sering diajukan

Apakah skenario pengujian sama dengan test suite? Tidak. Skenario menjelaskan perilaku yang akan diuji. Suite adalah kumpulan pengujian yang dapat dieksekusi yang dikelompokkan untuk dijalankan. Sebuah suite dapat berisi case dari banyak skenario. Lihat test suite vs test case.

Berapa banyak test case yang harus dimiliki satu skenario? Cukup untuk mencakup happy path ditambah setiap mode kegagalan yang tersirat oleh skenario. Skenario sederhana mungkin memerlukan tiga atau empat case; yang kompleks membutuhkan lebih banyak.

Siapa yang menulis skenario versus case? Skenario seringkali disusun bersama dengan produk dan QA, karena mereka mengkodekan tujuan. Case biasanya ditulis oleh QA atau pengembang, karena mereka mengkodekan detail teknis. Format spesifikasi test case membantu menjaga konsistensi penulisan case.

Apakah saya memerlukan skenario jika pengujian saya diotomatisasi? Ya. Otomatisasi menjalankan case, tetapi skenario tetap menjawab apakah case yang tepat ada. Otomatisasi tanpa peta cakupan hanya akan gagal lebih cepat.