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? 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. 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 Tentang item kerja dan jenis item kerja.

Bug juga menyediakan fitur-fitur 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

• Akses proyek: Ditambahkan ke proyek.

• Izin:

  • Minta Tampilkan item kerja dalam simpul ini dan Edit item kerja dalam izin simpul ini diatur ke Izinkan. Secara default, grup Kontributor memiliki izin ini. Untuk informasi selengkapnya, lihat Mengatur izin pelacakan kerja.

  • Untuk menambahkan tag baru ke item kerja, memiliki akses Dasar atau lebih tinggi dan tingkat proyek Buat izin definisi tag baru diatur ke Izinkan. Secara default, grup Kontributor memiliki izin ini.

    Catatan

    Pemangku kepentingan tidak dapat menambahkan tag baru, meskipun izin diatur secara eksplisit, karena tingkat aksesnya. Untuk informasi selengkapnya, lihat referensi akses cepat pemangku kepentingan.

• Item kerja email: Semua anggota proyek, termasuk yang ada di grup Pembaca , dapat mengirim email yang berisi item kerja.

Tip

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

Jenis item kerja bug

Gambar berikut menunjukkan jenis item kerja Bug untuk proses Scrum. Jenis item kerja Bug untuk proses Agile and Capability Maturity Model Integration (CMMI) melacak informasi serupa. Ini 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 diaktifkan oleh Anda atau administrator 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 Mereprodurasi (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.

---

InfoSistem 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 diselesaikan dengan 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 dropdown dari semua build yang telah berjalan, 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 Konfigurasi alur klasik.

---

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. 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. Ada metode alternatif yang dapat diterima 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.
• Organisasi pekerjaan 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, atau menumpuk peringkat, bug bersama dengan persyaratan
• Perkirakan upaya Bug untuk prakiraan
• Memperbarui status bug di papan
• Sertakan Bug dalam bagan Kecepatan dan Diagram Alur Kumulatif
• Dapat menggunakan alat Prakiraan untuk mendukung perencanaan sprint
• Seret bug ke panel Perencanaan untuk menetapkan bug ke sprint
• Lihat 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
• Seret 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 terlihat pada Paket Pengiriman

---

Bug tidak muncul di backlog atau papan

• Mengelola bug menggunakan kueri

Catatan

• Bug dikaitkan dengan Kategori Bug dan tidak muncul di backlog atau papan
• Bug tidak terlihat di Backlog, Papan, Backlog Sprint, Taskboard, atau Paket Pengiriman
• Anda tidak dapat menyeret 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. Untuk 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 menyesuaikan proses, kami sarankan Anda meninjau Tentang 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. Alat-alat ini termasuk backlog dan papan dan alat pengujian.

Tip

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

Menambahkan bug dari backlog atau papan Anda

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

• Menambahkan bug dari backlog produk

  

• Menambahkan bug dari papan

  

Tip

Saat Anda menambahkan bug dari backlog atau papan produk Anda, bug secara otomatis diberi Jalur Area dan Jalur Perulangan default 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, backlog produk, backlog Sprint, atau Sprint Taskboard Anda. Anda menambahkan bug sebagai anak ke item kerja backlog produk.

• 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.

  

• Menambahkan bug anak yang ditautkan dari papan

  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.

  

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 Anda menemukan lebih banyak pekerjaan setelah menyelesaikan atau menutup bug, aktifkan 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 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 saat anggota tim memverifikasinya sebagai tetap. Namun, Anda mungkin juga menutup bug karena salah satu alasan berikut. Alasan yang tersedia tergantung 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 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, seperti bug dibuka dalam tiga minggu terakhir (Created Date > @Today-21)

Saat Anda 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 Anda mulai mengoding dan menguji, adakan 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 bisa 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.
• Tetapkan bug ke sprint dari backlog Anda menggunakan panel Perencanaan .
• Petakan 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. Di 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 tidak ditautkan ke item backlog induk. Hanya bug dan tugas yang ditautkan ke item backlog produk induk (Scrum), cerita pengguna (Tangkas), 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 membuat hierarki tugas, bug, atau cerita pengguna, hanya tugas tingkat anak atau cerita tingkat anak di bagian bawah hierarki yang muncul. Untuk informasi selengkapnya, lihat Memecahkan masalah penyortiganan ulang dan berlapis.
• 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

Saat tim Anda melacak bug sebagai persyaratan, Anda dapat menggunakan papan 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 seperti yang ditunjukkan pada gambar berikut. Untuk informasi selengkapnya, lihat Memperbarui status item kerja.

  

• 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 Anda
• Mengkustomisasi Taskboard sprint
• Perubahan kueri pada papan

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 ketika anggota tim menyelesaikannya. 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. Contoh berikut 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, penerapan Git, dan permintaan pull. Saat 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 Membuat item kerja saat gagal.

Memantau status bug, penugasan, dan tren

Anda dapat melacak status bug, penugasan, dan tren menggunakan kueri yang 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 informasi selengkapnya tentang kueri, bagan, dan dasbor, lihat kueri, bagan, dan dasbor terkelola.

Menggunakan tampilan Analytics dan layanan Analytics untuk membuat laporan bug

Layanan Analitik adalah platform pelaporan untuk Azure DevOps. Ini 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 informasi selengkapnya tentang menggunakan tampilan Analitik, lihat Tentang 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 kueri. Untuk informasi selengkapnya, lihat Menyambungkan dengan Konektor Data Power BI.

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

• Menghapus, menghapus, atau memulihkan item kerja
• Menyalin atau mengkloning item kerja

Backlog produk dan papan

• Menggunakan backlog untuk mengelola proyek
• Membuat backlog Anda
• Menentukan fitur dan epik
• Mengatur backlog dan memetakan item kerja anak Anda kepada orang tua
• Memfilter backlog, papan, kueri, dan paket secara interaktif
• Prakiraan backlog produk Anda

Tercetak

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

Sprint backlog dan Taskboard

• Pelajari tentang praktik terbaik Scrum
• Menetapkan item backlog ke sprint
• Menambahkan tugas
• Memperbarui Taskboard Anda

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