Pengkodean dan pengujian dalam sprint yang sama

Bagaimana pengujian ditangani dalam sprint yang sama dengan pengkodean, jika semua atau sebagian besar pengkodean tidak dilakukan sampai akhir sprint? (Saya mengacu pada pengembangan "sup ke kacang" dan pengujian satu PBI dalam sprint.)

Sebagian besar jawaban yang saya lihat online melibatkan otomatisasi QA, tetapi bahkan itu tidak benar-benar mungkin karena Anda umumnya memerlukan UI fungsional untuk merekam atau membuat tes otomatis. Saya hanya memiliki storyboard yang terus berkembang ketika saya mengembangkan fitur dan menemukan persyaratan baru.

Dalam kasus saya, saya sedang mengembangkan aplikasi desktop baru. Aplikasi desktop umumnya tidak cocok untuk pengujian otomatis dengan sangat baik. Saya memiliki beberapa tes unit otomatis, tetapi bukan tes fungsional / integrasi manual yang akan dilakukan oleh seorang profesional QA.

Jadi, di mana saya saat ini adalah bahwa sprint saya berakhir besok, saya masih memiliki kode untuk menyelesaikan, dan orang-orang QA saya belum melakukan tes, dan tidak tahu cara menguji apa pun yang saya berikan kepada mereka tanpa saya memegang tangan mereka.

Saya yakin saya bukan orang pertama yang mengalami dilema ini.

Di masa lalu, saya telah melakukan pipeline: di sprint saat ini tim uji menguji fitur yang telah diterapkan selama sprint sebelumnya. Pada pekerjaan saya saat ini, PM menyebut pendekatan ini sebagai "air terjun", dan karenanya, tidak dapat diterima.

Jika Anda tidak menguji Cerita Pengguna (AS) dan memverifikasi bahwa kriteria penerimaan terpenuhi, cerita ini tidak selesai. Jika ini tidak dilakukan, AS akan menuju sprint berikutnya. Dan jika semua US Anda berada dalam keadaan ini Anda sprint telah berakhir tanpa nilai tambah untuk proyek. Dari sudut pandang klien, saya tidak dapat membedakan ini dari seluruh tim pengembangan yang sedang berlibur.

Salah satu prinsip lean (lincah tidak berakhir dengan scrum) mengatakan "kualitas adalah bawaan". Sesuatu hanya dilakukan jika memenuhi kriteria kualitas yang Anda tetapkan. Ini sangat penting untuk memiliki proses gesit yang nyata, mengakhiri pegas dengan nilai nol atau pengujian terpisah dari pengembangan adalah gejala dari masalah besar.

Ada banyak hal yang dapat Anda lakukan:

• otomatisasi adalah kunci kesuksesan. Setidaknya pada tingkat unit test, dan beberapa praktik lain seperti CI juga penting. Ini tidak cukup, tetapi jika dilakukan dengan baik, jenis pengujian ini menghasilkan sedikit atau tidak ada bug yang ditemukan dalam pengujian manual (biasanya hal-hal kecil UI). Jika Anda telah mendedikasikan orang-orang QA, mereka dapat menjadi orang-orang yang mengotomatiskan pengujian penerimaan, dan beberapa dari otomatisasi ini dapat dimulai sebelum Anda menyelesaikan sprint.

• Lihatlah ukuran Cerita Pengguna Anda. Jika Anda memiliki AS yang selesai dalam dua hari pertama sprint, hari ketiga seorang QA dapat mengujinya. Menurut pendapat saya, memiliki sedikit riwayat pengguna (SMART) adalah salah satu hal terpenting untuk berhasil dalam pengembangan yang gesit, dan banyak orang tampaknya tidak menyadari hal ini.

• Kolaborasi antara penguji dan pengembang adalah bagian kunci kesuksesan lainnya. Dalam proyek saya sebelumnya ketika AS selesai oleh pengembang, orang QA melakukan "pair testing" dengan pengembang (bisa manual, bisa melalui peluncuran beberapa otomatis, atau lebih baik, keduanya), ini bekerja dengan cukup baik.

Masalah penting adalah bahwa Anda memiliki programmer yang membuat kode tetapi tidak menguji dan penguji yang menguji tetapi tidak kode.

Selesaikan masalah itu dan Anda tidak akan mengalami masalah ini, dan tim yang bisa dibilang lebih efisien.

Salah satu cara yang berhasil bagi saya di masa lalu adalah menyarankan pembuat kode dan penguji untuk berpasangan pada cerita dengan tugas eksplisit untuk menyampaikan cerita yang telah teruji sepenuhnya. Bersamaan dengan itu saya telah menghapus semua bentuk pemikiran "dev complete": tidak ada kolom "dev complete" pada papan scrum / kanban / trello, tidak ada sikap "dev done" oleh coders.

Apa yang terjadi adalah:

• Pasangan bertanggung jawab untuk menyampaikan cerita dan mereka berdua akan gagal jika sebuah cerita tidak selesai. Mereka diperlakukan sebagai profesional yang bertanggung jawab yang bertanggung jawab atas pengiriman perangkat lunak dan mereka melakukannya, dalam banyak kasus.

• Ada jauh lebih sedikit pekerjaan pengujian dilakukan karena penguji terkena tes unit dan integrasi, sehingga mereka tidak mengulangi tes yang sama secara manual.

• Beberapa pengujian menjadi otomatis ketika para devs memahami lebih baik apa yang dibutuhkan para penguji.

• Beberapa orang menjadi kesal.

• Cerita disampaikan lebih cepat rata-rata karena siklus uji-komit-tarik-uji menjadi hampir instan

Tentu saja, ini hanya pengalaman anekdotal saya, tetapi Anda mungkin ingin mencobanya sendiri jika Anda bisa.

Dalam kasus Anda, mengingat komentar Anda bahwa penguji dan pengembang dipisahkan secara resmi di perusahaan Anda, pesannya tampak jelas bagi saya. Ada penghalang yang jelas untuk komunikasi dan kolaborasi yang dibuat oleh aturan perusahaan.

Ini adalah masalah komunikasi , bukan masalah lincah . Mengadopsi metodologi yang tangkas hanya membuatnya jelas. Tim Silo'd adalah manajemen anti-pola yang dikenal , jadi rangkul ketangkasan non-adaptasi dalam hal ini!

Peran aktual QA Anda dekat dengan pengujian penerimaan. Saya membayangkan ini dilakukan oleh tim terpisah, yang bertindak lebih sebagai pemilik produk daripada bagian dari tim pengembangan.

Contoh: selama sprint, Anda perlu menambahkan fitur yang memungkinkan untuk memfilter hasil pencarian dengan kriteria yang berbeda. Anda sudah menerapkan mekanisme pencarian Anda, tetapi hasilnya disusun sesuai abjad.

• Selama sprint:

  1. Tim merancang desain fitur baru dan dampaknya pada basis kode yang sebenarnya.

  2. Pengembang menulis tes unit yang memastikan bahwa pemesanan berfungsi seperti yang diharapkan, dan pada saat yang sama menulis kode yang sebenarnya.

  3. Fitur baru diuji secara serius untuk memastikan tidak merusak apa pun (pengujian regresi) dan berfungsi seperti yang diharapkan (pengujian unit).

  4. Jika mungkin dan sesuai , yang tidak terjadi di sebagian besar proyek , pemilik produk (dan tim QA Anda) dapat terus-menerus mengevaluasi fitur baru untuk mencegah tim masuk ke arah yang salah. Ini membutuhkan integrasi berkelanjutan dengan lusinan bangunan setiap hari.

• Setelah sprint, pemilik produk mengevaluasi fitur baru untuk memeriksa apakah itu sesuai dengan kebutuhan pelanggan. Tim QA Anda sebenarnya ada di sini, setelah sprint berakhir.

Saya yakin masalah Anda yang sebenarnya adalah sebagai berikut:

• Lingkup . Sprint menyangkut tim Anda, dan tim Anda saja, bukan QA Anda yang sebenarnya yang bertindak lebih sebagai pemilik produk.

• Pengujian . Fakta bahwa Anda memiliki tim QA tidak berarti bahwa semua yang perlu Anda lakukan adalah menulis kode. Tugas tim Anda adalah memberikan fitur yang berfungsi seperti yang diharapkan, bukan untuk membuang kode yang akan diuji orang lain. Jika Anda mengandalkan tim QA untuk melakukan pengujian untuk Anda, ini akan meningkatkan biaya keseluruhan, karena bug akan diperbaiki satu hingga dua minggu kemudian alih-alih diperbaiki hampir secara instan.

jika semua atau sebagian besar pengkodean tidak dilakukan sampai akhir sprint?

Mengapa itu tidak selesai lebih cepat? Keterbatasan utama ini adalah sumber masalah Anda, dan saya telah melihat dua pendekatan berhasil. Yang satu cocok dengan pendekatan tangkas (tetapi bukan praktik umum lainnya) dan noda lainnya sedikit tangkas (tetapi lebih umum).

Yang pertama adalah Anda tidak kode sampai akhir sprint. Sebenarnya menulis kode adalah bagian yang relatif kecil dari pengembangan. Jika Anda menyelesaikan sekitar setengah jalan melalui sprint, itu memberikan banyak waktu bagi QA untuk melakukan pekerjaan mereka. Ini juga membuat Anda punya banyak waktu untuk menulis dokumentasi, membersihkan utang teknis, merancang desain untuk item jaminan ... Semua hal lain yang perlu Anda lakukan untuk produk yang berkualitas. Kelemahan dari ini yang saya lihat adalah hampir tidak mungkin untuk mendapatkan fungsionalitas dan pengujian unit dilakukan dengan cepat. Secara pribadi, saya pikir itu baik-baik saja untuk melakukan unit test setelah membiarkan QA mulai melihat fungsionalitas, tetapi pendukung TDD (dan lainnya) akan tidak setuju.

Opsi kedua adalah meminta QA mengoperasikan sprint di belakang staf pengembangan seperti yang dibenci PM Anda. Saya juga cenderung tidak suka ini. Ini menghilangkan konsep "produk yang dapat dirilis" di akhir sprint, bahkan jika Anda memiliki proses eskalasi untuk rilis Anda. Lebih buruk lagi, pengembang akan fokus pada hal-hal "baru" ketika QA mendatangi mereka dengan pertanyaan atau bug dari pengujian. Pengembang juga lebih tidak mungkin untuk memperbaiki bug dalam pengaturan ini. Tetapi saya telah melihatnya menghasilkan perangkat lunak berkualitas tepat waktu.

Panduan Scrum mengharuskan tim berfungsi lintas fungsi. Semua anggota tim dianggap pengembang, terlepas dari spesialisasi masing-masing. Silo'd individu (coder, tester, qa, ux, dll) tidak membantu dalam Scrum. Anggota tim saling membantu di mana pun mereka bisa. Tidak ada konsep 'meneruskan item ke qa'.

Dalam situasi Anda, sepertinya Anda memiliki masalah perkiraan. Saat memperkirakan item simpanan produk, Anda harus mempertimbangkan semua aktivitas, yaitu: Pengkodean, Pengujian, Tinjauan Sebaya, Penerapan, Integrasi - apa pun definisi tuntutan yang dilakukan.

Sebagai aturan dasar, harap bawa antara 5 dan 15 item jaminan simpanan produk ke sprint. Ini memberi Anda gambaran tentang seberapa besar setiap item simpanan produk seharusnya. Ini juga memberi Anda peluang bagus untuk menyelesaikan pekerjaan dalam sprint.

Akhirnya, tugas tim adalah memindahkan satu item simpanan produk ke 'selesai' dan kemudian pindah ke yang berikutnya. Kadang-kadang, melakukan ini berarti bahwa orang-orang saling menginjak-injak jari kaki dan dengan demikian masuk akal untuk meningkatkan lebih dari satu jaminan produk pada suatu waktu. Pedoman Anda harus mengurangi pekerjaan Anda yang sedang berjalan (WIP) dan memindahkan item simpanan produk untuk dilakukan.

Pengujian dan pengkodean berjalan seiring. Anda dapat menjadwalkannya modul demi modul. Setelah modul selesai, Anda bisa menyediakannya untuk penguji. Seluruh skenario ini juga tergantung pada fase pengujian yang sedang Anda kerjakan. Model Spiral SDLC terlihat bagus. Dalam hal itu, pengujian dan pengkodean simultan nyaman dilakukan. Pendekatan lain bisa menjadi model V .

Jawaban saya, yang mungkin agak aneh pada awalnya, adalah: Anda tidak punya waktu untuk menguji karena Anda pikir pengujian harus dilakukan pada efek samping kode. Dan dengan efek samping yang saya maksud istilah ilmu komputer :

fungsi (...) dikatakan memiliki efek samping jika, selain mengembalikan nilai, itu juga (...) memiliki interaksi yang dapat diamati dengan (...) dunia luar.

Saya memunculkan kutipan untuk menekankan bagian "interaksi dengan dunia luar": Anda ingin pengujian terjadi pada UI seperti yang dicetak pada layar ("[untuk memulai pengujian] tidak benar-benar mungkin karena Anda umumnya memerlukan fungsional UI untuk merekam atau membuat tes otomatis dari ").

Jawaban lain telah memberi tahu Anda untuk mengotomatiskan "pengujian penerimaan" ini, sehingga dapat terjadi dengan cepat. Ini benar, tetapi tidak sepenuhnya mengatasi masalah awal Anda: bagaimana jika tidak ada cukup waktu untuk menulis tes penerimaan tersebut?

Anda harus melepaskan pandangan Anda tentang pengujian setelah kode berinteraksi dengan dunia luar, yaitu telah mencetak sesuatu dan mengharapkan beberapa masukan. Masalah dengan efek samping adalah bahwa mereka, pada dasarnya, tidak dapat diuji. Ini membuat saya sadar ketika membaca sebuah wawancara dengan Guido van Rossum, di mana dia mengatakan bahwa pernyataan yang mematikan komputer hanya dapat dibuktikan berhasil dengan menjalankannya.

Solusi untuk "ketidakberdayaan" itu adalah untuk memahami bahwa, jika Anda telah membuktikan sekali bahwa pernyataan itu berfungsi, Anda dapat menggunakannya di mana-mana dan bergantung padanya untuk melakukan pekerjaannya. Mengisolasinya dalam suatu fungsi dan menguji segala sesuatu yang lain .

Membawa contoh itu lebih dekat ke pertanyaan Anda, fungsi sekarang mungkin seluruh perpustakaan atau kerangka kerja, dan bukannya mematikan komputer, itu mencetak sesuatu: antarmuka pengguna. Pertahankan agar panggilan itu sebodoh dan sekuat mungkin , karena begitu Anda memasuki bagian aplikasi itu, Anda hanya dapat menguji melalui tes penerimaan yang mahal, yaitu semacam pengamatan eksternal.

Menganggap UI sebagai "wilayah asing" sebenarnya adalah sudut pandang yang benar, karena Anda tidak perlu menguji logika perpustakaan yang tidak disediakan oleh Anda, dan mungkin mengejutkan, itu adalah sudut pandang yang realistis: apakah Anda benar-benar berharap untuk pernah menguji panggilan itu misalnya MyWidget.draw()melakukan apa yang Anda harapkan, ke tingkat satu piksel?

Ini bukan untuk mengatakan bahwa pengujian penerimaan tidak penting, atau bahwa itu dapat dilewati. Itu ada untuk tetap dan mengotomatiskannya, seperti jawaban lain menyarankan, memiliki manfaat yang sangat besar. Tetapi jika Anda ingin mencari waktu untuk menguji dan kode dalam sprint yang sama, cobalah untuk menjaga kode Anda sebagai efek samping sebisa mungkin.