Strategi untuk Automation Testing (Part 1)
Tidak hanya mengasah kemampuan lama yang telah terukir selama ini, sebagai QA Engineer sejatinya kita harus terus upgrade skill dan terbuka terhadap perkembangan tools baru di dunia testing. Salah satunya yang paling dibutuhkan jaman now yakni skill menguasai salah satu minimal bahasa pemrograman dan tools yang digunakan untuk menjalankan skenario tes melalui sebuah rangkaian kode-kode (koding). Agar implementasi automation testing dapat berjalan sesuai ekspetasi dan mampu memberikan pengaruh yang baik pada proses testing itu sendiri dan bisnis dibutuhkan perencanaan tes yang matang.
Topik yang gue bahas di part 1 ini menyangkut beberapa point yang menurut gue penting sebelum memulai automation.
- Kita hendaknya mesti tahu dulu apa tujuan seorang qa mulai menerapakan automation testing untuk menguji aplikasi perusahaan?
- Kira-kira resource orang untuk membuat automation sudah cukup belum, atau sudah memadai ?
- Strategi tes seperti apa yang cocok diterapkan untuk mengimplementasikan automation testing
Apasih tujuan automation test itu ?
Bayangin dah, lo jadi tester tinggal duduk manis ngopi, sambil nunggu skenario tes jalan. Terus abis itu report udah bisa keliatan otomatis.
Awal gue jadi QA, itu gue masih asing banget yang namanya automation testing. Selama beberapa sprint, itu cukup kewalahan memang untuk menguji beberapa fitur sampai rilis, terutama pada saat regression tes. Sehingga terkadang, butuh waktu lama untuk menguji fitur yang berulang-ulang dan harus dites lagi. Padahal udah cukup stabil dan sebenernya gausah tes pake jemari tangan lagi, tugas gue menguji fitur yang selanjutnya. Disaat inilah bantuan mesin sangat dibutuhkan, automation dijalankan. Setelah gue explore-explore, beneran ada yang namanya automation testing. Kurang lebih 8 bulan gue mempelarjari automation testing dan menerapkan itu untuk keperluan tes baik di web maupun mobile. Walaupun tidak sepenuhnya coverage tes dijalankan secara otomatis.
Nah, pada dasarnya automation test itu untuk memudahkan QA ketika ingin menguji fitur yang sudah cukup stabil, terdapat skenario yang membutuhkan perulangan yang banyak pada pengujian, dan tingkat valuable tes yang tinggi pada product. Secara sederhana, kita ga perlu lagi spend waktu untuk fitur sudah memiliki jumlah bug == 0. Kemudian katakanlah, ada fitur register yang ingin di automate. Concern-nya, selain fitur register ini berhasil dijalankan sampe user dapat notif verifikasi email dan masuk halaman dashboard (happy path) yang tidak kalah penting ialah apakah dengan hanyak memasukan nama, no telp, dan password tanpa email seorang user dapat tetap bisa daftar?. Skenario semacam skenario itu, yang bisa kita masukan kedalam proses automation testing. Kalo memang ekspetasinya email itu harus required berarti user belum berhasil register, bukan malah ke bypass ke halaman dashboard atau tiba-tiba belum ada handling error jika email kosong. Kalo memang email kosong seharusnya apa feedback yang diberikan sistem kepada user yang harus dideteksi sampai benar.
Kemudian fokus kita adalah ke fitur-fitur yang telah dikembangkan sama developer. Ketika fitur-fitur itu digabung jadi satu dan diuji dalam satu fase pengujian yang bersamaan kita tinggal jalanin automation test-nya kemudian tinggal lihat reportnya seperti apa. Manfaat dari automation juga sedini mungkin kita dapat mengetahui bug yang terjadi secara cepat, dan bisa langsung report ke developer. Sehingga itu dapat membantu tim juga untuk deploy ke production dan release. Namun semua kembali pada kebutuhan tester, tes apa yang sangat mereka butuhkan untuk di automate. Sehingga effort pengujian yang dilakukan tidak terlalu besar pada saat regression test. Ga perlu ngulangin tes yang fiturnya sebenernya udah pasti berhasil. Dan udah ga ada skenario lagi yang bisa dianeh-anehin.
Kuncinya automation untuk tiap tim yang bakal menerapakan automation adalah memahami apa yang bakal dicapai. Jadi lo sama tim bener-bener harus mikirin kenapa ya gue butuh automation?. Selain itu, cari tools yang tepat, gampang, efektif, dan efisien. Jika udah bermain di scripting sebaik mungkin buat test code untuk skenario yang mudah dipahami, dibaca, dan di maintenace.
Dari pengalaman gue sih, kalo udah bermain di automation testing otomatis kita bakal ngoding untuk beberapa skenario tes. Bahasa pemrograman apa yang mau kita pake idealnya disamakan dengan bahasa yang digunakan oleh developer. Keuntungannya pertama, kita bisa belajar dari developer kalo kita stak atau udah pasrah nemu error yang bikin automation kita ga jalan, kedua jadi bisa saling update skill terkait bahasa pemrograman yang digunakan, ketiga sebagai ajang mengharmoniskan hubungan developer. Jadi biar ga kaku lagi dan terbuai dengan pekerjaannya sendiri-sendiri. Itu sih menurut gue ya. Jikalau tools / bahasa yang dipake berbeda dengan developer juga ga masalah. Misal elo sebagai QA udah ada basic python nih, sementara dikantor pakenya java. Implementasiin aja dulu, sambil liat positive/negative-nya juga. Atau mungkin kalau ada yang lebih bagus lagi untuk automation selain python bisa dicari dulu referensinya atau diskusi bareng juga sama tim. Kemudian liat baik-baik kemampuan dan juga jumlah testernya. Jangan memaksakan jika cuma ada satu QA, automation testing diterapin secara full. Alangkah baiknya kalo memang cuma ada satu QA, script automation di cicil sedikit demi sedikit. Syukur-syukur untuk satu project jumlah QA terdiri dari 2–3 orang, jadi ada yang fokus khusus membuat automation test-nya. Semua balik lagi pada kebutuhan dan sumber daya tim kayak gimana, yang penting tujuan awal automation bisa tercapat dengan baik.
Dah, ini points of sharing yang bisa gue sampaikan dulu terkait strategi untuk automation test. Ini masih awal juga sih, dan tentunya gue juga masih belajar. Hehe. Semoga bermanfaat, happy testing !.
Referensi:
https://testautomationu.applitools.com
