Menggunakan RPA untuk pengujian perangkat lunak:"peretasan teknologi"?
Otomatisasi pengujian perangkat lunak yang tidak efektif terkenal karena menunda rilis sementara menghabiskan banyak sumber daya.
Sering kali, umpan berita saya menampilkan artikel yang menawarkan "10 Peretasan Kehidupan Teratas." Ini adalah tips dan trik tentang cara menggunakan produk rumah tangga biasa dengan cara yang tidak terduga untuk meningkatkan kehidupan Anda— “…dan tip nomor 7 akan mengejutkan Anda!!!”
Memang, saya telah tertipu untuk membuka umpan klik ini. Sejujurnya, ada saat-saat aku terkejut. Misalnya, siapa yang tahu bahwa Anda dapat memotong kemasan blister plastik yang mengganggu dengan pembuka kaleng, atau menggunakan gulungan kertas toilet agar kertas pembungkus tidak terbuka?
Saya mencoba dua "peretasan" di atas dan coba tebak? Mereka "agak" bekerja ... untuk sementara waktu. Pembuka kaleng memotong jahitan tempat plastik menyatu, tetapi gagal memotong panjang kemasan. Gulungan toilet menahan kertas pembungkus untuk sementara waktu, tetapi akhirnya carboard melemah dan kertas pembungkus terurai. Tidak mengherankan, menggunakan gunting untuk kemasan blister plastik dan selotip kecil untuk kertas pembungkus bekerja jauh lebih baik.
Dalam nada yang sangat mirip, banyak organisasi sekarang mempertimbangkan untuk menggunakan RPA untuk mengotomatisasi pengujian perangkat lunak:semacam "peretasan teknologi" untuk pengujian perangkat lunak. Namun, sama seperti gulungan kertas toilet tidak menghadirkan solusi berkelanjutan untuk menjaga kertas pembungkus saya agar tidak terbuka, RPA bukanlah solusi berkelanjutan untuk otomatisasi pengujian perangkat lunak…dan modifikasi yang diperlukan untuk membuat alat RPA berkelanjutan untuk tugas pengujian perangkat lunak otomatisasi akan menjadi, yah, peretasan.
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 mendasar (misalnya, membuat pengguna baru dan menyelesaikan transaksi), menambahkan validasi, dan yakin bahwa Anda berada di jalur untuk menguji otomatisasi.
Namun, penting untuk menyadari bahwa otomatisasi pengujian yang berhasil—dan berkelanjutan— membutuhkan lebih dari sekadar kemampuan untuk mengklik melalui jalur aplikasi. Untuk naik di atas tingkat otomatisasi pengujian rata-rata industri yang suram <20%, tim juga harus mampu membangun dan menstabilkan rangkaian pengujian otomatis yang efektif. Alat RPA biasanya tidak dirancang untuk mengaktifkan ini. Akibatnya, Anda akan menemui hambatan otomatisasi pengujian seperti penundaan menunggu data pengujian dan lingkungan pengujian yang diperlukan, hasil yang tidak konsisten yang mengikis kepercayaan pada inisiatif otomatisasi, dan rangkaian pengujian "membengkak" yang menghabiskan banyak sumber daya tetapi tidak memberikan hasil yang jelas, umpan balik yang dapat ditindaklanjuti.
Untuk ikhtisar singkat tentang perbedaan cakupan antara alat RPA dan alat otomatisasi pengujian, bandingkan definisi berikut dari Gartner:
Alat RPA "melakukan pernyataan 'jika, lalu, yang lain' pada data terstruktur, biasanya menggunakan kombinasi interaksi antarmuka pengguna (UI), atau dengan menghubungkan ke API untuk menggerakkan server klien, mainframe, atau kode HTML. Alat RPA beroperasi dengan memetakan proses dalam bahasa alat RPA untuk diikuti oleh "robot" perangkat lunak, dengan waktu proses yang dialokasikan untuk menjalankan skrip oleh dasbor kontrol.”
Alat otomasi pengujian “memungkinkan organisasi untuk merancang, mengembangkan, memelihara, mengelola, melaksanakan, dan menganalisis pengujian fungsional otomatis … Mereka menyediakan produk dan fitur yang luas dan mendalam di seluruh siklus hidup pengembangan perangkat lunak (SDLC). Ini termasuk desain dan pengembangan pengujian; pemeliharaan dan penggunaan kembali kasus uji; dan manajemen pengujian, manajemen data pengujian, pengujian dan integrasi otomatis, dengan fokus kuat pada dukungan untuk pengujian berkelanjutan.”
Kebutuhan akan kemampuan pengujian tambahan ini menjadi jelas ketika Anda mempertimbangkan beberapa perbedaan inti antara:
• Mengotomatiskan urutan tugas di lingkungan produksi agar berhasil menjalankan jalur yang ditentukan dengan jelas melalui suatu proses sehingga Anda dapat menyelesaikan pekerjaan lebih cepat, dan
• Mengotomatiskan proses bisnis yang realistis di lingkungan pengujian untuk melihat di mana aplikasi gagal sehingga Anda dapat membuat keputusan yang tepat tentang apakah aplikasi terlalu berisiko untuk dirilis
Apa arti perbedaan ini untuk pengujian perangkat lunak?
• Otomatisasi harus dijalankan dalam lingkungan pengujian yang biasanya tidak lengkap, berkembang, dan dibatasi
• Mengelola data pengujian yang stateful, aman, dan sesuai menjadi tantangan besar
• Desain kasus pengujian yang efektif sangat penting untuk keberhasilan
• Kegagalan perlu memberikan wawasan tentang risiko bisnis
Untuk membuatnya lebih konkret, mari kita pertimbangkan contoh pengujian layanan perjalanan online. Asumsikan Anda ingin memeriksa fungsionalitas yang memungkinkan pengguna untuk memperpanjang reservasi hotel prabayarnya. Pertama, Anda perlu memutuskan berapa banyak pengujian yang diperlukan untuk menjalankan logika aplikasi secara menyeluruh— dan kombinasi data apa yang perlu digunakan masing-masing.
Kemudian, Anda perlu memperoleh dan menyediakan semua data yang diperlukan untuk menyetel aplikasi ke status tempat skenario pengujian dapat dijalankan. Dalam hal ini, Anda memerlukan (setidaknya) akun pengguna yang sudah ada dengan reservasi prabayar yang ada untuk beberapa tanggal di masa mendatang—dan Anda tidak dapat menggunakan data produksi yang sebenarnya, karena peraturan privasi seperti GDPR.
Selanjutnya, Anda memerlukan cara untuk meminta berbagai tanggapan yang diperlukan dari sistem reservasi hotel yang terhubung (kamar tersedia/tidak tersedia), kartu kredit (transaksi disetujui/ditolak), dll.—tetapi tanpa benar-benar memesan kamar atau membebankan biaya kartu kredit.
Anda perlu mengotomatiskan prosesnya, tentu saja. Ini melibatkan masuk, mengambil reservasi yang ada, menunjukkan bahwa Anda ingin mengubahnya, lalu menentukan panjang ekstensi.
Setelah Anda mendapatkan proses yang lengkap secara otomatis, Anda perlu mengonfigurasi sejumlah validasi di pos pemeriksaan yang berbeda. Apakah rincian yang sesuai dikirim ke hotel dalam format pesan yang sesuai? Apakah reservasi diperbarui di database pengguna Anda? Apakah data pembayaran terkirim dengan benar ke penyedia kartu kredit? Apakah ada kredit akun yang diterapkan? Apakah pengguna menerima pesan yang sesuai jika reservasi tidak dapat diperpanjang? Bagaimana jika kartu kredit ditolak? Dan jika kartu kredit ditolak, apakah sistem Anda kembali ke durasi reservasi asli daripada menambahkan malam tambahan yang sebenarnya tidak dibayar?
Sekarang bayangkan perusahaan Anda memutuskan untuk menambahkan biaya perubahan $10 untuk semua reservasi prabayar. Bisakah Anda dengan mudah memasukkan persyaratan baru ini ke dalam pengujian otomatis yang ada—atau apakah Anda harus mengerjakan ulang setiap pengujian secara substansial untuk mengakomodasi perubahan kecil ini?
Bahkan contoh sederhana ini memperlihatkan beberapa dari banyak kerumitan pengujian perangkat lunak yang tidak dirancang untuk ditangani oleh alat RPA. Alat RPA dibangun untuk mengotomatisasi tugas-tugas tertentu dalam suatu urutan. Alat otomatisasi pengujian perangkat lunak dirancang untuk mengukur ketahanan urutan tugas yang lebih luas. Terus terang:alat RPA dirancang untuk membuat proses bekerja. Namun untuk pengujian perangkat lunak, Anda memerlukan alat yang membantu Anda menentukan bagaimana suatu proses dapat rusak.
Otomatisasi pengujian perangkat lunak yang tidak efektif terkenal karena menunda rilis sambil menghabiskan sumber daya dalam jumlah yang luar biasa. Karena CIO semakin banyak berinvestasi dalam inisiatif transformasi digital yang meningkatkan pengalaman pelanggan melalui pengiriman perangkat lunak yang lebih cepat, mengurangi pengujian perangkat lunak menjadi kontraproduktif. Memilih alat yang tepat untuk pekerjaan tersebut akan memberikan hasil yang signifikan dalam hal pengiriman yang dipercepat, risiko bisnis yang berkurang, dan lebih banyak sumber daya untuk dipersembahkan untuk inovasi.
Wayne Ariola, adalah penulis Pengujian Berkelanjutan untuk para pemimpin TI dan pembicara utama yang terkenal di ruang DevOps dan App Dev.
