Pengembangan perangkat lunak bergerak cepat, terutama di lingkungan agile dan pengiriman berkelanjutan. Tim sering merilis build, menerapkan perbaikan cepat, dan mengirimkan pembaruan bertahap. Dalam konteks ini, sanity testing memainkan peran penting dalam memastikan bahwa perubahan terbaru tidak merusak fungsionalitas inti aplikasi.
Artikel ini menyediakan panduan praktis yang terperinci untuk sanity testing, menjelaskan apa itu, kapan menggunakannya, bagaimana ia cocok dalam siklus hidup pengujian, dan bagaimana alat modern seperti Apidog dapat mendukung sanity testing untuk sistem berbasis API.

Apa Itu Sanity Testing?
Sanity testing adalah jenis pengujian perangkat lunak terfokus yang dilakukan setelah perubahan kode kecil, perbaikan bug, atau pembaruan konfigurasi. Tujuannya adalah untuk memverifikasi dengan cepat bahwa fungsionalitas tertentu masih berfungsi seperti yang diharapkan dan build cukup stabil untuk pengujian lebih lanjut.
Tidak seperti pendekatan pengujian menyeluruh, sanity testing bersifat sempit, dangkal, dan bertarget. Ini hanya memvalidasi area yang terpengaruh, bukan seluruh sistem.
Secara sederhana:
“Apakah perubahan kecil ini berfungsi dengan benar, atau apakah ada yang rusak secara kritis?”
Sanity Testing vs Smoke Testing
Sanity testing seringkali disalahpahami dengan smoke testing. Meskipun keduanya terkait, mereka memiliki tujuan yang berbeda.
| Aspek | Sanity Testing | Smoke Testing |
|---|---|---|
| Cakupan | Sempit dan terfokus | Luas dan dangkal |
| Pemicu | Setelah perubahan kecil atau perbaikan bug | Setelah build baru |
| Tujuan | Memverifikasi kebenaran fitur spesifik | Memverifikasi stabilitas build |
| Kedalaman | Lebih dalam dari smoke testing | Sangat dasar |
| Eksekusi | Biasanya manual, terkadang otomatis | Seringkali otomatis |
Smoke testing memeriksa apakah build dapat diuji. Sanity testing memeriksa apakah perubahan terbaru masuk akal.
Kapan Seharusnya Anda Melakukan Sanity Testing?
Sanity testing biasanya dieksekusi dalam skenario berikut:
- Setelah perbaikan bug diterapkan
- Setelah peningkatan kecil atau penyesuaian fitur
- Setelah perubahan konfigurasi atau lingkungan
- Sebelum menjalankan pengujian regresi
- Selama pipeline integrasi berkelanjutan untuk memvalidasi patch dengan cepat
Ini sangat berharga ketika waktu terbatas dan tim membutuhkan umpan balik cepat sebelum melanjutkan.
Proses Sanity Testing
Sanity testing tidak mengikuti proses yang berat dan formal, tetapi tetap mendapat manfaat dari struktur.
Alur Kerja Sanity Testing Langkah demi Langkah
- Identifikasi modul yang terpengaruh
Fokus hanya pada area yang terpengaruh oleh perubahan terbaru. - Pilih (Evaluasi) kasus uji kritis
Pilih pengujian yang memvalidasi logika inti dan hasil yang diharapkan. - Jalankan sanity tests
Lakukan pemeriksaan manual atau otomatis.
Analisis hasil
- Jika sanity tests berhasil → lanjutkan dengan pengujian yang lebih mendalam
- Jika sanity tests gagal → tolak build dan perbaiki masalah segera

Contoh Alur Kerja
Perubahan Kode → Build Dibuat → Sanity Testing
→ Berhasil → Pengujian Regresi / Sistem
→ Gagal → Perbaiki & Buat Ulang
Atribut Kunci Sanity Testing
Sanity testing memiliki beberapa karakteristik penentu:
- Terfokus: Hanya menargetkan fungsionalitas yang terpengaruh
- Cepat: Dieksekusi dalam hitungan menit atau jam, bukan hari
- Tidak menyeluruh: Tidak bertujuan untuk cakupan penuh
- Didorong oleh perubahan: Dipicu oleh modifikasi spesifik
- Seringkali manual: Meskipun otomatisasi dimungkinkan untuk API dan CI/CD
Atribut-atribut ini menjadikan sanity testing ideal untuk siklus pengembangan yang bergerak cepat.
Contoh Sanity Testing (Perspektif Fungsional)
Bayangkan perbaikan bug login di mana logika validasi kata sandi telah dikoreksi.
Kasus Uji Sanity Mungkin Termasuk:
✓ Nama pengguna valid + kata sandi valid → login berhasil
✓ Nama pengguna valid + kata sandi tidak valid → pesan kesalahan ditampilkan
✓ Akun terkunci → akses ditolak
Anda tidak akan menguji fitur yang tidak terkait seperti pengeditan profil pengguna atau pemrosesan pembayaran selama sanity testing.
Sanity Testing untuk API
Dalam aplikasi modern, API seringkali merupakan titik integrasi paling kritis. Sanity testing API memastikan bahwa perubahan backend terbaru tidak merusak perilaku permintaan/respons.
Contoh: Sanity Test untuk Endpoint API
POST /api/login
Content-Type: application/json
{
"username": "test_user",
"password": "valid_password"
}
Respons yang Diharapkan:
{
"status": "success",
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}
Jika respons ini berubah secara tak terduga setelah perbaikan, sanity testing akan mendeteksinya lebih awal.
Keuntungan Sanity Testing
Sanity testing menawarkan beberapa manfaat praktis:
- Menghemat waktu dengan menghindari siklus regresi penuh yang tidak perlu
- Memberikan umpan balik cepat kepada pengembang
- Mengurangi risiko penyebaran build yang tidak stabil
- Meningkatkan kepercayaan diri dalam rilis minor
- Cocok secara alami dengan alur kerja agile dan DevOps
Keterbatasan Sanity Testing
Meskipun nilainya, sanity testing memiliki keterbatasan:
- Tidak memberikan cakupan penuh
- Mungkin melewatkan cacat tersembunyi atau tidak langsung
- Sangat bergantung pada penilaian penguji
- Tidak dapat menggantikan pengujian regresi atau sistem
Untuk alasan ini, sanity testing harus dipandang sebagai penjaga gerbang, bukan jaminan kualitas akhir.
Di Mana Sanity Testing Berada dalam Piramida Pengujian
Sanity testing biasanya berada di atas smoke testing dan di bawah regression testing.
Pengujian Sistem / E2E
-------------------------
Pengujian Regresi
-------------------------
Sanity Testing
-------------------------
Smoke Testing
-------------------------
Pengujian Unit
Penempatan ini memungkinkan tim untuk menyaring build yang tidak stabil lebih awal tanpa menginvestasikan upaya pengujian yang berlebihan.

Bagaimana Apidog Membantu Sanity Testing untuk API
Untuk tim yang membangun sistem berbasis API, sanity testing seringkali berpusat pada verifikasi perilaku endpoint setelah perubahan. Apidog sangat efektif dalam konteks ini.
Bagaimana Apidog Mendukung Sanity Testing
- Validasi API cepat: Langsung menjalankan pemeriksaan sanitasi terhadap endpoint setelah perubahan
- Kasus uji yang dapat digunakan kembali: Simpan dan gunakan kembali skenario sanity test kritis
- Peralihan lingkungan: Validasi perubahan di seluruh setup dev, staging, dan mirip produksi
- Eksekusi otomatis: Integrasikan sanity test API ke dalam pipeline CI/CD
- Pernyataan yang jelas: Validasi kode status, skema respons, dan logika bisnis

Contoh: Pemeriksaan Sanity API di Apidog
{
"assertions": [
"statusCode == 200",
"response.body.token != null"
]
}
Ini menjadikan Apidog alat yang ideal untuk memastikan API tetap stabil setelah pembaruan bertahap, tanpa menjalankan suite pengujian lengkap.
Praktik Terbaik untuk Sanity Testing yang Efektif
Untuk mendapatkan nilai terbaik dari sanity testing:
- Fokus hanya pada perubahan terbaru
- Jaga kasus uji tetap sederhana dan dapat diulang
- Pertahankan suite sanity test yang kecil
- Otomatisasi sanity test API jika memungkinkan
- Gabungkan sanity testing dengan smoke dan regression testing
- Jalankan sanity tests lebih awal di pipeline CI/CD
Pertanyaan yang Sering Diajukan
Q1. Apakah sanity testing manual atau otomatis?
Sanity testing secara tradisional manual, tetapi dapat diotomatisasi—terutama untuk API dan layanan backend menggunakan alat seperti Apidog.
Q2. Bagaimana sanity testing berbeda dari regression testing?
Sanity testing bersifat sempit dan cepat, berfokus pada perubahan terbaru. Regression testing lebih luas dan memastikan fungsionalitas yang ada tetap tidak terpengaruh.
Q3. Siapa yang melakukan sanity testing?
Biasanya insinyur QA atau pengembang, tergantung pada struktur tim dan urgensi rilis.
Q4. Bisakah sanity testing menggantikan regression testing?
Tidak. Sanity testing adalah pemeriksaan awal, bukan pengganti untuk pengujian regresi yang komprehensif.
Q5. Apakah sanity testing diperlukan untuk setiap rilis?
Sangat direkomendasikan untuk pembaruan minor dan hotfix, terutama di lingkungan agile dan DevOps.
Kesimpulan
Sanity testing adalah teknik pengujian yang ringan namun ampuh yang memastikan perubahan terbaru berfungsi dengan benar tanpa membuang waktu pada siklus pengujian penuh. Dengan berfokus pada area yang terpengaruh, ia memberikan umpan balik cepat, mengurangi risiko, dan meningkatkan kepercayaan diri rilis.
Dalam arsitektur berpusat API, sanity testing menjadi lebih berharga. Alat seperti Apidog membantu tim menjalankan sanity test yang andal dan dapat diulang untuk endpoint API—mempermudah deteksi masalah lebih awal dan menjaga pengembangan tetap cepat tanpa mengorbankan kualitas.
