Dalam pengujian perangkat lunak, terutama API, terdapat dua istilah penting yang sering digunakan: Test Case dan Test Scenario. Meskipun keduanya berkaitan, terdapat perbedaan mendasar dalam penggunaannya. Pada kesempatan ini akan membahas perbedaan tersebut agar lebih mudah memahami serta memberikan contoh penerapannya dalam pengujian API login.
Perbedaan Test Case dan Test Scenario
| Aspek | Test Case | Test Scenario |
|---|---|---|
| Definisi | Dokumen yang berisi langkah-langkah detail untuk menguji fitur atau fungsionalitas tertentu. | Deskripsi umum tentang skenario pengujian tanpa langkah detail. |
| Tingkat Detail | Sangat detail, mencakup input, langkah-langkah eksekusi, hasil yang diharapkan, dan kondisi awal. | Lebih abstrak, hanya menjelaskan skenario tanpa langkah spesifik. |
| Tujuan | Memastikan setiap aspek fitur diuji secara sistematis. | Memberikan gambaran besar tentang apa yang perlu diuji. |
| Digunakan untuk | Pengujian manual dan otomatisasi, membantu QA dalam menguji secara sistematis. | Perencanaan pengujian, brainstorming kasus uji, dan memahami cakupan pengujian. |
Contoh Perbedaan dalam API Login
Test Scenario API Login
- Pengguna dapat login dengan kredensial yang valid.
- Sistem harus menolak login dengan kredensial salah.
- Sistem harus menolak login jika akun belum diverifikasi.
Test Case API Login
Test Case 1: Login dengan kredensial valid
- Precondition: User sudah terdaftar.
- Langkah: Kirim request POST ke
/api/logindengan email dan password valid. - Expected Result: Response
200 OK, token dikembalikan.
Test Case 2: Login dengan password salah
- Precondition: User sudah terdaftar.
- Langkah: Kirim request POST ke
/api/logindengan email benar tapi password salah. - Expected Result: Response
401 Unauthorized, pesan error “Invalid credentials”.
Setelah kita melihat contoh diatas jadi dapat disimpulkan Test Case adalah dokumen terperinci yang berisi langkah-langkah pengujian, data uji, kondisi awal, dan hasil yang diharapkan untuk menguji suatu fungsionalitas secara spesifik. sedangkan Test Scenario adalah gambaran umum tentang skenario pengujian tanpa langkah detail, yang digunakan untuk memahami cakupan pengujian dan perencanaan pengujian lebih lanjut.
Dalam Real Project Biasanya Lead QA / Senior QA akan membuatkan Sekenario Utama berdasarkar requirement yang ada, dan tester akan membuat Test Case berdasarkan testing yang dia lakukan dan akan memberi masukan jika ada sekenario yang kurang atau tidak bisa dilakukan testing. Setelah selesai testing QA Lead akan mereview hasil testing.
Jenis-Jenis Test Case dalam API Login
1. Functional Testing
Pengujian yang memastikan API bekerja sesuai dengan fungsionalitas yang diharapkan.
Contoh Test Case Functional Testing
| TC ID | Test Case | Precondition | Test Steps | Expected Result |
| TC001 | Login dengan kredensial valid | API harus aktif dan database memiliki user terdaftar | 1. Kirim request POST ke /api/login dengan payload: { “email”: “valid@example.com”, “password”: “ValidPassword123” } | Response status 200 OK, token dikembalikan |
| TC002 | Login dengan email yang tidak terdaftar | API harus aktif | 1. Kirim request POST ke /api/login dengan payload: { “email”: “notregistered@example.com”, “password”: “ValidPassword123” } | Response status 401 Unauthorized, pesan error “User not found” |
| TC003 | Login dengan password salah | User dengan email yang digunakan harus ada di database | 1. Kirim request POST ke /api/login dengan payload: { “email”: “valid@example.com”, “password”: “WrongPassword” } | Response status 401 Unauthorized, pesan error “Invalid credentials” |
| TC004 | Login dengan email kosong | API harus aktif | 1. Kirim request POST ke /api/login dengan payload: { “email”: “”, “password”: “ValidPassword123” } | Response status 400 Bad Request, pesan error “Email is required” |
| TC005 | Login dengan password kosong | API harus aktif | 1. Kirim request POST ke /api/login dengan payload: { “email”: “valid@example.com”, “password”: “” } | Response status 400 Bad Request, pesan error “Password is required” |
| TC006 | Login dengan format email tidak valid | API harus aktif | 1. Kirim request POST ke /api/login dengan payload: { “email”: “invalid-email”, “password”: “ValidPassword123” } | Response status 400 Bad Request, pesan error “Invalid email format” |
| TC007 | Login dengan payload kosong | API harus aktif | 1. Kirim request POST ke /api/login tanpa body atau {} | Response status 400 Bad Request, pesan error “Email and password are required” |
| TC008 | Login dengan metode HTTP selain POST | API harus aktif | 1. Kirim request GET ke /api/login | Response status 405 Method Not Allowed |
| TC009 | Login dengan akun yang sudah diblokir | Pastikan user di database memiliki status “blocked” | 1. Kirim request POST ke /api/login dengan akun yang diblokir | Response status 403 Forbidden, pesan error “User is blocked” |
| TC010 | Login dengan akun yang belum diverifikasi | Pastikan user di database memiliki status “unverified” | 1. Kirim request POST ke /api/login dengan akun yang belum diverifikasi | Response status 403 Forbidden, pesan error “User not verified” |
2. Integration Testing
Pengujian yang berfokus pada bagaimana API login berinteraksi dengan komponen lain, seperti database, middleware, autentikasi, dan layanan eksternal.
Contoh Test Case Integration Testing
| TC ID | Test Scenario | Precondition | Test Steps | Expected Result |
| TC001 | Integrasi dengan Database – User valid | Database memiliki user dengan email dan password yang valid | 1. Kirim request POST ke /api/login dengan kredensial valid 2. Verifikasi response dari API | Response status 200 OK, token dikembalikan, user ditemukan di database |
| TC002 | Integrasi dengan Database – User tidak ditemukan | Database tidak memiliki user dengan email yang diberikan | 1. Kirim request POST ke /api/login dengan email yang tidak terdaftar | Response status 401 Unauthorized, pesan error “User not found” |
| TC003 | Integrasi dengan Database – Password salah | Database memiliki user dengan email yang diberikan, tapi password salah | 1. Kirim request POST ke /api/login dengan password yang salah | Response status 401 Unauthorized, pesan error “Invalid credentials” |
| TC004 | Integrasi dengan Middleware – Validasi Input | API memiliki middleware untuk validasi request | 1. Kirim request POST ke /api/login dengan request body kosong 2. Kirim request dengan email dalam format salah | Response status 400 Bad Request, pesan error sesuai validasi middleware |
| TC005 | Integrasi dengan Authentication Service – Token Generation | API harus menghasilkan token JWT saat login sukses | 1. Kirim request POST ke /api/login dengan kredensial valid 2. Periksa apakah token JWT dikembalikan | Token JWT dikembalikan dalam response |
| TC006 | Integrasi dengan Authentication Service – Token Expiry | API mengembalikan token dengan waktu kedaluwarsa yang benar | 1. Login untuk mendapatkan token 2. Verifikasi expiry time di token (misal 1 jam) | Token memiliki expiry time yang benar (misal exp: <timestamp>) |
| TC007 | Integrasi dengan Redis (Session Store) – Menyimpan Session Aktif | Jika API menggunakan Redis untuk menyimpan sesi | 1. Login dengan kredensial valid 2. Periksa apakah sesi disimpan di Redis | Redis menyimpan session user dengan token aktif |
| TC008 | Integrasi dengan External Logging Service | API mencatat percobaan login ke sistem logging eksternal (misal ELK, Datadog) | 1. Login dengan berbagai skenario (sukses, gagal, blokir) 2. Periksa log di sistem logging | Log tercatat dengan benar (email, status login, timestamp) |
| TC009 | Integrasi dengan Rate Limiting | API membatasi jumlah login per menit (misal 5x per menit) | 1. Kirim lebih dari 5 request login dalam 1 menit | Response status 429 Too Many Requests, pesan error “Rate limit exceeded” |
| TC010 | Integrasi dengan Email Service – Kirim Notifikasi Login | Jika API mengirim notifikasi login ke user | 1. Login dengan kredensial valid 2. Periksa apakah email notifikasi dikirim | Email notifikasi login terkirim ke u |
3. End-to-End (E2E) Testing
Pengujian menyeluruh dari awal hingga akhir untuk memastikan seluruh proses login bekerja dengan baik.
Contoh Test Case End-to-End Testing
| TC ID | Test Scenario | Precondition | Test Steps | Expected Result |
| TC001 | Login sukses dengan kredensial valid | User terdaftar di database | 1. Akses halaman login (jika ada UI) atau kirim request POST ke /api/login dengan kredensial valid 2. Verifikasi response API 3. Pastikan user diarahkan ke halaman dashboard (UI) atau mendapatkan token JWT (API) | Login berhasil, response 200 OK, token dikembalikan, user diarahkan ke dashboard |
| TC002 | Login gagal dengan email tidak terdaftar | API dan database aktif | 1. Masukkan email yang tidak terdaftar 2. Kirim request login | Response 401 Unauthorized, pesan error “User not found” |
| TC003 | Login gagal dengan password salah | User terdaftar di database | 1. Masukkan email valid tetapi password salah 2. Kirim request login | Response 401 Unauthorized, pesan error “Invalid credentials” |
| TC004 | Login gagal dengan input kosong | API aktif | 1. Kirim request login dengan {} atau input kosong | Response 400 Bad Request, pesan error “Email and password are required” |
| TC005 | Login dengan akun yang belum diverifikasi | User ada di database tetapi belum verifikasi email | 1. Masukkan email dan password valid untuk akun yang belum diverifikasi 2. Kirim request login | Response 403 Forbidden, pesan error “User not verified” |
| TC006 | Login dengan akun yang diblokir | User di database memiliki status blocked | 1. Masukkan email dan password valid untuk akun yang diblokir 2. Kirim request login | Response 403 Forbidden, pesan error “User is blocked” |
| TC007 | Login berhasil lalu akses halaman dashboard | User terdaftar, UI tersedia | 1. Login dengan kredensial valid 2. Gunakan token JWT untuk mengakses /api/dashboard | Dashboard bisa diakses, response 200 OK |
| TC008 | Login dengan metode HTTP selain POST | API aktif | 1. Kirim request GET atau PUT ke /api/login | Response 405 Method Not Allowed |
| TC009 | Login dengan terlalu banyak percobaan gagal (Brute Force Protection) | API memiliki rate limiting | 1. Coba login lebih dari 5 kali dengan password salah dalam 1 menit | Response 429 Too Many Requests, pesan error “Rate limit exceeded” |
| TC010 | Login sukses lalu logout | User login dan mendapatkan token JWT | 1. Login dengan kredensial valid 2. Kirim request POST ke /api/logout dengan token 3. Coba akses endpoint /api/dashboard | Response logout sukses, dashboard tidak bisa diakses (response 401 Unauthorized) |
| TC011 | Login sukses lalu coba akses dengan token kedaluwarsa | JWT memiliki expiry time | 1. Login dan dapatkan token 2. Tunggu hingga token kedaluwarsa 3. Gunakan token untuk akses API yang membutuhkan autentikasi | Response 401 Unauthorized, pesan error “Token expired” |
| TC012 | Login sukses dan periksa audit log | Sistem logging (misal ELK, Datadog) aktif | 1. Login dengan kredensial valid 2. Cek log sistem | Log mencatat informasi login (email, timestamp, IP, status) |
| TC013 | Login dengan autentikasi dua faktor (2FA) | User mengaktifkan 2FA | 1. Masukkan email dan password valid 2. Masukkan kode OTP yang dikirim ke email atau aplikasi autentikasi | Response sukses setelah OTP benar, 200 OK, token dikembalikan |
Dari ketiga jenis pengujian di atas, terdapat beberapa test case yang selalu ada dalam setiap pengujian API login:
| TC ID | Test Scenario |
|---|---|
| TC001 | Login sukses dengan kredensial valid ✅ |
| TC002 | Login dengan email yang tidak terdaftar ✅ |
| TC003 | Login dengan password salah ✅ |
| TC004 | Login dengan input kosong ✅ |
| TC008 | Login dengan metode HTTP selain POST ✅ |
Mengapa test case ini selalu ada?
Karena test case tersebut menguji fungsionalitas dasar API login, sehingga harus diuji dalam Functional, Integration, dan E2E Testing.
Kesimpulan
- Test Scenario memberikan gambaran besar tentang pengujian yang harus dilakukan, sedangkan Test Case memberikan langkah detail untuk menjalankan pengujian tersebut.
- Functional Testing fokus pada validasi fungsi API login, Integration Testing memastikan API berinteraksi dengan baik dengan sistem lain, dan End-to-End Testing menguji seluruh alur kerja dari awal hingga akhir.
- Beberapa test case selalu ada, seperti login sukses, kredensial salah, dan validasi input, karena ini adalah skenario dasar API login.
Dengan memahami perbedaan ini, QA Engineer dapat lebih efektif dalam merancang pengujian API untuk memastikan sistem yang dibuat sesuai requirement / sesuai kebutuhan sehingga dapat meminimalisir terjadinya bug. oke sampai disini dulu pembahasannya. semoga bermanfaat.
