Nulis API Test Case yang Proper

Belajar SQA Bareng #15 · API Testing

Ada bedanya antara pakai Postman dan test API dengan benar.

Selama jadi developer, aku termasuk yang pertama. Buka Postman, kirim request, lihat response, kalau datanya sesuai ya sudah. Tidak ada dokumentasi, tidak ada assertion, tidak ada struktur. Pure coba-coba.

Setelah belajar API Testing dari sisi QA, aku bikin sesuatu yang berbeda: API test case yang proper, lengkap dengan test plan, execution log, defect report, dan metrics. Dan bedanya jauh sekali.

Dari Coba-coba ke Terstruktur

Waktu coba-coba di Postman sebagai developer, yang ada di kepala hanya satu pertanyaan “endpoint ini return apa?”

API test case yang proper menjawab pertanyaan yang jauh lebih banyak:

Semua itu terdokumentas, bisa direproduksi siapa saja, dan bisa dijalankan ulang kapan saja.

Struktur API Test Case yang Aku Pakai

Untuk project STI Alumni, ini kolom yang aku gunakan di setiap test case:

Struktur API Test Case

Contoh Nyata: Auth Endpoint

Ini tiga test case dari module Auth yang menunjukkan perbedaan antara positive, negative, dan validation case:

TC-AUTH-001 — Login Berhasil (Positive)

Contoh Positive Test Case — Auth

TC-AUTH-002 — Login Gagal (Negative)

Contoh Negative Test Case — Auth

TC-AUTH-003 — Body Kosong (Validation)

Contoh Edge Case — Auth

Tiga test case, tiga skenario berbeda, semuanya terdokumentasi dengan jelas.

Yang Membedakan API Test Case yang Bagus

1. Pre-condition yang spesifik

Bukan hanya “aplikasi running”, tapi kondisi yang benar-benar spesifik: “User sudah terdaftar di DB”, “Token valid tersimpan di environment variable”, “Email belum pernah dipakai.”

Tanpa pre-condition yang jelas, test case yang sama bisa menghasilkan hasil yang berbeda tergantung kondisi data.

2. Expected Status Code yang tepat, bukan sekadar “sukses atau gagal”

• 200 untuk GET yang berhasil
• 201 untuk POST yang berhasil membuat resource baru
• 401 untuk unauthorized
• 404 untuk resource tidak ditemukan
• 409 untuk conflict (misalnya email sudah terdaftar)
• 422 untuk validation error

3. Postman Assertion yang otomatis

Bukan cuma lihat response secara visual, tapi menulis script yang memverifikasi secara otomatis. Ini bikin collection bisa dijalankan ulang tanpa perlu cek manual satu per satu.

🔍 Dev Lens

Waktu jadi developer, aku tidak pernah mendokumentasikan testing apapun. Kalau berhasil ya lanjut, kalau gagal ya debug, kalau ada yang nanya ya coba lagi dari awal.

Struktur seperti ini memaksa untuk mendokumentasikan semuanya: apa yang ditest, bagaimana cara testnya, hasilnya apa, dan kalau ada bug, ada di mana.

Bukan berarti sebagai developer harus bikin yang serapih ini untuk setiap testing. Tapi sebagai QA, dokumentasi ini adalah hasil kerja yang bisa ditunjukkan, diverifikasi, dan direproduksi oleh orang lain. Itu yang membedakannya dari sekadar coba-coba.

💬 Jujur Corner

Jujurnya, bikin template ini lebih lama dari yang aku kira. Bukan karena teknisnya susah, tapi karena harus mikirin edge case untuk setiap endpoint: skenario apa saja yang perlu dicakup, pre-condition apa yang dibutuhkan, dan assertion apa yang paling relevan.

Dan aku belum testing langsung ke API-nya. Template ini masih akan terus berkembang setelah eksekusi berjalan dan ketemu hal-hal yang tidak terpikir sebelumnya.

Itu juga bagian dari prosesnya.

Takeaway

• API test case yang proper bukan sekadar “kirim request dan lihat hasilnya” tapi dokumentasi lengkap yang bisa direproduksi siapa saja
• Pre-condition yang spesifik dan expected status code yang tepat adalah dua hal yang paling membedakan test case yang bagus dari yang seadanya
• Postman assertion mengubah testing dari proses manual menjadi sesuatu yang bisa diverifikasi dan dijalankan ulang secara otomatis
• Execution log, defect report, dan metrics bukan formalitas, tapi alat untuk tahu seberapa baik coverage testing yang sudah dilakukan

Artikel berikutnya kita masuk ke topik yang sedikit berbeda: bagaimana cara QA menguji fitur AI dan chatbot. Ini yang paling relevan dengan industri sekarang dan paling jarang dibahas. Follow dulu biar nggak ketinggalan! 👋

— Isna, developer yang lagi belajar ngobrak-abrik software