Sebuah tim dapat membangun perangkat lunak yang secara sempurna sesuai dengan spesifikasinya dan tetap merilis produk yang salah. Mereka juga dapat membangun produk yang benar-benar tepat di atas kode yang penuh cacat. Dua kegagalan ini memiliki nama: yang pertama adalah masalah verifikasi, yang kedua adalah masalah validasi. Mencampuradukkan keduanya adalah bagaimana proses kualitas menjadi sibuk tetapi tidak efektif.
Panduan ini menjelaskan kedua istilah, menguraikan perbedaannya, dan menunjukkan di mana masing-masing berada dalam alur kerja pengujian API dengan Apidog.
Apa itu verifikasi?
Verifikasi bertanya: apakah kita membangun produk dengan benar?
Ini memeriksa bahwa sepotong perangkat lunak sesuai dengan spesifikasi, desain, dan standarnya. Verifikasi membandingkan pekerjaan dengan tujuan yang didokumentasikan. Ini tidak menanyakan apakah tujuan itu benar; ini hanya menanyakan apakah implementasinya cocok.
Verifikasi terjadi secara berkelanjutan, sepanjang pengembangan, bukan di akhir. Aktivitas verifikasi yang umum meliputi:
- Tinjauan kode dan walkthrough
- Analisis statis dan linting
- Tinjauan desain dan arsitektur
- Pemeriksaan skema dan kontrak
- Uji unit yang mengonfirmasi suatu fungsi melakukan apa yang dijanjikan oleh tandatangannya
Ciri utamanya adalah verifikasi sebagian besar bersifat internal. Ini membandingkan satu artefak dengan artefak lain: kode dengan desain, respons dengan skema, implementasi dengan spesifikasi. Tidak diperlukan pengguna nyata. Jika spesifikasi mengatakan endpoint mengembalikan 201 dengan header Location, verifikasi mengonfirmasi bahwa memang demikian.
Apa itu validasi?
Validasi bertanya: apakah kita membangun produk yang tepat?
Ini memeriksa bahwa perangkat lunak benar-benar memenuhi kebutuhan pengguna dan memecahkan masalah yang sebenarnya, terlepas dari apa yang dikatakan spesifikasi. Validasi membandingkan pekerjaan dengan kenyataan dan maksud penggunaan, bukan dengan dokumen.
Validasi cenderung terjadi kemudian, setelah ada sesuatu yang dapat digunakan oleh pengguna atau pemangku kepentingan. Aktivitas validasi yang umum meliputi:
- Pengujian penerimaan pengguna
- Program beta dan pengujian kegunaan
- Pengujian end-to-end dari alur kerja lengkap
- Demo pemangku kepentingan dan persetujuan
Ciri utamanya adalah validasi bersifat eksternal. Ini menanyakan apakah produk jadi berguna dan benar dalam konteksnya. Sebuah API dapat lulus setiap pemeriksaan verifikasi, sesuai sepenuhnya dengan spesifikasi OpenAPI-nya, dan masih gagal validasi karena spesifikasi itu sendiri memecahkan masalah yang salah; model paginasi tidak dapat digunakan, atau alur otentikasi tidak sesuai dengan cara klien berintegrasi.
Validasi vs verifikasi: perbedaannya
| Dimensi | Verifikasi | Validasi |
|---|---|---|
| Pertanyaan inti | Apakah kita membangunnya dengan benar? | Apakah kita membangun hal yang benar? |
| Membandingkan dengan | Spesifikasi, desain, standar | Kebutuhan pengguna, penggunaan dunia nyata |
| Waktu | Berkelanjutan, sepanjang pengembangan | Nanti, setelah sesuatu dapat digunakan |
| Metode umum | Tinjauan, analisis statis, uji unit, pemeriksaan skema | Pengujian penerimaan, beta, end-to-end, demo |
| Arah | Internal: artefak vs artefak | Eksternal: produk vs kenyataan |
| Menangkap | Cacat, penyimpangan spesifikasi, pergeseran kontrak | Persyaratan yang salah, kesesuaian yang buruk, celah kegunaan |
| Biaya melewatkan | Kode yang salah yang sesuai dengan spesifikasi yang baik | Produk yang sempurna memecahkan masalah yang salah |
Keduanya tidak dapat dipertukarkan, dan tidak ada yang menggantikan yang lain. Verifikasi yang kuat dengan validasi yang lemah memberi Anda produk bebas cacat yang tidak diinginkan siapa pun. Validasi yang kuat dengan verifikasi yang lemah memberi Anda ide yang tepat yang diimplementasikan pada kode yang tidak stabil. Anda membutuhkan keduanya, diterapkan pada waktu yang tepat.
Sebuah mnemonic sederhana: verifikasi adalah pengujian terhadap dokumen, validasi adalah pengujian terhadap tujuan.
Bagaimana ini terjadi dalam pengujian API
API membuat perbedaan ini konkret, karena API memiliki spesifikasi eksplisit, yang dapat dibaca mesin: definisi OpenAPI atau skemanya. Spesifikasi itu adalah dasar verifikasi.
Verifikasi untuk API berarti memeriksa implementasi terhadap kontrak tersebut:
- Apakah setiap endpoint mengembalikan kode status yang didokumentasikan? Mendapatkan konsistensi ini adalah disiplin tersendiri; lihat kode status HTTP apa yang harus digunakan oleh REST API.
- Apakah setiap respons cocok dengan skema yang didokumentasikan, dengan nama dan tipe bidang yang benar?
- Apakah parameter yang diperlukan ditegakkan persis seperti yang ditentukan?
- Apakah format kesalahan cocok dengan bentuk kesalahan yang didokumentasikan?
Di sinilah pengujian kontrak API berada. Pengujian kontrak adalah verifikasi murni: ini mengonfirmasi bahwa produsen masih menghormati perjanjian yang diandalkan oleh konsumen. Asersi API pada status, skema, dan header adalah unit kerja verifikasi.
Validasi untuk API berarti memeriksa apakah API benar-benar melayani konsumennya:
- Dapatkah klien menyelesaikan alur kerja end-to-end yang nyata, login, membuat, memperbarui, menghapus, tanpa solusi sementara yang canggung?
- Apakah data yang dikembalikan API benar-benar menjawab pertanyaan yang diajukan pengembang klien?
- Apakah model otentikasi praktis untuk integrasi yang ada?
- Apakah contoh yang didokumentasikan mencerminkan bagaimana API sebenarnya digunakan?
Skenario pengujian API yang merangkai beberapa permintaan ke dalam perjalanan pengguna yang lengkap lebih mendekati validasi; pemeriksaan skema satu endpoint adalah verifikasi. Keduanya termasuk dalam suite. Memahami skenario pengujian vs kasus pengujian membantu Anda melihat lapisan mana yang sedang Anda kerjakan.
Di mana Apidog cocok
Apidog mendukung kedua sisi perbedaan karena menyimpan desain, pengujian, dan dokumentasi API dalam satu ruang kerja.
Untuk verifikasi, desain API adalah spesifikasi. Ketika Anda membangun pengujian, Anda mengasumsikan respons terhadap skema yang sama yang mendefinisikan API, sehingga verifikasi tidak memiliki salinan kedua dari kontrak yang menyimpang. Asersi skema, asersi status, dan pemeriksaan kontrak semuanya berjalan terhadap sumber kebenaran. Jalankan pada setiap komit melalui CI; mengotomatiskan pengujian API di CI/CD membuat verifikasi berkelanjutan, yaitu kapan seharusnya terjadi.
Untuk validasi, skenario pengujian Apidog merangkai beberapa endpoint ke dalam alur kerja yang lengkap. Anda dapat membangun skenario yang mendaftarkan pengguna, login, membuat sumber daya, dan mengonfirmasi hasilnya, lalu menjalankannya seperti yang dilakukan klien sungguhan. Latihan end-to-end itulah cara Anda memeriksa apakah API memecahkan masalah yang sebenarnya, bukan hanya bahwa setiap endpoint cocok dengan barisnya dalam spesifikasi.
Pelaporan menutup putaran. Apidog menghasilkan hasil per langkah, sehingga pemeriksaan verifikasi yang gagal (ketidakcocokan skema) dan pemeriksaan validasi yang gagal (alur kerja multi-langkah yang rusak) keduanya terlihat, berbeda, dan dapat dilacak.
Unduh Apidog untuk menyiapkan verifikasi tingkat kontrak dan validasi tingkat alur kerja terhadap API Anda sendiri.
Contoh dunia nyata
Bayangkan sebuah tim sedang membangun API pembayaran. Spesifikasi mengatakan POST /payments menerima jumlah dan mata uang, mengembalikan 201 dengan payment_id, dan menolak mata uang yang tidak valid dengan 400.
Verifikasi pada API ini berjalan lancar. Tinjauan kode mengonfirmasi penangan cocok dengan desain. Asersi skema mengonfirmasi setiap respons memiliki bidang dan tipe yang didokumentasikan. Pengujian kontrak mengonfirmasi bentuk kesalahan 400 persis seperti yang ditentukan. Pemeriksaan kode status lulus secara keseluruhan. Dengan setiap ukuran verifikasi, API dibangun dengan benar.
Kemudian klien nyata pertama berintegrasi. Mereka menemukan bahwa API menerima jumlah sebagai angka floating-point, sehingga 0.1 + 0.2 dibulatkan ke nilai yang tidak cocok dengan faktur pelanggan. Spesifikasi mengatakan "jumlah: angka." Implementasi menghormatinya dengan sempurna. Spesifikasi itu salah; uang seharusnya tidak pernah menjadi float. Verifikasi tidak akan pernah bisa menangkap ini, karena verifikasi hanya memeriksa implementasi terhadap spesifikasi, dan keduanya setuju.
Validasi menangkapnya. Saat klien menjalankan pembayaran end-to-end yang nyata dan merekonsiliasinya dengan faktur, kesalahan pembulatan muncul. Perbaikannya bukanlah laporan cacat kode; itu adalah perubahan spesifikasi, jumlah menjadi unit minor bilangan bulat. Itulah ciri temuan validasi: jawabannya bukan "perbaiki kode agar sesuai dengan spesifikasi," tetapi "spesifikasi itu sendiri salah."
Inilah mengapa keduanya penting. Verifikasi akan menghasilkan implementasi yang sempurna dari kontrak yang rusak. Validasi, menggunakan API sebagaimana konsumen sungguhan melakukannya, adalah satu-satunya hal yang mengungkap kontrak sebagai masalah.
Daftar periksa praktis
Untuk setiap rilis API, jalankan kedua kolom:
Verifikasi (terhadap spesifikasi):
- Setiap endpoint mengembalikan kode status yang didokumentasikan
- Setiap respons sesuai dengan skemanya
- Parameter yang diperlukan ditegakkan
- Respons kesalahan cocok dengan bentuk yang didokumentasikan
- Pengujian kontrak lulus untuk semua endpoint yang menghadap konsumen
Validasi (terhadap tujuan):
- Klien baru dapat menyelesaikan alur kerja inti dari awal hingga akhir
- Data yang dikembalikan menjawab pertanyaan klien yang sebenarnya
- Alur otentikasi berfungsi untuk pola integrasi yang sebenarnya
- Contoh yang didokumentasikan cocok dengan penggunaan nyata
- Pemangku kepentingan mengonfirmasi API memecahkan masalah yang dimaksudkan
Jika hanya kolom pertama yang lulus, Anda memiliki implementasi yang benar dari desain yang mungkin salah. Jika hanya yang kedua yang lulus, Anda memiliki ide yang tepat pada kode yang goyah. Merilis dengan percaya diri berarti keduanya.
Pertanyaan yang sering diajukan
Apakah verifikasi atau validasi dilakukan terlebih dahulu? Verifikasi dimulai lebih dulu dan berjalan terus-menerus, karena Anda dapat memeriksa kode terhadap spesifikasi segera setelah kode itu ada. Validasi datang setelah ada produk yang dapat digunakan untuk diuji terhadap kebutuhan nyata.
Apakah pengujian sama dengan validasi? Tidak. Pengujian mencakup keduanya. Uji unit dan pemeriksaan skema adalah verifikasi; pengujian penerimaan dan end-to-end adalah validasi. Istilah "pengujian" mencakup seluruh rentang.
Dapatkah perangkat lunak lulus verifikasi tetapi gagal validasi? Ya, dan ini umum. Implementasinya sangat cocok dengan spesifikasi, tetapi spesifikasi itu memecahkan masalah yang salah. Produk itu diverifikasi tetapi tidak divalidasi.
Bagaimana ini berlaku untuk pengujian kontrak API? Pengujian kontrak adalah verifikasi. Ini mengonfirmasi bahwa API masih menghormati perjanjian yang didokumentasikan dengan konsumen. Ini tidak mengonfirmasi bahwa perjanjian itu benar; itu adalah tugas validasi.
Mana yang menemukan lebih banyak bug? Verifikasi menemukan lebih banyak cacat berdasarkan jumlah, karena berjalan terus-menerus dan menangkap penyimpangan kecil lebih awal. Validasi menemukan lebih sedikit masalah tetapi yang lebih mahal, karena kegagalan validasi biasanya berarti persyaratan atau desainnya salah, bukan hanya kodenya.
Bisakah otomatisasi mencakup keduanya? Otomatisasi menangani verifikasi dengan baik: pemeriksaan skema, pengujian kontrak, dan asersi status berjalan pada setiap komit. Validasi lebih sulit untuk diotomatisasi sepenuhnya karena bergantung pada penilaian tentang kesesuaian dunia nyata, meskipun pengujian alur kerja end-to-end mengotomatisasi bagian yang berarti darinya.