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

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.

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.

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.

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.

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.

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.