Menentukan, menangkap, melakukan triase, dan mengelola bug perangkat lunak di Azure Boards

Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019

Bagaimana Anda melacak dan mengelola cacat dalam kode Anda? Bagaimana Anda memastikan masalah perangkat lunak dan umpan balik pelanggan ditangani dengan cepat untuk mendukung penyebaran perangkat lunak berkualitas tinggi? Dan, bagaimana Anda membuat kemajuan yang baik pada fitur baru dan mengatasi utang teknis Anda?

Minimal, Anda memerlukan cara untuk menangkap masalah perangkat lunak Anda, memprioritaskannya, menetapkannya ke anggota tim, dan melacak kemajuan. Dan, Anda ingin mengelola cacat kode dengan cara yang selaras dengan praktik Agile Anda.

Untuk mendukung skenario ini, Azure Boards menyediakan jenis item kerja tertentu untuk melacak cacat kode bernama Bug. Item kerja bug berbagi semua fitur standar dari jenis item kerja lainnya dengan beberapa lagi. Untuk gambaran umum fitur standar, lihat Melacak pekerjaan dengan cerita pengguna, masalah, bug, fitur, dan epik.

Bug juga menyediakan fitur tambahan berikut:

• Opsi bagi setiap tim untuk memilih bagaimana mereka ingin melacak bug
• Menguji alat untuk menangkap bug
• Integrasi bawaan di seluruh Azure DevOps untuk melacak bug yang ditautkan ke build, rilis, dan pengujian

Catatan

Jenis item kerja bug tidak tersedia dengan proses Dasar. Proses Dasar melacak bug sebagai Masalah dan tersedia saat Anda membuat proyek baru dari Azure DevOps Services atau Azure DevOps Server 2019.1 atau versi yang lebih baru.

Prasyarat

• Anda harus ditambahkan ke proyek.
• Untuk melihat atau mengubah item kerja, Anda harus memiliki Item kerja Tampilan dalam simpul ini dan Mengedit item kerja dalam izin simpul ini yang diatur ke Izinkan. Secara default, grup Kontributor memiliki kumpulan izin ini. Untuk informasi selengkapnya, lihat Mengatur izin dan akses untuk pelacakan kerja.
• Untuk menambahkan tag baru untuk ditambahkan ke item kerja, Anda harus memiliki akses Dasar atau lebih tinggi dan mengatur izin Buat definisi tag baru tingkat proyek ke Izinkan. Secara default, grup Kontributor memiliki kumpulan izin ini. Bahkan jika izin secara eksplisit ditetapkan untuk Pemangku Kepentingan, mereka tidak memiliki izin untuk menambahkan tag baru, karena mereka dilarang melalui tingkat akses mereka. Untuk informasi selengkapnya, lihat referensi akses cepat pemangku kepentingan.
• Semua anggota proyek, bahkan anggota di grup Pembaca , dapat mengirim email yang berisi item kerja.

Tip

Untuk melaporkan bug, pengguna harus memiliki minimal akses Pemangku Kepentingan dan Mengedit item kerja dalam izin simpul ini diatur ke Izinkan Jalur Area tempat mereka menambahkan bug. Untuk informasi selengkapnya, lihat Mengatur izin dan akses untuk pelacakan kerja

Jenis item kerja bug

Gambar berikut menunjukkan jenis item kerja Bug untuk proses Scrum. Jenis item kerja Bug untuk proses Agile dan CMMI melacak informasi serupa. Ini dirancang untuk muncul di backlog produk bersama dengan persyaratan atau di Taskboard bersama dengan tugas.

Catatan

Gambar yang Anda lihat dari portal web Anda mungkin berbeda dari gambar yang Anda lihat di artikel ini. Perbedaan ini dihasilkan dari pembaruan yang dibuat pada aplikasi web Anda, opsi yang telah diaktifkan oleh Anda atau admin Anda, dan proses mana yang dipilih saat membuat proyek Anda—Agile, Basic, Scrum, atau CMMI. Proses Dasar tersedia dengan Azure DevOps Server 2019 Update 1 dan versi yang lebih baru.

Bidang khusus untuk bug

Jenis item kerja Bug menggunakan beberapa bidang khusus bug. Untuk menangkap masalah awal dan penemuan yang sedang berlangsung, gunakan bidang yang dijelaskan dalam tabel berikut. Untuk informasi tentang bidang khusus untuk Bug yang ditentukan untuk proses Capability Maturity Model Integration (CMMI), lihat Bug, masalah, dan referensi bidang risiko. Untuk informasi tentang semua bidang lainnya, lihat Indeks bidang item kerja.

---

Bidang, Grup, atau Tab

Penggunaan

---

Langkah-langkah untuk Mereprodusi
(nama yang mudah diingat=Langkah-langkah Repro)

Gunakan untuk menangkap informasi yang cukup sehingga anggota tim lain dapat sepenuhnya memahami cacat kode. Sertakan tindakan yang diambil untuk menemukan atau mereproduksi bug dan perilaku yang diharapkan.

---

Info Sistem
Ditemukan dalam Build

Informasi tentang perangkat lunak dan konfigurasi sistem yang relevan dengan bug dan pengujian yang akan diterapkan. Info Sistem dan Ditemukan di bidang Build secara otomatis diisi saat Anda membuat bug melalui alat pengujian. Bidang-bidang ini menentukan informasi tentang lingkungan perangkat lunak dan membangun tempat bug terjadi. Untuk informasi selengkapnya, lihat Menguji konfigurasi yang berbeda.

---

Kriteria Penerimaan

Berikan kriteria yang harus dipenuhi sebelum bug dapat ditutup. Sebelum pekerjaan dimulai, jelaskan kriteria penerimaan pelanggan sejelas mungkin. Teams harus menggunakan kriteria ini sebagai dasar untuk pengujian penerimaan, dan untuk mengevaluasi apakah item telah selesai secara memuaskan.

---

Terintegrasi dalam Build

Menentukan nama build yang menggabungkan kode yang memperbaiki bug. Bidang ini harus ditentukan ketika Anda menyelesaikan bug. Untuk Azure DevOps lokal, untuk mengakses menu drop-down dari semua build yang telah dijalankan, Anda dapat memperbarui FIELD definisi untuk Ditemukan di Build dan Terintegrasi di Build untuk mereferensikan daftar global. Daftar global secara otomatis diperbarui dengan setiap build yang dijalankan. Untuk informasi selengkapnya, lihat Kueri berdasarkan bidang integrasi build dan pengujian.
Untuk informasi tentang cara menentukan nomor build, lihat opsi format nomor build.

---

Prioritas¹

• 1: Produk memerlukan resolusi item kerja yang berhasil sebelum dikirim dan segera ditangani.
• 2: Produk memerlukan resolusi item kerja yang berhasil sebelum dikirim, tetapi tidak perlu segera ditangani.
• 3: Resolusi item kerja bersifat opsional berdasarkan sumber daya, waktu, dan risiko.

---

Tingkat keparahan¹

Peringkat subjektif dampak bug atau item kerja pada proyek atau sistem perangkat lunak. Misalnya: Jika tautan jarak jauh dalam antarmuka pengguna—peristiwa langka—menyebabkan aplikasi atau halaman web mengalami crash—pengalaman pelanggan yang parah, Anda dapat menentukan Tingkat Keparahan = 2 - Tinggi dan Prioritas = 3. Nilai yang diizinkan dan panduan yang disarankan adalah:

• 1 - Kritis: Harus diperbaiki. Cacat yang menyebabkan penghentian satu atau beberapa komponen sistem atau sistem lengkap, atau menyebabkan kerusakan data yang luas. Dan, tidak ada metode alternatif yang dapat diterima untuk mencapai hasil yang diperlukan.
• 2 - Tinggi: Pertimbangkan perbaikan. Cacat yang menyebabkan penghentian satu atau beberapa komponen sistem atau sistem lengkap, atau menyebabkan kerusakan data yang luas. Namun, metode alternatif yang dapat diterima ada untuk mencapai hasil yang diperlukan.
• 3 - Sedang: (Default) Cacat yang menyebabkan sistem menghasilkan hasil yang salah, tidak lengkap, atau tidak konsisten.
• 4 - Rendah: Cacat kecil atau kosmetik yang memiliki solusi yang dapat diterima untuk mencapai hasil yang diperlukan.

---

Penyebaran

Kontrol Penyebaran mendukung tautan ke dan tampilan rilis yang berisi item kerja. Untuk menggunakan kontrol, Anda harus mengaktifkan pengaturan untuk rilis. Untuk informasi selengkapnya, lihat Menautkan item kerja untuk rilis nanti di artikel ini.

---

Pengembangan

Kontrol Pengembangan mendukung tautan ke dan tampilan tautan yang dibuat ke objek pengembangan. Objek ini termasuk penerapan Git dan permintaan pull, atau set perubahan TFVC dan item versi. Anda dapat menentukan tautan dari item kerja atau dari penerapan, permintaan pull, atau objek pengembangan lainnya. Untuk informasi selengkapnya, lihat Menautkan item kerja untuk pengembangan nanti di artikel ini.

---

Catatan:

¹ Untuk mengubah pilihan menu atau daftar pilih, lihat Menyesuaikan pengalaman pelacakan kerja. Metode penyesuaian tergantung pada model proses yang digunakan oleh proyek Anda.

Pilih bagaimana tim Anda melacak bug

Tim Anda dapat melacak bug sebagai persyaratan atau sebagai tugas. Untuk mendukung pilihan tim, pertimbangkan faktor-faktor berikut.

• Ukuran tim Anda. Tim yang lebih kecil dapat mempertahankan jejak yang ringan dengan melacak bug sebagai persyaratan.
• Persyaratan organisasi untuk melacak pekerjaan. Jika tim Anda diperlukan untuk melacak jam, maka pilih untuk melacak bug sebagai tugas.
• Cara kerja tim Anda. Jika tim Anda bergantung pada backlog produk untuk memprioritaskan pekerjaan dan menambahkan bug, lacak bug sebagai persyaratan.
• Alat yang ingin digunakan tim Anda seperti panel Perencanaan, bagan kecepatan, prakiraan, rollup, dan paket pengiriman. Melacak bug sebagai tugas mencegah penggunaan beberapa alat ini.

Tabel berikut ini meringkas tiga tim opsi harus melacak bug. Untuk mempelajari lebih lanjut dan mengatur opsi untuk tim Anda, lihat Menampilkan bug di backlog dan papan.

---

Opsi

Pilih kapan Anda ingin...

---

Lacak bug sebagai Persyaratan

• Memprioritaskan bug (peringkat tumpukan) bersama dengan persyaratan
• Perkirakan upaya Bug untuk prakiraan
• Memperbarui status bug di papan Kanban
• Sertakan Bug dalam bagan Kecepatan dan Diagram Alur Kumulatif
• Dapat menggunakan alat Prakiraan untuk mendukung perencanaan sprint
• Dapat menyeret dan meletakkan bug ke panel Perencanaan untuk menetapkan bug ke sprint
• Dapat melihat Bug pada Paket Pengiriman

Catatan

• Bug ditetapkan ke Kategori Persyaratan

---

Lacak bug sebagai Tugas

• Memperkirakan pekerjaan untuk bug yang mirip dengan tugas
• Memperbarui status bug pada sprint Taskboards
• Menautkan bug ke persyaratan sebagai item anak
• Dapat menyeret dan meletakkan bug ke panel Perencanaan untuk menetapkan bug ke sprint

Catatan

• Bug ditetapkan ke Kategori Tugas
• Cerita Pengguna (Tangkas), Item Backlog Produk (Scrum), atau Persyaratan (CMMI) adalah jenis item kerja induk alami untuk Bug
• Bug tidak akan terlihat pada Paket Pengiriman

---

Bug tidak muncul di backlog atau papan

• Mengelola bug menggunakan kueri

Catatan

• Bug dikaitkan dengan Kategori Bug dan tidak akan muncul di backlog atau papan
• Bug tidak akan terlihat di Backlog, Papan, Backlog Sprint, Taskboard, atau Paket Pengiriman
• Tidak dapat menyeret dan meletakkan bug ke panel Perencanaan untuk menetapkan bug ke sprint

---

Mengkustomisasi tipe item kerja

Anda dapat menyesuaikan Jenis bug dan item kerja lainnya. Atau, buat jenis kustom untuk melacak masalah perangkat lunak atau umpan balik pelanggan. Dengan semua jenis item kerja, Anda bisa mengkustomisasi elemen berikut:

• Menambahkan atau menghapus bidang kustom
• Menambahkan kontrol kustom atau tab kustom dalam formulir item kerja
• Mengkustomisasi status alur kerja
• Menambahkan aturan bersyarah
• Pilih tingkat backlog tempat item kerja muncul

Sebelum Anda menyesuaikan proses, sebaiknya tinjau Mengonfigurasi dan menyesuaikan Azure Boards.

Untuk mengkustomisasi proses khusus Anda, lihat Menyesuaikan proses pewarisan.

Menambahkan atau menangkap bug

Anda dapat menentukan bug dari beberapa alat Azure DevOps yang berbeda. Ini termasuk backlog dan papan dan alat pengujian.

Tip

Secara default, bidang Judul adalah satu-satunya bidang yang diperlukan saat membuat bug. Anda dapat dengan cepat menambahkan bug dengan cara yang sama seperti Anda menambahkan cerita pengguna atau item backlog produk menggunakan Azure Boards. Jika Anda ingin membuat beberapa bidang yang diperlukan, lakukan dengan menambahkan aturan bersyarat berdasarkan perubahan status. Untuk informasi selengkapnya, lihat Menambahkan aturan ke jenis item kerja (Proses warisan).

Menambahkan bug dari backlog atau papan Anda

Jika tim Anda memilih untuk mengelola bug dengan persyaratan, Anda dapat menentukan bug dari backlog produk atau papan Kanban Anda. Untuk informasi selengkapnya, lihat Membuat backlog produk Anda atau Mulai menggunakan papan Kanban Anda.

• Menambahkan bug dari backlog produk

  

• Menambahkan bug dari backlog produk

  

Tip

Saat Anda menambahkan bug dari backlog produk atau papan Kanban, bug secara otomatis diberi Jalur Area default dan Jalur Perulangan yang ditentukan untuk tim. Untuk informasi selengkapnya, lihat Default tim yang direferensikan oleh backlog dan papan.

Menambahkan bug dari backlog sprint atau Taskboard Anda

Jika tim Anda memilih untuk mengelola bug dengan tugas, Anda dapat menentukan bug dari papan Kanban, backlog produk, backlog Sprint, atau Sprint Taskboard Anda. Anda menambahkan bug sebagai anak ke item kerja backlog produk.

• Menambahkan bug anak yang ditautkan dari papan Kanban
  Anda menambahkan bug dengan cara yang sama seperti Anda menambahkan tugas ke item backlog. Untuk informasi selengkapnya, lihat Menambahkan tugas atau item turunan sebagai daftar periksa.

  

• Menambahkan bug anak yang ditautkan dari Sprint Backlog
  Anda menambahkan bug dengan cara yang sama seperti Anda menambahkan tugas ke backlog Sprint. Untuk informasi selengkapnya, lihat Menambahkan tugas ke item backlog.

  

Membuat bug dari alat pengujian

Dua alat pengujian yang dapat Anda gunakan untuk menambahkan bug saat pengujian termasuk Portal web Test Runner dan ekstensi Uji & Umpan Balik.

• Uji Runner: Saat menjalankan pengujian manual, Anda dapat memilih untuk Membuat bug. Untuk informasi selengkapnya, lihat Menjalankan pengujian manual.

  

• Ekstensi Uji & Umpan Balik: Saat menjalankan pengujian eksplorasi, Anda dapat memilih untuk Membuat bug atau Membuat tugas. Untuk informasi selengkapnya, lihat Pengujian eksplorasi dengan ekstensi Uji & Umpan Balik

Siklus hidup bug dan status alur kerja

Seperti semua jenis item kerja lainnya, jenis item kerja Bug memiliki alur kerja yang terdefinisi dengan baik. Setiap alur kerja terdiri dari tiga Status atau lebih dan Alasan. Alasan menentukan mengapa item ditransisikan dari satu Status ke Status lainnya. Gambar berikut mengilustrasikan alur kerja bug default yang ditentukan untuk proses Agile, Scrum, dan CMMI .

Agile	Scrum	CMMI

Untuk bug Scrum, Anda mengubah Status dari Penerapan (mirip dengan Aktif) menjadi Selesai. Untuk Agile dan CMMI, Pertama-tama Anda menyelesaikan bug dan memilih alasan yang menunjukkan bug diperbaiki. Biasanya, orang yang membuat bug kemudian memverifikasi perbaikan dan memperbarui Status dari Diselesaikan ke Ditutup. Jika lebih banyak pekerjaan ditemukan setelah bug diselesaikan atau ditutup, Anda dapat mengaktifkannya kembali dengan mengatur Status ke Berkomitmen atau Aktif.

Catatan

Jenis item kerja bug proses Agile sebelumnya memiliki aturan yang menetapkan ulang bug kepada orang yang membuatnya. Aturan ini telah dihapus dari proses sistem default. Anda dapat memulihkan otomatisasi ini dengan menambahkan aturan. Untuk proses Pewarisan, lihat Menerapkan aturan ke status alur kerja, Mengotomatiskan penetapan ulang berdasarkan perubahan status.

Memverifikasi perbaikan

Untuk memverifikasi perbaikan, pengembang atau penguji mencoba mereproduksi bug dan mencari perilaku yang lebih tidak terduga. Jika perlu, mereka harus mengaktifkan kembali bug.

Saat memverifikasi perbaikan bug, Anda mungkin menemukan bahwa bug tidak diperbaiki atau Anda mungkin tidak setuju dengan resolusi. Dalam hal ini, diskusikan bug dengan orang yang menyelesaikannya, sampai pada perjanjian, dan mungkin mengaktifkan kembali bug. Jika Anda mengaktifkan kembali bug, sertakan alasan untuk mengaktifkan kembali bug dalam deskripsi bug.

Menutup bug

Anda menutup bug setelah diverifikasi sebagai tetap. Namun, Anda mungkin juga menutup bug karena salah satu alasan berikut. Alasan yang tersedia untuk dipilih bergantung pada proses proyek dan status transisi bug.

Proses tangkas:

• Ditangguhkan: Tangguhkan perbaikan bug hingga rilis produk berikutnya.
• Diperbaiki: Bug diverifikasi sebagai tetap.
• Duplikat: Bug melacak bug lain yang saat ini ditentukan. Anda dapat menautkan setiap bug dengan Duplikat/Duplikat jenis tautan dan menutup salah satu bug.
• Seperti yang Dirancang: Fitur berfungsi seperti yang dirancang.
• Tidak Dapat Mereproduksi: Pengujian membuktikan bahwa bug tidak dapat direproduksi.
• Usang: Fitur bug tidak lagi ada di produk.
• Disalin ke Backlog: Cerita pengguna telah dibuka untuk melacak bug.

Proses scrum:

• Bukan Bug: Bug diverifikasi bahwa itu bukan bug.
• Duplikat: Bug melacak bug lain yang saat ini ditentukan. Anda dapat menautkan setiap bug dengan Duplikat/Duplikat jenis tautan dan menutup salah satu bug.
• Dihapus dari backlog: Bug diverifikasi bahwa itu bukan bug. Hapus bug dari backlog.
• Pekerjaan selesai: Bug telah diverifikasi sebagai tetap.

Proses CMMI:

• Ditangguhkan: Tangguhkan perbaikan bug hingga rilis produk berikutnya.
• Duplikat: Bug melacak bug lain yang saat ini ditentukan. Anda dapat menautkan setiap bug dengan Duplikat/Duplikat jenis tautan dan menutup salah satu bug.
• Ditolak: Bug diverifikasi bahwa ini bukan bug.
• Diverifikasi: Bug diverifikasi sebagai tetap.

Tip

Setelah bug ditutup dan perbaikan secara aktif dirilis dalam penyebaran, praktik yang direkomendasikan adalah tidak pernah membukanya kembali karena regresi. Sebagai gantinya, Anda harus mempertimbangkan untuk membuka bug baru dan menautkan ke bug yang lebih lama dan tertutup.

Selalu merupakan ide yang baik untuk menggambarkan detail lebih lanjut untuk menutup bug di bidang Diskusi untuk menghindari kebingungan di masa depan mengapa bug ditutup.

Mengotomatiskan penutupan bug saat menggabungkan permintaan pull

Jika tim Anda menggunakan repositori Git, Anda dapat mengatur Status dalam bug tertaut dan item kerja lainnya untuk ditutup setelah penggabungan permintaan pull berhasil. Untuk informasi selengkapnya, lihat Mengatur status item kerja dalam permintaan pull nanti di artikel ini.

Bug daftar dan triase

Sebagian besar tim, opsi apa pun yang mereka pilih untuk melacak bug, menentukan satu atau beberapa kueri bug. Dengan kueri, Anda dapat mencantumkan bug aktif, bug yang tidak ditetapkan, bug basi, tren bug, dan banyak lagi. Anda kemudian dapat menambahkan kueri dan bagan kueri ke dasbor tim Anda untuk memantau status bug dan kemajuan.

Kueri bug

Buka kueri bersama atau gunakan editor kueri untuk membuat kueri bug yang berguna, seperti opsi berikut:

• Bug aktif berdasarkan prioritas (State <> Done atau State <> Closed)
• Bug Sedang Berlangsung (State = Committed atau State = Active)
• Bug yang akan diperbaiki untuk rilis target (Tags Contains RTM)
• Bug terbaru - bug dibuka dalam tiga minggu terakhir (Created Date > @Today-21)

Setelah memiliki kueri yang menarik bagi tim, Anda dapat membuat bagan status atau tren. Anda juga dapat menambahkan bagan yang Anda buat ke dasbor.

Mode triase dalam hasil kueri

Setelah memulai pengkodan dan pengujian, Anda harus mengadakan rapat triase berkala untuk meninjau dan memberi peringkat bug Anda. Biasanya, pemilik proyek menjalankan rapat triase bug. Pemimpin tim, analis bisnis, dan pemangku kepentingan lainnya yang dapat berbicara tentang risiko proyek tertentu menghadiri rapat triase.

Pemilik proyek dapat menentukan kueri bersama untuk bug baru dan yang dibuka kembali untuk mencantumkan bug yang akan dipangkas.

Dari halaman hasil kueri, Anda dapat dengan cepat berpindah ke atas dan ke bawah dalam daftar item kerja bug menggunakan panah atas dan bawah. Saat meninjau setiap bug, Anda dapat menetapkannya, menambahkan detail, atau mengatur prioritas.

Mengatur dan menetapkan bug ke sprint

Jika tim Anda melacak bug sebagai persyaratan, lihat daftar bug aktif dari backlog Anda. Dengan fungsi filter, Anda hanya dapat fokus pada bug. Dari backlog produk, Anda juga dapat melakukan tugas-tugas berikut:

• Atur bug di backlog Anda, tumpukan peringkat terhadap item lain (peringkat tumpukan dinonaktifkan saat pemfilteran diaktifkan)
• Menetapkan bug ke sprint dari backlog Anda menggunakan panel Perencanaan
• Bug induk ke Fitur atau item backlog portofolio lainnya menggunakan panel Pemetaan
• Lihat rollup pekerjaan ke item backlog portofolio.

Jika tim Anda melacak bug sebagai tugas, gunakan kueri terkelola untuk mencantumkan dan melakukan triase bug. Kemudian, dalam setiap sprint, Anda akan melihat bug yang ditetapkan ke sprint dari backlog Sprint atau Taskboard.

Item papan tugas versus item daftar kueri

Anda mungkin melihat dan bertanya-tanya mengapa item yang ditampilkan di sprint Taskboard dapat berbeda dari daftar kueri yang dibuat dalam backlog sprint yang sesuai.

Dimungkinkan untuk menetapkan tugas atau bug ke iterasi tetapi tidak menautkannya ke item backlog induk. Item ini muncul dalam kueri yang dibuat, tetapi mungkin tidak muncul di Taskboard itu sendiri. Sistem menjalankan kueri lalu menerapkan beberapa proses latar belakang sebelum menampilkan item Taskboard.

Alasan ini dapat menyebabkan item kerja milik Kategori Tugas tidak muncul di backlog sprint atau Taskboard:

• Tugas atau bug belum ditautkan ke item backlog induk. Hanya bug dan tugas yang telah Anda tautkan ke item backlog produk induk (Scrum), cerita pengguna (Agile), atau persyaratan (CMMI) dengan jalur iterasi yang diatur ke sprint muncul di halaman backlog sprint.
• Tugas atau bug adalah induk dari tugas atau bug lain, atau cerita pengguna adalah induk dari cerita pengguna lain. Jika Anda telah membuat hierarki tugas, bug, atau cerita pengguna, hanya tugas tingkat anak atau cerita tingkat anak di bagian bawah hierarki yang muncul.
• Induk tertaut tugas atau bug sesuai dengan item backlog yang ditentukan untuk tim lain. Atau, jalur area item backlog induk tugas atau bug berbeda dari jalur area tugas atau bug.

Membuat pengujian sebaris yang ditautkan ke bug

Ketika tim Anda melacak bug sebagai persyaratan, Anda dapat menggunakan papan Kanban untuk menambahkan pengujian untuk memverifikasi perbaikan bug.

Memperbarui status bug

Anda dapat memperbarui status bug dengan menyeret dan menjatuhkan bug ke kolom baru di papan.

• Jika tim Anda melacak bug sebagai persyaratan, Anda menggunakan papan Kanban seperti yang ditunjukkan pada gambar berikut. Untuk informasi selengkapnya, lihat Mulai menggunakan papan Kanban Anda.

  

• Jika tim Anda melacak bug sebagai tugas, Anda menggunakan Taskboard. Untuk informasi selengkapnya, lihat Memperbarui dan memantau Taskboard Anda.

  

Kustomisasi papan Anda untuk melacak status menengah

Anda dapat menambahkan kolom perantara untuk melacak status bug Anda di papan. Anda juga dapat menentukan kueri yang memfilter berdasarkan status Kolom Papan. Untuk informasi lebih lanjut, baca artikel berikut:

• Menambahkan kolom ke papan Kanban Anda
• Mengkustomisasi Taskboard sprint
• Kueri perubahan papan Kanban

Mengotomatiskan penugasan ulang bug berdasarkan status alur kerja

Untuk mengotomatiskan tindakan pilih, tambahkan aturan kustom ke jenis item kerja Bug Anda. Misalnya, tambahkan aturan seperti yang ditunjukkan pada gambar berikut. Aturan ini menentukan untuk menetapkan ulang bug kepada orang yang membuka bug setelah diselesaikan. Biasanya, orang itu memverifikasi bahwa bug diperbaiki dan menutup bug. Untuk informasi selengkapnya, lihat Menerapkan aturan ke status alur kerja (Proses warisan).

Atur status item kerja dalam permintaan penarikan

Saat membuat permintaan pull, Anda dapat mengatur nilai status item kerja yang ditautkan dalam deskripsi. Ikuti sintaks: {state value}: #ID. Saat Anda menggabungkan permintaan pull, sistem membaca deskripsi dan memperbarui status item kerja. Dalam contoh berikut, kami mengatur item kerja #300 dan #301 ke Diselesaikan, dan #323 dan #324 ke Ditutup.

Integrasi di seluruh Azure DevOps

Salah satu metode yang digunakan oleh Azure DevOps untuk mendukung integrasi adalah menautkan objek ke objek lain. Bersama dengan menautkan item kerja ke item kerja, Anda juga dapat menautkan item kerja ke objek lain. Tautkan ke objek seperti build, rilis, cabang, penerapan, dan permintaan pull seperti yang diilustrasikan dalam gambar berikut.

Anda dapat menambahkan tautan dari item kerja atau dari objek build dan rilis.

Menautkan item kerja ke pengembangan

Kontrol Pengembangan mendukung penautan ke dan menampilkan tautan yang dibuat ke build, Git menerapkan, dan menarik permintaan. Atau, ketika repositori TFVC digunakan, repositori ini mendukung tautan ke set perubahan dan item versi. Memilih tautan akan membuka item yang sesuai di tab browser baru. Untuk informasi selengkapnya, lihat Mendorong pengembangan Git dari item kerja.

Menautkan item kerja ke rilis

Kontrol Penyebaran mendukung tautan ke dan tampilan rilis yang berisi item kerja. Misalnya, gambar berikut menunjukkan beberapa rilis yang berisi tautan ke item kerja saat ini. Anda dapat memperluas setiap rilis untuk melihat detail tentang setiap tahap. Anda dapat memilih tautan untuk setiap rilis dan tahap untuk membuka rilis atau tahap yang sesuai. Untuk informasi selengkapnya, lihat Menautkan item kerja ke penyebaran.

Menautkan item kerja ke eksekusi alur

Alur sering didefinisikan untuk berjalan secara otomatis ketika penerapan baru terjadi pada repositori Git. Item kerja yang terkait dengan alur penerapan muncul sebagai bagian dari eksekusi alur jika Anda menyesuaikan pengaturan alur Anda. Untuk informasi selengkapnya, lihat Menyesuaikan alur Anda.

Membuat atau mengedit item kerja setelah kegagalan build

Jika Anda menggunakan alur klasik (bukan YAML), Anda dapat membuat item kerja pada kegagalan build. Untuk informasi selengkapnya, lihat Opsi build, Membuat item kerja saat gagal.

Memantau status bug, penugasan, dan tren

Anda dapat melacak status bug, penugasan, dan tren menggunakan kueri yang kemudian dapat Anda buat bagan dan tambahkan ke dasbor. Misalnya, berikut adalah dua contoh yang menunjukkan tren bug aktif berdasarkan Status dan Bug Aktif berdasarkan Prioritas dari waktu ke waktu.

Untuk mempelajari selengkapnya tentang kueri, bagan, dan dasbor; lihat Tentang kueri dan Bagan terkelola, serta Dasbor.

Menggunakan tampilan Analytics dan layanan Analytics untuk membuat laporan bug

Layanan Analitik adalah platform pelaporan untuk Azure DevOps, menggantikan platform sebelumnya berdasarkan SQL Server Reporting Services.

Tampilan analitik menyediakan filter bawaan untuk melihat item kerja. Empat tampilan Analitik didukung untuk pelaporan bug. Anda dapat menggunakan tampilan ini sebagaimana didefinisikan atau diedit lebih lanjut untuk membuat tampilan kustom yang difilter.

• Bug - Semua riwayat menurut bulan
• Bug - 26 minggu terakhir
• Bug - 30 hari terakhir
• Bug - Hari Ini

Untuk mempelajari selengkapnya tentang menggunakan tampilan Analitik, lihat Apa itu tampilan Analitik dan Membuat laporan bug aktif di Power BI berdasarkan tampilan Analitik kustom.

Anda bisa menggunakan Power BI untuk membuat laporan yang lebih kompleks daripada apa yang bisa Anda dapatkan dari kueri. Untuk informasi selengkapnya, lihat Koneksi dengan Power BI Data Koneksi or.

Ekstensi marketplace

Ada beberapa ekstensi Marketplace terkait bug. Lihat Marketplace untuk Azure DevOps.

Untuk informasi selengkapnya tentang ekstensi, lihat Ekstensi Azure Boards yang dikembangkan oleh Microsoft.

Langkah berikutnya

Menggunakan templat untuk menambahkan dan memperbarui item kerja

Artikel terkait

• Memindahkan, mengubah jenis, atau menghapus item kerja
• Menyalin atau mengkloning item kerja

Backlog produk dan papan Kanban

• Backlog, portofolio, dan manajemen proyek Agile
• Membuat backlog Anda
• Menentukan fitur dan epik
• Atur backlog Anda, petakan item kerja anak ke orang tua
• Memfilter backlog, papan, kueri, dan paket secara interaktif
• Prakiraan backlog produk Anda

Papan Kanban

• Tentang Papan dan Kanban
• Mulai cepat papan Kanban
• Menyusun ulang kartu
• Menambahkan tugas atau item turunan sebagai daftar periksa

Sprint backlog dan Taskboard

• Scrum dan bekerja dengan praktik terbaik sprint
• Menetapkan item backlog ke sprint
• Menambahkan tugas
• Memperbarui Taskboard

Integrasi dalam Azure DevOps

• Menautkan cerita pengguna, masalah, bug, dan item kerja lainnya
• Mengikuti item kerja atau permintaan pull
• Mengonfigurasi nomor eksekusi atau build

Sumber daya industri

• Utang Teknis yang Baik dan Buruk (dan bagaimana TDD membantu) oleh Henrik Kniberg
• Mengelola Utang Teknis yang diposting oleh Sven Johann & Eberhard Wolff