DEV Community

Cover image for Validasi vs Verifikasi: Perbedaan Utama dalam Pengujian
Walse
Walse

Posted on • Originally published at apidog.com

Validasi vs Verifikasi: Perbedaan Utama dalam Pengujian

Sebuah tim bisa membangun perangkat lunak yang sesuai spesifikasi, tetapi tetap merilis produk yang salah. Sebaliknya, tim juga bisa membangun produk yang tepat di atas kode yang penuh cacat. Kegagalan pertama adalah masalah verifikasi. Kegagalan kedua adalah masalah validasi. Jika keduanya dicampuradukkan, proses quality assurance terlihat sibuk tetapi tidak efektif.

Coba Apidog hari ini

Panduan ini menjelaskan perbedaan verifikasi dan validasi, lalu menunjukkan cara menerapkannya dalam pengujian API menggunakan Apidog.

Apa itu verifikasi?

Verifikasi menjawab pertanyaan:

Apakah kita membangun produk dengan benar?

Dalam praktiknya, verifikasi memeriksa apakah implementasi sesuai dengan spesifikasi, desain, kontrak, dan standar yang sudah disepakati.

Verifikasi tidak menilai apakah spesifikasinya sudah benar. Ia hanya memastikan implementasi mengikuti spesifikasi tersebut.

Contoh aktivitas verifikasi:

  • Code review
  • Walkthrough desain
  • Static analysis dan linting
  • Unit test
  • Pemeriksaan schema
  • Pemeriksaan kontrak API
  • Validasi status code, header, dan response body terhadap dokumentasi

Contoh sederhana:

POST /users
Enter fullscreen mode Exit fullscreen mode

Jika spesifikasi mengatakan endpoint ini harus mengembalikan:

201 Created
Location: /users/{id}
Enter fullscreen mode Exit fullscreen mode

maka verifikasi memastikan implementasi benar-benar mengembalikan 201 dan header Location.

Fokus verifikasi adalah artefak vs artefak:

  • kode vs desain
  • response vs schema
  • implementasi vs spesifikasi
  • endpoint vs kontrak API

Apa itu validasi?

Validasi menjawab pertanyaan:

Apakah kita membangun produk yang tepat?

Validasi memeriksa apakah perangkat lunak benar-benar menyelesaikan masalah pengguna. Fokusnya bukan lagi sekadar “sesuai dokumen”, tetapi “berguna dalam konteks nyata”.

Contoh aktivitas validasi:

  • User acceptance testing
  • Beta testing
  • Usability testing
  • End-to-end testing untuk alur kerja nyata
  • Demo ke stakeholder
  • Review integrasi oleh developer client

Contoh pada API:

Sebuah endpoint bisa sepenuhnya sesuai OpenAPI specification, tetapi tetap gagal validasi jika:

  • model pagination sulit digunakan client
  • authentication flow tidak cocok dengan integrasi yang ada
  • response tidak menyediakan data yang benar-benar dibutuhkan
  • contoh dokumentasi tidak mencerminkan penggunaan nyata

Validasi berfokus pada produk vs kenyataan.

Validasi vs verifikasi: perbedaannya

Dimensi Verifikasi Validasi
Pertanyaan inti Apakah kita membangunnya dengan benar? Apakah kita membangun hal yang benar?
Dibandingkan dengan Spesifikasi, desain, standar Kebutuhan pengguna, penggunaan dunia nyata
Waktu Berjalan terus selama development Setelah ada sesuatu yang dapat digunakan
Metode umum Review, static analysis, unit test, schema check Acceptance test, beta test, end-to-end test, demo
Arah Internal: artefak vs artefak Eksternal: produk vs kenyataan
Menangkap Bug, penyimpangan spesifikasi, contract drift Requirement yang salah, UX buruk, workflow tidak cocok
Risiko jika dilewati Kode salah terhadap spesifikasi yang benar Produk sempurna untuk masalah yang salah

Keduanya tidak saling menggantikan.

Verifikasi yang kuat tanpa validasi menghasilkan produk yang rapi, tetapi mungkin tidak dibutuhkan. Validasi yang kuat tanpa verifikasi menghasilkan ide yang benar, tetapi implementasinya tidak stabil.

Mnemonic sederhana:

Verifikasi menguji terhadap dokumen.

Validasi menguji terhadap tujuan.

Bagaimana ini terjadi dalam pengujian API

API membuat perbedaan ini lebih jelas karena biasanya memiliki kontrak eksplisit, seperti OpenAPI specification atau schema.

Kontrak tersebut menjadi dasar verifikasi.

Verifikasi API

Verifikasi API berarti memeriksa implementasi terhadap kontrak.

Checklist verifikasi API:

  • Apakah setiap endpoint mengembalikan status code yang didokumentasikan?
  • Apakah response body cocok dengan schema?
  • Apakah nama field dan tipe data sesuai?
  • Apakah required parameter benar-benar diwajibkan?
  • Apakah error response mengikuti format yang didokumentasikan?
  • Apakah header yang diwajibkan selalu dikirim?

Contoh assertion sederhana:

{
  "status": 201,
  "body": {
    "id": "string",
    "email": "string",
    "created_at": "string"
  }
}
Enter fullscreen mode Exit fullscreen mode

Jika schema menyatakan email harus berupa string, maka response seperti ini lulus verifikasi:

{
  "id": "usr_123",
  "email": "dev@example.com",
  "created_at": "2026-05-22T10:00:00Z"
}
Enter fullscreen mode Exit fullscreen mode

Tetapi response ini gagal verifikasi:

{
  "id": "usr_123",
  "email": null,
  "created_at": "2026-05-22T10:00:00Z"
}
Enter fullscreen mode Exit fullscreen mode

Untuk konsistensi status code, lihat panduan tentang kode status HTTP apa yang harus digunakan oleh REST API.

Di lapisan ini, pengujian kontrak API adalah bentuk verifikasi. Tujuannya memastikan API producer tetap memenuhi kontrak yang digunakan API consumer.

Asersi API pada status, schema, header, dan body adalah unit kerja verifikasi.

Validasi API

Validasi API berarti memeriksa apakah API benar-benar membantu client menyelesaikan workflow nyata.

Checklist validasi API:

  • Bisakah client login, membuat resource, memperbarui data, lalu menghapusnya tanpa workaround?
  • Apakah data yang dikembalikan cukup untuk kebutuhan UI atau sistem client?
  • Apakah authentication model cocok dengan integrasi yang ada?
  • Apakah error message cukup jelas untuk ditangani client?
  • Apakah dokumentasi dan contoh request mencerminkan penggunaan sebenarnya?

Contoh workflow validasi:

1. Register user
2. Login
3. Buat payment method
4. Buat transaksi
5. Cek status transaksi
6. Refund transaksi
7. Pastikan status akhir benar
Enter fullscreen mode Exit fullscreen mode

Schema check pada satu endpoint adalah verifikasi. Workflow multi-step seperti di atas lebih dekat ke validasi karena menguji apakah API bekerja dalam konteks penggunaan nyata.

Untuk memahami lapisan ini, lihat skenario pengujian vs kasus pengujian.

Di mana Apidog cocok

Apidog membantu menjalankan verifikasi dan validasi API dalam satu workspace: desain, dokumentasi, pengujian, dan pelaporan.

Menggunakan Apidog untuk verifikasi

Untuk verifikasi, desain API menjadi sumber kebenaran.

Langkah praktis:

  1. Definisikan endpoint, parameter, request body, response body, dan status code.
  2. Buat test berdasarkan schema yang sama.
  3. Tambahkan assertion untuk:
    • status code
    • response schema
    • required field
    • header
    • error format
  4. Jalankan test secara rutin.
  5. Integrasikan ke CI/CD agar kontrak diuji setiap perubahan kode.

Contoh assertion yang perlu ada untuk endpoint POST /payments:

- status code harus 201
- response harus memiliki payment_id
- payment_id harus string
- amount harus number atau integer sesuai spesifikasi
- currency harus mengikuti format yang disepakati
- error 400 harus mengikuti schema error
Enter fullscreen mode Exit fullscreen mode

Dengan pendekatan ini, verifikasi tidak menggunakan salinan kontrak yang berbeda. Test berjalan terhadap sumber spesifikasi yang sama.

Untuk pipeline otomatis, lihat panduan mengotomatiskan pengujian API di CI/CD.

Menggunakan Apidog untuk validasi

Untuk validasi, gunakan skenario pengujian yang merangkai beberapa endpoint menjadi satu workflow.

Contoh skenario:

1. Register user
2. Login dan simpan token
3. Buat resource baru
4. Ambil resource tersebut
5. Update resource
6. Verifikasi perubahan
7. Hapus resource
8. Pastikan resource tidak bisa diambil lagi
Enter fullscreen mode Exit fullscreen mode

Skenario seperti ini membantu menjawab pertanyaan validasi:

  • Apakah API bisa digunakan seperti client sungguhan?
  • Apakah urutan endpoint masuk akal?
  • Apakah data dari satu step cukup untuk step berikutnya?
  • Apakah workflow berhenti karena desain API yang tidak praktis?

Pelaporan per langkah juga membantu membedakan jenis kegagalan:

  • Kegagalan verifikasi: schema mismatch, status code salah, header hilang.
  • Kegagalan validasi: workflow multi-step tidak bisa diselesaikan, data tidak cukup, authentication flow tidak cocok.

Unduh Apidog untuk menyiapkan verifikasi tingkat kontrak dan validasi tingkat workflow pada API Anda.

Contoh dunia nyata

Bayangkan tim sedang membangun API pembayaran.

Spesifikasi menyatakan:

POST /payments
Enter fullscreen mode Exit fullscreen mode

Request:

{
  "amount": 10.5,
  "currency": "USD"
}
Enter fullscreen mode Exit fullscreen mode

Response sukses:

201 Created
Enter fullscreen mode Exit fullscreen mode 
{
  "payment_id": "pay_123"
}
Enter fullscreen mode Exit fullscreen mode

Response gagal untuk mata uang tidak valid:

400 Bad Request
Enter fullscreen mode Exit fullscreen mode 
{
  "error": "INVALID_CURRENCY"
}
Enter fullscreen mode Exit fullscreen mode

Dari sisi verifikasi

Verifikasi bisa lulus sepenuhnya:

  • handler cocok dengan desain
  • status code 201 dikembalikan untuk request valid
  • response memiliki payment_id
  • currency tidak valid menghasilkan 400
  • error body cocok dengan schema
  • contract test lulus

Dengan ukuran verifikasi, API ini benar.

Dari sisi validasi

Client pertama mulai mengintegrasikan API tersebut. Mereka menemukan bahwa amount memakai floating-point number.

Masalahnya muncul saat nilai seperti ini diproses:

0.1 + 0.2
Enter fullscreen mode Exit fullscreen mode

Hasilnya bukan angka desimal yang ideal untuk transaksi uang:

0.30000000000000004
Enter fullscreen mode Exit fullscreen mode

Implementasi tidak melanggar spesifikasi. Spesifikasi memang mengatakan amount adalah angka. Jadi verifikasi tidak akan menangkap masalah ini.

Masalahnya ada pada desain kontrak. Untuk uang, amount seharusnya dikirim sebagai unit minor integer, misalnya:

{
  "amount": 1050,
  "currency": "USD"
}
Enter fullscreen mode Exit fullscreen mode

Artinya 1050 merepresentasikan 10.50 USD.

Ini adalah temuan validasi. Solusinya bukan sekadar memperbaiki kode agar sesuai spesifikasi. Solusinya adalah memperbaiki spesifikasi karena kontraknya salah.

Daftar periksa praktis untuk rilis API

Gunakan dua checklist berikut sebelum rilis.

Verifikasi: uji terhadap spesifikasi

Pastikan:

  • Semua endpoint mengembalikan status code yang didokumentasikan.
  • Semua response sesuai schema.
  • Required parameter benar-benar diwajibkan.
  • Request body divalidasi sesuai kontrak.
  • Error response mengikuti format dokumentasi.
  • Header yang diperlukan tersedia.
  • Contract test lulus untuk endpoint yang digunakan consumer.
  • Test berjalan di CI/CD.

Contoh minimal assertion:

GET /users/{id}

- status = 200
- body.id = string
- body.email = string
- body.created_at = ISO datetime
- jika user tidak ditemukan, status = 404
- error body mengikuti schema error
Enter fullscreen mode Exit fullscreen mode

Validasi: uji terhadap tujuan

Pastikan:

  • Client baru bisa menyelesaikan workflow inti dari awal sampai akhir.
  • Data yang dikembalikan cukup untuk kebutuhan client.
  • Authentication flow cocok dengan pola integrasi nyata.
  • Error message bisa ditangani dengan jelas.
  • Dokumentasi dan contoh request sesuai penggunaan aktual.
  • Stakeholder mengonfirmasi API memecahkan masalah yang dimaksud.

Contoh workflow validasi:

User baru:
1. Membuat akun
2. Login
3. Membuat resource
4. Membaca resource
5. Mengubah resource
6. Menghapus resource

Ekspektasi:
- Tidak ada step yang membutuhkan workaround manual
- Token bisa dipakai antar-request
- Response menyediakan data yang dibutuhkan step berikutnya
- Error dapat dipahami dan ditangani client
Enter fullscreen mode Exit fullscreen mode

Jika hanya checklist verifikasi yang lulus, Anda memiliki implementasi yang benar dari desain yang mungkin salah.

Jika hanya checklist validasi yang lulus, Anda memiliki ide yang tepat tetapi implementasinya belum stabil.

Rilis yang sehat membutuhkan keduanya.

Pertanyaan yang sering diajukan

Apakah verifikasi atau validasi dilakukan terlebih dahulu?

Verifikasi dimulai lebih awal dan berjalan terus selama development. Begitu ada kode atau kontrak, Anda bisa memeriksanya terhadap spesifikasi.

Validasi biasanya dilakukan setelah ada produk atau workflow yang bisa digunakan untuk diuji terhadap kebutuhan nyata.

Apakah pengujian sama dengan validasi?

Tidak.

Pengujian mencakup verifikasi dan validasi.

Contoh verifikasi:

  • unit test
  • schema check
  • contract test
  • status code assertion

Contoh validasi:

  • user acceptance test
  • beta test
  • end-to-end workflow test
  • demo stakeholder

Dapatkah software lulus verifikasi tetapi gagal validasi?

Ya.

Ini sering terjadi ketika implementasi cocok dengan spesifikasi, tetapi spesifikasinya menyelesaikan masalah yang salah.

Produk tersebut terverifikasi, tetapi tidak tervalidasi.

Bagaimana ini berlaku untuk pengujian kontrak API?

Pengujian kontrak API adalah verifikasi.

Ia memastikan API tetap memenuhi perjanjian yang didokumentasikan dengan consumer. Namun, contract testing tidak membuktikan bahwa kontrak tersebut adalah kontrak yang tepat. Itu tugas validasi.

Mana yang menemukan lebih banyak bug?

Verifikasi biasanya menemukan lebih banyak cacat kecil karena berjalan lebih sering dan lebih awal.

Validasi biasanya menemukan lebih sedikit masalah, tetapi dampaknya lebih besar karena masalah validasi sering berarti requirement, desain, atau workflow salah.

Bisakah otomatisasi mencakup keduanya?

Otomatisasi sangat cocok untuk verifikasi:

  • schema check
  • contract test
  • status code assertion
  • header assertion
  • CI/CD test run

Validasi lebih sulit diotomatisasi sepenuhnya karena membutuhkan penilaian terhadap kebutuhan dunia nyata. Namun, end-to-end workflow test tetap bisa mengotomatisasi sebagian besar proses validasi teknis.

Top comments (0)