Software Quality Assurance Vs Developer

Fitri Zakiyah
QA Malang
Published in
3 min readOct 12, 2018
Photo by rawpixel on Unsplash

Dalam suatu perusahaan atau software house, pastilah ada tim yang bergerak bersama untuk mencapai tujuan perusahaan. Dalam sebuah tim, ada stuktural organisasi yang berkolaborasi mengerjakan task. Setiap anggota memiliki peranannya tersendiri berdasarkan skill yang dimiliki tiap individu. Challenge-nya adalah bagaimana dalam perusahaan dapat melakukan corporate branding, bahwasanya bekerja bersama mereka adalah yang terbaik.

“If you want to walk fast, walk alone. If you want to walk far, walk together” — Ratan Tata

Namun, kadang kala ada beberapa mindset yang salah tertanam dibenak beberapa orang. Bahwasannya pekerjaan yang “kelihatannya berat sebelah” di bagian devisi tertentu memberikan jarak antar tim. Salah satu contohnya yang kesannya terlihat “cekcok” di mata orang lain itu QA dan developer.

Apakah kalian seorang QA atau seorang developer? Jika kalian salah satu dari keduanya, atau mungkin merangkap keduanya pasti akan merasakan bagaimana hubungan antara seorang developer dengan QA terbentuk. Dua sejoli ini tampaknya memiliki task yang sering kali membentuk hal yang sentimen. Sehingga banyak pandangan atau mindset salah yang tertanam dibenak kebanyakan orang.

QA is developer’s enemy? NO !! we are friends :)

Persepsi bahwa QA itu musuhnya developer adalah hal yang disalahkan. Persepsi itu muncul karena pekerjaan QA yang mencari-cari bug/error pada sistem yang dibangun oleh developer. Padahal QA hanya menjalankan tugasnya untuk menjaga kualitas software yang harus minim bug. Semakin banyak bug yang didemokan oleh seorang QA bukan berarti dia benci sama developernya, justru dia mencoba untuk mencegah sentimen negatif ketika product sudah di publish, Seperti yang dikatakan oleh paman ben (pamannya spiderman) “with great power comes great responsibility”, dengan privilege untuk menahan rilis sebuah fitur sebelum kualitasnya terjamin, kredibilitas QA justru baru akan terlihat setelah fitur itu rilis. Namanya juga QA ya kan? harus punya prinsip bahwa kualitas yang prioritas, meski harus berhadapan dengan developer yang mungkin capek menerima laporan bug hehe.

image by 1.bp.blogspot.com

Ada sebuah kasus nih (yang mungkin kasusnya diada-adain hehe) saat developer ingin productnya cepet rilis, sedangkan masih ada bug, product owner pengen productnya berkualitas, sedangkan untuk mempertahankan kredibilitas perusahaan perlu adanya product yang cepet rilis dan harus berkualitas. Peranan QA dalam kasus ini pastinya harus bersikap tegas ke developer untuk menolak rilis kalau masih ada bug. Sampai akhirnya product benar-benar siap rilis dengan fungsional fitur yang sudah oke dan UX yang holistik. Mungkin ada beberapa saran agar QA engineer bisa work better dengan developer.

  1. Focus on quality, not testing
    Testing hanyalah sebuah tools untuk mencapai tujuan. Tanggung jawab QA adalah kualitasnya, pastikan kita paham apa yang penting bagi customer/user, jangan hanya melihat user story, cobalah untuk berfikir sebagai customer/user, dan pastikan aplikasi tersebut masuk akal dari sudut pandang user. Untuk merealisasikannya, seorang QA pasti butuh untuk berinteraksi dengan developer, untuk memberikan saran.
  2. Share responsibility
    Seperti yang sudah dijelaskan diatas, setiap orang memiliki sisi tanggung jawabnya tersendiri. Tetapi setiap anggota dari tim pasti punya satu tanggung jawab yang sama, mempertahankan kredibilitas perusahaan dengan mempertahankan kualitas product.
  3. Tentukan prioritas
    Kalau dalam suatu sistem ada bug, jangan habiskan waktu untuk berdebat sedangkan bug tersebut tidak terlalu penting, tidak terlalu berpengaruh pada fungsional sistem.
  4. Don’t punish developers
    Dari kasus yang dijabarkan diatas (kasus yang diada-adakan), solusi dari kasus tersebut bukan berarti seorang QA keukeuh tidak mengizinkan merilis productnya. Ada beberapa hal yang dapat dilakukan seorang QA dalam hal kualitas rendah, taktik umumnya product dapat dirilis sebagai procuct “alpha”, “beta”, atau “early access” untuk menetapkan ekspektasi.

Mungkin masih banyak lagi upaya-upaya yang bisa dilakukan seorang QA untuk mengurangi sensitifitas hubungan antara developer dan QA. Sehingga bisa menggugurkan mindset negatif kebanyakan orang dan pastinya untuk membangun tim yang lebih solid :)

--

--