Temukan cara menggabungkan berbagai jenis pengujian ke dalam strategi wajar yang cocok dengan project Anda.
Selamat datang kembali! Artikel terakhir menjelaskan banyak dasar tentang cara menggunakan berbagai jenis pengujian dan kontennya, serta mengklarifikasi definisi jenis pengujian. Ingat gambar meme kecil ini? Anda mungkin bertanya-tanya bagaimana semua jenis pengujian yang telah Anda pelajari dapat bekerja sama.
Selanjutnya, Anda akan mempelajarinya. Artikel ini memberikan pengantar tentang cara menggabungkan jenis pengujian ini ke dalam strategi yang wajar dan memilih salah satu yang sesuai dengan proyek Anda.
Anda dapat membandingkan strategi ini dengan beberapa bentuk untuk lebih memahami artinya. Berikut daftar strategi dengan masing-masing ukuran dan cakupan pengembangan.
Mari kita lihat lebih dekat strategi-strategi itu dan pelajari makna di balik namanya.
Menentukan tujuan pengujian: Apa yang ingin Anda capai dengan pengujian ini?
Sebelum Anda dapat mulai membangun strategi yang baik, cari tahu sasaran pengujian Anda. Kapan Anda merasa bahwa aplikasi Anda telah diuji secara memadai?
Mencapai cakupan pengujian yang tinggi sering kali dipandang sebagai sasaran utama bagi developer dalam hal pengujian. Namun, apakah itu selalu merupakan pendekatan terbaik? Mungkin ada faktor penting lainnya yang perlu dipertimbangkan saat memutuskan strategi pengujian untuk memenuhi kebutuhan pengguna Anda.
Sebagai developer, Anda juga menggunakan banyak aplikasi dan perangkat lain. Dalam hal ini, Anda adalah pengguna yang mengandalkan semua sistem ini untuk “berfungsi dengan baik”. Selanjutnya, Anda mengandalkan banyak developer untuk melakukan yang terbaik agar aplikasi dan perangkat mereka berfungsi. Untuk membalikkan hal ini, sebagai developer, Anda juga berusaha memenuhi kepercayaan ini. Jadi, sasaran pertama Anda adalah mengirimkan software yang berfungsi dan melayani pengguna. Hal ini mencakup pengujian yang Anda tulis untuk memastikan kualitas aplikasi. Kent C. Dodds merangkumnya dengan sangat baik dalam postingannya Static vs Unit vs Integration vs E2E Testing for Frontend Apps:
Semakin mirip pengujian dengan cara penggunaan software, semakin percaya diri Anda.
oleh Kent C. Dodd
Kent menggambarkannya sebagai peningkatan kepercayaan diri dalam pengujian. Semakin dekat Anda menjangkau pengguna dengan memilih jenis pengujian yang sesuai, semakin Anda dapat memercayai pengujian untuk memiliki hasil yang valid. Dengan kata lain, semakin tinggi Anda mendaki piramida, semakin Anda percaya diri. Tapi tunggu dulu, apa itu piramida?
Menentukan strategi pengujian: Cara memilih strategi pengujian
Sebagai langkah pertama, tentukan bagian persyaratan mana yang perlu Anda periksa untuk memastikan bahwa terpenuhi. Cari tahu jenis pengujian apa yang akan digunakan dan pada tingkat detail apa Anda dapat mencapai tingkat keyakinan paling tinggi sekaligus mempertahankan struktur biaya yang efisien. Banyak developer mendekati topik ini dengan menggunakan analogi. Berikut yang paling umum, dimulai dari istilah klasik yang sudah terkenal.
Klasik: Piramida uji
Segera setelah Anda mulai mencari strategi pengujian, Anda mungkin akan menemukan piramida otomatisasi pengujian sebagai analogi pertama. Mike Cohn memperkenalkan konsep ini dalam bukunya "Succeeding with Agile". Kemudian, Martin Fowler memperluas konsep tersebut dalam artikelnya Practical Test Pyramid. Anda dapat menampilkan piramida secara visual sebagai berikut:
Seperti yang ditunjukkan dalam gambar ini, piramida uji terdiri dari tiga lapisan:
Satuan. Anda menemukan pengujian ini pada lapisan dasar piramida karena cepat dijalankan dan mudah dikelola. Pengujian tersebut diisolasi dan menarget unit pengujian yang paling kecil. Misalnya, lihat pengujian unit standar untuk produk yang sangat kecil.
Integrasi. Pengujian ini berada di tengah piramida, karena memiliki kecepatan eksekusi yang dapat diterima, tetapi membawa Anda lebih dekat ke pengguna daripada yang dapat dilakukan pengujian unit. Contoh pengujian integrasi adalah pengujian API. Anda juga dapat mengklasifikasikan pengujian komponen sebagai jenis ini.
Pengujian E2E (juga disebut pengujian UI). Pengujian ini menyimulasikan pengguna asli dan interaksi mereka. Pengujian tersebut memerlukan lebih banyak waktu untuk dijalankan sehingga memerlukan biaya yang lebih mahal. Mereka berada di bagian atas piramida.
Keyakinan versus sumber daya
Seperti yang telah dibahas secara singkat sebelumnya, urutan lapisan ini bukan suatu kebetulan. Diagram-diagram menunjukkan prioritas dan biaya-biaya terkait. Hal ini memberi Anda gambaran yang jelas tentang jumlah pengujian yang harus Anda tulis untuk setiap lapisan. Anda telah melihat ini dalam definisi jenis pengujian.
Karena pengujian E2E paling dekat dengan pengguna Anda, pengujian tersebut memberi Anda keyakinan besar bahwa aplikasi Anda berfungsi sebagaimana mestinya. Akan tetapi, mereka memerlukan tumpukan aplikasi lengkap dan pengguna yang disimulasikan, oleh karena itu, metode itu mungkin juga paling mahal. Jadi, tingkat keyakinannya adalah dalam persaingan langsung dengan sumber daya yang Anda butuhkan untuk menjalankan pengujian.
Piramida mencoba menyelesaikan masalah ini dengan membuat Anda lebih berfokus pada pengujian unit dan secara ketat memprioritaskan kasus yang dicakup oleh pengujian E2E. Misalnya, perjalanan pengguna yang paling penting atau tempat yang paling rentan terhadap kerusakan. Seperti yang ditekankan Martin Fowler, dua poin terpenting dalam piramida Cohn adalah sebagai berikut:
- Menulis pengujian dengan tingkat perincian yang berbeda.
- Semakin tinggi level yang Anda dapatkan, semakin sedikit pengujian yang seharusnya Anda miliki.
Piramida berkembang! Adaptasi piramida uji
Selama beberapa tahun, pembicaraan terus diputar di seputar piramida. Piramida tampaknya terlalu menyederhanakan strategi pengujian, mengabaikan banyak jenis pengujian, dan tidak lagi sesuai dengan semua proyek dunia nyata. Oleh karena itu, judul ini mungkin menyesatkan. Apakah piramida itu tidak berbentuk? Guillermo Rauch memiliki pendapat tentang hal ini:
Menulis pengujian. Tidak terlalu banyak. Sebagian besar integrasi.
oleh Guillermo Rauch
Ini adalah salah satu kutipan yang paling sering dikutip tentang subjek ini, jadi mari kita uraikan:
- "Menulis pengujian". Bukan hanya karena membangun kepercayaan, tetapi juga menghemat waktu dalam pemeliharaan.
- "Tidak terlalu banyak". Cakupan 100% tidak selalu baik karena pengujian tidak diprioritaskan dan akan ada banyak pemeliharaan.
- "Sebagian besar integrasi". Sekali lagi, penekanannya adalah pada pengujian integrasi: pengujian ini memiliki nilai bisnis paling besar dengan memberi Anda tingkat kepercayaan harian yang tinggi sekaligus mempertahankan waktu eksekusi yang wajar.
Hal ini membuat Anda berpikir kembali tentang piramida pengujian dan mengalihkan fokus Anda ke pengujian integrasi. Selama beberapa tahun terakhir, banyak adaptasi telah diusulkan, jadi mari kita lihat adaptasi yang paling umum.
Uji berlian
Adaptasi pertama menghilangkan penekanan berlebihan pada pengujian unit, seperti yang terlihat dalam piramida pengujian. Bayangkan Anda telah mencapai cakupan 100% pada pengujian unit. Namun, saat berikutnya Anda memfaktorkan ulang, Anda harus memperbarui banyak pengujian unit ini dan Anda mungkin tergoda untuk melewatinya. Sehingga terkikis.
Akibatnya, dan bersama dengan fokus yang lebih tinggi pada pengujian integrasi, bentuk berikut mungkin muncul:
Piramida berkembang menjadi berlian. Anda dapat melihat tiga lapisan sebelumnya, tetapi dengan ukuran yang berbeda, dan lapisan unit telah dipotong:
- Satuan. Tulis pengujian unit dengan cara Anda menentukannya sebelumnya. Namun, karena cenderung mengikis, memprioritaskan, dan hanya mencakup kasus yang paling kritis.
- Integrasi. Pengujian integrasi yang Anda ketahui, menguji kombinasi unit tunggal.
- E2E. Lapisan ini menangani pengujian UI yang mirip dengan piramida pengujian. Pastikan Anda hanya menulis pengujian E2E untuk kasus pengujian yang paling kritis.
Menguji honeycomb
Ada adaptasi lain, yang diperkenalkan oleh Spotify, yang mirip dengan berlian pengujian tetapi lebih dikhususkan untuk sistem software berbasis microservice. Pengujian honeycomb adalah analogi visual lainnya untuk perincian, cakupan, dan jumlah pengujian yang harus ditulis untuk sistem software berbasis microservice. Karena ukurannya yang kecil, kompleksitas paling besar pada microservice bukan pada layanan itu sendiri, tetapi pada cara layanan tersebut berinteraksi dengan layanan lain. Jadi, strategi pengujian untuk microservice harus fokus pada pengujian integrasi.
Bentuk ini mengingatkan kita pada sarang lebah, demikian namanya. Lapisan ini memiliki lapisan berikut:
- Pengujian terintegrasi. Artikel oleh Spotify menggunakan kutipan dari J. B. Rainsberger untuk menentukan lapisan ini: “Pengujian yang akan lulus atau gagal berdasarkan kebenaran sistem lain.” Pengujian tersebut memiliki dependensi eksternal yang perlu Anda pertimbangkan, dan sebaliknya, sistem Anda mungkin menjadi dependensi yang merusak sistem lain. Mirip dengan pengujian E2E dalam analogi lain, gunakan pengujian ini dengan hati-hati, hanya untuk kasus yang paling penting.
- Pengujian integrasi. Serupa dengan adaptasi lainnya, Anda harus berfokus pada lapisan ini. Layanan ini berisi pengujian yang memverifikasi ketepatan layanan Anda dengan cara yang lebih terisolasi, namun masih dikombinasikan dengan layanan lain. Artinya, pengujian juga akan menyertakan beberapa sistem lain dan berfokus pada titik interaksi, misalnya, melalui pengujian API.
- Pengujian pada detail implementasi. Pengujian ini menyerupai pengujian unit, yaitu pengujian yang berfokus pada bagian kode yang terisolasi secara alami sehingga memiliki kompleksitas internalnya sendiri.
Jika Anda ingin mengetahui lebih lanjut tentang strategi pengujian ini, lihat postingan yang membandingkan piramida uji dengan sarang lebah oleh Martin Fowler dan artikel asli dari Spotify.
Piala pengujian
Anda sudah dapat melihat fokus berulang pada pengujian integrasi. Namun, jenis lain yang Anda temukan di artikel sebelumnya tidak melakukan pengujian secara teori, tetapi masih merupakan aspek penting yang harus Anda pertimbangkan dalam strategi pengujian. Analisis statis hilang dari piramida uji dan di sebagian besar adaptasi yang telah Anda lihat sejauh ini. Ada adaptasi trofi pengujian yang mempertimbangkan analisis statis sambil mempertahankan fokus pada pengujian integrasi. Piala pengujian berasal dari kutipan sebelumnya oleh Guillermo Rauch dan dikembangkan oleh Kent C. Dodds:
Trofi pengujian adalah analogi yang menggambarkan perincian pengujian dengan cara yang sedikit berbeda. Model ini memiliki empat lapisan:
- Analisis statis. Alat ini memainkan peran penting dalam analogi ini dan memungkinkan Anda menemukan kesalahan ketik, kesalahan gaya, dan bug lainnya dengan menjalankan langkah-langkah proses debug yang telah diuraikan saja.
- Pengujian unit. Hal tersebut memastikan bahwa unit terkecil Anda diuji dengan tepat, tetapi piala pengujian tidak akan menekankannya seperti halnya piramida pengujian.
- Integrasi. Hal ini adalah fokus utamanya karena menyeimbangkan biaya dan tingkat keyakinan yang lebih tinggi dengan cara terbaik, seperti halnya adaptasi lainnya.
- Pengujian UI. Termasuk E2E dan pengujian visual, mereka berada di puncak piala pengujian, mirip dengan peran mereka dalam piramida uji coba.
Untuk membaca lebih lanjut tentang piala pengujian, lihat postingan blog oleh Kent C. Dodds untuk subjek ini.
Beberapa pendekatan yang lebih berfokus pada UI
Itu semua bagus dan bagus, tetapi tidak peduli bagaimana Anda menyebut strategi Anda, “piramida”, “sarang lebah”, atau “berlian”, masih ada yang belum lengkap. Meskipun otomatisasi pengujian sangat bermanfaat, perlu diingat bahwa pengujian manual tetaplah penting. Pengujian otomatis akan meringankan tugas rutin dan membebaskan para insinyur uji mutu untuk fokus pada area penting. Alih-alih mengganti pengujian manual, otomatisasi harus melengkapinya. Adakah cara untuk mengintegrasikan pengujian manual dengan otomatisasi untuk mendapatkan hasil yang optimal?
Menguji kerucut es dan menguji kepiting
Memang ada dua adaptasi piramida pengujian yang lebih berfokus pada cara pengujian yang berfokus pada UI ini. Keduanya memiliki keunggulan tingkat keyakinan tinggi, tetapi secara alami lebih mahal karena eksekusi uji yang lebih lambat.
Yang pertama, kerucut es uji, terlihat seperti piramida terbalik. Tanpa langkah pengujian manual, pizza ini juga dikenal sebagai pizza pengujian.
Kerucut es memiliki fokus yang lebih besar pada pengujian manual atau UI dan paling tidak fokus pada pengujian unit. Hal ini sering kali terbentuk dalam project di mana developer mulai bekerja hanya dengan beberapa pemikiran tentang strategi pengujian. Kode es dianggap sebagai antipola dan memang semestinya begitu. Ini adalah kode yang mahal dalam hal sumber daya dan pekerjaan manual.
Kepiting tes mirip dengan kerucut es tes, tetapi dengan lebih menekankan pada E2E dan pengujian visual:
Strategi pengujian ini mencakup satu aspek lagi: strategi ini memverifikasi bahwa aplikasi Anda berfungsi dan terlihat bagus. Tabel pivot pengujian menyoroti pentingnya pengujian visual, yang dijelaskan dalam artikel sebelumnya. Pengujian integrasi, yang dibagi menjadi pengujian komponen dan API, bergerak lebih jauh ke latar belakang, dan pengujian unit memainkan peran yang lebih sekunder di sini. Anda dapat menemukan detail lebih lanjut tentang strategi pengujian ini dalam artikel tentang kepiting pengujian.
Meskipun lebih mahal, kedua strategi pengujian ini memiliki perannya masing-masing: misalnya, dalam project lebih kecil yang memerlukan lebih sedikit pengujian, atau lebih sedikit kompleksitas yang perlu dicakup. Dalam hal ini, strategi pengujian menyeluruh yang berfokus pada pengujian integrasi mungkin direkayasa secara berlebihan.
Meskipun kedua strategi pengujian ini lebih mahal, keduanya tersedia, misalnya, dalam project lebih kecil yang memerlukan lebih sedikit pengujian dan tidak perlu mencakup banyak kerumitan. Dalam hal ini, strategi pengujian skala penuh yang berfokus pada pengujian integrasi mungkin terlalu rumit.
Saran praktis: Mari kita menyusun strategi!
Anda sekarang telah mempelajari strategi pengujian yang paling umum. Mulai dengan piramida klasik—piramida uji—dan mengenal berbagai adaptasinya. Sekarang Anda perlu mengevaluasinya untuk produk Anda dan memutuskan mana yang terbaik untuk proyek Anda. Jawaban atas pertanyaan ini harus dimulai dengan "Tergantung" favorit semua orang. Namun, itu tidak membuatnya kurang akurat.
Pilihan strategi pengujian yang paling tepat dari yang sudah dijelaskan—dan bahkan strategi yang tertinggal—bergantung pada aplikasi Anda. Bagian ini harus menjelaskan arsitektur, persyaratan Anda, dan terakhir, pengguna dan persyaratan mereka. Semua ini mungkin berbeda dari satu aplikasi ke aplikasi lainnya. Hal itu sangatlah wajar. Ingatlah bahwa tujuan Anda yang paling penting adalah untuk melayani pengguna Anda, bukan definisi dari buku teks.
Sering kali, pengujian di dunia nyata sulit dipisahkan dan ditentukan satu per satu. Bahkan Martin Fowler sendiri menekankan aspek positif dari definisi yang berbeda, seperti dalam kasus pengujian unit. Seperti yang dinyatakan dengan benar Justin Searls di tweetnya:
[...] menulis pengujian ekspresif yang menetapkan batas yang jelas, berjalan dengan cepat & andal, dan hanya gagal karena alasan yang berguna.
oleh Justin Searls
Fokus pada pengujian yang melaporkan kesalahan aktual yang mungkin dialami pengguna, dan jangan terganggu dari tujuan Anda. Pengujian harus dirancang untuk memberikan manfaat kepada pengguna, tidak hanya memberikan cakupan 100% atau untuk memperdebatkan persentase jenis pengujian yang akan ditulis.
Fokus pada pengujian yang melaporkan kesalahan dalam kehidupan nyata yang mungkin dialami pengguna dan yang tidak teralihkan dari tujuan Anda. Pengujian harus dirancang untuk memberikan manfaat kepada pengguna, tidak hanya memberikan cakupan 100% atau memicu perdebatan tentang persentase jenis pengujian tertentu yang harus Anda tulis.