Tim sering mengatakan mereka "menggunakan otomatisasi" seolah itu menyelesaikan pertanyaan tentang bagaimana pengujian mereka diatur. Padahal tidak. Dua suite dapat sama-sama otomatis dan tetap disusun dengan cara yang sama sekali berbeda, dengan biaya pemeliharaan yang sama sekali berbeda. Struktur adalah kerangka kerja, dan jenis kerangka kerja yang Anda pilih membentuk seberapa cepat pengujian berkembang, seberapa mudah non-programmer berkontribusi, dan seberapa buruk perubahan kecil UI dapat memengaruhi kode Anda.
Artikel ini membahas enam jenis kerangka kerja pengujian otomatisasi klasik: linear, modular, data-driven, keyword-driven, hybrid, dan behavior-driven. Artikel ini menjelaskan apa masing-masing jenis, di mana keunggulannya, dan di mana kekurangannya, sehingga Anda dapat mencocokkan struktur dengan tim Anda alih-alih mewarisi apa pun yang telah diatur oleh insinyur sebelumnya. Konsep-konsep ini berlaku untuk pengujian UI, API, dan unit.
Apa itu kerangka kerja pengujian otomatisasi
Kerangka kerja pengujian otomatisasi adalah seperangkat panduan, konvensi, dan komponen yang dapat digunakan kembali yang mendefinisikan bagaimana pengujian otomatis ditulis, diatur, dan dieksekusi. Ini bukan alat yang Anda instal. Ini adalah arsitektur tempat pengujian Anda berada.
Sebuah kerangka kerja menjawab pertanyaan struktural sebelum siapa pun menulis pengujian. Di mana data pengujian disimpan? Bagaimana langkah-langkah yang dapat digunakan kembali dibagikan? Siapa yang dapat berkontribusi, hanya programmer atau juga analis? Bagaimana hasilnya dilaporkan? Jenis kerangka kerja yang berbeda menjawab pertanyaan-pertanyaan itu secara berbeda, dan itulah yang membedakannya. Jika Anda baru mengenal ide yang lebih luas, gambaran umum kami tentang apa itu pengujian otomatis memberikan latar belakang yang berguna sebelum rincian jenis di bawah ini.
Alasan mengapa ini penting adalah pemeliharaan. Menulis seratus pengujian otomatis pertama itu mudah. Memelihara ribuan di antaranya saat aplikasi berubah setiap minggu itu sulit, dan jenis kerangka kerja adalah faktor terbesar tunggal dalam seberapa besar biaya pemeliharaan tersebut.
Pertimbangkan contoh konkret. Sebuah layar login mengubah label bidangnya. Dalam satu suite, perubahan itu merusak dua pengujian dan membutuhkan sepuluh menit untuk memperbaikinya. Dalam suite lain yang menguji aplikasi yang persis sama, itu merusak dua ratus pengujian dan membutuhkan dua hari. Aplikasi tersebut identik; hanya struktur kerangka kerja yang berbeda. Kesenjangan itulah seluruh alasan mengapa jenis kerangka kerja patut dipikirkan sebelum Anda menulis kode, bukan setelahnya.
Enam jenis kerangka kerja
1. Linear (rekam dan putar ulang)
Kerangka kerja linear merekam tindakan Anda dan memutarnya kembali sebagai skrip. Setiap pengujian adalah urutan langkah-langkah datar tanpa fungsi bersama dan tanpa pemisahan data dari logika. Alat menghasilkan skrip untuk Anda, sehingga hambatan masuk hampir nol.
Daya tariknya adalah kecepatan untuk proyek kecil, demo cepat, atau pemeriksaan asap sekali pakai. Biayanya muncul dengan cepat. Karena tidak ada yang digunakan kembali, langkah-langkah login yang sama disalin-tempel ke setiap pengujian. Ketika halaman login berubah, Anda mengedit lima puluh skrip. Kerangka kerja linear tidak berskala, dan sebagian besar tim mengatasinya dalam beberapa minggu.
2. Modular
Kerangka kerja modular memecah aplikasi menjadi modul-modul kecil yang independen dan menulis fungsi yang dapat digunakan kembali untuk setiap modul. Sebuah pengujian kemudian merupakan komposisi dari fungsi-fungsi tersebut: masuk, mencari, menambah ke keranjang, checkout. Ketika layar login berubah, Anda memperbaiki satu fungsi dan setiap pengujian mendapatkan manfaatnya.
Ini adalah struktur pertama yang benar-benar berskala. Komprominya adalah desain awal. Seseorang harus memutuskan batas modul dan membangun lapisan abstraksi sebelum pengujian berjalan cepat. Bagi sebagian besar tim rekayasa, modular adalah standar yang masuk akal, dan ini cocok dengan disiplin yang dijelaskan dalam panduan kami untuk menulis skrip pengujian otomatis.
3. Berbasis Data (Data-driven)
Kerangka kerja berbasis data memisahkan logika pengujian dari data pengujian. Satu fungsi pengujian berjalan berkali-kali terhadap baris input yang disimpan dalam file CSV, file JSON, spreadsheet, atau database. Cakupan bertambah dengan menambahkan baris, bukan dengan menulis kode.
Jenis ini ideal ketika alur kerja yang sama harus diverifikasi terhadap lusinan kombinasi input: login valid, login tidak valid, nilai batas, variasi lokal. Khusus untuk API, pendekatan pengujian berbasis data dengan CSV dan JSON mengubah satu permintaan menjadi ratusan kasus. Komprominya adalah logika pengujian itu sendiri tetap; struktur berbasis data memperluas input, bukan perilaku.
4. Berbasis Kata Kunci (Keyword-driven)
Kerangka kerja berbasis kata kunci mengabstraksi tindakan ke dalam kata kunci bernama seperti Login, SearchProduct, atau VerifyTotal. Pengujian ditulis sebagai tabel kata kunci plus argumen, seringkali dalam spreadsheet, sehingga non-programmer dapat menyusun pengujian tanpa menyentuh kode.
Kekuatannya adalah aksesibilitas. Analis QA dan staf bisnis dapat membangun dan membaca pengujian secara langsung. Biayanya adalah pustaka kata kunci: insinyur harus membangun dan memelihara implementasi di balik setiap kata kunci, dan set kata kunci yang dirancang dengan buruk menjadi beban pemeliharaan tersendiri. Struktur berbasis kata kunci cocok untuk tim di mana penulisan pengujian dan perancangan pengujian dibagi antara peran yang berbeda.
5. Hibrida (Hybrid)
Kerangka kerja hibrida menggabungkan dua atau lebih dari yang disebutkan di atas, paling umum adalah penggunaan ulang modular ditambah input berbasis data ditambah abstraksi kata kunci. Ini bukan jenis yang berbeda melainkan pengakuan pragmatis bahwa proyek nyata membutuhkan struktur yang berbeda di tempat yang berbeda.
Sebagian besar suite pengujian yang matang bersifat hibrida pada saat mereka mencapai beberapa ribu pengujian. Risikonya adalah ketidaksesuaian: jika kombinasi tidak dirancang dengan sengaja, Anda mendapatkan biaya pemeliharaan dari setiap jenis dan tidak ada kejelasan. Kerangka kerja hibrida berfungsi ketika campurannya disengaja dan didokumentasikan.
6. Berbasis Perilaku (BDD)
Kerangka kerja berbasis perilaku mengekspresikan pengujian dalam bahasa yang mendekati bahasa alami menggunakan pola Given-When-Then, biasanya ditulis dalam Gherkin dan dieksekusi oleh alat seperti Cucumber. Sebuah skenario berbunyi sebagai kalimat: diberikan pengguna terdaftar, ketika mereka mengirimkan kredensial yang valid, maka mereka mencapai dasbor.
Nilai BDD adalah pemahaman bersama. Produk, QA, dan rekayasa membaca spesifikasi yang sama, yang mengurangi kesenjangan antara apa yang diminta dan apa yang dibangun. Biayanya adalah dua lapisan: Gherkin yang dapat dibaca dan definisi langkah yang mengimplementasikannya. Jika staf produk tidak pernah benar-benar membaca skenario, Anda membayar biaya BDD tanpa mendapatkan manfaatnya. Panduan Gherkin kami untuk pengujian API BDD menunjukkan pola yang diterapkan pada API.
Membandingkan jenis kerangka kerja
| Jenis kerangka kerja | Penggunaan ulang | Non-programmer bisa membuat | Biaya penyiapan | Berskala |
|---|---|---|---|---|
| Linear | Tidak ada | Ya, melalui rekaman | Sangat rendah | Buruk |
| Modular | Tinggi | Tidak | Sedang | Baik |
| Berbasis data | Sedang | Sebagian | Sedang | Baik untuk input |
| Berbasis kata kunci | Tinggi | Ya | Tinggi | Baik |
| Hibrida | Tinggi | Kadang-kadang | Tinggi | Sangat baik |
| BDD | Tinggi | Ya, untuk membaca dan membuat | Tinggi | Baik |
Tabel ini menjelaskan polanya dengan jelas. Penyiapan yang lebih murah cenderung berarti skalabilitas yang lebih buruk, dan struktur yang melibatkan non-programmer membutuhkan lebih banyak investasi rekayasa di balik layar. Tidak ada opsi gratis, hanya opsi yang sesuai dengan batasan Anda.
Kesalahan umum kerangka kerja
Bahkan tim yang memilih jenis yang masuk akal sering kali merusaknya dalam praktiknya. Tiga kesalahan muncul berulang kali.
Yang pertama adalah abstraksi prematur. Sebuah tim mengadopsi struktur berbasis kata kunci atau hibrida untuk suite yang memiliki lima belas pengujian. Lapisan abstraksi membutuhkan biaya lebih banyak untuk dibangun dan dipelihara daripada pengujian yang dilayaninya. Struktur harus mengikuti skala; biarkan duplikasi nyata membenarkan lapisan penggunaan ulang berikutnya.
Yang kedua adalah kebalikannya: menolak untuk berkembang. Suite linear yang berfungsi pada dua puluh pengujian masih linear pada empat ratus pengujian, dan setiap perubahan aplikasi sekarang memicu sapuan menyakitkan dari skrip yang disalin-tempel. Biaya untuk tetap linear menumpuk secara diam-diam sampai perubahan kecil tunggal menghapus satu hari kerja. Perhatikan sinyalnya, yaitu mengedit banyak pengujian untuk satu perubahan produk, dan refaktor menuju modular sebelum rasa sakit menjadi rutinitas.
Yang ketiga adalah memilih jenis untuk audiens yang tidak dimilikinya. BDD hanya memberikan hasil ketika non-insinyur benar-benar membaca Gherkin. Berbasis kata kunci hanya memberikan hasil ketika analis benar-benar membuat pengujian. Jika orang-orang itu tidak pernah menyentuh suite, Anda menanggung biaya lapisan tambahan tanpa manfaatnya. Cocokkan jenis dengan siapa yang benar-benar berpartisipasi, bukan dengan siapa yang mungkin secara teori.
Bagaimana memilih jenis kerangka kerja
Pilihlah berdasarkan tim dan proyek Anda, bukan berdasarkan tren.
- Ukuran dan masa pakai. Skrip sekali pakai bisa linear. Apa pun yang dipelihara selama lebih dari seperempat tahun harus modular minimal.
- Siapa yang menulis pengujian. Semua insinyur mengarah pada modular atau hibrida. Peran campuran mengarah pada berbasis kata kunci atau BDD.
- Variasi input. Banyak kombinasi input terhadap alur kerja yang stabil mengarah pada berbasis data.
- Kesenjangan komunikasi. Kesalahpahaman yang sering terjadi antara produk dan rekayasa mengarah pada BDD, karena spesifikasi bersama adalah manfaat utamanya.
- Keterampilan yang ada. Jenis kerangka kerja terbaik adalah yang dapat benar-benar dipelihara oleh tim Anda. Struktur yang elegan yang tidak dipahami siapa pun gagal lebih cepat daripada struktur sederhana yang dipahami semua orang.
Sebagian besar tim berakhir pada hibrida: penggunaan ulang modular sebagai tulang punggung, input berbasis data untuk kasus variasi tinggi, dan BDD di mana kolaborasi paling penting. Mulailah dengan sederhana dan biarkan rasa sakit yang nyata, bukan teori, membenarkan penambahan struktur. Untuk strategi pengujian di luar jenis kerangka kerja, perbedaan dalam panduan skenario pengujian versus kasus pengujian kami membantu Anda menentukan cakupan setiap pengujian.
Di mana platform membantu
Memilih jenis kerangka kerja adalah keputusan arsitektur. Melaksanakannya dengan baik masih membutuhkan alat yang tepat. Khusus untuk pengujian API, Apidog mendukung penggunaan ulang modular melalui permintaan bersama yang diparameterisasi, eksekusi berbasis data dari file CSV dan JSON, dan pembuat pengujian visual yang memungkinkan non-programmer menyusun pengujian, yang merupakan semangat struktur berbasis kata kunci tanpa pustaka kata kunci buatan tangan.
Ini penting karena jenis kerangka kerja hanya sebagus kemampuan tim untuk mengikutinya secara konsisten. Platform yang menerapkan struktur di dalamnya menjaga pengujian tetap koheren saat suite berkembang dan saat orang bergabung dan pergi. Anda dapat mengunduh Apidog untuk melihat bagaimana pola-pola ini terasa dalam praktik, lalu memutuskan berapa banyak kode kerangka kerja kustom yang masih Anda butuhkan. Jawaban jujurnya biasanya lebih sedikit dari yang Anda harapkan, karena Apidog sudah menangani lapisan permintaan, data, dan pelaporan yang akan diimplementasikan ulang oleh kerangka kerja buatan tangan.
Pertanyaan yang sering diajukan
Apa perbedaan antara alat otomatisasi dan kerangka kerja pengujian otomatisasi?
Alat menjalankan pengujian, seperti driver browser atau klien HTTP. Kerangka kerja adalah struktur di sekitar alat-alat itu: konvensi untuk mengatur pengujian, berbagi logika, menyediakan data, dan melaporkan hasil. Anda dapat memiliki alat tanpa kerangka kerja, tetapi pengujian akan sulit dipelihara. Kerangka kerja adalah yang membuat otomatisasi berkelanjutan.
Jenis kerangka kerja pengujian otomatisasi mana yang terbaik?
Tidak ada yang terbaik secara universal. Linear cocok untuk skrip sekali pakai, modular cocok untuk sebagian besar tim rekayasa, berbasis data cocok untuk variasi input yang tinggi, berbasis kata kunci dan BDD cocok untuk tim dengan keterampilan campuran, dan hibrida cocok untuk suite besar yang matang. Cocokkan jenis dengan keterampilan tim Anda dan masa pakai proyek daripada memilih opsi yang paling populer.
Apakah BDD hanya untuk API atau hanya untuk pengujian UI?
Keduanya tidak. BDD adalah pola struktural, bukan lapisan. Format Given-When-Then berfungsi untuk pengujian unit, API, dan UI. Persyaratan utamanya bukanlah lapisan pengujian tetapi audiens: BDD hanya memberikan manfaat ketika non-insinyur benar-benar membaca atau menulis skenario.
Bisakah saya mengubah jenis kerangka kerja setelah saya membangun sebuah suite?
Ya, tetapi membutuhkan upaya yang proporsional dengan ukuran suite. Beralih dari linear ke modular berarti mengekstrak fungsi-fungsi yang dapat digunakan kembali dari skrip yang disalin-tempel. Pelajarannya adalah memilih struktur yang berskala sejak awal, karena memperbaiki jenis kerangka kerja pada ribuan pengujian jauh lebih sulit daripada memulai dengan yang benar.
Apakah proyek kecil membutuhkan kerangka kerja sama sekali?
Proyek yang benar-benar berumur pendek dapat berjalan pada skrip linear yang direkam tanpa kerangka kerja nyata. Tetapi proyek "kecil" memiliki kebiasaan untuk berkembang. Jika sebuah suite akan hidup lebih lama dari beberapa minggu atau disentuh oleh lebih dari satu orang, bahkan struktur modular yang ringan pun akan menguntungkan dengan cepat.