Siapa yang harus menulis rencana tes?


10

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


1
Satu-satunya masukan untuk ini yang harus dimiliki para pengembang adalah menyarankan area dan mungkin beberapa kasus tepi yang harus diuji (dan tidak lupa). Tetapi mereka tidak harus memberikan rincian langkah demi langkah tentang bagaimana tepatnya menguji.
CaffGeek

Jawaban:


10

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.


Inilah yang saya katakan selama bertahun-tahun di satu pekerjaan.
David Thornley

1
Baik sampai kalimat terakhir, tetapi pengujian tidak boleh hanya bertahan untuk memeriksa aplikasi mengikuti harapan (tetapi juga harus mencakup yang tak terduga!), Dan mengetahui setidaknya sedikit tentang bagaimana aplikasi itu dirancang secara teknis SELALU membantu saya sebagai penguji untuk mengidentifikasi celah-celah yang bisa saya dapatkan pada linggis tester saya untuk membuka benda itu dengan lebar. ;) Ini sedikit gagasan kuno untuk membayangkan bahwa penguji lebih baik tidak tahu apa-apa tentang implementasi.
testerab

1
Tepatnya, @testerab. Tidak mengetahui internal membantu merancang beberapa jenis kasus pengujian, sementara mengetahui bantuan internal dalam pengujian kotak abu-abu, misalnya, saya tahu area risiko dalam kode, saya hanya perlu membuktikan aplikasi untuk mencapai kode itu.
dzieciou

7

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.


3
Mungkin dengan bantuan dari pengembang, tetapi sebagian besar tim QA.
Zachary K

Bagaimana jika kita tidak memiliki tim QA? Haruskah tugas ini jatuh pada pemohon? Dari jawaban di sini, ini akan menjadi yang paling logis.
ckng

Jika Anda bergerak ke arah Agile, cobalah untuk merekrut beberapa orang yang berspesialisasi dalam pengujian ke dalam tim pengembangan Anda saat ini. (Catatan: baca di berbagai sekolah pengujian pertama, beberapa tidak kompatibel dengan pendekatan Agile - redcanary.mypublicsquare.com/view/hiring-software )
testerab

2
Jika Anda tidak memiliki tim QA, Anda harus datang bersama dengan para pemohon untuk membuat keputusan itu. Di satu sisi para devs seharusnya tidak perlu melakukan rencana pengujian. Di sisi lain banyak / sebagian besar pelanggan bisnis tidak tahu apa-apa tentang pengujian, dan Anda akan menghabiskan BANYAK PELATIHAN WAKTU DAN PENANGANAN TANGAN pada awalnya. Kami pernah mencoba ini dan pelanggan bisnis kesulitan besar. Kasus-kasus biasa bukan masalah besar, tetapi ketika datang ke kasus-kasus rinci dan terutama kasus pengujian negatif mereka berjuang. Lebih baik mendapatkan / menunjuk seorang pria QA atau seorang analis bisnis daripada menugaskan kepada pelanggan.
sdek

4

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.


2

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.


2

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).


Jawaban yang bagus, cara yang bagus untuk mendapatkan dev dari monoton yang membosankan sambil mendapatkan umpan balik klien. Dan tautan yang bagus.
Ethel Evans

1

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.


1

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.


en.wikipedia.org/wiki/… untuk informasi lebih lanjut.
Ethel Evans

+1 untuk menunjukkan bahwa tes penerimaan pengguna perlu dirancang oleh pengguna. Meskipun saya telah menyarankan pendekatan alternatif dalam jawaban saya (karena tampaknya mereka tidak benar-benar memiliki sumber daya QA), pengujian penerimaan pengguna tidak dapat dilakukan secara efektif oleh non-pengguna. Dalam situasi ini, sepertinya dev dan pengguna berada pada sedikit jalan buntu, jadi saya pikir dev perlu mencoba untuk memecahkannya.
testerab
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.