Jika menjalankan proyek menggunakan BDD dengan cakupan cerita pengguna 100% dengan tes penerimaan otomatis, apa yang akan menjadi peran penguji / petugas penjaminan kualitas?
Saya kira saya membayangkan bahwa pengembang akan menulis tes penerimaan bersama dengan pemilik produk, beri tahu saya jika itu tampak seperti asumsi yang bodoh.
Jawaban:
Mungkin saya terlalu kuno, tetapi bahkan pengembangan atau teknik proses yang paling modern tidak dapat menggantikan serangkaian mata baru, mata segar, sebelum merilis produk ke klien Anda.
Bahkan jika produk Anda hanyalah sebuah API untuk pengembang lain, Anda dapat menggunakan QA untuk berpikir sebagai pengguna API, menyediakan skenario pengujian / penggunaan yang Anda atau klien Anda tidak pikirkan sebelumnya.
Jika produk Anda berat berdasarkan pada antarmuka pengguna, pasti Anda ingin orang lain (itu bukan Anda atau seseorang dari tim Anda) mencari hasil akhir sebelum mengirimkannya ke klien.
Seperti kata kunci lainnya di industri kami, BDD - bahkan dengan cakupan 100% - bukanlah peluru perak .
Cakupan 100% tidak sama dengan 100% yang diuji.
Saya akan melihat orang QA dalam proyek ATDD sebagai seseorang yang akan membantu menulis tes dan melakukan jenis pengujian lain yang masih ada. Yakni Pengujian UI, pengujian kerusakan dan uji beban / stres.
Tapi saya belum pernah mengerjakan proyek ATDD.
Pekerjaan QA adalah untuk menghancurkan aplikasi, pekerjaan devs adalah untuk tidak merusaknya. Karena itu mereka menulis tes mereka dari sudut pandang berbeda. Misalnya devs menulis tes untuk melihat apakah perilaku yang diharapkan terjadi, QA menulis tes untuk melihat apa yang terjadi ketika pengguna melakukan sesuatu yang tidak akan pernah dipertimbangkan oleh pengguna. Lebih jauh, pengembang sering salah menafsirkan persyaratan dan tes QA akan menangkap ketika interpretasi mereka berbeda dari apa yang pengembang pikir artinya dan kemudian berkumpul dengan pemangku kepentingan proyek untuk menentukan interpretasi mana yang benar. Tes yang ditulis oleh devs yang menulis kode sering memiliki blind spot besar karena dev memiliki blind spot besar. Misalnya, mungkin menguji apa yang terjadi 97% dari waktu tetapi tidak pada kasus tepi.
Di perusahaan sebelumnya, peran QA adalah untuk tidak menguji produk tetapi untuk menjamin para pengembang pada dasarnya melakukan apa yang mereka katakan akan mereka lakukan sehubungan dengan tes penerimaan yang ditentukan sebelumnya yang ditentukan oleh QA.
Pemilik produk di sisi lain sama sekali tidak ada hubungannya dengan pengujian. Berurusan dengan pengujian di tingkat IMHO apa pun bukanlah peran pemilik produk.
Pada titik tertentu Anda harus memiliki kepercayaan pada karyawan Anda; checks and balances baik, tetapi Anda tidak harus memaksakan solusi dalam siklus pengembangan yang pada kenyataannya adalah hanya menangani sebagian kecil dari etos kerja karyawan.
Di dunia yang sempurna saya melihat kolaborasi dengan dev dan QA diformalkan dengan penulisan tes penerimaan secara bersama. QA harus membawa aspek yang berbeda ke meja sebagaimana seharusnya tim pengembangan. QA harus memegang pai saat masih bayi produk dan tetap terlibat sepanjang siklus. Pemilik produk kemudian harus menggunakan QA untuk memahami kondisi produk saat ini, risiko, dll ... dan fokus pada produk secara holistik; bukan nuansa spesifik yang membentuk produk.
Dari pengalaman saya: Kami menggunakan uji Unit untuk mencakup lebih dari 90% kode. Ada juga tes integrasi dan build setiap jam. jBehave tes untuk BDD.
Peran QA: - mengadopsi cerita pengguna untuk pengujian - menulis kode di belakang langkah-langkah - pengujian eksplorasi menggunakan plug-in RestClient untuk IDEA (jadi kami menemukan beberapa bug utama)
Bagian dari BDD menerapkan pendekatan 3 Amigos di mana para pemangku kepentingan berkolaborasi untuk menghasilkan kriteria penerimaan. QA / Dev dapat menulis kode langkah untuk membuat skenario dieksekusi sebagai tes penerimaan. Di mana nilai QA untuk mengeksekusi secara manual tes penerimaan yang sama bahwa alat BDD akan mengeksekusi secara otomatis? Nilai tambah QA adalah untuk memvalidasi tes penerimaan tersebut dan melakukan pengujian eksplorasi manual di luar tes penerimaan yang dituliskan. Duplikasi biasanya akan menghasilkan hasil yang sama.
Pengembang tidak menulis ulang persyaratan dan spesifikasi, QA tidak menulis ulang kode aplikasi ... dimungkinkan bagi QA untuk tidak harus melakukan tes skrip yang sama yang dijalankan oleh pengembang sebagai tes penerimaan. Sudah waktunya bagi Devs untuk mengenakan topi QA!