Ubah pengujian menjadi aktivitas bernilai tambah

Kita semua mengatakan bahwa pengujian itu penting – lagipula, untuk persyaratan apa pun, kita hanya dapat mengatakan itu “selesai” ketika semua pengujian yang relevan telah lulus. Tapi “penting” tidak sama dengan “berharga”. Ini bukan hanya perbedaan penting, tetapi yang tidak dapat dibuat oleh orang-orang QA.

sang penulis: Peter Fogel

Misalnya, menurut saya setiap lelucon yang saya ceritakan adalah “lucu”. Sayangnya, pendapat saya tidak diperhitungkan – hanya orang yang mendengar lelucon yang memiliki pendapat yang diperhitungkan. Dan meskipun menurut saya pengujian harus dianggap sebagai aktivitas “nilai tambah”, pendapat saya tidak menjadi masalah di sana: “nilai” ada di mata pelanggan, bukan pabrikan.

Dan mudah untuk membuktikan bahwa pengguna tidak melihat pengujian sebagai aktivitas “nilai tambah”: tanyakan apakah mereka tidak keberatan jika Anda menghentikan pengujian, selama jumlah bug tidak bertambah. Kami semua cukup yakin bahwa pengguna tidak akan mengeluh. Itu karena pengguna Anda—satu-satunya opini yang penting di sini—Tidak Pertimbangkan pengujian sebagai aktivitas nilai tambah.

Namun, kami tahu bahwa kami tidak dapat (belum) membuat aplikasi bebas bug tanpa pengujian. Sayangnya, meskipun ini menjadikan pengujian sebagai tugas yang “perlu”, ini tidak menjadikannya tugas “bernilai tambah”.

Mulai lebih awal

Ada cara untuk mengubah persepsi ini: membawa penguji ke dalam proses lebih awal – terutama dalam proses persyaratan.

Jika menurut Anda tugas penguji adalah “menemukan bug” dan tidak ada hubungannya dengan persyaratan, Anda kehilangan nilai yang dibawa oleh penguji. Seperti yang dikatakan QA Lead Niall Lynch, “Siapa pun dapat menemukan bug. “Pelanggan selalu melakukannya secara gratis.”

Namun, penguji memiliki koneksi unik ke “aplikasi yang sedang diuji”, dan membawa penguji lebih awal tidak hanya memungkinkan Anda memanfaatkannya, tetapi juga menambah nilai yang diperhatikan pengguna. Sementara penguji (seperti pengguna) sangat peduli dengan cara kerja aplikasi, penguji (seperti pengembang) adalah bagian dari proses pengiriman aplikasi.

Penguji perlu memahami sisi bisnis (proses yang terlibat/tujuan apa yang ingin dicapai) dan sisi teknis (bagaimana aplikasi seharusnya bekerja/apa yang mampu dilakukan aplikasi). Dengan kata lain: penguji perlu mengetahui seperti apa “selesai” dari perspektif pengguna akhir dan perspektif aplikasi.

Basis untuk pengguna

Kami tidak dapat menyediakan perangkat lunak bebas bug (setidaknya, tidak dengan alat saat ini). Tetapi melibatkan penguji dalam proses persyaratan meningkatkan kemungkinan bahwa pengguna akan mendapatkan apa yang mereka inginkan, di mana bug yang tak terhindarkan yang dapat dialami pengguna. Pada awal proyek, pengujian eksplorasi lebih cenderung menemukan “bug kritis” jika didasarkan pada pemahaman penguji tentang kebutuhan pelanggan.

Ini juga berlaku di akhir proyek. Jika penguji memiliki pemahaman mendalam tentang apa yang diinginkan pengguna, yang dikembangkan selama fase persyaratan dan dilanjutkan sepanjang proyek, penguji dapat membantu menyempurnakan kriteria dan memfokuskan pengujian penerimaan pengguna. Ini memastikan bahwa UAT mewakili apa yang dibutuhkan pengguna untuk menerbitkan perangkat lunak – sesuatu yang dihargai pengguna.

Selama pengembangan, karena kami tidak dapat menghilangkan semua bug, QA memungkinkan kami mengelola risiko yang terkait dengan setiap rilis. Orang-orang yang harus memutuskan seberapa besar risiko yang dapat diterima adalah para pengguna… kecuali kami tidak dapat melibatkan mereka sebanyak yang kami inginkan (pengguna memiliki pekerjaan). Akibatnya, selama proses pengujian, penguji harus bertindak sebagai proxy bagi pengguna agar berhasil memprioritaskan pengujian. Ini hanya mungkin jika penguji pada awalnya terlibat dalam menentukan persyaratan tersebut.

Padahal, kebutuhan akan tester sebagai proxy bagi pengguna muncul di semua tahapan pengujian. Saat membuat kasus pengujian, penguji perlu mengetahui bidang apa saja yang diperlukan untuk memenuhi kebutuhan bisnis, data apa yang dianggap valid/tidak valid, dan apa yang dianggap sebagai “kasus khusus”.

Ini adalah pertanyaan bisnis, bukan pertanyaan teknis. Saya pernah keberatan untuk mengizinkan kartu waktu karyawan lebih dari 24 jam per hari… sampai seseorang menjelaskan kepada saya dampak gaji bahaya, lembur, dan bonus potensial lainnya yang menghasilkan kartu waktu yang Totalnya lebih dari 24 jam hari. Penguji berada di posisi terbaik untuk memastikan bahwa pengguna mendapatkan apa yang mereka inginkan saat berpartisipasi dalam pengembangan persyaratan.

Peningkatan tes

Selain itu, karena proses kami, kami perlu melibatkan penguji sejak awal: kami telah memutuskan bahwa memberikan “definisi selesai” memberi pengguna kesempatan terbaik untuk mendapatkan apa yang mereka inginkan. Dan ini berarti pengujian definisi yang membuktikan bahwa definisi tersebut terpenuhi. Penguji harus dilibatkan dalam fase persyaratan untuk memastikan bahwa persyaratan berisi “definisi selesai” yang bermakna.

“Bermakna” berarti menandai pengujian yang berharga bagi pengguna dan dengan demikian memprioritaskan fitur yang relevan. Memprioritaskan pengujian memastikan bahwa pengguna mendapatkan kinerja andal yang mereka pedulikan sesegera mungkin.

Ya, sebagian besar waktu, pengguna menginginkan “jalur bahagia” untuk dijalankan terlebih dahulu. Namun, seringkali, ada pengecualian—sering kali kasus ekstrem yang cukup penting sehingga program tidak benar-benar “siap digunakan” hingga kasus tertentu tersebut ditangani. Di sisi lain, saya pernah mengirimkan versi aplikasi di mana pengujian kami menunjukkan bahwa hanya “jalur bahagia” aplikasi yang berfungsi, dan itupun hanya di bawah beban ringan. Tapi itu tidak masalah karena klien hanya menginginkan versi aplikasi yang dapat mereka gunakan sebagai demo di pameran dagang.

Selain itu, mendapatkan definisi yang dapat diuji dari yang dilakukan di awal proses memungkinkan penguji menetapkan pengukuran progres yang dihargai pengguna: jumlah pengujian (fitur) yang dilakukan/dibatalkan dan jumlah bug yang diketahui belum diperbaiki. Pengguna menghargai metrik ini (terutama saat mereka melihat peningkatan angka pertama dan penurunan kedua).

Terakhir: Setelah penguji dan pengguna mulai bekerja sama dalam fase persyaratan, wajar jika kemitraan ini berlanjut. Sebagian besar alat pengujian modern (seperti Telerik Test Studio) menyediakan perekam yang memungkinkan pengguna membuat skrip pengujian dengan bekerja menggunakan aplikasi. Penguji dan pengguna dapat menggunakan alat ini untuk membuat pengujian bersama, dan pemahaman kedua kelompok tentang aplikasi dan persyaratan Ambillah lebih dalam. Lebih penting lagi, dengan berpartisipasi dalam pembuatan tes, pengguna lebih cenderung menghargai (dan percaya pada) tes tersebut.

Pengujian sebagai aktivitas nilai tambah

Dikutip oleh Lisa Crispin dan Janet Gregory di tes kelincahan, tujuan sebenarnya dari penguji adalah untuk “… bekerja dengan pelanggan atau pemilik produk untuk membantu mereka mengartikulasikan kebutuhan mereka secara memadai sehingga mereka dapat memperoleh fitur yang mereka butuhkan dan memberikan umpan balik kepada semua orang tentang kemajuan proyek. ” Dan inilah yang bahkan dianggap oleh pengguna sebagai “nilai tambah”.

Tentang Penulis

Peter Vogel adalah Arsitek Sistem dan Direktur Layanan Informasi di PH&V. PH&V menawarkan konsultasi lengkap dari desain UX melalui pemodelan objek hingga desain basis data. Peter juga menulis kursus dan mengajar untuk Learning Tree International.