Memanfaatkan RPA untuk Pengujian Perangkat Lunak: Pendekatan Strategis
Otomasi pengujian perangkat lunak yang tidak efektif terkenal karena menunda rilis sambil mengonsumsi jumlah sumber daya yang luar biasa.
Kadang-kadang, feed berita saya menampilkan artikel yang menawarkan “10 Trik Kehidupan Teratas.” Ini adalah tips dan trik tentang cara menggunakan produk rumah tangga biasa dengan cara yang tidak terduga untuk meningkatkan hidup Anda— “…dan trik nomor 7 akan membingungkan pikiran Anda!!!”
Tidak dapat disangkal, saya telah tertipu untuk membuka klik ini. Untuk jujur, ada kalanya saya agradable terkejut. Misalnya, siapa yang tahu bahwa Anda dapat memotong plastik blister pack yang mengganggu dengan pembuka kaleng, atau menggunakan gulungan toilet paper untuk menjaga kertas kawat tidak tergulung?
Saya mencoba dua “trik” di atas dan tebak apa? Mereka “secara” bekerja… untuk sementara waktu. Pembuka kaleng memotong sel di mana plastik dileburkan, tetapi gagal memotong sepanjang kemasan. Gulungan toilet paper memegang kertas kawat untuk sementara waktu, tetapi pada akhirnya kardus melemah dan kertas kawat tergulung. Tidak mengejutkan, menggunakan gunting untuk plastik blister pack dan potongan kertas kecil untuk kertas kawat bekerja jauh, jauh lebih baik.
Pada garis yang sangat mirip, banyak organisasi sekarang mempertimbangkan untuk menggunakan RPA untuk mengotomatisasi pengujian perangkat lunak: sebuah “tech hack” untuk pengujian perangkat lunak, dari segala cara. Namun, sama seperti gulungan toilet paper tidak memberikan solusi yang berkelanjutan untuk menjaga kertas kawat saya tidak tergulung, RPA bukan solusi yang berkelanjutan untuk otomatisasi pengujian perangkat lunak… dan modifikasi yang diperlukan untuk membuat alat RPA berkelanjutan untuk tugas pengujian perangkat lunak akan, ya, sebuah hack.
Jika Anda sudah memiliki alat RPA di organisasi Anda dan Anda ingin memulai dengan otomatisasi pengujian, alat RPA Anda mungkin tampak seperti pilihan yang logis. Biasanya relatif mudah untuk mengotomatisasi beberapa skenario pengujian dasar (misalnya, membuat pengguna baru dan menyelesaikan transaksi), menambahkan validasi, dan percaya bahwa Anda berada di jalur otomatisasi pengujian.
Namun, penting untuk mengenali bahwa otomatisasi pengujian yang berhasil—dan berkelanjutan—membutuhkan lebih dari sekadar kemampuan untuk mengklik melalui jalur aplikasi. Untuk naik di atas rata-rata industri yang muram tingkat otomatisasi pengujian <20%, tim juga harus mampu membangun dan mengstabilkan suite pengujian otomatis yang efektif. Alat RPA biasanya tidak dirancang untuk memungkinkan hal ini. Akibatnya, Anda akan menghambat jalan otomatisasi pengujian seperti penundaan menunggu data pengujian dan lingkungan pengujian yang diperlukan, hasil yang tidak konsisten yang merusak kepercayaan pada inisiatif otomatisasi, dan suite pengujian yang “bloated” yang mengonsumsi sumber daya yang besar tetapi tidak memberikan umpan balik yang jelas dan dapat ditindaklanjuti.
Untuk gambaran cepat tentang perbedaan ruang lingkup antara alat RPA dan alat otomatisasi pengujian, bandingkan definisi berikut dari Gartner:
Alat RPA “melakukan pernyataan ‘if, then, else’ pada data terstruktur, biasanya menggunakan kombinasi interaksi antarmuka pengguna (UI), atau dengan terhubung ke API untuk menggerakkan client server, mainframe atau kode HTML. Sebuah alat RPA bekerja dengan memetakan proses dalam bahasa alat RPA untuk robot perangkat lunak diikuti, dengan waktu proses dialokasikan untuk mengeksekusi skrip oleh dashboard kontrol.”
Alat otomatisasi pengujian “memungkinkan organisasi untuk merancang, mengembangkan, memelihara, mengelola, mengeksekusi dan menganalisis uji fungsional otomatis … Mereka menyediakan lebar dan kedalaman produk dan fitur melalui siklus hidup pengembangan perangkat lunak (SDLC). Ini mencakup desain dan pengembangan uji; pemeliharaan dan penggunaan ulang kasus uji; dan manajemen uji, manajemen data uji, pengujian otomatis dan integrasi, dengan fokus kuat pada dukungan pengujian berkelanjutan.”
Kebutuhan akan kemampuan pengujian tambahan ini menjadi jelas saat mempertimbangkan beberapa perbedaan inti antara:
• Mengotomatisasi urutan tugas di lingkungan produksi untuk mengeksekusi jalur yang telah ditentukan melalui proses sehingga Anda dapat menyelesaikan pekerjaan lebih cepat, dan
• Mengotomatisasi proses bisnis yang realistis di lingkungan pengujian untuk melihat di mana aplikasi gagal sehingga Anda dapat membuat keputusan yang tepat apakah aplikasi terlalu berisiko untuk dirilis
Apa artinya perbedaan ini untuk pengujian perangkat lunak?
• Otomasi harus dieksekusi di lingkungan pengujian yang biasanya tidak lengkap, berkembang, dan terbatas
• Mengelola data pengujian yang stateful, aman, dan kompatibel menjadi tantangan besar
• Desain kasus uji yang efektif sangat penting untuk keberhasilan
• Kegagalan perlu memberikan wawasan tentang risiko bisnis
Untuk menjadikannya lebih konkret, mari kita pertimbangkan contoh pengujian layanan perjalanan online. Asumsikan Anda ingin memeriksa fungsionalitas yang memungkinkan pengguna untuk memperpanjang reservasi hotel bayar di muka mereka. Pertama, Anda perlu memutuskan berapa banyak uji yang diperlukan untuk secara menyeluruh melatih logika aplikasi— dan kombinasi data apa yang harus digunakan oleh masing-masing.
Kemudian, Anda perlu memperoleh dan menyediakan semua data yang diperlukan untuk mengatur aplikasi ke kondisi di mana skenario uji dapat dieksekusi. Dalam kasus ini, Anda perlu (setidaknya) akun pengguna yang sudah ada dengan reservasi bayar di muka untuk tanggal di masa depan—dan Anda tidak dapat menggunakan data produksi aktual, karena regulasi privasi seperti GDPR.
Selanjutnya, Anda perlu memiliki cara untuk memanggil rentang respons yang diperlukan dari sistem reservasi hotel yang terhubung (kamar tersedia/tidak tersedia), kartu kredit (transaksi disetujui/ditolak) dll.—tetapi tanpa sebenarnya memesan kamar atau mengenakan biaya pada kartu kredit.
Anda akan perlu mengotomatisasi proses, tentu saja. Ini melibatkan login, mengambil reservasi yang sudah ada, menunjukkan bahwa Anda ingin mengubahnya, kemudian menentukan panjang perpanjangnya.
Setelah Anda mengotomatisasi proses yang lengkap, Anda perlu mengonfigurasi sejumlah validasi di berbagai titik pemeriksaan. Apakah detail yang sesuai telah dikirim ke hotel dalam format pesan yang sesuai? Apakah reservasi diperbarui dalam database pengguna Anda? Apakah data pembayaran telah dikirim dengan benar ke penyedia kartu kredit? Apakah kredit akun yang diterapkan? Apakah pengguna menerima pesan yang sesuai jika reservasi tidak dapat diperpanjang? Apa jika kartu kredit ditolak? Dan jika kartu kredit ditolak, apakah sistem Anda kembali ke panjang reservasi asli daripada menambahkan malam tambahan yang sebenarnya tidak dibayar?
Sekarang bayangkan perusahaan Anda memutuskan untuk menambahkan biaya perubahan $10 untuk semua reservasi bayar di muka. Apakah Anda dapat dengan mudah memasukkan persyaratan baru ini ke dalam tes otomatis yang ada—atau apakah Anda harus mengubah ulang setiap tes secara signifikan untuk mengakomodasi perubahan kecil ini?
Meskipun contoh sederhana ini mengungkapkan beberapa kompleksitas pengujian perangkat lunak yang tidak dirancang untuk diatasi oleh alat RPA. Alat RPA dibangun untuk mengotomatisasi tugas tertentu dalam urutan. Alat otomatisasi pengujian perangkat lunak dirancang untuk mengukur ketahanan dari urutan tugas yang lebih luas. Untuk mengatakannya dengan kasar: alat RPA dirancang untuk membuat proses bekerja. Tetapi untuk pengujian perangkat lunak, Anda membutuhkan alat yang membantu Anda menentukan bagaimana proses dapat mungkin rusak.
Otomasi pengujian perangkat lunak yang tidak efektif terkenal karena menunda rilis sambil mengonsumsi jumlah sumber daya yang luar biasa. Saat CIOs berinvestasi lebih dan lebih dalam inisiatif transformasi digital yang meningkatkan pengalaman pelanggan melalui pengiriman perangkat lunak yang lebih cepat, menghemat pada pengujian perangkat lunak adalah kontraproduktif. Memilih alat yang tepat untuk pekerjaan akan membayar secara signifikan dalam hal percepatan pengiriman, pengurangan risiko bisnis, dan lebih banyak sumber daya untuk dialokasikan untuk inovasi.
Wayne Ariola, adalah penulis Continuous Testing for IT leaders dan pembicara utama yang terkenal di ruang DevOps dan App Dev.
