Menyingkirkan tim QA mungkin sebenarnya adalah keputusan yang buruk
- Bagian paling lambat dalam pengiriman software adalah pengujian. Alasan continuous deployment ada adalah karena pengujian, jadi ketika ini menjadi titik bottleneck, itu justru bisa dianggap sebagai keadaan yang sudah dioptimalkan.
- Kebiasaan dan perilaku yang berfokus pada optimasi membuat industri cenderung melihat tim QA sebagai bottleneck lalu berusaha menghilangkannya. Akibatnya, rasa hormat terhadap peran QA menurun, dan muncul masalah ketidakmampuan menghasilkan software berkualitas.
- Developer tidak benar-benar memahami pengelolaan kualitas software. Banyak organisasi tidak tahu siapa yang seharusnya bertanggung jawab atas kualitas software, dan bahkan di tempat yang masih mempertahankan fungsi QA, mereka kesulitan menemukan posisi yang tepat untuk peran tersebut.
Apa yang perlu dilakukan untuk mengelola kualitas dalam praktik software
- Pelacakan cacat: Diperlukan cara agar pengguna dapat memberikan informasi tentang bug dan developer dapat mencatat bug tersebut.
- Triage: Triage bug adalah proses mengelola penugasan, penetapan prioritas, perapian, klasifikasi, dan penghapusan duplikasi bug.
- Investigasi cacat: Mereproduksi bug adalah bagian penting dari pengelolaan bug, dan diperlukan upaya engineering untuk memahami serta menyelesaikan masalah yang sebenarnya.
- Fokus: Perusahaan perlu memiliki orang-orang yang fokus pada kualitas, serta seseorang yang mengadvokasi kualitas untuk menjaga keseimbangan antara kualitas dan kecepatan.
- Pengujian end-to-end: Masalah kepemilikan sistem muncul akibat arsitektur yang kompleks, dan ini berujung pada tidak adanya pengujian penggunaan nyata sebelum produk dirilis.
Opini GN⁺
- Menghilangkan tim QA adalah kesalahan manajerial yang dalam jangka panjang dapat berdampak serius pada kualitas software.
- Dalam proses pengembangan software, quality assurance adalah pekerjaan yang penting, dan sikap mengabaikan atau meremehkannya pada akhirnya dapat berujung pada kegagalan.
- Artikel ini menarik karena menyoroti kembali pentingnya QA dalam industri software, serta menekankan perlunya pemahaman yang tepat tentang pengelolaan kualitas dan pembagian peran di dalam organisasi.
1 komentar
Opini Hacker News
Pada akhir 1970-an, pernah menangani pekerjaan jaminan produk di IBM, termasuk menulis kode pengujian dan merakit perangkat keras untuk produk yang ditangani (sistem pengolah kata). Kasus uji tidak dibagikan secara rinci kepada tim pengembang; hanya masalah umum yang disampaikan untuk mendorong perbaikan bug. Dari ketidaksesuaian antara bug yang ditemukan dengan metode ini dan bug yang diperbaiki tim pengembang, perkiraan jumlah bug yang tersisa dapat dihitung secara statistik.
Di organisasi tanpa tim QA, diperkenalkan konsep "sniff test". Ini adalah sesi ketika semua orang di perusahaan menguji fitur baru secara intensif dalam waktu singkat (biasanya 1 jam), dan hasilnya menghasilkan banyak tiket bug. Tes sederhana sering kali memunculkan masalah, tetapi sekarang itu tidak lagi mengejutkan.
Dua perusahaan tempat bekerja 15-20 tahun lalu berinvestasi pada tim QA kelas atas, dan mereka sangat unggul dalam menemukan bug yang tidak terpikirkan oleh para developer. Tim QA memiliki kewenangan akhir untuk memutuskan apakah produk boleh dirilis. Saat ini banyak perusahaan menganggap lebih baik jika developer menulis automated test dan menghabiskan banyak waktu pada code coverage, tetapi saya telah melihat banyak produk yang sebenarnya tidak berfungsi. Bukan berarti automated test itu buruk, melainkan ini mempertanyakan penghapusan tester QA manusia.
Karyawan yang paling berhati nurani dalam organisasi sering kali juga yang paling tidak puas. Mereka menyadari masalah kualitas dan berusaha menyelesaikannya, tetapi tidak dihargai; ketika berbicara soal kualitas, mereka diperlakukan seperti orang yang ingin bergerak lambat. Sementara orang-orang yang "bergerak cepat dan merusak banyak hal" terus diberi penghargaan, mereka marah karena harus membereskan akibatnya, dan merasa bahwa benar-benar peduli pada organisasi bisa merugikan karier mereka.
QA cenderung dianggap sebagai "cost center" oleh bisnis dan manajemen puncak. Ada anggapan bahwa bekerja di departemen yang dipandang sebagai "cost center" sebaiknya dihindari, dan kompensasi serta pengakuan selalu jatuh kepada orang-orang yang menghasilkan pendapatan. QA harus melakukan lebih banyak pekerjaan dengan lebih sedikit orang, disalahkan atas kegagalan, dan bisa menjadi bagian pertama yang terkena PHK saat bisnis perlu dirampingkan.
QA engineer memiliki kemampuan debugging yang luar biasa. Mereka bekerja di semua sisi aplikasi, termasuk pipeline, source code, dan direktori pengujian, sementara software engineer sering menghabiskan waktu berhari-hari untuk menebak solusi tanpa membaca pesan kesalahan pipeline atau malah mengabaikan masalah dasarnya. Sikap meremehkan terhadap QA engineer tidak dilebih-lebihkan dalam artikel itu; karena organisasi QA tidak menjalani proses wawancara seketat organisasi engineering, QA engineer dipandang lebih rendah.
Dari pengalaman pribadi, belum pernah bertemu tim QA yang benar-benar menulis pengujian untuk engineering. Sebagian besar tim QA menjalankan "test plan" secara manual atau, lebih jarang, melalui pengujian browser/perangkat yang diotomatisasi. Jenis pengujian ini memang bernilai, tetapi tidak setara dengan "unit test" atau "integration test". Dalam model ini, justru tim engineering yang pada praktiknya menjalankan peran QA, sementara tim QA sering menandai hal yang sebenarnya bukan bug sebagai bug sehingga nilainya berkurang.
Setelah menghapus tim QA, Microsoft terlihat mengalami lebih banyak bug pada Windows dan produk cloud-nya.