"Pengujian fungsional versus pengujian otomatis" adalah salah satu perbandingan paling umum di QA, dan perbandingan ini dibangun di atas sebuah kesalahan. Kedua istilah tersebut bukanlah lawan kata. Keduanya menjelaskan hal yang sangat berbeda, dan Anda bisa memiliki salah satu tanpa yang lain, atau keduanya sekaligus. Memperlakukan keduanya sebagai sebuah pilihan, fungsional *atau* otomatis, membuat tim membangun strategi pengujian yang salah.
Panduan ini akan mengurai kedua istilah tersebut, menjelaskan dua sumbu terpisah tempat keduanya berada, dan menunjukkan di mana masing-masing cocok dalam alur kerja pengujian API yang sebenarnya.
Kesalahan kategori
Kebingungan muncul dari membandingkan jawaban atas dua pertanyaan yang berbeda.
Pengujian fungsional menjawab: apa yang sedang kita uji? Ini menguji apakah perangkat lunak melakukan apa yang seharusnya dilakukannya, fitur-fitur, perilaku, dan outputnya.
Pengujian otomatis menjawab: bagaimana kita menjalankan pengujian? Ini menjalankan pengujian dengan alat perangkat lunak alih-alih manusia yang melakukan langkah-langkah secara manual.
Ini independen. "Apa yang Anda uji" dan "bagaimana Anda menjalankannya" adalah sumbu yang terpisah. Sebuah pengujian fungsional dapat dijalankan secara manual atau otomatis. Sebuah pengujian otomatis dapat memeriksa perilaku fungsional atau perilaku non-fungsional seperti kinerja. Jadi perbandingan yang sebenarnya bukanlah fungsional versus otomatis; ini adalah dua dimensi berbeda yang kebetulan disebutkan bersamaan.
Setelah Anda melihat itu, pertanyaan "haruskah kita melakukan pengujian fungsional atau pengujian otomatis?" menjadi tidak masuk akal. Pertanyaan yang tepat adalah: apa yang harus kita uji, dan mana dari pengujian tersebut yang harus kita otomatiskan?
Apa itu pengujian fungsional
Pengujian fungsional memverifikasi bahwa setiap fitur aplikasi berperilaku sesuai dengan persyaratannya. Ini biasanya black-box: penguji memeriksa input dan output tanpa melihat kode internal. Berikan input pada fitur, amati outputnya, bandingkan dengan apa yang dikatakan persyaratan harus terjadi.
Untuk API, pengujian fungsional berarti mengonfirmasi bahwa suatu endpoint mengembalikan data yang benar, kode status yang benar, dan respons kesalahan yang benar. Apakah POST /orders membuat pesanan? Apakah ia menolak payload yang tidak valid dengan 400? Apakah respons sesuai dengan skema yang didokumentasikan? Itu adalah pemeriksaan fungsional, dan semuanya bertumpu pada API assertions yang membandingkan respons aktual dengan yang diharapkan.
Kekuatan pengujian fungsional adalah relevansi langsung: ia memeriksa hal yang benar-benar diperhatikan pengguna, yaitu apakah fiturnya berfungsi. Batasnya adalah cakupan. Pengujian fungsional saja tidak mengatakan apa-apa tentang kecepatan, stabilitas di bawah beban, atau keamanan. Sebuah endpoint bisa sempurna secara fungsional dan masih runtuh di bawah lalu lintas; celah itulah yang ditangani oleh pengujian kinerja. Pengujian fungsional diperlukan, tetapi bukan gambaran keseluruhannya.
Lawan dari pengujian fungsional adalah pengujian non-fungsional, kinerja, beban, keamanan, kegunaan, yang merupakan lawan kata yang tepat untuk istilah tersebut, bukan "pengujian otomatis."
Apa itu pengujian otomatis
Pengujian otomatis menggunakan alat dan skrip untuk mengeksekusi pengujian dan memeriksa hasilnya, alih-alih orang yang mengklik langkah-langkah secara manual. Anda menentukan pengujian sekali, dengan input dan hasil yang diharapkan, dan alat tersebut menjalankannya sesuai permintaan, sesuai jadwal, atau pada setiap perubahan kode.
Lawan dari pengujian otomatis adalah pengujian manual, di mana manusia melakukan setiap langkah. Itu adalah lawan kata yang tepat untuk istilah tersebut.
Nilai otomatisasi adalah konsistensi dan skala. Mesin menjalankan pengujian keseribu persis seperti yang pertama dan tidak pernah lelah. Ini membuat pengujian regresi cukup murah untuk dijalankan pada setiap commit. Biayanya adalah bahwa pengujian otomatis harus ditulis dan dipelihara, dan mereka tidak dapat menggunakan penilaian, mereka hanya memeriksa apa yang Anda perintahkan untuk diharapkan. Pembahasan yang lebih mendalam ada di apa itu pengujian otomatis.
Yang krusial, otomatisasi adalah mekanisme pengiriman, bukan jenis pengujian. Anda mengotomatiskan *beberapa jenis* pengujian, fungsional, kinerja, keamanan. "Pengujian otomatis" dengan sendirinya tidak mengatakan apa yang sedang diperiksa.
Bagaimana kedua sumbu digabungkan
Gabungkan kedua sumbu dan Anda mendapatkan empat kategori nyata, yang semuanya ada dalam praktik.
| Fungsional | Non-fungsional | |
|---|---|---|
| Manual | Seorang penguji mengklik alur checkout untuk mengonfirmasi bahwa itu berfungsi | Seorang penguji menilai apakah UI terasa responsif |
| Otomatis | Sebuah skrip memanggil endpoint dan memastikan responsnya benar | Sebuah load test menggerakkan 500 pengguna virtual dan mengukur latensi |
Setiap sel adalah jenis pengujian yang sah dan umum. Kiri atas, pengujian fungsional manual, adalah apa yang dibayangkan kebanyakan orang ketika mereka mendengar "pengujian." Kiri bawah, pengujian fungsional otomatis, adalah sebagian besar dari suite pengujian API modern: skrip atau skenario yang memeriksa fitur secara otomatis. Kolom kanan adalah pekerjaan non-fungsional, juga dilakukan dengan kedua cara.
Jadi keputusan penting bukanlah "fungsional atau otomatis." Keputusan penting adalah:
- Perilaku apa yang akan diuji: baik fungsional maupun non-fungsional membutuhkan cakupan.
- Pengujian mana yang akan diotomatisasi: yang stabil, berulang, bernilai tinggi; biarkan pemeriksaan eksplorasi dan yang membutuhkan penilaian tetap manual.
Sebuah pengujian dapat berada di sel mana pun, dan strategi yang sehat menggunakan keempatnya.
Di mana ini berlaku dalam pengujian API
Pengujian API adalah tempat di mana kedua sumbu paling bersih selaras, karena API sangat cocok untuk pengujian fungsional otomatis.
API memiliki kontrak yang jelas, permintaan dan respons yang terstruktur, dan tidak ada UI untuk dirender. Hal itu membuat perilaku fungsionalnya mudah diperiksa dengan skrip dan mudah dipastikan secara tepat. Jadi untuk API, sebagian besar pengujian fungsional harus diotomatisasi. Ada sedikit alasan untuk secara manual mengirim ulang permintaan yang sama dan melihat responsnya ratusan kali ketika alat dapat melakukannya pada setiap commit.
Pendekatan pengujian API praktis terlihat seperti ini. Pemeriksaan fungsional, kode status, badan respons, kesesuaian skema, bentuk kesalahan, ditulis sebagai kasus uji dan dikelompokkan ke dalam skenario uji. Skenario tersebut berjalan secara otomatis, pada setiap perubahan, melalui CI/CD. Pemeriksaan non-fungsional, beban dan kinerja, juga berjalan secara otomatis, sesuai jadwal. Upaya manual diarahkan pada pengujian eksplorasi dan untuk memvalidasi bahwa API benar-benar memecahkan masalah, pekerjaan validasi yang harus dilakukan oleh penilaian, bukan skrip.
Apa yang harus diotomatisasi dan apa yang harus tetap manual
Melihat kedua sumbu dengan jelas mengarah pada pertanyaan yang sebenarnya penting: dari semua pengujian fungsional yang dapat Anda jalankan, mana yang pantas diotomatisasi? Mengotomatisasi segalanya itu boros, dan mengotomatisasi hal yang salah menghasilkan suite yang lambat dan rapuh. Beberapa aturan membantu.
Otomatiskan yang berulang dan stabil. Sebuah pemeriksaan fungsional yang akan Anda jalankan pada setiap commit selama dua tahun ke depan adalah kandidat otomatisasi yang sempurna. Biaya penulisan akan terbayar ratusan kali. Pengujian regresi, pemeriksaan yang mengonfirmasi fitur lama masih berfungsi, adalah kasus yang paling jelas.
Otomatiskan jalur bernilai tinggi terlebih dahulu. Alur login, checkout, endpoint API inti, apa pun yang kegagalannya merupakan insiden serius, harus diotomatisasi lebih awal. Ini adalah pengujian yang tidak dapat Anda lewatkan di bawah tekanan tenggat waktu, dan otomatisasi menghilangkan godaan.
Jangan otomatisasi yang jarang atau tidak stabil. Pemeriksaan yang akan Anda jalankan dua kali tidak sepadan untuk diskripkan. Fitur yang masih berubah setiap hari akan merusak pengujiannya setiap hari; tunggu sampai stabil. Otomatisasi prematur pada target yang bergerak hanya menciptakan kebisingan pemeliharaan.
Jaga agar pengujian eksplorasi tetap manual. Pengujian otomatis hanya menemukan apa yang Anda perintahkan untuk dicari. Manusia yang mengutak-atik perangkat lunak dengan cara yang tidak diskripkan menemukan bug yang tidak seorang pun duga. Pekerjaan ini juga merupakan pengujian fungsional, dan harus tetap manual secara sengaja.
Jaga agar pemeriksaan berbasis penilaian tetap manual. Apakah pesan kesalahan benar-benar membantu, apakah alur kerja terasa koheren, apakah API benar-benar memecahkan masalah pengguna, ini membutuhkan seseorang. Tidak ada assertion yang menangkapnya.
Hasilnya adalah pemisahan yang disengaja: suite fungsional otomatis yang besar yang mencakup jalur yang stabil, kritis, berulang, dan upaya manual yang lebih kecil dan berkelanjutan yang berfokus pada eksplorasi dan penilaian. Tim yang mengotomatiskan dengan bijaksana mendapatkan umpan balik yang cepat tanpa suite yang rapuh; tim yang mengotomatiskan segalanya pada akhirnya memelihara pengujian alih-alih mengirimkan produk.
Membangun pengujian fungsional API otomatis di Apidog
Apidog dibangun untuk pengujian fungsional API otomatis tanpa scripting. Anda mendefinisikan sebuah endpoint, menambahkan assertion visual untuk status, bidang body, skema, dan waktu respons, lalu mengelompokkan permintaan ke dalam skenario uji. Skenario tersebut berjalan sesuai permintaan atau dalam pipeline CI, menjalankan pemeriksaan fungsional secara otomatis dan melaporkan assertion mana yang gagal.
Karena ruang kerja yang sama juga menjalankan load test, Anda mencakup kedua sumbu, fungsional dan non-fungsional, secara otomatis, di satu tempat. Skenario fungsional yang Anda bangun untuk kebenaran menjadi load test yang Anda jalankan untuk kinerja. Unduh Apidog untuk membangun suite pengujian fungsional otomatis untuk API yang sudah Anda miliki.
Pertanyaan yang sering diajukan
Apakah pengujian otomatis merupakan jenis pengujian fungsional? Tidak. Pengujian otomatis adalah cara menjalankan pengujian. Pengujian fungsional adalah kategori dari apa yang Anda uji. Sebuah pengujian otomatis bisa fungsional atau non-fungsional; sebuah pengujian fungsional bisa manual atau otomatis.
Bisakah pengujian fungsional diotomatisasi? Ya, dan untuk API biasanya harus begitu. Pengujian fungsional otomatis, skrip atau skenario yang memeriksa fitur pada setiap perubahan, adalah inti dari suite pengujian API modern.
Apa lawan sebenarnya dari pengujian fungsional? Pengujian non-fungsional: kinerja, beban, keamanan, dan kegunaan. Ini memeriksa kualitas selain apakah sebuah fitur menghasilkan output yang benar.
Haruskah setiap pengujian fungsional diotomatisasi? Tidak. Otomatiskan pemeriksaan yang stabil, berulang, dan bernilai tinggi. Jaga pengujian eksplorasi dan validasi berbasis penilaian tetap manual, karena otomatisasi tidak dapat memutuskan apakah sesuatu benar-benar baik, hanya apakah itu sesuai dengan harapan.
Dari mana sebuah tim harus memulai? Dengan pengujian fungsional API otomatis. Mereka cepat, stabil, dan mencakup logika inti. Tambahkan pengujian non-fungsional otomatis dan pengujian eksplorasi manual dari sana.
Apakah pengujian otomatis menggantikan penguji manual? Tidak. Ini menggantikan bagian pekerjaan mereka yang berulang, menjalankan ulang pemeriksaan yang sama, sehingga penguji dapat fokus pada pengujian eksplorasi, kasus ekstrem, dan menilai apakah perangkat lunak benar-benar baik. Tugas-tugas tersebut membutuhkan orang, dan nilainya lebih tinggi daripada mengklik daftar periksa regresi secara manual.
Bisakah pengujian yang sama menjadi fungsional dan otomatis? Ya, dan sebagian besar pengujian API persis seperti itu: pengujian fungsional otomatis. Sebuah skrip yang memanggil endpoint dan memastikan responsnya benar memeriksa fungsi dan berjalan secara otomatis. Kedua label tersebut menggambarkan aspek yang berbeda dari pengujian yang sama, bukan sebuah kontradiksi.