Tinjau hasil pengiriman Taiga berdasarkan bukti

Mulai dari hasil inisiatif

Layanan peralatan fiktif kini memungkinkan karyawan melihat permintaannya sendiri. Mulai peninjauan dari hasil dan cakupan inisiatif. Identifikasi hal yang harus benar dan hal yang harus dipertahankan perubahan.

Untuk pengiriman ini, karyawan tidak boleh membaca permintaan karyawan lain. Manajer harus tetap memiliki akses yang telah ditentukan. Pengujian yang hanya membuka halaman tidak membuktikan kedua syarat tersebut.

Hubungkan catatan

Halaman Runs mencatat percobaan, termasuk kegagalan. Setiap eksekusi mengidentifikasi rencana yang dijalankannya. Halaman eksekusi merupakan catatan pemeriksaan; keputusan yang mengubah pekerjaan dilakukan pada inisiatif.

Baca bukti langkah untuk pengujian dan pemformatan. Taiga menampilkan pemeriksaan yang gagal atau belum dijalankan. Jangan mengubah “tidak dijalankan” menjadi “lulus” dalam ringkasan peninjauan.

Periksa asumsi dan batas

Cari asumsi tentang model akses, skema, lingkungan, dan layanan eksternal. Bandingkan dengan maksud yang dipublikasikan dan kode yang sebenarnya.

Untuk layanan peralatan, periksa lokasi pemeriksaan pemilik permintaan. Uji permintaan yang diizinkan, permintaan karyawan lain, dan permintaan yang tidak ada. Periksa bahwa log tidak mengungkap isi permintaan yang rahasia.

Tinjau juga perubahan pengujian. Hasil yang lulus memiliki nilai terbatas jika perubahan menghapus assertion yang akan mendeteksi cacat. Perlakukan perubahan alur kerja dan konfigurasi pengujian sebagai bagian cakupan peninjauan.

Berikan umpan balik yang dapat ditindaklanjuti

Identifikasi perilaku, hasil yang diharapkan, dan bukti yang diperlukan. Misalnya: “Endpoint memeriksa login, tetapi tidak memeriksa kepemilikan permintaan. Tambahkan pemeriksaan akses di server dan pengujian menggunakan permintaan karyawan lain.”

Taiga dapat merespons umpan balik peninjauan pull request dan pemeriksaan yang gagal dengan perubahan pada branch yang sama. Setelah pembaruan, periksa commit baru dan pemeriksaannya. Bukti sebelumnya mungkin tidak mencakup artefak yang berubah.

Jika eksekusi berhenti karena rencana belum lengkap atau pemeriksaan dilemahkan, baca alasan yang dinyatakan. Jangan hapus status draf hanya karena ringkasan pemeriksaan yang terlihat berwarna hijau.

Buat keputusan penerimaan yang tepat

Catat kriteria yang terverifikasi dan yang belum terselesaikan. Biarkan peninjauan dan pemeriksaan wajib repositori menegakkan batas merge. Pertahankan keputusan rilis yang terpisah jika ada.

Taiga mengamati deployment yang dilakukan pipeline Anda. Verifikasi lingkungan dan artefak sebelum memberi tahu pengguna bahwa perubahan tersedia. Deployment yang gagal dapat membuat versi sebelumnya yang berhasil tetap melayani traffic.

Pastikan hasil dengan pemeriksaan tingkat layanan: karyawan dapat menggunakan fitur, akses tanpa izin ditolak, dan penanggung jawab operasi dapat mengamati kegagalan. Lanjutkan ke penanganan penghentian.