Pengujian otomatis, tidak berbeda dengan perangkat lunak yang kita tulis. Mereka bermain pada lingkup prioritas yang sama seperti hal lain pada umumnya. Kamu punya fitur-fitur yang perlu ditentukan, desain yang dibuat, bugs yang perlu diperbaiki, rapat requirements gathering yang harus dilakukan, flags fitur yang harus disusun, dan lain-lain. Supaya dapat membuat prioritas dari aktivitas-aktivitas ini, kamu harus tau biaya dari tidak melakukannya dan manfaat bila diselesaikan. Dan ketika membuat prioritas, kamu tidak mengatakan, kamu "tidak akan" melakukan itu, kamu hanya mengatakan kamu akan mengerjakan satu hal terlebih dahulu. Jadi hal itu juga bisa membantu untuk tau, secara relatif, biaya/manfaat jika dilakukan nanti versus biaya/manfaat jika dilakukan sekarang.
Mari ambil beberapa skenario berbeda.
- Sebuah bug mencegah pengguna mengubah bio mereka jika mereka tidak memasang avatar lebih dulu.
- Alur checkout produk yang kamu buat tidak tercakup dalam pengujian.
Persoalan bug, biaya yang diterima berupa satu UI yang tidak bisa diandalkan bagi segelintir pengguna yang tidak mengunggah avatar, namun ingin mengubah bio mereka. Bukanlah pengalaman yang baik.
Persoalan alur checkout, itu cukup serius. Perubahan code apapun yang menyentuh alur tersebut bisa saja merusak alur checkout (berpotensi memberi kerugian uang bagi penjual dan waktu berharga bagi pembeli).
Saya pikir untuk kasus itu, mari prioritaskan menambah satu pengujian dulu, dan dilanjut perbaikan bug.
Ok, skenario yang lain.
- Kamu sedang membangun perusahaan startup dan kamu belum mulai menjual produk mu karena fiturnya belum cukup lengkap untuk dikatakan berguna. Kamu mulai kehabisan uang.
- Kamu baru saja menulis sebuah function kecil, untuk menghitung jarak scroll yang dibutuhkan scrollable list mu, pada saat pengguna menekan tombol ArrowDown dan kamu mencoba untuk memutuskan, dibuatkan pengujiannya atau tidak ya?
Demi kebaikanmu, abaikan pengujian tersebut, upayakan peluncuran produk mu dan jual lah! uang mu mulai menipis 🔥💵🔥
Dengan kata lain, kamu mungkin menemukan bahwa demo untuk klien potensial tidak berjalan dengan baik karena insinyur mu terus menerus menghasilkan code yang cacat. Dalam keadaan ini, tulislah satu atau dua pengujian E2E (End-to-End) yang cepat dan sederhana, untuk alur umum dalam demo dan jalankan itu sebelum kamu merge code apa pun.
Mari coba satu skenario terakhir. Iseng aja.
- Kamu baru saja mengimplementasikan sebuah fitur baru yang memungkinkan pengguna untuk membuat sebuah playlist dari lagu-lagu favorit mereka. Kamu memikirkan apakah perlu menambahkan pengujian.
- Kamu melihat sebuah font keren dan tema editor di sebuah siaran langsung dari developer favoritmu dan kamu ingin bertanya kepada mereka apa nama nya supaya kamu bisa mencoba nya.
😐
Apa yang ingin saya sampaikan pada postingan ini ialah pengujian tidaklah berbeda dengan urusan lainnya (apa saja) yang bisa kamu lakukan dengan waktu yang kamu punya. Pertimbangkan biaya dan manfaat, dan bertindak sesuai itu. Ingatlah bahwa pengujian adalah pemberi manfaat yang berkelanjutan.
Semoga beruntung!