Cara menyesuaikan pengujian di sprint Scrum dan bagaimana menulis cerita pengguna di Scrum

15

Saya adalah pemimpin tim pengembangan proyek baru di perusahaan saya. Ini adalah proyek pertama di mana perusahaan akan menggunakan Scrum. Kami memiliki air terjun / SDLC berulang. BA menulis dokumen persyaratan, menyerahkan ke dev dan menguji, dev mulai mengembangkan dan akan dirilis untuk pengujian dalam iterasi. Penguji membutuhkan waktu lama untuk menguji rilis yang digunakan pengembang untuk melanjutkan pengembangan tetapi juga perbaikan bug untuk rilis saat ini. Saya punya beberapa pertanyaan

  1. Dalam sprint dengan mengatakan 5 cerita kapan Anda rilis untuk pengujian? Apakah segera setelah cerita selesai oleh dev atau setelah semua cerita selesai tetapi sebelum akhir sprint memberikan tes waktu yang diperlukan untuk menguji.
  2. Jika BA menulis cerita pengguna apa yang harus detail. Biasanya diperlukan waktu lama untuk menulis spec dengan semua tata letak UI, perilaku, teks dll untuk diselesaikan. Saya kira pertanyaan saya adalah bagaimana menulis cerita yang dapat diimplementasikan dan diuji.
  3. Tim uji kami adalah non-teknis. Seberapa penting memiliki pengujian UI otomatis untuk Scrum. UI didasarkan pada WPF.

Saya memiliki pengalaman pengembangan yang solid menggunakan metode gesit (TDD, ulasan kode, refactoring dll) tetapi baru untuk scrum.

sunting: Dengan iterasi yang saya maksudkan bahwa jika ada 100 persyaratan yang kami dapat lepaskan untuk pengujian ketika kami telah menyelesaikan 30, 35, 35 persyaratan daripada menunggu sampai semua 100 persyaratan telah selesai.

scrum softveda
sumber
4
We have a waterfall/iterative SDLC.Rumuskan hal ini. Waterfall, menurut definisi, adalah proses berurutan, bukan proses berulang. Meskipun ada air terjun yang dimodifikasi (seperti model sashimi atau air terjun-dengan-proyek), semuanya berurutan. Apakah Anda mencoba untuk beralih ke proses berulang dari proses sekuensial Anda saat ini?
Thomas Owens
1
@Ratik bagaimana hal bekerja untuk Anda? Apakah Anda berhasil bekerja sama lebih baik dengan tim QA?
flup

Jawaban:

11

Jika pengujian terpisah dari pengembangan, Anda memiliki dua tim scrum terpisah. Ini adalah ide yang buruk untuk memiliki satu pekerjaan tangan ke yang lain.

Pengembang Anda harus menulis tes mereka sendiri, terpisah dari tim lain ini. Anda harus memperlakukan tim "uji" lainnya ini sebagai pelanggan Anda.

Dalam sprint ... kapan Anda merilis untuk pengujian?

Saat sprint selesai. Benar-benar selesai. Itu berarti Anda telah melakukan pengujian unit Anda sendiri dan yakin itu berhasil. Setelah tim pengembangan Anda selesai, Anda melepaskannya ke tim lain untuk "pengujian" atau "penyebaran" atau apa pun yang terjadi di organisasi.

Saya kira pertanyaan saya adalah bagaimana menulis cerita yang dapat diimplementasikan dan diuji.

Itu bervariasi dari tim ke tim. BA adalah bagian dari tim pengembangan. Anda harus mengerjakannya sebagai tim (BA plus pengembang) untuk mendapatkan jumlah detail yang tepat. Ini adalah upaya tim untuk mendapatkan informasi yang benar dari BA ke seluruh tim.

Seberapa penting memiliki pengujian UI otomatis untuk Scrum.

Penting Benar-benar diperlukan untuk pengembangan UI apa pun. Pengembang harus melakukan semua pengujian sendiri sebelum diberikan kepada "tim uji". Jika ada UI, mereka harus mengujinya. Jika tidak ada UI, maka pengujian UI otomatis tidak diperlukan. Diperlukan pengujian, dan UI harus diuji. Pengujian otomatis adalah praktik terbaik saat ini.

Intinya. Tim "tes" yang terpisah dan BA yang menulis setiap detail kecil bukanlah organisasi yang optimal untuk Scrum. Scrum berarti Anda harus memikirkan kembali organisasi Anda serta proses Anda.

S.Lott
sumber
6
After you're development team is done, you release it to other teams for "testing" or "deployment" or whatever else happens in the organization. Apa bedanya dengan Air Terjun Iteratif? Dalam hal ini sprint hanyalah Iterasi Air Terjun yang sangat singkat. Jenis kekalahan ini salah satu kekuatan terbesar dari Agile and Scrum IMO, bahwa semua BA, Pengembang, dan QA bersama-sama di tim yang sama dan mereka semua secara kolektif memiliki sprint yang mereka keluarkan. Ini meruntuhkan hambatan yang terjadi dalam proyek.
maple_shaft
4
Bisakah Anda menguraikan mengapa pengujian UI otomatis sangat penting? Scrum adalah kerangka kerja manajemen proyek yang tidak menentukan praktik teknis apa pun. Satu-satunya referensi untuk pengujian yang dapat saya temukan berkaitan dengan Scrum bahwa Tim Scrum adalah tim lintas fungsi. Meskipun saya lebih suka pengujian otomatis, Scrum tidak memerlukan pengujian otomatis atau pengujian sama sekali, meskipun lulus tes harus menjadi bagian dari Definisi Selesai. Itu hanya mengatakan bahwa setiap pengujian yang dilakukan dilakukan oleh tim. Intinya Anda benar - struktur organisasi saat ini tidak cocok untuk Scrum.
Thomas Owens
2
Pertanyaannya adalah, disalin langsung dari posting asli, penekanan ditambahkan: "Seberapa penting memiliki pengujian UI otomatis untuk Scrum ." Bagi Scrum, itu tidak penting sama sekali.
Thomas Owens
2
Kata-kata dalam jawaban Anda membuatnya terdengar seperti pengujian UI otomatis adalah bagian dari proses Scrum, dan tidak. Tapi itu tidak berarti itu bukan hal yang baik yang harus dilakukan oleh tim pengembangan untuk meningkatkan kualitas. Saya setuju ini adalah pertanyaan dengan kata-kata yang buruk, tetapi perbedaan harus dibuat antara "apakah ini diperlukan untuk Scrum" dan "harus menyelesaikan pengujian UI otomatis menjadi bagian dari definisi saya tentang dilakukan untuk sebuah cerita". Pada akhirnya, jawabannya tidak berubah, tetapi menjadi lebih jelas mengapa itu diperlukan.
Thomas Owens
9
Essential. Completely required.perlu diubah untuk mencerminkan bahwa itu tidak "penting" atau "benar-benar diperlukan" oleh kerangka proses Scrum. Saat ini, pembaca yang tidak mendapat informasi akan membaca jawaban ini dan membuat kesimpulan bahwa jika Anda tidak melakukan pengujian UI otomatis, Anda tidak melakukan Scrum. Itu adalah kesimpulan yang salah, tetapi sepenuhnya dapat dimengerti mengingat kata-kata dari jawaban ini. Ada perbedaan yang jelas antara "sesuatu yang harus Anda lakukan" dan "sesuatu yang diamanatkan".
Thomas Owens
9

Sebagian besar jawaban yang akan saya berikan terkait dengan metode pengembangan perangkat lunak Agile versus metode Air Terjun Iteratif. Scrum kebetulan menjadi implementasi Agile yang populer.

  1. Dalam Scrum tipikal tidak ada fase pengujian terpisah, karena pengujian formal harus dilakukan di seluruh sprint. Saat pengembang menyelesaikan Cerita Pengguna, sumber daya QA seharusnya sudah menyiapkan kasus pengujiannya dan mulai menguji pada saat itu. Jika kasus uji mereka lulus, mereka menerima cerita pengguna dan pindah ke yang berikutnya. Setelah semua Cerita Pengguna selesai dan Diterima maka sprint selesai dan Anda memulai yang berikutnya. Ini semua tentu saja tergantung pada Integrasi Berkelanjutan, sehingga perubahan pengembangan segera tersedia untuk QA. Pengembangan lebih lanjut harus mengikuti pedoman TDD untuk memastikan pengujian regresi secepat dan tidak menyakitkan mungkin.

  2. Merupakan ide bagus bagi BA untuk menulis cerita pengguna, tetapi untuk kontrol yang lebih rinci dan spesifik, Cerita Pengguna dapat menyertai dokumen Persyaratan formal. Kisah Pengguna harus ditulis dari perspektif pengguna tunggal berdasarkan peran. Ini mengungkapkan kebutuhan dari sudut pandang pengguna, jadi wajar saja jika perangkat lunak saat ini memenuhi semua aspek kebutuhan itu maka kisah pengguna terpenuhi. Cerita pengguna dapat terdiri dari cerita pengguna anak dan Tugas yang ditugaskan. Mungkin ada tumpang tindih dalam Tugas untuk beberapa cerita pengguna.

  3. Pengujian UI otomatis bisa menjadi hal yang baik, tetapi saya pribadi merasa bahwa lebih banyak upaya pada metode TDD dan cakupan uji unit 100% dari semua Logika Bisnis lebih penting. Sebagian besar tim pengembangan perangkat lunak tampaknya tidak dapat mencapai cakupan 100% dari Logika Bisnis, jadi menurut saya Pengujian UI Otomatis akan membuang-buang waktu berharga yang dapat digunakan untuk menulis lebih banyak unit test untuk BL. Ini adalah kemewahan yang tidak perlu menurut saya.

maple_shaft
sumber
Sebuah pertanyaan asli mengenai 1: jika QA menguji setiap Kisah Pengguna segera setelah itu selesai, kemudian pindah ke yang berikutnya, bagaimana Anda memeriksa bahwa cerita terakhir dalam sprint yang sama tidak rusak (mungkin dengan cara yang halus) salah satu dari Cerita Pengguna yang sudah diuji? Semacam "regresi dalam sprint yang sama". Saya berbicara tentang QA manual, bukan suite tes otomatis, tentu saja.
Andres F.
@AndresF. Jika mengikuti proses TDD bersama dengan CI, maka jika check-in merusak fungsionalitas yang ada maka pengujian unit akan gagal dan orang-orang akan diberitahu. Tentu saja ini hanya efektif jika cakupan uji 100% dari logika bisnis ada, namun logika sederhana, masalah lingkungan atau integrasi, dan logika presentasi masih berpotensi memiliki cacat yang diperkenalkan dalam pengembangan kisah pengguna baru yang tidak tertangkap. Pengujian UI otomatis seperti yang disarankan oleh S.Lott jauh untuk menangkap sebagian besar dari ini, tetapi pada akhirnya, sedikit lebih dari tes asap cepat harus mengatasi masalah ini. cont ...
maple_shaft
... lanj. Jika Anda menemukan ini adalah masalah berulang maka Anda mungkin memiliki kelemahan desain yang lebih dalam atau masalah yang harus diatasi seperti kopling ketat dan kohesi rendah yang membuat kode Anda sangat rapuh.
maple_shaft
@maple_shaft: Itu mudah untuk dikatakan tetapi QA tidak suka rilis di tengah pengujian mereka. Kami juga sering melakukan checkin dengan build CI tetapi rilis dilakukan berdasarkan permintaan saja. Tim pengujian saat ini tidak dapat menulis tes UI otomatis. Mereka melakukan pengujian manual murni. Ini akan sulit bagi saya untuk berubah.
softveda
@Ratik Saya mengerti betapa sulitnya mempercayai saya. Saya tahu sakitnya. Mungkin Anda dapat memperpanjang sprint tetapi memiliki tiga atau empat rilis ke lingkungan pengujian per sprint? Dengan cara ini tim pengujian dapat pergi untuk hari di tengah-tengah ujian dan yakin lingkungan tidak berubah dalam semalam.
maple_shaft
4

  1. Di Scrum, Anda seharusnya menghasilkan peningkatan perangkat lunak yang berpotensi dapat dikirim pada akhir setiap sprint. Sebagai hasilnya, Scrum mempromosikan konsep seluruh tim atau lintas fungsi di mana setiap keterampilan yang diperlukan untuk memimpin cerita pengguna tertentu untuk dilakukan harus ada di tim.

    Dalam proyek saya saat ini, karena cerita yang sepenuhnya teruji adalah bagian dari definisi kami tentang selesai, kami telah menyertakan penguji dalam tim. Selama beberapa hari pertama sprint, sementara pengembang mulai mengerjakan cerita pengguna pertama, penguji akan menyiapkan skenario pengujian dan menyiapkan beberapa data pengujian. Begitu dev untuk salah satu cerita pengguna selesai, mereka akan mengujinya.

  2. Ini adalah salah satu kesulitan terbesar dalam Scrum IMO. Anda harus menemukan jumlah spesifikasi yang tepat yang diperlukan untuk mendapatkan cerita pengguna yang dapat diimplementasikan dan diuji. Terlalu banyak analisis dimuka, dokumentasi dan spesifikasi akan menghasilkan rencana kaku yang pasti akan terbukti salah selama sprint. Sebaliknya, cerita pengguna yang belum didefinisikan dan diungkapkan dengan jelas oleh Pemilik Produk akan menyebabkan bandwidth komunikasi jenuh antara pengembang dan PO selama Sprint dan keterlambatan dalam pengembangan sementara PO membuat keputusan tentang cerita pengguna di tengah sprint .

    Dalam kasus kami, kami telah menetapkan jumlah detail yang tepat untuk cerita pengguna menjadi 1 / deskripsi dalam bentuk "sebagai ... Saya ingin ... sehingga ..." dan 2 / serangkaian penerimaan kriteria. Kami jarang membuat maket UI sebelumnya, itu bisa terjadi selama sprint planings tetapi mereka lebih banyak sketsa yang dibuang sesudahnya.

  3. Dalam pengalaman saya, pengujian UI otomatis sangat memakan waktu dan sangat rapuh. Ada cara untuk melakukan itu di WPF tetapi saya akan dengan hati-hati merenungkan biaya pemeliharaan tes tersebut dengan manfaatnya sebelum pergi ke sana.

guillaume31
sumber
2

Bekerja dalam iterasi yang lebih pendek dan lebih pendek membuat semua handoff ini semakin mahal. Anda dapat mengurangi biaya ini dengan mengikuti aturan bodoh dan sederhana: potong ukuran bets menjadi dua, ubah cara Anda bekerja agar nyaman, ulangi sampai bahagia.

Ambil contoh sprint 5 lantai Anda. Jika tim Anda terbiasa menulis kode untuk semua 5 cerita, lalu menguji semua 5 cerita, maka ukuran kumpulan adalah 5 cerita. Potong itu menjadi dua. Dalam sprint berikutnya, kerjakan 3 cerita paling mendesak terlebih dahulu, siapkan mereka untuk diuji sedini mungkin. Karena penguji sedang menguji 3 cerita itu, sisanya bisa menyiapkan 2 cerita yang tersisa untuk diuji. Ini akan menyebabkan rasa sakit yang tumbuh. Ubah cara Anda bekerja agar lebih nyaman.

Misalnya, lebih banyak orang akan mengerjakan setiap cerita bersama, jadi cobalah lebih banyak pasangan dan lihat apakah itu membantu Anda bekerja lebih mantap. Atau, mungkin, penguji akan menemukan masalah dalam cerita 2 yang mengalihkan perhatian beberapa programmer saat mereka sedang berusaha mengerjakan cerita 5, jadi doronglah para programmer dan penguji berlari cepat untuk membahas sebelumnya bagaimana menguji salah satu cerita dalam "batch pertama" "sehingga programmer cenderung membuat kesalahan yang mudah ditangkap oleh seorang penguji dengan sebuah tes.

Mungkin diperlukan beberapa sprint untuk menyelesaikan masalah besar yang terkait dengan penguji yang menguji sejumlah kecil cerita sementara para programmer bekerja pada kumpulan cerita selanjutnya. Setelah merasa nyaman, potong ukuran bets menjadi dua lagi. Dan lagi. Dalam setahun atau lebih, tim akan dengan nyaman menguji cerita karena para programmer percaya mereka telah selesai dengan mereka dan mungkin membuat lebih sedikit kesalahan di sepanjang jalan. Setiap cerita akan dilakukan lebih cepat.

Tentu saja, pada titik ini, sekarang Anda dapat melakukan hal yang sama dengan batch yang diterima tim dari pemilik produk, atau bahwa tim mengirim ke organisasi operasi. Dan seterusnya. Pada titik ini, Anda dapat menangani "berapa banyak detail yang harus ditulis oleh BA untuk cerita?" masalah.

Omong-omong: agar penguji dapat menurunkan waktu penyelesaian, mereka harus mengadopsi beberapa otomatisasi, dengan beberapa kombinasi belajar cara mengotomatisasi dan pemrogram membantu mereka mengotomatisasi. Saat Anda mencoba mengurangi ukuran bets, Anda akan mengetahui kapan Anda harus memperbaiki masalah tersebut. Jangan menambahkan otomatisasi hanya karena sebuah buku mengatakan Anda membutuhkannya.

Saya harap itu membantu Anda.

JB Rainsberger
sumber
0

Hanya ingin berbagi beberapa pengalaman seperti di bawah ini, semoga bermanfaat bagi Anda.

Dalam sprint dengan mengatakan 5 cerita kapan Anda rilis untuk pengujian? Apakah segera setelah cerita selesai oleh dev atau setelah semua cerita selesai tetapi sebelum akhir sprint memberikan tes waktu yang diperlukan untuk menguji.

Untuk setiap kisah pengguna besar, itu harus dipecah menjadi banyak sub-tugas dan ketika sub-tugas sepenuhnya dilakukan oleh pengembang, mereka harus dirilis ke QC untuk pengujian segera. Cacat harus diperbaiki setelah pengujian untuk sub-tugas tersebut menyelesaikan pengujian.

Jika BA menulis cerita pengguna apa yang harus detail. Biasanya diperlukan waktu lama untuk menulis spec dengan semua tata letak UI, perilaku, teks dll untuk diselesaikan. Saya kira pertanyaan saya adalah bagaimana menulis cerita yang dapat diimplementasikan dan diuji.

Di Scrum, cerita pengguna harus dalam format apa pun asalkan percakapan seputar cerita terjadi dan tidak diharapkan selesai atau statis. Sebuah cerita kecil, yang disebut hanya cerita pengguna, adalah cerita yang dipahami dengan baik dan dapat diimplementasikan dalam sprint. Prioritas cerita dapat didasarkan pada ROI, nilai bisnis, atau apa pun yang disetujui pengguna itu penting. Ini adalah aktivitas yang dilakukan oleh PO.

Tim uji kami adalah non-teknis. Seberapa penting memiliki pengujian UI otomatis untuk Scrum. UI didasarkan pada WPF

Menerapkan pengujian otomatisasi di Scrum adalah kegiatan yang cukup sulit. Karena semua fungsi diimplementasikan secara tidak lengkap dan tidak terlalu stabil untuk membiarkan QC menerapkan uji kasus oleh beberapa alat pengujian otomatis. Ini harus dilakukan untuk sprint yang disebut: regresi.

Danh
sumber