Temukan cara menggabungkan berbagai jenis pengujian ke dalam strategi yang wajar dan cocok dengan project Anda.
Selamat datang kembali! Artikel terakhir telah meletakkan banyak dasar tentang cara mendekati berbagai jenis pengujian dan isinya, serta menjelaskan 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 mempelajari hal tersebut. Artikel ini memberikan pengantar tentang cara menggabungkan jenis pengujian ini menjadi strategi yang wajar dan memilih salah satu yang cocok dengan project Anda.
Anda dapat membandingkan strategi dengan sejumlah bentuk untuk lebih memahami maknanya. Berikut adalah daftar strategi dengan ukuran dan cakupan pengembangan masing-masing.
Mari kita pelajari lebih lanjut strategi tersebut dan pelajari makna di balik namanya.
Tentukan sasaran pengujian: Apa yang ingin Anda capai dengan pengujian ini?
Sebelum Anda dapat mulai membuat strategi yang baik, tentukan sasaran pengujian Anda. Kapan Anda menganggap bahwa aplikasi Anda telah diuji secara memadai?
Mencapai cakupan pengujian yang tinggi sering kali dipandang sebagai tujuan akhir bagi developer dalam hal pengujian. Namun, apakah ini selalu merupakan pendekatan terbaik? Mungkin ada faktor penting lain yang perlu dipertimbangkan saat memutuskan strategi pengujian—memenuhi kebutuhan pengguna.
Sebagai developer, Anda juga menggunakan banyak aplikasi dan perangkat lainnya. Dalam hal ini, Anda adalah pengguna yang mengandalkan semua sistem ini untuk “berfungsi dengan baik”. Sebagai gantinya, Anda mengandalkan banyak developer untuk melakukan yang terbaik agar aplikasi dan perangkat mereka berfungsi. Untuk mengembalikan kepercayaan ini, sebagai developer, Anda juga harus berusaha memenuhi kepercayaan ini. Jadi, sasaran pertama Anda harus selalu mengirimkan software yang berfungsi dan melayani pengguna. Hal ini juga berlaku untuk pengujian yang Anda tulis untuk memastikan kualitas aplikasi. Kent C. Dodds merangkumnya dengan sangat baik dalam postingan Static vs Unit vs Integration vs E2E Testing for Frontend Apps:
Makin mirip pengujian Anda dengan cara software digunakan, makin besar keyakinan yang dapat Anda peroleh.
oleh Kent C. Dodds
Kent menggambarkannya sebagai mendapatkan keyakinan dalam pengujian. Makin dekat Anda dengan pengguna dengan memilih jenis pengujian yang sesuai, makin besar kepercayaan Anda bahwa pengujian akan memiliki hasil yang valid. Dengan kata lain, semakin tinggi Anda mendaki piramida, semakin percaya diri Anda. Tapi tunggu, apa itu piramida?
Menentukan strategi pengujian: Cara memilih strategi pengujian
Sebagai langkah pertama, tentukan bagian persyaratan yang perlu Anda periksa untuk memastikannya terpenuhi. Cari tahu jenis pengujian yang akan digunakan dan tingkat detail yang dapat Anda capai dengan tingkat keyakinan tertinggi sekaligus mempertahankan struktur biaya yang efisien. Banyak developer membahas topik ini dengan menggunakan analogi. Berikut adalah yang paling umum, dimulai dengan klasik yang terkenal.
Klasik: Piramida pengujian
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 ini dalam artikel Practical Test Pyramid. Anda dapat merepresentasikan piramida secara visual sebagai berikut:
Seperti yang ditunjukkan dalam gambar ini, piramida pengujian terdiri dari tiga lapisan:
Unit. Anda akan menemukan pengujian ini di lapisan dasar piramida karena pengujian ini cepat dijalankan dan mudah dikelola. Pengujian ini terisolasi dan menargetkan 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 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 interaksinya. Pengujian tersebut memerlukan lebih banyak waktu untuk dijalankan sehingga lebih mahal. Mereka berada di bagian atas piramida.
Keyakinan versus resource
Seperti yang telah dibahas secara singkat sebelumnya, urutan lapisan bukanlah kebetulan. Laporan ini menampilkan prioritas dan biaya yang sesuai. Hal ini memberi Anda gambaran yang jelas tentang jumlah pengujian yang harus ditulis untuk setiap lapisan. Anda telah melihatnya dalam definisi jenis pengujian.
Karena pengujian E2E paling dekat dengan pengguna, pengujian ini memberi Anda keyakinan terbesar bahwa aplikasi Anda berfungsi sebagaimana mestinya. Namun, alat ini memerlukan stack aplikasi lengkap dan pengguna simulasi, sehingga berpotensi menjadi yang paling mahal. Jadi, keyakinan bersaing langsung dengan resource yang Anda perlukan untuk menjalankan pengujian.
Piramida ini mencoba memecahkan masalah ini dengan membuat Anda lebih berfokus pada pengujian unit dan memprioritaskan kasus yang tercakup dalam pengujian E2E secara ketat. Misalnya, perjalanan pengguna yang paling penting atau tempat yang paling rentan terhadap kerusakan. Seperti yang ditekankan oleh Martin Fowler, dua poin terpenting dalam piramida Cohn adalah sebagai berikut:
- Tulis pengujian dengan perincian yang berbeda.
- Makin tinggi level yang Anda dapatkan, makin sedikit pengujian yang harus Anda lakukan.
Piramida telah berkembang. Adaptasi piramida pengujian
Selama beberapa tahun, diskusi telah berputar di sekitar piramida. Piramida ini tampaknya menyederhanakan strategi pengujian, mengabaikan banyak jenis pengujian, dan tidak lagi sesuai dengan semua project di dunia nyata. Oleh karena itu, informasi ini mungkin menyesatkan. Apakah piramida sudah 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 urai:
- "Tulis pengujian". Tidak hanya karena membangun kepercayaan, tetapi juga karena menghemat waktu dalam pemeliharaan.
- "Tidak terlalu banyak". Cakupan 100% tidak selalu baik karena pengujian Anda tidak diprioritaskan dan akan ada banyak pemeliharaan.
- "Sebagian besar integrasi". Di sini, penekanannya kembali pada pengujian integrasi: pengujian ini memiliki nilai bisnis terbanyak dengan memberi Anda tingkat keyakinan tinggi setiap hari sekaligus mempertahankan waktu eksekusi yang wajar.
Hal ini membuat Anda berpikir kembali tentang piramida pengujian dan mengalihkan fokus ke pengujian integrasi. Selama beberapa tahun terakhir, banyak adaptasi yang telah diusulkan, jadi mari kita lihat adaptasi yang paling umum.
Uji diamond
Adaptasi pertama menghilangkan penekanan berlebihan pada pengujian unit, seperti yang terlihat pada 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. Jadi, mereka terkikis.
Akibatnya, dan bersama dengan fokus yang lebih tinggi pada pengujian integrasi, bentuk berikut dapat muncul:
Piramida berubah menjadi berlian. Anda dapat melihat tiga lapisan sebelumnya, tetapi dengan ukuran yang berbeda, dan lapisan unit telah dipotong:
- Unit. Tulis pengujian unit seperti yang Anda tentukan sebelumnya. Namun, karena cenderung terkikis, prioritaskan dan hanya bahas kasus yang paling penting.
- Integrasi. Pengujian integrasi yang Anda ketahui, menguji kombinasi satu unit.
- E2E. Lapisan ini menangani pengujian UI yang mirip dengan piramida pengujian. Pastikan untuk hanya menulis pengujian E2E untuk kasus pengujian yang paling penting.
Menguji sarang lebah
Ada adaptasi lain, yang diperkenalkan oleh Spotify, yang mirip dengan berlian pengujian, tetapi lebih dikhususkan untuk sistem software berbasis microservice. Honeycomb pengujian adalah analogi visual lain untuk tingkat perincian, cakupan, dan jumlah pengujian yang akan ditulis untuk sistem software berbasis microservice. Karena ukurannya yang kecil, kompleksitas yang paling besar dalam microservice bukanlah dalam layanan itu sendiri, tetapi dalam cara layanan tersebut berinteraksi dengan layanan lainnya. Jadi, strategi pengujian untuk microservice harus terutama berfokus pada pengujian integrasi.
Bentuk ini mengingatkan kita pada sarang lebah, sehingga namanya. Laporan 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 merupakan dependensi yang merusak sistem lain. Serupa 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. Pengujian ini berisi pengujian yang memverifikasi kebenaran layanan Anda dengan cara yang lebih terisolasi, tetapi tetap dikombinasikan dengan layanan lain. Artinya, pengujian juga akan mencakup beberapa sistem lain dan berfokus pada titik interaksi, misalnya, melalui pengujian API.
- Pengujian pada detail penerapan. Pengujian ini menyerupai pengujian unit—pengujian yang berfokus pada bagian kode yang secara alami terisolasi sehingga memiliki kompleksitas internalnya sendiri.
Jika Anda ingin mengetahui lebih lanjut strategi pengujian ini, lihat postingan yang membandingkan piramida pengujian dengan sarang lebah oleh Martin Fowler dan artikel asli dari Spotify.
Trofi pengujian
Anda sudah dapat melihat fokus berulang pada pengujian integrasi. Namun, jenis lain yang Anda temukan di artikel sebelumnya bukanlah pengujian dalam teori, tetapi tetap merupakan aspek penting yang harus Anda pertimbangkan dalam strategi pengujian. Analisis statis tidak ada dalam piramida pengujian dan di sebagian besar adaptasi yang telah Anda lihat sejauh ini. Ada adaptasi trofi pengujian yang memperhitungkan analisis statis sekaligus mempertahankan fokus pada pengujian integrasi. Trofi pengujian berasal dari kutipan sebelumnya oleh Guillermo Rauch dan dikembangkan oleh Kent C. Dodds:
Piala pengujian adalah analogi yang menggambarkan perincian pengujian dengan cara yang sedikit berbeda. Laporan 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 hanya dengan menjalankan langkah-langkah proses debug yang telah diuraikan.
- Pengujian unit. Pengujian ini memastikan bahwa unit terkecil Anda diuji dengan tepat, tetapi piala pengujian tidak akan menekankannya dengan tingkat yang sama seperti piramida pengujian.
- Integrasi. Hal ini merupakan fokus utama karena menyeimbangkan biaya dan keyakinan yang lebih tinggi dengan cara terbaik, seperti halnya adaptasi lainnya.
- Pengujian UI. Termasuk pengujian E2E dan visual, keduanya berada di bagian atas piala pengujian, mirip dengan perannya dalam piramida pengujian.
Untuk membaca lebih lanjut tentang piala pengujian, lihat postingan blog oleh Kent C. Dodds tentang subjek ini.
Beberapa pendekatan yang lebih berfokus pada UI
Itu bagus, tetapi apa pun nama strategi Anda, “piramida”, “sarang lebah”, atau “berlian”, masih ada yang kurang. Meskipun otomatisasi pengujian sangat berharga, penting untuk diingat bahwa pengujian manual masih sangat penting. Pengujian otomatis harus meringankan tugas rutin dan membebaskan engineer jaminan kualitas untuk berfokus pada area penting. Otomatisasi harus melengkapi, bukan menggantikan, pengujian manual. Apakah ada 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 berupa keyakinan tinggi, tetapi secara alami lebih mahal karena eksekusi pengujian yang lebih lambat.
Yang pertama, es krim kerucut pengujian, terlihat seperti piramida terbalik. Tanpa langkah pengujian manual, proses ini juga dikenal sebagai pizza pengujian.
Es krim kerucut memiliki fokus yang lebih besar pada pengujian manual atau UI dan paling sedikit fokus pada pengujian unit. Hal ini sering kali terjadi dalam project yang dimulai oleh developer dengan hanya beberapa pemikiran tentang strategi pengujian. Kode es dianggap sebagai anti-pola dan memang demikian. Kode ini mahal dalam hal resource dan pekerjaan manual.
Kepiting pengujian mirip dengan es krim kerucut pengujian, tetapi dengan penekanan lebih pada pengujian E2E dan visual:
Strategi pengujian ini mencakup satu aspek lagi: strategi ini memverifikasi bahwa aplikasi Anda berfungsi dan terlihat bagus. Kepiting 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 selengkapnya tentang strategi pengujian ini dalam artikel tentang kepiting pengujian ini.
Meskipun lebih mahal, kedua strategi pengujian ini memiliki tempatnya: misalnya, dalam project yang lebih kecil yang memerlukan lebih sedikit pengujian, atau lebih sedikit kompleksitas yang perlu dibahas. Dalam hal ini, strategi pengujian menyeluruh yang berfokus pada pengujian integrasi mungkin terlalu rumit.
Meskipun kedua strategi pengujian ini lebih mahal, keduanya memiliki tempatnya, misalnya, dalam project yang lebih kecil yang memerlukan lebih sedikit pengujian dan tidak perlu mencakup banyak kompleksitas. Dalam hal ini, strategi pengujian skala penuh yang berfokus pada pengujian integrasi mungkin tidak perlu rumit.
Saran praktis: Mari kita buat strategi.
Sekarang Anda telah mempelajari strategi pengujian yang paling umum. Anda memulai dengan yang klasik—piramida pengujian—dan mengenal banyak adaptasinya. Sekarang Anda perlu mengevaluasinya untuk produk Anda dan memutuskan mana yang terbaik untuk project Anda. Jawaban untuk pertanyaan ini harus diawali dengan jawaban favorit semua orang, yaitu "Tergantung". Namun, hal ini tidak mengurangi keakuratannya.
Pilihan strategi pengujian yang paling sesuai dari yang dijelaskan—dan bahkan yang dihilangkan—bergantung pada aplikasi Anda. Desain harus sesuai dengan arsitektur, persyaratan, dan yang terakhir, pengguna serta persyaratan mereka. Semua ini mungkin berbeda untuk setiap aplikasi. Hal itu sangatlah wajar. Ingatlah bahwa sasaran Anda yang paling penting adalah melayani pengguna, bukan definisi 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 oleh Justin Searls dalam tweet-nya:
[…] menulis pengujian ekspresif yang menetapkan batasan yang jelas, berjalan dengan cepat & andal, dan hanya gagal karena alasan yang berguna.
oleh Justin Searls
Fokuslah pada pengujian yang melaporkan error sebenarnya yang mungkin dialami pengguna, dan jangan terdistraksi dari sasaran Anda. Pengujian harus dirancang untuk menguntungkan pengguna, bukan hanya memberikan cakupan 100% atau untuk memperdebatkan persentase jenis pengujian yang akan ditulis.
Fokuslah pada pengujian yang melaporkan error di dunia nyata yang mungkin dialami pengguna dan jangan terdistraksi dari sasaran Anda. Pengujian harus dirancang untuk menguntungkan pengguna, bukan hanya memberikan cakupan 100% atau memicu perdebatan tentang persentase jenis pengujian tertentu yang harus Anda tulis.