Tester Mindset: Pandangan yang berbeda dari software developer

Dev vs tester at Devs.lol

Developer dengan tester sering kali digambarkan sebagai dua belah pihak yang memiliki cara pandang yang sangat berbeda satu sama lain. Ya makanya ga jarang ada kondisi yang membuat mereka masuk kedalam konflik karena berbagai macam faktor.

Memang benar sekali tester itu punya mindset yang cukup berbeda dengan developer. Walaupun demikian, tujuannya ya tetap sama, membangun sebuah produk dengan kualitas yang memenuhi kebutuhan pelanggan atau pengguna.

Baik kamu adalah developer ataupun tester, aku mau sharing ke kamu terlebih dahulu tentang bagaiamana seseorang dianggap sebagai seorang tester yang hebat (great tester). Setidaknya, mereka tuh harus:

1. Be like godzilla: Hancurkan sesuatu dan tidak peduli dengan rambu lalu lintas.
   Bukan mengabaikan saran dari developer, tapi dengerin saran darinya, lalu masukkan ke dalam rencana atau rangkaian pengujian. Hehe. Misal dev bilang “itu udah aku test barusan di dev, jadi gausah diuji lagi”. Nah, inilah saatnya menjadi godzilla, dengan tidak mengindahkan siapapun yang minta seorang tester untuk berhenti membuat kerusakan. Godzilla ga berenti di BangJo (traffic light) kan? Ya tujuannya buat nemuin masalah sebelum user atau customer yang menemukannya.
2. Be like Sherloc Holmes: Memecahkan misteri dengan penalaran Deduktif
   Sherlock holmes itu detektif fiksi yang hebat, penguji yang hebat dan sangat jeli. Seorang tester yang baik akan menemukan akar permasalahan dari suatu issue, bergerak maju dan mengikuti perilaku misterius yang ditemukan terlebih dahulu ke tempat yang dituju, lalu mundur ke tempat asalnya. Menemukan kemungkinan asal masalahnya, dan memperkirakan implikasi dari masalah tersebut. yang merupaan resiko bagi bisnis atau customer jika tidak diperbaiki.
3. A Dash Of Barry Sanders(football player) : Menggunakan Intuisi dan Penglihatan luas, Temukan dan eksploitasi kesenjangan yang ditemukan
   Gini, seringnya developer, bisnis analis, system analis, dan product owner itu mikir mereka membicarakan hal yang sama… tapi tidak demikian. Ada kesenjangan yang tidak terlihat, dan tidak ada diantara mereka yang melihatnya. Ini karena mereka berada di garis pertahanan, terlalu dekat dengan masalah untuk menyadarinya. Penguji yang hebat mulai mengamati dan mendengarkan celah-celah ini sebelum satu baris kode ditulis. Mereka memberi tahu tim mereka di mana letak celah tersebut sehingga dapat ditutup lebih awal dan pasti, dengan keberuntungan bahkan sebelum software dikembangkan atau kodenya mulai ditulis.
4. A Healthy Helping Of Ernest Hemingway: Ceritakan Kisah Secara Akurat dan Ringkas
   Seorang tester tuh harus jadi storyteller yang baik, karena kerjaannya nemuin masalah dan jelasin masalahnya ke tim. Penting untuk bisa menyampaikan pentingnya masalah atau bug ke orang lain, dan karenanya itu harus menarik, terperinci, dan ringkas.
   (medium ini jadi salah satu sarana aku belajar sih biar bisa jadi story teller yang baik, hehe)
   Kalau sebagai tester ngerasa bahwa masalah itu harus diselesaikan, maka buatlah cerita yang akan jadi best seller. Seorang tester harus siap untuk meyakinkan siapa pun di dalem tim bahwa kesimpulannya benar.

Lalu untuk bisa seperti itu, harus bagaimana? atau bahasa kerennya What do Software tester do. Yang harus dilakukan adalah:

• Menginvestigasi
• Mencari dan memberikan informasi
• Belajar tentang risiko
• Bertanya
• Mengklarifikasi atau memperjelas
• Menemukan gap (ketidaksesuaian)
• Memeriksa Ekspektasi
• Mendokumentasikan dan mengkomunikasikan temuan
• Temukan kenyataannya (karena kadang bug ditutup — tutupi)
• Cari cara untuk yang lebih baik (apabila ada yang kurang efisien atau sejenisnya)
• Tanya, dan tanya sebanyak-banyaknya

Tester Mindset

Dari kebiasaan dan apa yang dilakukan oleh tester di atas sebagaimana yang aku sebutin gimana biar mereka jadi great tester, terbentuklah mindset tersendiri yang unik dimiliki dan memang harus dimiliki oleh seorang software tester. Diantaranya adalah:

• Tester fokus ke bagaimana caranya untuk membuat software ini sampai pada breaking pointnya.
• Perlu bisa mengkomunikasikan temuannya dengan baik. Developer juga punya emosi, mereka manusia. Kalau cuma jadi godzilla yang ngancurin semuanya tanpa ngasih info yang jelas, developer akan jadi sensitif karena kamu ngancurin apa yang mereka buat dengan tanpa alasan jelas.
• Tester juga sebenarnya bukan hanya menemukan bug, tapi mencegahnya. Apabila menemukan defect misal pada requirement, akan lebih baik dikomunikasikan sebelum code dibuat.

Tester juga punya cara berpikir sendiri, diantaranya:

• Berpikir terbalik
  Software tester bukan berpikir software yang diujinya itu sudah sesuai dengan requirement, tapi berpikir kalau software yang diujinya pasti punya bug dan harus ditemukan.
  Kasarnya: Perangkat lunak yang diberikan harus dianggap jebakan dan ada yang disembunyikan, sampai terbukti tidak ada apapun yang disembunyikan.
• Berempati dan bermain peran (roleplaying)
  Ini kadang asik sih, main peran, membayangkan “kalau aku jadi user normal aku akan ngapain?”, “kalau aku seorang yang bngst mencari cuan dari bug, aku harus ngapain?”, dan lain sebagainya. Ini juga mempraktekan empati pada posisi tertentu, seperti “apakah ini akan membuat lelah pengguna?”.
• Menantang asumsi
  Software tester ga bertanya “kenapa” ke semua hal ya, ini berarti ga semua asumsi ditantang begitu saja. Asumsi dievaluasi untuk menentukan apakah asumsi itu valid dan berharga, atau malah menyesatkan aktivitas pengujian.
• Intuitif, dan eksploratif
  Namanya juga menguji, ya harus senang eksplore. Discovering the unknown.
• Merekognisi kebiasaan manusia
  manusia itu punya bias. mulai dari pemangku kepentingan, bisnis analis, sistem analis, developer di bagian backend, frontend. mereka semua punya bias. yang membuat aplikasi yang dibangun tidak menjadi top 10 aplikasi terbaik saat ini.
  Ketika duduk untuk menguji software, perlu kamu pahami sebenarnya produk yang kamu lihat sekarang itu adalah hasil akhir dari aktivitas manusia yang memiliki bias, kecenderungan, dan kekurangan. Bug yang dicari, itu cenderung merupakan hasil dari gejala bias tersebut, dibanding dengan kesalahan developer membangun kode, atau algoritma terhadap requirement. Pahami kebiasaan manusianya, dan itu akan membantu dalam menemukan bug dalam aplikasi tersebut.

Itulah yang bisa aku sampaikan tentang bagaimana dan apa yang dipikirkan oleh seorang tester, jadi sebenarnya tester dengan developer itu bisa saja berteman. Selama ada di luar urusan project :D Karena kalau udah urusan project, gaada nego kata teman hahahaha 🤣

Makasih telah membaca!

Jika kamu merasa ada sesuatu yang salah atau punya pertanyaan, jangan ragu untuk memberi aku tanggapan ya!