DEV Community

Cover image for Skenario Pengujian vs Kasus Pengujian: Perbedaan Utama Dijelaskan
Walse
Walse

Posted on • Originally published at apidog.com

Skenario Pengujian vs Kasus Pengujian: Perbedaan Utama Dijelaskan

“Test scenario” dan “test case” sering dipakai seolah-olah sama. Padahal keduanya berbeda. Skenario menjelaskan apa yang harus diuji; test case menjelaskan bagaimana cara mengujinya secara konkret. Jika keduanya dicampur, rencana pengujian bisa menjadi terlalu samar untuk dieksekusi atau terlalu detail untuk dibaca.

Coba Apidog hari ini

Panduan ini membahas perbedaan skenario pengujian dan test case, cara menghubungkannya, serta contoh implementasinya dalam pengujian API menggunakan Apidog.

Apa itu skenario pengujian?

Skenario pengujian adalah pernyataan tingkat tinggi tentang perilaku atau kondisi yang perlu diverifikasi.

Skenario tidak berisi langkah teknis, payload, endpoint, atau assertion detail. Skenario cukup menjawab:

Perilaku apa yang harus dipastikan berjalan?

Contoh skenario untuk checkout e-commerce:

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

Setiap skenario menjelaskan cakupan dari sudut pandang pengguna atau bisnis. Karena itu, skenario harus mudah dibaca oleh product manager, QA, dan engineer.

Gunakan skenario untuk memastikan tidak ada area penting yang terlewat. Jika skenario tidak ditulis, test case sedetail apa pun tidak akan menutup celah cakupan tersebut.

Apa itu test case?

Test case adalah pemeriksaan konkret yang bisa dijalankan. Test case berada di bawah sebuah skenario dan berisi detail teknis seperti:

  • Prakondisi
  • Endpoint
  • Method
  • Payload
  • Header atau token
  • Langkah eksekusi
  • Status code yang diharapkan
  • Body respons yang diharapkan
  • Assertion tambahan seperti schema atau waktu respons

Ambil skenario berikut:

Verifikasi checkout untuk pengguna tamu.

Skenario tersebut dapat dipecah menjadi beberapa test case:

  • 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

Contoh test case yang lebih eksplisit:

POST /orders
Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode 
{
  "customer": {
    "type": "guest",
    "email": "guest@example.com"
  },
  "shipping_address": {
    "city": "Jakarta",
    "postal_code": "10110"
  },
  "items": [
    {
      "sku": "SKU-123",
      "quantity": 1
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Expected result:

{
  "status": 201,
  "body": {
    "order_id": "<not_empty>"
  }
}
Enter fullscreen mode Exit fullscreen mode

Ciri utama test case adalah presisi. “Checkout berfungsi” bukan test case; itu masih skenario. “Kirim POST /orders dengan payload tamu valid dan harapkan 201 dengan order_id tidak kosong” adalah test case.

Jika Anda ingin format test case API yang lebih detail, lihat cara menulis test case API. Untuk membedakan test case dengan kode eksekusi, lihat test case vs test script.

Perbedaan utama

Dimensi Skenario Pengujian Test Case
Tingkat Tingkat tinggi Tingkat rendah
Fokus Apa yang diuji Bagaimana cara menguji
Detail Singkat, biasanya satu baris Detail, berisi data dan assertion
Masukan Tidak ditentukan Payload, parameter, header, token
Hasil yang diharapkan Tersirat Ditulis eksplisit
Audiens Produk, QA, engineer QA, developer, automation runner
Jumlah Sedikit per fitur Banyak per skenario
Waktu dibuat Saat perencanaan pengujian Setelah skenario disepakati
Status pelacakan Tercakup / tidak tercakup Lulus / gagal

Hubungannya hierarkis:

Skenario
├── Test case 1
├── Test case 2
├── Test case 3
└── Test case 4
Enter fullscreen mode Exit fullscreen mode

Satu skenario menghasilkan beberapa test case. Skenario mengontrol luas cakupan. Test case mengontrol kedalaman validasi.

Kesalahan umum adalah langsung menulis banyak test case tanpa peta skenario. Akibatnya, tim punya banyak pemeriksaan teknis, tetapi tidak tahu apakah fitur sudah tercakup secara menyeluruh.

Cara mengubah skenario menjadi test case

Gunakan alur berikut.

1. Ambil skenario dari requirement

Baca spesifikasi produk, dokumentasi API, atau acceptance criteria. Tulis setiap perilaku yang perlu diverifikasi.

Contoh:

Skenario: pengguna tamu dapat melakukan checkout.
Enter fullscreen mode Exit fullscreen mode

Tambahkan juga unhappy path:

Skenario: checkout ditolak ketika pembayaran gagal.
Skenario: checkout ditolak ketika item kehabisan stok.
Skenario: checkout ditolak ketika alamat pengiriman tidak valid.
Enter fullscreen mode Exit fullscreen mode

2. Definisikan tujuan skenario

Untuk setiap skenario, tulis arti “berhasil”.

Contoh:

Pengguna tamu dapat membuat pesanan menggunakan data pengiriman valid.
Sistem mengembalikan konfirmasi pesanan dan order_id.
Pesanan tidak valid ditolak dengan pesan error yang jelas.
Enter fullscreen mode Exit fullscreen mode

Tujuan ini membantu menentukan test case apa saja yang perlu dibuat.

3. Turunkan menjadi test case

Untuk setiap skenario, buat variasi input dan expected result.

Contoh untuk skenario “pengguna tamu dapat melakukan checkout”:

Case Kondisi Expected result
Happy path Payload valid 201, order_id tersedia
Alamat hilang shipping_address tidak ada 400, validation_error
Email tidak valid Format email salah 400, error menyebut email
SKU habis Item tidak tersedia 409, out_of_stock
Pembayaran gagal Payment provider menolak 402 atau error sesuai kontrak API

4. Pastikan cakupan cukup

Gunakan checklist ini:

  • Apakah setiap skenario punya minimal satu happy path?
  • Apakah setiap skenario punya negative case?
  • Apakah semua status code yang didokumentasikan sudah diuji?
  • Apakah field wajib sudah diuji ketika hilang?
  • Apakah validasi format sudah diuji?
  • Apakah edge case seperti payload besar atau token invalid sudah diuji?
  • Apakah assertion memeriksa body, bukan hanya status code?

5. Jalankan dan laporkan hasil

Saat test case dijalankan, catat hasilnya di dua level:

Skenario: pengguna tamu dapat melakukan checkout
├── Case: payload valid -> passed
├── Case: alamat hilang -> passed
├── Case: SKU habis -> failed
└── Case: pembayaran gagal -> passed
Enter fullscreen mode Exit fullscreen mode

Dengan struktur ini, engineer bisa melihat case mana yang gagal, sementara stakeholder bisa melihat skenario mana yang berisiko.

Untuk tim yang memakai BDD, skenario bisa ditulis dalam format Given-When-Then. Lihat panduan Gherkin untuk pengujian API BDD.

Contoh kerja: dari skenario ke test case

Misalkan Anda memiliki API aplikasi catatan. Salah satu perilakunya:

Skenario: pengguna dapat membuat catatan.
Enter fullscreen mode Exit fullscreen mode

Skenario ini cukup untuk rencana pengujian tingkat tinggi. Namun belum bisa dieksekusi. Untuk menjalankannya, pecah menjadi test case.

Case 1: happy path

Request:

POST /notes
Authorization: Bearer <valid_token>
Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode 
{
  "title": "Groceries",
  "body": "milk, eggs"
}
Enter fullscreen mode Exit fullscreen mode

Expected result:

  • Status code 201
  • Respons memiliki id yang tidak kosong
  • title sama dengan Groceries
  • Respons memiliki created_at
  • Waktu respons di bawah 600 ms

Case 2: field wajib hilang

Request:

POST /notes
Authorization: Bearer <valid_token>
Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode 
{
  "body": "milk, eggs"
}
Enter fullscreen mode Exit fullscreen mode

Expected result:

  • Status code 400
  • error sama dengan validation_error
  • details menyebut field title

Case 3: tidak terautentikasi

Request:

POST /notes
Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode 
{
  "title": "Groceries",
  "body": "milk, eggs"
}
Enter fullscreen mode Exit fullscreen mode

Expected result:

  • Status code 401
  • Respons tidak berisi id

Case 4: payload terlalu besar

Request:

POST /notes
Authorization: Bearer <valid_token>
Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode

Body berukuran 2 MB.

Expected result:

  • Status code 413
  • Respons berisi pesan error yang jelas

Hasil akhirnya:

Skenario: pengguna dapat membuat catatan
├── Case 1: catatan valid dibuat
├── Case 2: title wajib diisi
├── Case 3: token wajib dikirim
└── Case 4: payload terlalu besar ditolak
Enter fullscreen mode Exit fullscreen mode

Jika nanti fitur baru ditambahkan, misalnya “pengguna dapat melampirkan file ke catatan”, itu menjadi skenario baru dengan rangkaian test case sendiri.

Membangun skenario dan test case di Apidog

Apidog membantu memodelkan struktur ini di dalam workflow pengujian API.

Secara praktis, Anda bisa menggunakan pola berikut.

1. Buat skenario sebagai alur API

Skenario di Apidog dapat dibuat sebagai urutan request API.

Contoh alur:

Login
-> Ambil token
-> Buat catatan
-> Validasi respons
Enter fullscreen mode Exit fullscreen mode

Untuk skenario checkout:

Buat cart
-> Tambahkan item
-> Buat order
-> Proses pembayaran
-> Validasi konfirmasi
Enter fullscreen mode Exit fullscreen mode

2. Tambahkan assertion di setiap langkah

Setiap request perlu memiliki assertion sendiri, misalnya:

  • Status code harus 200, 201, 400, atau sesuai kontrak
  • Field tertentu harus ada
  • Field tidak boleh kosong
  • Schema respons harus sesuai
  • Waktu respons berada di bawah batas tertentu

Contoh assertion konseptual:

status == 201
body.id is not empty
body.title == "Groceries"
response_time < 600ms
Enter fullscreen mode Exit fullscreen mode

Setiap request plus assertion tersebut berperan sebagai test case yang bisa dijalankan.

3. Gunakan data-driven testing untuk variasi input

Untuk negative case, Anda dapat menjalankan satu struktur test dengan banyak input.

Contoh data:

title,body,expected_status,expected_error
,hello,400,validation_error
Groceries,,201,
<very_long_title>,hello,400,validation_error
Enter fullscreen mode Exit fullscreen mode

Dengan pendekatan ini, Anda tidak perlu menduplikasi test secara manual untuk setiap variasi validasi.

4. Kelompokkan skenario ke dalam test suite

Setelah beberapa skenario dibuat, kelompokkan ke dalam test suites.

Contoh struktur suite:

Checkout API Suite
├── Skenario: guest checkout berhasil
├── Skenario: checkout gagal karena stok habis
├── Skenario: checkout gagal karena pembayaran ditolak
└── Skenario: checkout gagal karena alamat tidak valid
Enter fullscreen mode Exit fullscreen mode

Suite membantu menjalankan pengujian secara terorganisir, baik secara lokal, terjadwal, maupun di dalam CI.

5. Baca hasil di dua level

Gunakan hasil test untuk menjawab dua pertanyaan berbeda:

  • Level test case: request atau assertion mana yang gagal?
  • Level skenario: perilaku bisnis mana yang sedang berisiko?

Inilah alasan skenario dan test case sebaiknya tetap dipisahkan.

Unduh Apidog untuk membangun skenario API pertama Anda dan melihat bagaimana test case digabungkan ke dalam skenario.

Mengapa Anda membutuhkan keduanya?

Jika hanya menulis test case tanpa skenario, rencana pengujian menjadi daftar panjang yang datar. Anda mungkin punya banyak test, tetapi sulit menjawab:

Apakah guest checkout sudah tercakup penuh?
Apakah semua mode kegagalan pembayaran sudah diuji?
Apakah fitur ini siap dirilis?
Enter fullscreen mode Exit fullscreen mode

Sebaliknya, jika hanya menulis skenario tanpa test case, rencana pengujian tidak bisa dieksekusi secara konsisten. “Verifikasi checkout” bisa berarti hal berbeda bagi setiap penguji.

Keduanya melayani pembaca yang berbeda:

  • Product manager membaca skenario untuk memastikan perilaku yang benar diuji.
  • QA membaca skenario dan test case untuk memastikan cakupan dan eksekusi.
  • Developer membaca test case untuk memahami detail teknis.
  • Automation runner menjalankan test case.
  • Stakeholder membaca laporan skenario untuk menilai risiko rilis.

Praktik yang baik:

  • Buat skenario stabil dan berbasis perilaku.
  • Perbarui test case ketika kontrak API berubah.
  • Jangan ubah skenario kecuali tujuan fitur berubah.
  • Pastikan setiap skenario punya happy path dan negative path.
  • Laporkan hasil test case sekaligus status cakupan skenario.

Pertanyaan yang sering diajukan

Apakah skenario pengujian sama dengan test suite?

Tidak. Skenario menjelaskan perilaku yang akan diuji. Test suite adalah kumpulan pengujian yang dikelompokkan untuk dijalankan bersama.

Satu suite dapat berisi test case dari banyak skenario. Lihat test suite vs test case.

Berapa banyak test case yang harus dimiliki satu skenario?

Secukupnya untuk mencakup happy path, negative path, dan edge case yang relevan.

Skenario sederhana mungkin hanya perlu tiga atau empat test case. Skenario kompleks bisa membutuhkan lebih banyak.

Siapa yang menulis skenario dan test case?

Skenario biasanya ditulis bersama oleh product, QA, dan engineering karena berhubungan dengan tujuan fitur.

Test case biasanya ditulis oleh QA atau developer karena membutuhkan detail teknis seperti endpoint, payload, status code, dan assertion. Format spesifikasi test case membantu menjaga konsistensi.

Apakah skenario tetap diperlukan jika semua test sudah otomatis?

Ya. Otomatisasi menjalankan test case, tetapi skenario menjawab apakah test case yang tepat sudah ada.

Tanpa skenario, otomatisasi hanya membuat eksekusi lebih cepat, bukan memastikan cakupan lebih lengkap.

Top comments (0)