![]() |
| Software Tester |
Menjadi software QA/tester adalah suatu profesi di dunia IT yang sebelumnya nggak pernah terbayang bakal jadi bagian dari hidup saya. Dulu, saya cuma mendengar perihal software QA ini di mata kuliah Rekayasa Perangkat Lunak, sebagai materi sampingan, sambil ngantuk-ngantuk, kebayang juga kaga. Sekarang, nggak terasa sudah 6 bulan saya bekerja sebagai software QA. Jadi saya udah mulai bisa cerita nih sedikit-sedikit tentang asam garam dunia per-QA-an, terutama di perusahaan internet skala start-up yang lagi naik daun. Dan berhubung produk perusahannya berhubungan dengan internet (e-commerce), otomatis fokus QAnya pun lebih ke web system.
So, what’s hot about this job?
Jika mengerti esensinya dan dilakukan dengan penuh makna *ceile*, sesungguhnya ini adalah pekerjaan yang sangat challenging, penuh pressure, butuh logika, kemampuan ekspolasi, attention to detail yang tinggi, system analysis, komunikasi, dan technical writing–alias dokumentasi– yang baik. Bisa dibilang, we are developer’s enemy (bukan musuh dalam artian sebenarnya yahh), maksudnya.. pekerjaan kita adalah mencaricari bug/error/kesalahan dalam sistem, code, apapun yang dibuat oleh developer. Developer’s bug is our victory. Makin banyak bug yang ditemukan, makin bagus. QA lah yang jadi penentu, memberikan lampu hijau untuk sebuah fitur dianggap ‘layak’ untuk dirilis ke pasaran.
Tapi seperti kata pamannya Spiderman, “with great power comes great responsibility.” itu emang bener. Dengan privilege untuk menahan rilis sebuah fitur sebelom kualitasnya terjamin, kredibilitas QA justru baru akan terlihat setelah fitur itu rilis. Is there any leaking bug? How many bugs are found after release? Disitulah beban QA yang sesungguhnya menurut saya. Walaupun ngga ada sistem di dunia ini yang 100% bug-free, setidaknya kemunculan bug setelah rilis harus diminimalisir.
Pengalaman saya, menjadi QA itu benar-benar membuka wawasan. Terutama tentang produk yang lagi ditest. You will constantly find new things, learn new things, from your own work and everything around you. You will gain new perspective–as user, as developer, and as a tester–. It’s also a constant learning. Just as when you think you’ve done enough, you will see that it’s never enough.
Tapi tentu, seperti halnya semua pekerjaan di dunia ini, setiap ada yang enak pasti ada juga ngga enaknya.
The drawbacks
Hidup di dunia per-QA-an penuh dengan tekanan dari berbagai pihak mulai dari developer hingga project owner. PO ingin produk yang dirilis berkualitas, developer juga pingin produknya cepat rilis, tapi untuk produk itu bisa rilis dengan berkualitas, perlu waktu dan testing yang komperhensif dengan jiwa yang tenang, dan seringkali waktunya juga ngga ada, mengakibatkan jiwa ngga tenang. Matek kan? Susah tuh kalo orangnya nggak tegaan. Karena jadi QA tu kamu dituntut harus tega buat menolak puppy eyes para developer yang minta dirilisin, kalo emang belum layak rilis. Juga kuat iman kalo ternyata ada bug yang leaking setelah fitur rilis. #elusdada
Terus, kudu bisa juga nentuin prioritas. Harapan semua QA adalah men-deliver produk yang 100% bug-free. Tapi sempurna itu cuma milik Allah. Jadi, daripada ga kesampean mending prioritasin testing yang bener-bener critical untuk didahulukan. Kedengerannya gampang, tapi sebenernya susah. Kalo dah testing, semuanya keliatan penting. Cuma pengalaman yang bisa mengajarkan ini. So, take your time.
Dan, kalo kamu anti-dokumentasi. Jauh-jauh aja dari pekerjaan ini. Karena niscaya, makananmu sehari-hari kalo jadi QA adalah test case, bug reports, dan report-report lainnya.
So, how it’s like to be a QA in one of Indonesian Start-Up company?
Beda-beda sih, tergantung maturity perusahaannya. Kalau di tempat saya, kebetulan sudah ada divisi QA sendiri. Tapi ada juga tempat lain dimana developer merangkap sebagai tester.
Sejujurnya, pekerjaan QA itu bakal jauuh lebih mudah kalo ada yang namanya System Requirement Document. Tapi Seperti yang kita tau, namanya juga start-up, bisa dipastikan yang namanya dokumentasi itu dinomorduakan. Selain karena biasanya kurang SDM, umumnya pasti mengedepankan produknya ada dulu, jalan dulu, rilis dulu. Jangan berharap ada System Requirement Documentation yang konkrit, jelas, dan membantu. Ada aja tuh uda syukur alhamdulillah. Pokoknya yang pasti di start up itu hanya perubahan. Let’s just take that as facts.
Hal itu membuat situasi QA jadi makin challenging. Gimana kita tau sistemnya dah bener apa engga kalo gada requirementnya? Kemana harus mencari kebenaran itu? Mau ngga mau harus tanya PO, developer terdahulu yang awal-awal bikin, atau bahkan mikir sendiri apakah flownya reasonable atau engga. Bahkan, kalau awal-awal sebelum perusahaannya berkembang sebesar sekarang, testing ya testing aja tanpa pakai test-case. Belakangan, test case juga dibuat berdasarkan requirement yang ditemukan selama eksplorasi. Ngga ideal memang. Tapi ya begitulah situasinya. We still gotta do something despites the condition.
Very challenging, but you will learn a lot.
Mungkin segitu aja dulu pembahasan QA kali ini. Kapan-kapan, saya bakal bahas lebih mendalam tentang urusan testing-menesting ini. Sukur-sukur bisa menjawab pertanyaan orang-orang di luar sana yang penasaran dengan QA di dunia IT.

Tidak ada komentar:
Komentar baru tidak diizinkan.