Apakah benar memperbaiki bug tanpa menambahkan fitur baru saat merilis perangkat lunak untuk pengujian sistem?

Pertanyaan ini untuk penguji yang berpengalaman atau lead tes. Ini adalah skenario dari proyek perangkat lunak:

Katakanlah tim dev telah menyelesaikan iterasi pertama dari 10 fitur dan merilisnya untuk pengujian sistem. Tim uji telah membuat kasus uji untuk 10 fitur ini dan memperkirakan 5 hari untuk pengujian. Tim pengembang tentu saja tidak bisa diam selama 5 hari dan mereka mulai membuat 10 fitur baru untuk iterasi berikutnya. Selama waktu ini tim uji menemukan cacat dan mengangkat beberapa bug. Bug diprioritaskan dan beberapa di antaranya harus diperbaiki sebelum iterasi berikutnya. Masalahnya adalah mereka tidak akan menerima rilis baru dengan fitur baru atau perubahan pada fitur yang ada sampai semua bug diperbaiki. Tim pengujian mengatakan bahwa bagaimana kami dapat menjamin rilis yang stabil untuk pengujian jika kami juga memperkenalkan fitur baru bersama dengan perbaikan bug. Mereka juga tidak dapat melakukan tes regresi dari semua kasus uji mereka setiap iterasi.

Ini berarti tim pengembang harus membuat cabang kode hanya untuk memperbaiki bug dan cabang lain di mana mereka melanjutkan pengembangan. Ada lebih banyak penggabungan overhead khususnya dengan perubahan refactoring dan arsitektur.

Bisakah Anda setuju jika ini adalah prinsip pengujian yang umum. Apakah kekhawatiran tim uji valid? Sudahkah Anda menemukan ini dalam praktik di proyek Anda.

Saya akan mengatakan sebaliknya bahwa setiap rilis fitur baru harus di cabang yang terpisah. Ini memungkinkan pengembangan dan rilis dipisahkan.

Bagaimana rilis Anda kepada pengguna akhir bekerja dalam proses ini? Tim pengujian sistem Anda harus kurang peduli dengan jadwal pengembangan, dan sebaliknya fokus pada jadwal rilis pelanggan.

Tidak ada gunanya mencoba menguji fitur baru secara formal saat pengembangan berlanjut, karena kemungkinan bagus bahwa 10 fitur Anda berikutnya akan menyentuh fungsi yang sama dan meminta mereka untuk menguji area tersebut lagi.

Mereka dapat terus menguji rilis internal sementara selama pengembangan dan menyempurnakan desain pengujian mereka (semoga menangkap sebagian besar bug dalam fitur-fitur baru), tetapi mereka akan memerlukan periode tambahan di akhir pengembangan untuk pengujian formal fitur baru dan regresi pengujian.

Ketika mereka memperkirakan 5 hari diperlukan untuk menguji 10 fitur baru Anda, apa yang harus mereka pertimbangkan adalah mereka membutuhkan 5 hari pada akhir siklus pengembangan, sebelum rilis ke pelanggan, untuk memvalidasi fitur-fitur baru (dan mungkin lebih banyak waktu untuk beralih) jika bug ditemukan). Selama periode ini, rilis pelanggan dapat bercabang untuk pengujian, dan pengembangan fitur baru dapat dilanjutkan untuk rilis berikutnya.

Kami menggunakan pendekatan hybrid. Untuk rilis pelanggan, kami pasti memiliki cabang sendiri yang hanya untuk perbaikan bug kritis saja.

Pengembangan reguler berlanjut pada beberapa versi perangkat lunak. Misalnya, katakanlah versi rilis stabil terbaru adalah 2.0. Semua fitur berisiko akan ditambahkan ke cabang 3.0. Hanya perbaikan bug yang masuk ke 2.0 cabang. Pengujian oleh tim QA khusus dilakukan hanya pada cabang yang stabil. Rilis pelanggan tentu saja dilakukan dari cabang lain berdasarkan 2.0. Fitur yang berjalan lama seperti pengembangan platform gen berikutnya akan dilakukan di 4.0 bahkan 3.0.

Semua ini terlihat bagus di atas kertas. Tetapi jika seorang pelanggan menginginkan fitur tertentu, itu perlu ditambahkan ke 2.0 cabang itu sendiri karena 3.0 tidak cukup stabil untuk dilepaskan ke pelanggan. Ini berarti tim QA harus menjalankan kembali seluruh paket regresi.

Satu hal yang kami lakukan adalah melakukan liputan kode untuk setiap kasus uji regresi. Hanya kasus uji regresi yang dijalankan yang akan dipengaruhi oleh perubahan kode untuk fitur. Tentu saja, untuk rilis pelanggan, paket regresi penuh dijalankan.

Itu benar-benar tergantung pada seberapa dekat ditambah fitur baru dengan bagian-bagian yang memerlukan perbaikan bug. Misalnya, jika Anda menambahkan fitur seret dan lepas baru ke satu bagian kecil dari UI, itu 'tidak boleh' mempengaruhi bug yang terkait dengan penguraian file yang dimuat oleh pengguna.

Karena itu, dapat dimengerti (tidak harus dibenarkan) bagi penguji untuk ingin menguji perbaikan 'Ceteris paribus' (semua hal 'lainnya' dianggap sama).

Mungkin ada beberapa kekhawatiran lain dengan cara rilis dan harapan pengguna akhir. Misalnya, Anda mungkin perlu merilis hanya setelah satu iterasi perbaikan bug + pengujian dan satu lagi fitur + pengujian baru karena pengguna HANYA ingin menginstal ulang atau memutakhirkan ketika ada fitur baru. Beberapa mungkin meminta perbaikan sebagai prioritas utama ASAP.

Anda dapat memecahkan masalah (umum) ini dengan menggabungkan menggabungkan kedua tim.

Penguji dalam tim pengembangan, pengujian ketika fitur diproduksi, dapat membantu sebagian besar tim meningkatkan kualitas output.

Saya sarankan Anda untuk membaca posting blog yang sangat baik ini dari Henrik Kniberg yang menjelaskan Kaban . Anda akan menemukan banyak ide dalam proses Scrum (buku gratis juga oleh Henrik Kniberg ).

Dia juga menulis artikel Kanban VS Scrum yang sangat bagus di blog-nya.

Nikmati.

Tim uji pasti memiliki kekhawatiran yang valid, tetapi saya akan mempertanyakan perlunya beberapa pengujian berulang untuk setiap rilis. Mengapa harus melalui seluruh putaran pengujian pada versi kode yang tidak akan pernah dilihat pengguna?

Jika penguji berusaha untuk mendapatkan rilis yang ditentukan untuk pelanggan, yang tidak mengharapkan fitur baru maka permintaan mereka masuk akal, dibenarkan dan Anda harus membungkuk ke belakang untuk mengirimkannya.

Jika ini hanya untuk membantu dalam "proses" mereka selama fase pengembangan normal, dan memastikan bahwa daftar bug tidak kehabisan kendali maka tanpa membuat masalah itu, tanyakan kepada kepala pengujian apakah pengekangan ini dapat dilonggarkan sedikit sampai kita semakin dekat ke titik rilis.

Pertimbangkan mengubah sistem kontrol sumber Anda menjadi produk yang didistribusikan. Ini akan membuatnya lebih mudah untuk memberikan rilis seperti itu.

"Bisakah Anda setuju jika ini adalah prinsip pengujian yang umum.

Yes

Apakah kekhawatiran tim uji valid?

Yes

Sudahkah Anda menemukan ini dalam praktik di proyek Anda. "

Yes

:

and Yes Merging is the downside of it 

Anda tidak bertanya siapa yang bertanggung jawab tetapi itu adalah tanggung jawab Manajer Konfigurasi. Strategi aliran ini harus dalam CMP-nya. Kalau tidak, pecat dia. Saya pikir respon dari Pierre 303 juga sangat baik tetapi tentu saja jika memungkinkan secara teknis (misalnya memikirkan rilis Siebel ...) dan secara organisasi.

Masalahnya adalah bahwa jika mereka menguji bug pada cabang, mereka masih perlu menguji ulang dan mengujinya di bagasi begitu mereka bergabung kembali (kecuali mereka sangat percaya yang jarang dilakukan oleh penguji yang baik). Ini bukan hanya membuat lebih banyak pekerjaan untuk para pengembang, itu membuat lebih banyak pekerjaan untuk para penguji.

Tidak ada jawaban yang benar di sini tetapi beberapa hal yang harus Anda pertimbangkan:

• Mungkinkah rilis bug ini (tanpa fungsionalitas baru) diberikan kepada pengguna? Jika demikian maka ya, itu harus bercabang dan diuji dan semua orang perlu menerimanya sebagai overhead.

• Apakah mungkin untuk membagi fungsionalitas baru sedemikian rupa sehingga ada di area aplikasi yang sepenuhnya terpisah dengan potongan-potongan sebelumnya yang sedang dikerjakan? Jika demikian, ini memberi Anda opsi - penguji dapat melakukan pengujian ulang bug dan bagian uji regresi aplikasi. Ini tidak ideal tetapi kompromi yang mungkin berhasil dan memberi mereka apa yang mereka inginkan.

• Berapa banyak pekerjaan yang sebenarnya untuk membuat mereka rilis? Biasanya itu menyebalkan, tetapi jumlah sebenarnya dari pekerjaan itu biasanya tidak terlalu bagus. Jelas Anda akan membutuhkan mereka untuk mengonfirmasi itu bukan hanya lebih banyak bekerja untuk mereka juga (lihat hal pertama yang saya katakan), tetapi saya telah melihat tempat membuat ini bekerja.

• Apakah ada cara yang lebih baik untuk menggunakan kontrol versi di sini? Sesuatu seperti Mercurial (lihat http://hginit.com/ - bacalah, itu bagus) atau cabang sistem kontrol versi terdistribusi lainnya dan bergabung dengan cara yang berbeda dan mungkin memungkinkan Anda untuk menyelesaikan masalahnya. Sungguh, lihatlah itu karena saya pikir itu mungkin jawaban untuk masalah Anda.

Tapi semoga berhasil, itu menyebalkan. Di atas semua ingat bahwa cara terbaik ke depan akan sangat tergantung pada perusahaan Anda, produk dan situasi jadi pastikan Anda memikirkan hal itu dan jangan hanya menarik sesuatu dari rak dan percaya Anda harus mematuhinya 100%.

Jika bug yang Anda uraikan adalah cacat aktual dan bukan desain optimasi , maka ya Anda harus benar-benar mencoba memperbaikinya sebelum mulai bekerja pada fitur-fitur baru.

Jika Anda membangun fitur baru di atas bug yang dikenal, Anda membuat rumah kartu. Anda mungkin mengembangkan perangkat lunak yang rapuh dan tidak dapat diprediksi. Bergantung pada tingkat isolasi antara kode kereta dan fitur baru Anda, bug juga dapat memengaruhi fitur baru Anda. Jika demikian, bagaimana Anda tahu jika fitur baru Anda berfungsi dengan benar?

Jika Anda memperbaiki bug Anda terlebih dahulu, Anda akan memiliki fondasi yang lebih kuat untuk semua fitur baru yang Anda tambahkan.

Tentu saja, ada saat-saat ketika kekuatan eksternal menekan Anda untuk menentang penilaian Anda yang lebih baik. Cobalah untuk membantu pembuat keputusan mencapai keputusan berdasarkan informasi di mana mereka mengetahui konsekuensi dari tindakan yang dilakukan (yaitu cacat yang belum terselesaikan versus tanggal pengiriman fitur yang terlewat) dan memungkinkan mereka untuk melakukan penilaian. Kadang-kadang ada alasan hukum dan keuangan di mana tindakan, meskipun tidak disukai, diperlukan.

Selalu coba untuk memperbaiki bug sebelum menambahkan fitur baru!

Di mana saya bekerja, kami menangani skenario ini di mana setiap rilis yang dimaksudkan untuk produksi memiliki cabang sendiri. Sebagai contoh, mari kita asumsikan untuk sesaat akan ada rilis pada akhir Juni dan lainnya pada akhir Juli. Rilis Juni akan mendapatkan cabang sendiri, dan semua fitur akan ditambahkan di sana dan dikirim ke QA. Pada titik ini kami akan mulai bekerja pada rilis Juli, dan cabang dari cabang Juni. Ketika QA menemukan bug, kami memperbaikinya di cabang Juni dan begitu perbaikan telah didorong ke QA mereka diperbaiki ke cabang rilis Juli. Ini memang menambah sedikit overhead untuk menangani penggabungan ini, tetapi biasanya penggabungan tersebut tidak menimbulkan rasa sakit. Sekali-sekali itu adalah rasa sakit yang besar pada Anda tahu apa, tetapi itu hanya terjadi ketika perubahan grosir dibuat, dan itu tidak boleh terjadi selama siklus QA (tetapi mereka terjadi, lebih dari yang saya akui). Tetapi dengan serangkaian pengujian yang baik (unit dan integrasi), dan cakupan kode dan semua kata kunci TDD lainnya, risikonya sedikit dikurangi. Untuk membantu, kami biasanya memiliki satu orang yang menangani penggabungan untuk setiap proyek.