Siapa yang harus menulis rencana tes?

Saya berada di tim pengembangan in-house perusahaan saya, dan kami mengembangkan situs web perusahaan kami sesuai dengan persyaratan tim pemasaran. Sebelum merilis situs kepada mereka untuk pengujian penerimaan, kami diminta untuk memberi mereka rencana pengujian untuk diikuti.

Namun, tim pengembangan merasa bahwa karena persyaratan datang dari para pemohon, mereka akan memiliki pengetahuan terbaik tentang apa yang harus diuji, apa yang harus diperhatikan, bagaimana hal-hal harus berperilaku dll dan karenanya rencana pengujian tidak diperlukan. Kami selalu berdebat tentang hal ini, dan pengembang merasa buang-buang waktu untuk menuliskan hal-hal seperti: -

1. Klik pada tombol A .
2. Kunci dalam XYZ di bidang bentuk dan klik tombol B .
3. Anda harus melihat perilaku C .

yang harus kami ulangi untuk setiap persyaratan / fitur yang diminta. Ini pada dasarnya mengulangi apa yang sudah ada dalam dokumen persyaratan.

Kami bergerak ke arah menggunakan pendekatan Agile untuk mengelola proyek kami dan ini juga diminta pada akhir setiap iterasi.

Selain pengujian unit dan integrasi, siapa yang harus membuat rencana pengujian penerimaan pengguna akhir? Haruskah itu reqestor atau pengembang?

Banyak terima kasih sebelumnya.

Salam
CK

Paket tes TIDAK boleh ditulis oleh pengembang. Bagian dari apa yang harus dilakukan oleh rencana pengujian adalah memeriksa untuk melihat apakah pengembang menafsirkan persyaratan dengan benar. Pengembang tidak dapat secara efektif menulis rencana pengujian pada kode yang akan ditulisnya. Rencana pengujian harus ditulis oleh orang-orang yang akan melakukan QA atau oleh analis bisnis. Jika pengembang harus menulis rencana, jangan pernah menugaskan seseorang untuk menulis rencana untuk bagian dari program yang akan ditulisnya.

Perhatikan bahwa ini berbeda dari merancang unit test yang harus ditulis oleh pengembang karena ia harus menguji kode yang ditulisnya untuk melihat apakah ia melakukan apa yang ia harapkan. Tetapi rencana pengujian adalah untuk menguji apakah aplikasi bekerja dengan cara yang diharapkan untuk bekerja dan ini harus dilakukan oleh seseorang yang tidak tahu bagaimana aplikasi itu secara teknis dirancang untuk bekerja agar menjadi efektif.

Tim QA harus menulis dan melaksanakan rencana pengujian.

Idealnya rencana pengujian harus ditulis secara paralel dengan spesifikasi fungsional - menakjubkan bagaimana memikirkan bagaimana menguji fungsionalitas memusatkan pikiran dan meningkatkan spesifikasi.

Jawaban Scrum: Jika Anda ingin mendefinisikan 'Definisi Selesai' Anda akan melihat bahwa memiliki rencana pengujian dengan cepat menjadi salah satu item. Bagaimana lagi Anda bisa menggambarkan cerita yang harus dilakukan, jika belum diuji.

Siapa yang kemudian bertanggung jawab untuk membuat rencana pengujian? Tim

Siapakah Tim? Setiap orang yang berkomitmen untuk mewujudkan produk harus menjadi anggota Tim.

Jadi, dalam kasus Anda, Anda dapat menyertakan (atau merekrut) orang yang dapat menulis rencana pengujian ke 'tim pengembangan' Anda. Jika Anda pindah ke Agile, Anda akan melihat bahwa membuat rencana pengujian terjadi secara paralel dengan pengembangan. Keduanya dimulai dari cerita yang sama, dan melalui komunikasi akhirnya menjadi sinkron dan disampaikan pada saat yang sama. Anda tidak boleh menyatakan bahwa cerita Anda 'selesai' sebelum lulus dari ujian yang oleh para Pemangku Kepentingan dipandang sebagai hal yang kritis.

Saya menemukan bahwa rencana uji fungsional harus ditulis oleh analis fungsional / bisnis. Mereka menulis analisis fungsional (bahkan jika Anda bekerja dengan gesit, saya berasumsi Anda memiliki beberapa analisis), dan mereka harus menuliskan jalan apa yang harus diikuti untuk aplikasi untuk keperluan pengujian.

Ini benar-benar tergantung pada bagaimana Anda bekerja, tetapi menurut saya pengembang tidak boleh menulis dokumen fungsional tentang cara menguji aplikasi, data apa yang digunakan untuk mengujinya, dll.

Inilah gagasan yang mungkin membuat kedua kelompok bahagia, dan cocok dengan gerakan menuju pendekatan Agile:

Otomatiskan cek penerimaan pengguna Anda, dan buat screencast mereka.

http://pragprog.com/magazine/2009-12/automating-screencasts

Kedengarannya seperti bagian dari masalah yang Anda hadapi adalah bahwa rencana tes yang Anda tulis sangat berulang dan murni konfirmasi. Sejujurnya, saya tidak akan menyebut apa yang Anda tulis pengujian sama sekali - jika itu hanya mengkonfirmasi persyaratan, itu memeriksa . Mengotomatiskan ini dan membuat screencasting akan memungkinkan Anda mengemas demo yang rapi untuk pelanggan Anda secara teratur (Anda bahkan dapat mengirimnya dalam waktu singkat) - mereka akan lebih cenderung mengklik demo dan menontonnya daripada membuka rencana pengujian dan mulailah bekerja melaluinya, jadi semoga Anda akan mendapatkan umpan balik yang lebih cepat (sangat penting jika Anda bergerak ke arah pendekatan yang lebih gesit). Anda dapat menggunakan kembali komponen sehingga akan mengurangi beban kerja untuk Anda,

Ini juga menyediakan cara untuk benar-benar mengeksekusi persyaratan - apakah Anda menemukan spesifikasi yang dapat dieksekusi Gojko Adzic? Lihatlah di sini: http://gojko.net/2010/08/04/lets-change-the-tune/ Jika Anda memikirkan ini sebagai cara untuk memasukkan persyaratan ke dalam formulir yang dapat dieksekusi untuk melakukan demo kepada pelanggan Anda , maka tiba-tiba itu tampak jauh lebih tidak berguna.

Sekarang, memakai topi penguji saya, saya merasa terhormat untuk menunjukkan bahwa jika hal screencast lepas landas, itu akan membebaskan Anda / pemangku kepentingan Anda untuk melakukan beberapa pengujian yang tepat - yaitu mencoba kasus tepi, dan tes yang benar-benar menantang aplikasi , Daripada hanya mengkonfirmasi persyaratan. Saya menyarankan agar Anda memberikan screencast bersama dengan pertanyaan atau saran singkat untuk bidang yang Anda ingin umpan balik lebih lanjut, misalnya:

1) Ini formulir pendaftaran baru kami - tonton screencast ini untuk mengetahui cara kerjanya!

Umpan balik yang kami inginkan: Kami telah menambahkan banyak pemeriksaan tambahan pada formulir ini untuk memastikan pelanggan tidak dapat memasukkan data yang salah - kami benar-benar ingin Anda melihat pesan kesalahan yang didapat pelanggan saat mereka memasukkan hal yang salah dan memberi tahu kami apakah pelanggan kami akan menemukan mereka mudah dimengerti.
Kami juga ingin tahu apakah kami terlalu ketat dalam beberapa kasus - jika Anda memiliki data pelanggan yang tidak biasa (mungkin nama yang sangat panjang, atau sangat pendek, atau seseorang dengan karakter yang tidak biasa dalam nama mereka,) atau sesuatu yang tidak kami pikirkan, atau mungkin alamat mereka tidak memiliki nama jalan atau sesuatu yang aneh seperti itu?) maka mungkin Anda dapat menghabiskan beberapa menit untuk mencobanya?

Yaitu, Anda menyajikan screencast yang bagus, dan kemudian meminta umpan balik, membingkainya tanpa terlalu spesifik, membuat mereka berpikir tentang masalah potensial daripada hanya mengkonfirmasi. Buat mereka berpikir , alih-alih hanya mengklik secara membabi buta melalui rencana pengujian. Anda pada dasarnya menulis piagam uji eksplorasi untuk mereka. (Jika Anda melihat Kuadran Agile Testing , ini akan menjadi tes di Kuadran 3).

Ambil contoh renovasi rumah Anda. Apakah Anda akan menerima daftar periksa yang dikerjakan oleh kontraktor Anda dengan meminta Anda memeriksa apa yang telah ia lakukan untuk Anda? Atau akankah Anda membuat daftar periksa sendiri dan memeriksa apakah kontraktor telah melakukan apa yang Anda tentukan?

Jawabannya jelas: pemohon harus memeriksa untuk melihat apakah apa yang dia minta dilakukan sesuai dengan spesifikasi. Dia harus keluar dengan daftar periksa sendiri dan menguji aplikasi. terhadap daftar ini.

Pengembang, bagaimanapun, harus memiliki daftar periksa sendiri dan memastikan pengujian internal yang tepat dilakukan dan bug dibersihkan sebelum menangani aplikasi. lebih untuk UAT. Idealnya, pengembang harus mengotomatisasi sebagian besar pengujian ini dalam bentuk skrip pengujian. Ingat TDD? Idealnya, skrip uji (dalam hal ini, unit uji kasus) harus ditulis untuk menguji komponen aplikasi. Test suite kemudian harus ditulis untuk menggabungkan unit-unit uji kasus ini untuk melakukan tes regresi terintegrasi dan selanjutnya.

Paket tes penerimaan pengguna akhir biasanya ditulis oleh klien atau rekanan bisnis di perusahaan yang mewakili pelanggan. Seharusnya mewakili fitur yang diinginkan klien, dan melengkapi pengujian integrasi QA. Baik QA maupun Development tidak dapat secara efektif merencanakan tes penerimaan pengguna, karena salah satu tujuan utama dari tes penerimaan pengguna adalah untuk memastikan bahwa apa yang QA dan Development pikir pelanggan inginkan sebenarnya akurat.