Artikel MADARA77
Node 01 / Platform Overview
MADARA77 | Automated Testing Bikin Update Sistem Gaming Nggak Meluncur Tanpa Lewat Pengujian
Ada satu kalimat yang cukup berbahaya dalam pengembangan software yaitu “di laptop gue jalan”. Sebuah perubahan bisa kelihatan normal saat dicoba sendiri tetapi mulai menunjukkan masalah ketika bertemu komponen lain data berbeda atau alur penggunaan yang nggak kepikiran sebelumnya. MADARA77 kali ini masuk ke automated testing untuk melihat bagaimana perubahan kode diperiksa berkali-kali sebelum sebuah update dianggap cukup siap untuk melangkah lebih jauh.
Pengujian otomatis bukan berarti komputer tiba-tiba tahu sendiri mana aplikasi yang bagus dan mana yang buruk. Tim tetap harus menentukan perilaku yang diharapkan lalu menulis test yang memeriksa perilaku tersebut. Bedanya setelah test tersedia pemeriksaan yang sama bisa dijalankan lagi setiap kali kode berubah tanpa seseorang harus mengulang semua langkah dari awal secara manual.
MADARA77 Mulai dari Perubahan Kecil yang Kelihatannya Aman
Bug nggak selalu datang dari perubahan besar. Kadang developer cuma mengubah satu fungsi kecil lalu tanpa sengaja memengaruhi bagian lain yang menggunakan fungsi tersebut.
Masalah seperti ini yang membuat testing penting. Tim membutuhkan cara untuk memastikan perilaku lama yang masih dibutuhkan nggak ikut rusak ketika fitur baru ditambahkan.
Semakin sering kode berubah semakin berat pula kalau seluruh pemeriksaan hanya mengandalkan pengecekan manual.
Automated Test Mengubah Pemeriksaan Menjadi Sesuatu yang Bisa Diulang
Bayangkan sebuah fungsi menerima input tertentu dan seharusnya menghasilkan output tertentu. Daripada seseorang mencoba fungsi tersebut setiap kali ada perubahan test dapat menjalankan skenario itu secara otomatis.
Kalau hasil aktual sesuai dengan yang diharapkan test lewat. Kalau berbeda test gagal dan memberikan sinyal bahwa ada sesuatu yang perlu diperiksa.
Sederhana memang tetapi ketika jumlah test bertambah kumpulan pemeriksaan tersebut menjadi pagar pengaman yang cukup berguna selama proses pengembangan.
Unit Test Menjaga Lingkup Pemeriksaan Tetap Kecil
Unit test biasanya fokus pada bagian kecil dari kode seperti function class atau komponen tertentu.
Karena ruang lingkupnya sempit test jenis ini biasanya bisa berjalan cepat. Developer dapat memeriksa banyak kondisi tanpa harus menyalakan seluruh sistem.
Buat teknologi MADARA77 unit test cocok sebagai lapisan awal untuk mengetahui apakah logika dasar masih bekerja setelah sebuah perubahan.
Satu Fungsi Sebaiknya Diuji dengan Lebih dari Satu Kondisi
Testing yang cuma memeriksa kondisi ideal gampang memberikan rasa aman palsu. Input di dunia nyata nggak selalu datang dalam bentuk yang paling nyaman.
Test dapat mencakup kondisi normal batas nilai input kosong format yang salah serta situasi lain yang memang relevan dengan fungsi tersebut.
Tujuannya bukan membuat skenario sebanyak mungkin tanpa arah tetapi memilih kasus yang membantu membuktikan perilaku penting.
Mock dan Test Double Membantu Mengisolasi Bagian Tertentu
Sebuah komponen kadang bergantung pada layanan lain. Kalau setiap unit test harus benar-benar memanggil database API atau service eksternal test bisa menjadi lambat dan sulit dikontrol.
Test double seperti mock atau stub dapat digunakan pada kondisi tertentu untuk menggantikan dependency tersebut selama pengujian.
Dengan begitu tim dapat fokus pada perilaku unit yang sedang diperiksa tanpa membuat test selalu bergantung pada sistem di luar ruang lingkupnya.
Lolos Unit Test Belum Berarti Semua Komponen Bisa Kerja Bareng
Dua komponen bisa lolos pengujian masing-masing tetapi gagal ketika disambungkan. Format data bisa berbeda konfigurasi bisa salah atau asumsi antara kedua bagian ternyata nggak cocok.
Di sinilah integration testing mulai mengambil peran.
Fokusnya bergeser dari apakah satu bagian bekerja sendiri menjadi apakah beberapa bagian dapat berkomunikasi dengan benar.
Integration Test Mulai Menyambungkan Potongan Sistem
Integration test dapat memeriksa hubungan aplikasi dengan database API internal message system atau dependency lain sesuai arsitektur yang digunakan.
Karena melibatkan lebih banyak komponen pengujiannya biasanya lebih berat dibanding unit test.
Sebagai gantinya tim mendapatkan gambaran mengenai masalah yang baru muncul ketika beberapa bagian mulai bekerja bersama.
Database Punya Banyak Titik yang Bisa Bikin Test Gagal
Kode aplikasi mungkin benar tetapi query schema migration atau constraint database bisa menghasilkan perilaku yang nggak sesuai.
Pengujian integrasi membantu melihat bagaimana aplikasi benar-benar berinteraksi dengan lapisan penyimpanan data.
Test data juga perlu dikontrol supaya hasil pengujian nggak berubah hanya karena environment mempunyai isi database yang berbeda.
API Testing Memeriksa Kontrak Antar-Layanan
Dalam sistem yang mempunyai beberapa layanan API menjadi salah satu titik pertemuan penting. Perubahan kecil pada nama field tipe data atau response dapat memengaruhi konsumen lain.
Automated API test dapat memeriksa status response struktur payload validasi input serta kondisi error yang memang sudah ditentukan.
Tujuannya supaya perubahan pada satu sisi nggak diam-diam merusak kontrak yang masih digunakan bagian lain.
End to End Test Melihat Sistem dari Jalur yang Lebih Panjang
Kalau unit test melihat potongan kecil end-to-end testing bergerak ke arah sebaliknya. Pengujian mencoba alur yang lebih lengkap dari titik awal sampai hasil akhir.
Misalnya browser membuka halaman melakukan tindakan tertentu lalu sistem memproses request dan memperbarui tampilan sesuai hasilnya.
Test seperti ini lebih dekat dengan pengalaman penggunaan nyata tetapi biasanya lebih lambat dan lebih mahal untuk dipelihara.
Semua Skenario Nggak Perlu Dipaksa Jadi End to End
Karena end-to-end terasa paling lengkap ada godaan untuk menguji semuanya lewat lapisan tersebut. Masalahnya test bisa menjadi lambat rapuh dan sulit mencari sumber kegagalannya.
Kalau sebuah aturan bisa diperiksa dengan unit test yang sederhana nggak selalu ada alasan membuat browser menjalankan seluruh aplikasi hanya untuk membuktikan aturan yang sama.
Kombinasi beberapa lapisan pengujian biasanya lebih masuk akal daripada menggantungkan seluruh kualitas pada satu jenis test.
Regression Testing Menjaga Fitur Lama Tetap Hidup
Salah satu risiko terbesar dari update adalah sesuatu yang nggak disentuh secara langsung justru ikut rusak.
Regression testing menggunakan kumpulan test untuk memeriksa apakah perilaku yang sebelumnya sudah bekerja masih tetap berjalan setelah perubahan baru masuk.
Inilah alasan automated testing terasa semakin berguna ketika aplikasi terus berkembang karena test lama dapat dijalankan kembali bersama test untuk fitur terbaru.
Bug yang Pernah Muncul Bisa Diubah Menjadi Test Baru
Ketika tim menemukan bug mereka nggak cuma bisa memperbaiki kodenya. Kasus tersebut juga dapat dijadikan test agar masalah yang sama lebih mudah terdeteksi kalau suatu hari muncul kembali.
Caranya adalah membuat skenario yang mereproduksi bug lalu memastikan test gagal sebelum perbaikan dan lolos setelah perbaikan diterapkan.
Sedikit demi sedikit kumpulan test akhirnya menyimpan banyak pelajaran dari masalah yang pernah ditemukan.
Test Data Harus Bisa Dikendalikan
Automated test membutuhkan kondisi awal yang jelas. Kalau hasilnya bergantung pada data acak yang terus berubah test bisa gagal hari ini lalu tiba-tiba lolos besok tanpa perubahan kode.
Karena itu data pengujian perlu dibuat konsisten dan dapat dipersiapkan ulang.
Setiap test idealnya memahami kondisi apa yang dibutuhkan daripada diam-diam bergantung pada sisa data dari test sebelumnya.
Flaky Test Bisa Bikin Tim Kehilangan Kepercayaan
Ada test yang kadang lolos dan kadang gagal meskipun kode nggak berubah. Kondisi seperti ini sering disebut flaky test.
Penyebabnya bisa bermacam-macam mulai dari timing dependency jaringan kondisi environment sampai test yang saling memengaruhi.
Kalau flaky test dibiarkan terlalu banyak tim bisa terbiasa mengabaikan kegagalan. Pada titik itu alarm pengujian kehilangan nilai karena orang nggak lagi yakin apakah kegagalan menunjukkan bug nyata.
Kecepatan Test Menentukan Seberapa Sering Ia Bisa Dipakai
Test yang memberikan hasil dalam beberapa detik bisa dijalankan berkali-kali selama developer bekerja. Sebaliknya suite yang membutuhkan waktu sangat lama cenderung dijalankan lebih jarang.
Karena itu kecepatan juga menjadi bagian dari desain testing.
Lapisan cepat dapat memberikan feedback awal sementara pengujian yang lebih berat dijalankan pada tahap berikutnya.
CI Pipeline Bisa Menjalankan Test Setiap Kode Berubah
Automated testing menjadi lebih berguna ketika dihubungkan dengan continuous integration. Setiap perubahan yang dikirim ke repository dapat memicu proses build dan kumpulan test secara otomatis.
Developer nggak harus mengandalkan ingatan untuk menjalankan seluruh pemeriksaan sebelum perubahan digabungkan.
Pipeline memberikan jalur pemeriksaan yang relatif konsisten untuk setiap perubahan.
Test Gagal Bisa Menahan Perubahan Sebelum Bergerak Lebih Jauh
Pipeline dapat mempunyai quality gate yang menentukan syarat minimum sebelum sebuah perubahan melanjutkan perjalanan.
Kalau test penting gagal build dapat dihentikan sehingga masalah diperiksa terlebih dahulu.
Pendekatan ini jauh lebih berguna daripada mengetahui bug setelah perubahan sudah berada pada tahap yang lebih jauh.
Code Coverage Memberi Angka tetapi Bukan Jawaban Lengkap
Coverage dapat menunjukkan bagian kode mana yang tersentuh ketika test berjalan. Informasi ini berguna untuk menemukan area yang sama sekali belum diperiksa.
Tetapi coverage tinggi nggak otomatis berarti kualitas test bagus. Sebuah baris bisa dieksekusi tanpa benar-benar mempunyai assertion yang membuktikan perilaku penting.
Karena itu angka coverage lebih cocok dijadikan sinyal daripada satu-satunya target kualitas.
Performance Testing Menanyakan Pertanyaan yang Berbeda
Functional test biasanya bertanya apakah sebuah fitur memberikan hasil yang benar. Performance testing bertanya bagaimana sistem berperilaku ketika menerima beban tertentu.
Tim dapat melihat response time throughput penggunaan resource atau titik ketika sistem mulai mengalami penurunan performa.
Test jenis ini membutuhkan skenario dan environment yang sesuai supaya hasilnya nggak ditafsirkan secara berlebihan.
Staging Jadi Tempat Bertemu Kondisi yang Lebih Lengkap
Sebelum update masuk production tim biasanya membutuhkan environment yang lebih mendekati konfigurasi sebenarnya.
Staging dapat digunakan untuk menjalankan integration test end-to-end test serta pemeriksaan lain yang membutuhkan beberapa komponen aktif secara bersamaan.
Tetap perlu diingat staging jarang identik seratus persen dengan production sehingga hasilnya bukan jaminan bahwa masalah nggak akan pernah muncul.
Manual Testing Tetap Punya Tempat
Automated testing bukan alasan menghapus manusia dari proses QA. Ada pengalaman visual usability eksplorasi dan kondisi baru yang lebih mudah ditemukan lewat pemeriksaan manusia.
Automation paling kuat untuk pekerjaan yang jelas berulang dan dapat didefinisikan secara konsisten.
Sementara exploratory testing memberi ruang bagi tester untuk mencoba jalur yang belum tentu pernah terpikir ketika test otomatis ditulis.
Test yang Bagus Harus Ikut Dirawat
Kode aplikasi berubah dan test juga perlu mengikuti perubahan yang memang disengaja. Test lama yang sudah nggak relevan bisa berubah menjadi beban.
Sebaliknya kalau setiap perubahan kecil membuat puluhan test harus ditulis ulang ada kemungkinan test terlalu terikat pada detail implementasi.
Maintenance menjadi bagian dari biaya automated testing yang perlu diperhitungkan sejak awal.
MADARA77 Nggak Menganggap Test Hijau Sebagai Jaminan Sempurna
Seratus test hijau hanya membuktikan bahwa seratus skenario yang ditulis berhasil melewati pemeriksaan. Masih mungkin ada kondisi lain yang belum pernah dimasukkan ke test suite.
Karena itu automated testing lebih tepat dipandang sebagai alat untuk menurunkan risiko dan mempercepat feedback bukan mesin yang bisa membuktikan software bebas bug.
Monitoring setelah release serta proses penanganan masalah tetap dibutuhkan.
Dari Satu Test MADARA77 Membangun Pagar Pengaman untuk Setiap Update
Tema MADARA77 kali ini akhirnya bukan soal seberapa banyak test yang bisa dibuat. Yang lebih penting adalah menempatkan pemeriksaan pada lapisan yang tepat. Unit test menjaga logika kecil integration test melihat hubungan antar-komponen dan end-to-end test memeriksa alur yang lebih lengkap.
Ketika semuanya masuk pipeline test dapat berjalan kembali setiap kali kode berubah. Regression yang ditemukan dapat diubah menjadi skenario baru sementara flaky test perlu dibereskan supaya hasil pengujian tetap dipercaya.
Update software memang nggak pernah bisa dibuat tanpa risiko sama sekali. Tetapi dengan automated testing MADARA77 perubahan nggak harus bergerak hanya berdasarkan perasaan bahwa kodenya sudah terlihat benar. Ada rangkaian pemeriksaan yang ikut berjalan sebelum update mendapat kesempatan untuk melangkah ke tahap berikutnya.
