Membangun Hubungan Harmonis antara QA dan Developer
Relationship QA dan Developer ibarat kisah hidup seorang manusia yang sedang menjalin hubungan dengan kekasihnya untuk satu tujuan. Tentu dalam setiap perjalanan atau kisah cinta yang mereka jalani tidak ingin ada gesekan-gesekan atau permasalahan yang akan merusak hubungan. Hal tersebut juga sangat diharapkan pada tiap anggota project team khususnya antara QA dan Developer, yang setiap harinya mereka isi dengan pairing kerjaan bareng, berdiskusi, debat, drama diem-dieman sampe berantem, dsb. Untuk itu, penulis mencoba sharing bagaimana sih menciptakan hubungan yang harmonis antara QA dan developer dalam menyelesaikan suatu project agar tidak terjadi blocking satu sama lain. #janganbaperya.
1. Komunikasi
Kenapa komunikasi penting?. Tanpa adanya komunikasi yang baik dan harmonis antara Developer dan QA, proses pengembangan fitur yang dilakukan dalam satu tim yang terdiri dari QA, Developer, dan juga PO akan terhambat. Disini komunikasi sangat membantu untuk membangun fondasi kepercayaan antara Developer dan QA, dan juga melakukan improvisasi dan perbaikan fungsi aplikasi secara sinkron. Dengan adanya komunikasi yang baik, juga bisa menghilangkan gap terkait requirement apa saja yang mesti dipenuhi oleh Developer dalam mengembangkan aplikasi. Menyamakan pemikiran antara QA dan Developer itu sangat penting. Selama proses pengembangan dan masuk tahap pull request, seorang QA juga turut membantu memberikan feedback apakah poin-poin fungsional yang ada ditiket telah dipasang pada aplikasi. Feedback harus bersifat relevan terhadap requirement. Hal tersebut sebetulnya bisa menjadi dasar dan kesempatan bagi Developer juga, untuk meninjau kembali pekerjaan mereka berdasarkan kriteria-kriteria fitur yang sudah ditentukan.
Sebagai seorang QA, baiknya perlu membiasakan diri untuk memberikan feedback positif ke Developer. Hilangkan ambiguitas / miss-konsepsi ketika memberikan feedback dan sebisa mungkin sampaikan komentar atau masukan secara jelas agar dapat dipahami dengan runut dan mudah. Jadi, jika QA hanya berkomentar ketika ada masalah saja, maka proses development bisa terhambat dan iteration flownya akan lama ketika masalah tersebut baru saja terjadi, hal tersebut juga dapat membuat komentar yang kita sampaikan bisa jadi masalah juga.
Luangkan waktu untuk menunjukkan bahwa kita sebagai seorang QA memberikan perhatian yang berarti pada kerjaan Developer dan memberikan feedback yang penting tanpa harus menjadi blocker dalam tim pada saat proses development.
2. Kolaborasi
Seringkali sebuah tim dihadapkan dalam satu blocking atau problem ketika melakukan backlog refinement/grooming, QA dapat mengambil andil untuk bisa membuat rekomendasi terkait fitur yang possible dan bisa masuk untuk dibawa kedalam sprint untuk dikembangkan. Dalam hal ini QA juga bisa mendiskusikan risiko seperti apa yang akan dihadapi jika ada sebuah fitur baru yang masuk kemudian kemungkinan bug-bug yang terjadi apa saja. Kontribusi QA untuk menemukan penyebab dan solusi pada case seperti ini sangat dibutuhkan.
Pekerjaan QA diawal bisa membantu Developer dalam menyelesaikan tiket-tiket yang akan dikerjakan di Sprint seperti membuat scenario test dan juga pairing bersama developer tentang apa saja batasan dalam lingkup fitur yang harus dipasang dan yang tidak boleh dipasang. Ketika kolaborasi ini bisa terjadi diawal-awal sprint, sebelum fitur yang dikembangkan benar-benar jadi dan siap untuk diuji, maka iterasi tiket balik ke Developer seharusnya juga akan berkurang. Hal tersebut bisa memberi dampak pada proses delivery fitur dan release semakin cepat. Tentu, dengan kualitas yang bagus dan telah memenuhi ekspetasi dari requirement yang telah dibuat. Jika kolaborasi ini bisa terjalin secara baik, insya Allah kehadiran QA tidak akan jadi bottle neck justru memudahkan proses development yang dilakukan developer. Dan developer akan menjadi lebih happy karena kemungkinan celah-celah dari aplikasi telah tercover dan ditutup melalui skenario yang dibuat oleh QA.
Apabila dirasa ada satu feedback dari QA terkait minor issue yang ditemukan dan itu nampaknya mengganggu experience user namun tidak ada dalam requirement, hal itu bisa jadi pertimbangan apakah dapat mengganggu proses development atau menimbulkan effort yang lebih. Case seperti ini dapat saja terjadi, namun perlu didiskusikan ke PO sehingga bisa jadi challenging dan dapat diambil keputusan akhirnya.
