Pengkodean dan pengujian dalam sprint yang sama


22

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.


2
Anda bukan orang pertama yang mengalami dilema ini. Anda dapat menggunakan saluran pipa: pada sprint saat ini tim uji menguji fitur yang telah diterapkan selama sprint sebelumnya.
Giorgio

2
PM memaksa tim untuk melakukan hal-hal dengan cara mereka terdengar seperti Agile Setengah-Arsed
agas


8
@ Markus Richman: Air Terjun? Anda tidak memiliki siklus pengembangan 1-2 minggu di air terjun. Saya pikir dia tidak tahu apa yang dia bicarakan.
Giorgio

2
@gnat: jika tim tidak terlalu berfungsi tinggi (dan sepertinya tim ini cocok dengan deskripsi itu), Anda dapat melihat ini sebagai PM yang memandu tim untuk mengembangkan strategi pengembangan yang lebih efektif. Mungkin PM merasa bahwa terus-menerus mengirimkan kode yang tidak diuji tidak baik untuk bisnis. Agile tidak selalu berarti "biarkan tim melakukan apa pun yang mereka inginkan", harus ada batasan sampai tim cukup matang untuk memutuskan sendiri.
Bryan Oakley

Jawaban:


13

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.


8

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!


2
Organisasi ini telah menciptakan batasan dan peran yang jelas untuk "pengembang" dan "penguji", dan sebelum itu keduanya akan bertemu;)
Mark Richman

Jadi, ubah aturannya!
Sklivvz

3
@MarkRichman dalam salah satu pekerjaan saya di masa lalu ada juga batasan yang jelas dalam peran "pengembang" dan "penguji", tetapi organisasi yang tidak menempatkan mereka akan menemui hambatan bagi mereka untuk berkomunikasi (betapa ide yang lemah antara!); Saya ingat melakukan sprint berpasangan dengan "tester yang ditugaskan" dan itu berjalan dengan baik. Apakah perusahaan Anda hanya memisahkan peran atau juga menetapkan penghalang komunikasi / kolaborasi antara insinyur yang menyelesaikan peran ini?
nyamuk

1
"Masalah utama adalah bahwa Anda memiliki programmer yang membuat kode tetapi tidak menguji dan penguji yang menguji tetapi tidak kode.": Hah? Mengapa ini menjadi masalah? Seorang programmer harus, baik, program dan tester harus menguji. Selanjutnya, Anda memerlukan beberapa fitur minimal yang diterapkan sebelum Anda dapat mengujinya : Anda tidak dapat memparalelkan dua tugas jika output dari satu tugas adalah input dari tugas lainnya.
Giorgio

@Iorgio itu pemandangan air terjun. Dengan gesit, orang yang dapat memberikan nilai secara mandiri sangat disukai. Tidak ada alasan mengapa pengembangan dan pengujian harus menjadi profesi yang terpisah. Ini adalah pilihan, terhormat, tetapi kurang cocok untuk pengembangan tangkas.
Sklivvz

4

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.


Saya benar-benar berpikir bahwa sebagian besar masalah organisasi ini (yang saya baru) adalah bahwa ada sedikit waktu yang dihabiskan di muka menganalisis persyaratan dan mendefinisikan solusi yang dapat diuraikan menjadi unit atom kecil. Dengan kondisi proyek dan tim saat ini, saya pikir sprint saat ini seharusnya tidak lebih dari sprint analisis, di mana hasil yang disampaikan adalah PBI lengkap dengan tugas dan kasus uji. Namun, mereka tampaknya fokus pada uang yang mereka bayarkan setiap jam, dan untuk setiap jam saya tidak "menggunakan kode keyboard", mereka kehilangan nilai.
Mark Richman

@MarkRichman untuk setiap jam mereka membayar Anda untuk mengetikkan omong kosong ke dalam basis kode mereka kehilangan bukan hanya jam mereka membayar Anda, tetapi semua jam yang dibutuhkan untuk mendapatkan omong kosong dari basis kode.
Móż

4

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.


1
Saya terbiasa memiliki QA menjadi sprint di belakang dalam pengujian mereka. Orang-orang di sini ingin melihat seluruh SDLC selesai setiap dua minggu. Aku hanya tidak mengerti bagaimana itu mungkin.
Mark Richman

5
@MarkRichman - Kenapa tidak? 1 hari untuk perencanaan, 5 hari untuk pengkodean dan 4 untuk pengujian unit, dokumentasi, perbaikan bug, dan desain untuk sprint berikutnya. Tantangannya bukan benar-benar menyelesaikannya, tetapi untuk menjadi cukup disiplin sebagai perusahaan untuk melakukan sejumlah kecil pekerjaan dengan baik.
Telastyn

1
karena mereka akan fokus bukan pada 5 hari saya coding, tetapi 5 hari lainnya saya tidak. Saya pasti akan mengisi 5 hari lainnya dengan pengkodean, tetapi karena mereka berkeinginan untuk menyelesaikan semua tugas pengkodean "sup ke kacang" (termasuk pengujian), itu tidak konsisten dengan panah fisika waktu :)
Mark Richman

1
@markrichman - bagus, maka seharusnya mudah untuk menunjuk ke semua hal lain yang bukan pengkodean yang perlu Anda lakukan untuk benar-benar dilakukan .
Telastyn

baik, saya juga menemukan pekerjaan tambahan yang perlu dilakukan untuk menyelesaikan pekerjaan yang dilakukan selama sprint saat ini. Ini memaksa pekerjaan lain untuk tidak diterapkan untuk sprint itu. Ini baik-baik saja, dan saya pikir dalam semangat lincah, tetapi saya diberitahu untuk tidak menambahkan apa pun ke sprint saat ini, dan menambahkan tugas-tugas yang baru ditemukan (dan selesai) ini ke Product Backlog, yang terasa tidak cocok untuk saya. .
Mark Richman

1

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.


0

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 .


Saya setuju dengan Anda, tetapi "kekuatan yang ada" tampaknya murni tentang apa pun selain menyelesaikan seluruh SDLC dalam satu sprint dua minggu. Apa pun selain metodologi ini tampaknya dianggap sebagai air terjun.
Mark Richman

0

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.

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.