Kriteria Penerimaan untuk Kasus Tepi

Saya adalah pemilik produk di tim yang gesit. Saya ketika melakukan pengujian penerimaan PO saya biasanya membuat catatan untuk mencoba beberapa kasus tepi. Itu tidak biasa bagi saya untuk menemukan sesuatu dan kemudian saya mengembalikannya kepada para devs. Saya mendapat dorongan kembali dari salah satu pengembang ketika saya menolak ceritanya. Dia mengatakan itu tidak adil karena saya tidak menentukan kasus tepi dan bagaimana program harus merespons dalam kriteria penerimaan, karena ia cenderung kode hanya untuk apa yang saya jelaskan dalam cerita. Saya telah mendorongnya untuk bertanya kepada saya ketika dia menabrak setiap kasus tepi saat coding, tapi dia pikir itu bukan tugasnya untuk memikirkan kasus tepi, milikku dan aku harus membuat cerita baru untuk sprint berikutnya.

Dalam pembelaan saya, saya tidak tahu desainnya untuk cerita sampai setelah dia mengimplementasikannya, jadi sulit untuk mengulangi semua kemungkinan (akankah konfigurasi ada dalam file DB atau properti?). Demi kesederhanaan, katakanlah kita memiliki cerita untuk menambahkan pembagian ke aplikasi kalkulator. Dalam dunia SCRUM yang ideal, akankah saya berkewajiban menambahkan "menangani pembagian dengan skenario nol" ke kriteria penerimaan atau haruskah ia menangani kasus-kasus tersebut saat ia berkembang sehingga aplikasi tidak meledak pada 5/0? Untuk lebih jelasnya, dalam hal ini saya tidak akan menerima jika aplikasi crash pada 5/0, tapi saya akan lulus jika itu log, mencetak DIV0, atau cara lain untuk menangani kesalahan ... asalkan tidak macet.

Saya pikir jawabannya adalah Anda berdua harus memikirkan set kasus tepi Anda sendiri. Dia sebagai dev harus menangani kasus tepi yang data spesifik seperti apakah aplikasi crash dari input pengguna yang diberikan, 5/0 tentu jatuh ke bagian spektrum ini. Pengembang harus bertanya tentang Anda apa yang menurut Anda akan menjadi pesan kesalahan yang sesuai ketika input yang diberikan sebagai bagian dari interaksi pengguna mengarah ke sesuatu yang tidak valid.

Bagian Anda dari spektrum adalah sisi bisnis. Bagaimana seharusnya kalkulator berperilaku jika akun pengguna tidak diizinkan menggunakan tombol bagi? Bagaimana seharusnya berperilaku ketika akun diizinkan untuk menggunakan operasi Mod tetapi tidak memiliki akses ke fitur divisi?

Pesan penting yang menurut saya perlu Anda sampaikan, dan terima dari semua anggota tim, adalah bahwa Anda semua berada di tim yang sama. Jika produk tidak lengkap produk tidak lengkap dan tim yang harus disalahkan, bukan anggota yang diberikan.

Tim perlu bekerja sama sebagai lawan dari jenis / mantra "Bukan pekerjaan saya, bukan tanggung jawab saya".

Kriteria penerimaan datang dalam bentuk:

• Penerimaan Bisnis
• Penerimaan Jaminan Kualitas

Biasanya penerimaan bisnis biasanya menjawab pertanyaan:

• Apakah fitur yang telah diterapkan melakukan apa yang saya inginkan?

Fitur ini akan memiliki sejumlah persyaratan yang berorientasi bisnis, seperti jika saya menekan tombol ini saya berharap tindakan ini terjadi. Ini akan mencantumkan skenario bisnis yang diharapkan dan perilaku yang diharapkan tetapi tidak akan mencakup semua kasus yang mungkin.

Diharapkan bahwa persyaratan bisnis harus didefinisikan sebelum iterasi sehingga jaminan kualitas dapat mengembangkan teknis apa pun pada persyaratan non-bisnis. Jaminan kualitas harus mengembangkan kasus yang merusak serta kasus tepi sesuai kebutuhan.

Kedua set persyaratan harus ditinjau sebelum memulai pekerjaan cerita sehingga estimasi formal dan komitmen dapat terjadi untuk unit kerja. Setelah ini selesai, fitur / cerita dapat dikerjakan. Pada titik ini semua orang jelas tentang apa yang harus disampaikan baik dari sudut pandang bisnis dan teknis.

Kisah tersebut mencapai penerimaan akhir setelah anggota tim bisnis dan penjaminan kualitas menandatangani cerita tersebut. Ini harus terjadi selama iterasi untuk penerimaan bisnis dan penerimaan jaminan kualitas. Ini adalah definisi selesai (DoD) yang menandakan pekerjaan cerita tambahan dapat dimulai.

Setiap temuan baru dapat dicatat sebagai cacat atau lonjakan cerita tambahan. Dalam dunia yang sempurna ini tidak akan pernah terjadi, tetapi dalam kenyataannya biasanya ada sejumlah "penemuan" yang terjadi ketika mengerjakan sebuah fitur / cerita. Ini alami.

The tim harus bekerja sama (bisnis, QA, pengembang) untuk hash keluar setiap jenis penemuan samar-samar persyaratan. Jika ini tangkas, mereka semua harus duduk di meja yang sama untuk menumbuhkan komunikasi dan penyelesaian cepat untuk setiap pertanyaan yang mungkin timbul. Seharusnya seperti ini:

QA:

"Hei, Pengembang kita harus menangani skenario khusus ini. Aku telah menemukan bahwa jika aku memasukkan data ini aku mendapat kesalahan."

DEV:

"Itu tidak tercakup dalam persyaratan apa pun, tetapi kita dapat menambahkan beberapa fungsionalitas tambahan untuk membahas hal ini. OK, Hai Pengusaha, bagaimana Anda menginginkan aplikasi berperilaku untuk kasus ini?"

BISNIS:

"Mari kita tunjukkan pesan kesalahan standar kami dan biarkan pengguna mencoba lagi untuk skenario ini. Berapa banyak upaya tambahan yang akan dilakukan kemudian?"

DEV:

"Itu akan mudah, hanya satu atau dua jam ekstra. Saya dapat berkomitmen untuk iterasi ini. QA tolong perbarui kriteria penerimaan Anda untuk skenario ini, kami tidak perlu cerita tambahan untuk ini. Terima kasih!"

Atau jika itu banyak pekerjaan, cerita baru ditambahkan ke dalam simpanan. Tim masih dapat menerima cerita asli karena memenuhi semua persyaratan asli, dan kemudian mengambil cerita spike di iterasi berikutnya.

Menulis perangkat lunak yang berperilaku kuat dalam menghadapi input yang salah atau ambigu adalah bagian penting dari pekerjaan pengembang perangkat lunak.

Jika pengembang Anda tidak melihatnya seperti itu, sertakan persyaratan non-fungsional tambahan dalam spesifikasi persyaratan yang menyatakan persyaratan ini secara eksplisit, dan berikan pengembang Anda dengan contoh dari proses pengujian Anda sehingga mereka dapat menerapkan proses itu sendiri sebelum mengirimkan final mereka kode untuk ditinjau.

Tes penerimaan harus menjadi bagian penting dari dokumen persyaratan apa pun. Jika suatu persyaratan tidak juga menyatakan kriteria penerimaannya, itu sebenarnya bukan persyaratan; itu sebuah harapan.

Apa yang terjadi di sini adalah Anda telah menemukan nilai . Nilai input tidak terpikirkan ketika cerita (dan kriteria penerimaan) ditulis atau ketika kode ditulis. Jika itu bukan bagian dari kriteria penerimaan, Anda tidak benar-benar memiliki dasar untuk menolak cerita.

Apa yang akan kami lakukan di tim saya adalah:

1. Buat Bug yang merinci perilaku yang diharapkan dan aktual.
2. Perbarui kriteria penerimaan sehingga persyaratan yang ditemukan baru didokumentasikan.
3. Prioritaskan Bug bersama dengan semua Cerita dan Bug lainnya di iterasi berikutnya.

Manfaatnya di sini adalah Anda dipaksa untuk mempertimbangkan apakah memperbaiki bug ini atau tidak adalah hal terpenting berikutnya yang harus dilakukan. Ini mungkin atau mungkin tidak cukup penting untuk diperbaiki, tetapi penting bahwa nilainya dipertimbangkan.

Tentu saja, Anda masih perlu menemukan cara untuk mendorong pengembang (dan diri Anda sendiri) untuk menjelajahi kasus tepi ini di muka. Jika tim dev Anda tidak menghabiskan waktu untuk menguraikan cerita, dorong mereka untuk memiliki sesi perencanaan yang terperinci sebelum mulai mengerjakannya.

Beberapa pengamatan:

... ketika saya menolak ceritanya

Saya tidak tahu budaya atau proses kerja Anda, tetapi bagi saya menolak cerita adalah langkah yang berat. Jika saya adalah dev, saya juga akan menghasilkan dorongan karena itu adalah tindakan yang direkam yang berdampak buruk pada saya dan tim.

Dia mengatakan itu tidak adil karena saya tidak menentukan kasus tepi.

Tidak adil baginya untuk mengharapkan Anda mengetahui semua kasus tepi. Tetapi pada saat yang sama, tidak adil bagi Anda untuk mengharapkannya. Setiap perubahan memiliki risiko, dan ketika masalah ditemukan Anda semua harus bekerja sama sebagai tim untuk mengatasinya.

Saya tidak tahu desainnya untuk cerita sampai setelah dia mengimplementasikannya

Anda seharusnya tidak perlu tahu desainnya. Akan sangat membantu untuk mengetahui desain untuk membuat tebakan awal yang terdidik tentang cerita mana yang lebih mudah atau lebih sulit untuk manajemen jaminan simpanan. Tetapi hindari menjebak pengembang ke dalam desain Anda saat Anda menulis cerita. Ini menyebalkan semua kesenangan dari itu ketika Anda hanya sebuah keyboard yang diaktifkan suara untuk PO.

Sepertinya kalian harus memperbaiki proses dan membangun tim. Beberapa hal yang mungkin saya sarankan untuk proses:

• Sarankan agar pengembang memasukkan waktu dalam cerita ke sampul memperbaiki kasus tepi yang ditemukan. Heck, jadikan itu bagian dari setiap kisah pengguna. Ini mudah dipertahankan melalui tujuan 0 bug baru yang diperkenalkan. Masalahnya adalah dev tidak merencanakan untuk saat ini. Dan dia kehabisan waktu ketika Anda menemukan masalah. Bagaimanapun juga, ini akan memakan waktu, jadi taruh dalam cerita yang terlihat saat perencanaan.
• Setelah pengujian Anda (dan terima kasih sudah mencoba!), Kirim dev daftar masalah yang ditemukan. Memperbaiki masalah-masalah itu akan bertentangan dengan kondisi kepuasan "memperbaiki kasus tepi".
• Jika sesuatu tetap tidak diperbaiki atau ditemukan terlambat, putuskan apakah cerita perlu didorong berdasarkan apakah use case dapat dipenuhi. Masalah yang diketahui dan penyelesaiannya terjadi. Mengungkapkannya dalam catatan rilis dan membuat cerita baru untuk memperbaikinya.
• Jika ada titik kasar tertentu dalam proses yang menghasilkan pushback, maka ubah proses Anda! Bagaimanapun, perbaikan proses adalah bagian dari Scrum. Misalnya, jika dev Anda marah ketika Anda menolak cerita itu, maka usulkan kepada tim perubahan dalam proses sehingga penolakan tidak memicu perbaikan. Lakukan pengujian dan perbaikan sebelum Selesai dan Ditolak.
• Bekerjalah dengan tim dan apa yang telah mereka hasilkan dan manfaatkan sebaik mungkin. Mereka tidak melakukan pekerjaan yang sempurna dan Anda juga tidak. Jadi rencanakan untuk itu. Tim saya biasanya adalah devop, jadi kami memiliki kisah pengguna Dukungan Tidak Terencana setiap sprint untuk masalah yang muncul ... perencanaan untuk yang tidak dapat direncanakan.

Persyaratan harus jelas dan singkat. Jika tidak, maka terjadi apa yang terjadi pada Anda. Ini adalah kesalahan Anda, dan hal terburuk yang dapat Anda lakukan ketika menentukan persyaratan adalah mengasumsikan sesuatu.

Anda contoh spesifik, tentang pembagian dengan nol. Jika Anda tidak menentukan bahwa Anda ingin mencatat kesalahan, maka jangan mengeluh jika pengembang mencetak 100 sebagai hasilnya.

Tetapi dalam kasus seperti itu, saya hanya akan mengisi celah yang hilang dan meneruskannya ke pengembang. Bagaimanapun, bug dalam persyaratan dapat terjadi.