Tukang nge-TES
Curhatan hati tukang kuli uji pengembangan perangkat lunak
Pengen sharing artikel tentang ini supaya kehadiran QA (Quality Assurance) engga dipandang sebelah mata dan kita jadi tau sense-nya jadi QA tuh kayak apa. Di kantor Mekari, banyak hal yang gue pelajari hingga pada akhirnya nemu beberapa rekan kerja yang mantep pengalamannya bisa ngasih petunjuk dan banyak pencerahan.
Sebelumnya apa sih QA ? QA itu question and answer … bukan sih QA itu Q dan asuransi, awalnya penulis ngira kerjaan QA tentang asuransi karena belakangnya huruf “A” langsung tandemnya asuransi, Quality asuransi?. No, oke bukan, bukan itu. QA adalah Quality Assurance atau jika diterjemahkan langsung ke dalam bahasa Indonesia adalah “Penjaminan Kualitas”. Istilah “Assurance” atau “Jaminan” menyatakan suatu kepastian ataupun kepercayaan terhadap produk yang dihasilkan oleh suatu perusahaan. Quality Assurance (QA) menjamin kualitas produk yang dihasilkan dan memastikan proses pembuatan produk tersebut sesuai dengan standar dan persyaratan yang telah ditentukan. Dalam hal ini, dibidang IT sendiri QA punya tanggung jawab untuk menjamin kualitas produk dari mulai tahap development aplikasi sampai dengan deliver to client. Untuk mencapai hal itu tentunya seorang QA mengimplementasikan beberapa metode/framework pengujian pada aplikasi, tujuannya agar pengujian dapat dilakukan secara efektif, efisien, dan pada saat akan release software yang telah dibuat memiliki standar kualitas dan keandalan yang baik.
Ketika awal berkarir dibidang per-testing-an cukup tidak mudah, butuh practice and best practice. Kebetulan karena sebelumnya penulis pernah merasakan terjun ke dunia IT yang sejatinya anything that buat sesuatu yang penting sesuai requirement dan it works dulu, kadang kita miss ga mikirin celah atau bolongnya aplikasi. Masuk ke dunia QA penulis tersadarkan ternyata banyak banget skenario yang terjadi dalam aplikasi, entah itu bug reproduce dan negative scenario yang harusnya ga boleh terjadi dan harus ditangani saat masuk production. Lebih sedihnya lagi kalo yang nemuin bug adalah client. Keren juga sih, client finding bug, jangan-jangan dia QA juga. Nah, sebenernya disinilah peran QA bermain agar semua hal-hal yang tidak diinginkan pada aplikasi terjadi. Ketika developer membuat suatu aplikasi yang case nya standar, happy path, atau lurus aja yang penting bisa jalan, seorang QA harus memastikan pada saat developement hingga release flow aplikasi tidak boleh keluar dari jalan kebenaran, maksudnya requirement yang udah ditentukan.
Awalnya gue mengira pekerjaan QA ya gitu-gitu aja. Nyari-nyari kesalahan, kita tuh harus suudzon sama developer, astagfirullah. Nah justru ga boleh kayak gitu, developer justru adalah partner terbaik dalam tim. Kalo ga ada developer terus kita mau ngetes apa, ga ada yang didevelop? hahaha. Menurut pengalaman dan belajar dari salah satu mastah QA ditempat kerja, seorang QA tidaklah mudah, karena kalo udah berurusan dengan “jaminan” hubungannya sama kualitas. Kalo udah ngomongin kualitas tentu tingkat kualitas yang mesti dicapai itu adalah HIGH, atau bahkan kalo bisa lebih dari ekspetasi. Itu artinya segala aspek, bagian, atau fungsi-fungsi aplikasi harus kita pastikan berjalan sesuai kemauan dan juga kebutuhan dari product requirement.
Bukan salah developer juga kalo pada saat proses development banyak case-case yang masih ga jalan atau ngebug. Hmm, berarti dari awal ada sebuah miss mungkin, developer belum banyak tau atau engeh secara detail case dari aplikasi flow dan impact nya kemana. Untuk itu, QA hadir untuk siap mengawal perjalanan bersama developer dan juga PO untuk merajut impian to building a product with high quality.
As a QA not only not waiting for the story to need the test
Kalo nunggu fitur didevelop dulu sama developer, terus kerjaan QA ngapain ? apakah baru bisa kerja ketika baru ada fitur yang siap di test? Sepertinya tidak. Disinilah skill seorang QA diuji. Diuji apakah seorang QA nganggur apa stay productive bener-bener kerja ? hahaha.
Pertama take your position, sebagai QA kita memiliki hak untuk memberikan feedback pada saat planning bersama product manager dan developer. Disaat itulah peran kita sudah mulai bermain, kita bisa memikirkan possibility scenario yang terjadi apabila ada fitur yang dapat memberikan impact yang kurang bagus untuk aplikasi. Misal, jika fitur xyz diimplementasi apakah dapat menyenggol modul lain, kemudian bisa juga soal performance apakah untuk menggunakan fitur xyz tersebut load nya besar sehingga dapat menimbulkan timeout pada transaksi. Setiap hal ada pertimbangan dan konsekuensinya, sebagai QA kita bisa memberikan alternatif atau metode yang lebih efisien dan scale pada fitur yang akan diimplementasikan. Dan yang paling penting tetap memperhatikan high of level usability dari user.
Kedua, prevent bugs, not find bugs. Ketika sudah ada requirement sebenernya kita bisa mulai mengawali membuat test-test case, tidak hanya skenario yang positive aja tapi negative testnya bisa dibuat. Menurut gue tahap ini juga sangat penting, segala output yang terjadi setelah develoement itu cukup bergantung dengan case-case apa yang udah kita handle dari awal. Jadi sebagai QA kita punya harapan saat udah ditengah-tengah developement, flow aplikasi udah ga “Kentang” lagi atau jadi secara setengah-setangah. Flow apps tetap berada dalam koridor, dan minim dengan critical bug. Skenario-skenario seperti itu kita bisa jadikan reference untuk developer sebelum atau selagi mereka mendevelop fitur apps. Sehingga mereka tahu, aplikasi yang bakal dibangun tuh maunya kayak gini, atau oh ga boleh kayak gitu harusnya. Jadi dalam ini, QA bukan nemuin bug justru membantu aplikasi terbebas dari bug-bug yang critical. Dan ketika release bisa lebih confidence, ga khawatir hal-hal aneh kejadian lagi.
Ketiga, explore and imagine yourself. Make sure dan lakukan exprolatory test pada sub fitur yang selesai didevelop. Kita harus menjamin skenario-skenario awal yang telah kita buat tadi tidak terjadi lagi ketika sudah masuk tahap testing. Ini sangat membantu QA untuk lebih menghemat waktu dan mempercepat proses developement aplikasi. Selama belum ada fitur-fitur yang done, tugas QA sebaiknya selalu improve, bagaimana dengan fitur yang banyak sementara kita sudah mulai kewalahan untuk ngetes. Automation test bisa jadi solusinya. Tugas automation bukan menggantikan tetapi membantu proses pengujian aplikasi yang dilakukan QA. Alangkah baiknya QA menemukan tools automation yang tepat dan ideal sesuai kebutuhan. Kita bisa baca artikel ini nih untuk referensi, click this . Buat yang belum bisa automate, tenang aja sudah banyak aplikasi sederhana dan siap pakai untuk membuat automation, yang penting kemauan untuk belajar dulu dan mindset, karena tidak selamanya manual itu indah hahaha. Untuk itu seorang QA harus bisa menentuka priority test, baik secara fitur apa yang mau ditest ataupun metode apa yang penting dahulu untuk diterapkan, itu mencakup manual and automation test.
Dan yang terakhir dari gue, save a good communication and negotiation. Ga ada yang bisa memastikan gimana kondisi dalam tim, kecuali dari diri sendiri bisa mengontrol, menjaga hubungan baik, dan berkomunikasi secara baik bareng anggota tim. Ga enak sih kalo QA sama developer juga diem-diem. Entah gara-gara qa nemu bug, developer jadi ngambek, fitur yang dibalikin ke inprogress malah jadi ga dikerjain lagi. Apapun itu yang penting jaga keharmonisan tim, jangan mempersulit tim.
Peran QA untuk membantu terwujudnya product secara good quality, butuh pairing dengan PO maupun developer. Kalo ada yang kurang paham bisa segera tanyakan dan diskusikan. Harus banyak nanya dan kepo aja tentang product, kalo perlu sampe tau asal muasalnya seperti apa. Jika ada bug, laporkan secara detail dan terstruktur dan terutama dengan bahasa yang mudah dipahami.
Oke, mungkin itu yang dapat gue share. Kebayangankan, jadi QA bukan hanya sekedar jadi tukang ngetes-ngetes doang. Selain ngetes aplikasi secara end-to-end, posisi kita juga bisa jadi end-to-end buat tim untuk achieve goal.
Referensi:
https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance
