Data uji realistis untuk aplikasi bisnis sebelum digunakan staf

Mengapa demo yang terlihat rapi gagal saat mulai digunakan staf

Demo yang terlihat rapi biasanya memakai layar kosong atau beberapa data yang sempurna. Setiap pelanggan memiliki nama lengkap, setiap pesanan memiliki status yang jelas, dan semua orang mengikuti alur yang sudah direncanakan. Ini membuktikan bahwa aplikasi dapat menampilkan sebuah alur kerja. Namun, ini belum membuktikan bahwa staf dapat menggunakannya pada hari Selasa yang sibuk.

Pekerjaan nyata lebih berantakan. Seorang asisten penjualan mungkin menyimpan kontak tanpa nomor telepon, lalu kembali nanti untuk memperbaiki alamat email. Manajer operasional mungkin mencari "Acme" dan menemukan enam data yang mirip. Seseorang mungkin perlu membuka kembali permintaan yang sudah ditutup karena pelanggan berubah pikiran. Data uji yang realistis membantu menemukan situasi seperti ini sebelum menimbulkan kebingungan di lingkungan produksi.

Layar kosong juga menyembunyikan pertanyaan praktis. Apakah staf tahu apa yang harus diisi terlebih dahulu? Dapatkah mereka membedakan draf dari permintaan yang sudah dikirim? Apakah aplikasi menjelaskan bagian yang kurang ketika kolom wajib dibiarkan kosong? Presenter bisa melewati celah ini karena mereka sudah mengetahui setiap langkah.

Data bersama mengubah alur kerja

Banyak masalah hanya muncul ketika beberapa orang menggunakan aplikasi yang sama. Satu staf memperbarui data pelanggan sementara staf lain melihat versi lama. Supervisor berharap dapat melihat semua permintaan, sedangkan karyawan hanya boleh melihat permintaannya sendiri. Seseorang mengubah status data, tetapi tidak meninggalkan catatan untuk orang berikutnya.

Uji pekerjaan bersama dengan aktivitas yang masuk akal. Buat data dengan nama yang mirip, detail yang belum lengkap, tanggal lama, duplikasi, dan informasi yang perlu diperbaiki. Lalu minta dua atau tiga penguji mengerjakan data yang sama secara bersamaan. Perhatikan perubahan yang tertimpa, kepemilikan yang tidak jelas, label status yang membingungkan, dan hasil pencarian yang sulit diurutkan.

Koder.ai memungkinkan tim membuat aplikasi web, server, dan seluler melalui chat, tetapi pengembangan yang cepat tidak menghilangkan kebutuhan untuk menguji perilaku manusia sehari-hari. Uji versi pertama berdasarkan kebiasaan kerja nyata sebelum seluruh tim bergantung padanya.

Pisahkan data uji dari informasi nyata

Gunakan nama, alamat email, nomor telepon, dan detail perusahaan fiktif selama pengujian. Beri label yang jelas pada data, misalnya "TEST - Northside Supplies", agar tidak ada yang mengira data tersebut adalah pelanggan sungguhan. Jangan menyalin daftar pelanggan, data karyawan, informasi keuangan, atau catatan pribadi ke lingkungan pengujian.

Sekumpulan data uji yang kecil dan beragam lebih berguna daripada banyak data duplikat. Sertakan contoh normal, data yang baru sebagian diisi, duplikasi, dan beberapa kesalahan yang terlihat jelas. Dengan begitu, staf dapat mencoba berbagai hal, membuat kesalahan, dan melaporkan bagian yang membingungkan tanpa membahayakan informasi nyata.

Mulailah dari pekerjaan yang benar-benar dilakukan staf

Aplikasi bisnis harus menghadapi pekerjaan yang ditangani orang pada hari Selasa biasa. Tuliskan tugas nyata dengan istilah yang digunakan staf. Asisten penjualan memasukkan pesanan. Manajer menyetujui pengembalian dana. Pemilik akun memperbarui nomor telepon klien. Ini adalah titik awal yang lebih baik daripada label umum seperti "uji layar pesanan".

Ubah setiap tugas menjadi skenario singkat dengan titik awal, tindakan, dan hasil yang diharapkan. Gunakan bahasa sederhana agar rekan kerja dapat membacanya tanpa bantuan teknis.

Contoh: "Seorang pelanggan menelepon untuk mengubah alamat pengiriman pada pesanan yang belum dikirim. Asisten penjualan mencari pesanan tersebut, mengedit alamat, menyimpannya, lalu melihat alamat baru pada konfirmasi pesanan." Contoh ini memberi tahu Anda data apa yang perlu disiapkan dan apa yang harus ditampilkan aplikasi setelah perubahan.

Tugas rutin perlu mendapat perhatian terbesar karena staf mengulanginya sepanjang hari. Catat variasi kecil yang dapat mengubah hasil: klien baru atau klien lama, satu barang atau lima barang, faktur yang lunas atau baru dibayar sebagian. Demo yang rapi sering memakai satu data sempurna. Pekerjaan nyata jarang seperti itu.

Uji juga tugas yang lebih jarang dilakukan. Staf mungkin lupa langkah-langkahnya, dan pembuat aplikasi mungkin belum pernah mencobanya. Sertakan pekerjaan seperti:

• Menutup satu bulan dan memeriksa faktur yang jatuh tempo
• Memperbaiki pesanan yang dimasukkan atas nama klien yang salah
• Memproses pengembalian dana setelah mendapat persetujuan manajer
• Mengalihkan pekerjaan terbuka milik karyawan yang sudah keluar
• Mengekspor laporan untuk bagian keuangan atau auditor

Jika Anda membuat aplikasi di Koder.ai, tulis skenario ini sebagai permintaan chat langsung selama pengembangan. Ulangi skenario dengan data yang sudah disiapkan sebelum mengundang staf, dan simpan hasil yang diharapkan di samping setiap skenario.

Skenario yang berguna memiliki batas akhir yang jelas. "Perbarui detail klien" terlalu umum. "Ubah email penagihan klien, simpan data, lalu pastikan faktur berikutnya menggunakan email tersebut" memberi penguji sesuatu yang spesifik untuk diverifikasi.

Buat data yang menyerupai data bisnis sehari-hari

Aplikasi yang kosong bisa terlihat bersih dalam demo, tetapi tetap gagal pada hari Selasa biasa. Staf perlu menemukan pelanggan dengan nama umum, memeriksa faktur yang terlambat, melihat catatan pemasok, dan memahami data yang sudah berpindah tangan dua kali.

Buat data sampel yang menyerupai informasi yang ditangani bisnis Anda. Gunakan nama dan detail kontak fiktif, bukan data pelanggan atau karyawan yang disalin. Sertakan campuran yang masuk akal: pelanggan baru, pelanggan lama, pemasok dengan detail yang belum lengkap, karyawan yang pindah departemen, dan data dengan beberapa catatan.

Tanggal, jumlah, dan status perlu bervariasi. Jika semua faktur memiliki total yang sama dan setiap permintaan berstatus "Terbuka", staf tidak dapat mengetahui apakah pengurutan, penyaringan, dan laporan sudah bekerja dengan benar. Buat data dari beberapa bulan dengan jumlah dan status berbeda, seperti draf, terkirim, lunas, terlambat, dibatalkan, atau diarsipkan, sesuai kebutuhan aplikasi.

Sekumpulan kecil pola realistis sering mengungkap lebih banyak hal daripada ratusan entri yang sama:

• Satu pelanggan memiliki dua pesanan pada hari yang sama.
• Satu pemasok memiliki nomor telepon lama dan catatan terbaru yang menjelaskan perubahan tersebut.
• Mantan karyawan muncul dalam data historis, tetapi tidak dapat menerima pekerjaan baru.
• Beberapa pelanggan memiliki nama belakang atau nama perusahaan yang sama.
• Satu jumlah besar muncul di antara banyak transaksi rutin bernilai kecil.

Tambahkan data lama dengan sengaja. Hasil pencarian yang hanya berisi lima entri baru tidak banyak memberi tahu apakah staf dapat menemukan permintaan tahun lalu atau apakah laporan bulanan mengelompokkan informasi dengan benar. Data lama juga memperlihatkan format tanggal yang tidak nyaman, status arsip, dan data tanpa pemilik aktif.

Buat catatan yang sederhana tetapi masuk akal. "Pelanggan meminta pengiriman dibagi menjadi dua kunjungan" lebih berguna daripada "Catatan uji 14". Jangan menambahkan alamat, nomor rekening, nomor telepon, atau komentar pribadi yang nyata ke aplikasi uji, meskipun pengujian dilakukan secara internal.

Modelkan pengguna dan izin sebelum mengundang tim

Aplikasi dapat menimbulkan masalah ketika semua orang melihat layar dan tombol yang sama. Pengujian realistis mencakup orang yang realistis: staf yang memasukkan data, manajer yang menyetujuinya, dan orang yang hanya memeriksa perkembangan.

Tentukan peran berdasarkan tugas harian, bukan hanya jabatan. Dua orang yang sama-sama disebut "manajer" mungkin memerlukan akses yang berbeda. Manajer penjualan mungkin boleh menyetujui diskon, tetapi tidak boleh melihat detail penggajian. Staf akuntansi mungkin boleh membuat faktur, tetapi tidak boleh mengubah batas kredit pelanggan.

Tuliskan apa yang dapat dilakukan setiap peran, lalu uji setiap tindakan dengan akun untuk peran tersebut. Periksa apakah pengguna dapat melihat, membuat, dan mengedit data yang mereka perlukan, sementara kolom dan tindakan yang dibatasi tetap tidak tersedia. Uji juga laporan, file, pengaturan, ekspor, dan notifikasi, karena data pribadi sering muncul di sana, bukan di halaman data utama.

Jangan hanya menguji alur yang direncanakan. Masuk sebagai staf dengan akses terbatas, buka data melalui pencarian, lalu coba mengaksesnya melalui alamat browser yang disimpan. Aplikasi harus memblokir tindakan tersebut. Menyembunyikan item menu tidak melindungi halaman yang masih dapat diakses oleh orang yang salah.

Sertakan akun administrator dan uji dengan cermat. Administrator sering dapat mengubah izin, melihat semua data, dan menghapus informasi. Pastikan akun ini dapat memulihkan akses ketika pengaturan akun staf salah.

Tambahkan juga akun sementara, misalnya kontraktor yang membantu selama dua minggu. Berikan hanya data dan tindakan yang diperlukan untuk pekerjaannya. Setelah masa kerja berakhir, orang tersebut harus kehilangan akses tanpa menghapus pekerjaan yang sudah dimasukkannya.

Dalam mode perencanaan Koder.ai, jelaskan peran sebelum mengundang staf. Buat akun uji terpisah dan ulangi tugas singkat yang sama dengan setiap akun. Masalah izin lebih mudah diperbaiki ketika aplikasi masih sering berubah.

Uji kasus yang tidak nyaman di sekitar alur kerja normal

Sebagian besar masalah aplikasi muncul di tengah pekerjaan biasa, bukan saat demo yang rapi. Sertakan data pada setiap tahap alur kerja, dengan tanggal, nama, catatan, dan jumlah yang menyerupai pekerjaan sehari-hari.

Untuk aplikasi pesanan, buat pesanan baru yang belum disentuh siapa pun, pesanan yang sedang disiapkan staf, pesanan yang sudah disetujui manajer, dan pesanan yang ditutup tim bulan lalu. Periksa kolom mana yang dapat diubah staf pada setiap tahap. Pesanan yang sudah ditutup tidak boleh diam-diam kembali menjadi "sedang diproses" hanya karena seseorang mengedit alamat pengirimannya.

Uji pengecualian yang terjadi dalam pekerjaan nyata:

• Batalkan pesanan setelah staf mulai mengerjakannya.
• Tandai pembayaran sebagai dikembalikan setelah aplikasi mencatatnya sebagai selesai.
• Buka permintaan setelah tanggal kedaluwarsanya.
• Kirim data tanpa lampiran yang diwajibkan alur kerja.
• Coba setujui data yang masih memiliki detail yang belum lengkap.

Dua orang yang mengubah item yang sama memerlukan pengujian tersendiri. Minta satu staf memperbarui nomor telepon pelanggan sementara staf lain mengubah status pesanan. Aplikasi harus menjelaskan hasilnya. Aplikasi bisa menyimpan kedua perubahan, memperingatkan orang kedua bahwa data telah berubah, atau meminta pengguna memuat ulang halaman. Aplikasi tidak boleh menyembunyikan pekerjaan seseorang tanpa pemberitahuan.

Riwayat status penting ketika muncul pertanyaan di kemudian hari. Uji urutan sederhana: Sam membuat permintaan pukul 9.10, Priya menyetujuinya pukul 9.25, dan Sam membatalkannya pukul 10.00 setelah pelanggan menelepon. Staf yang memiliki akses ke permintaan tersebut harus dapat melihat siapa yang melakukan setiap perubahan, kapan perubahan dilakukan, dan alasan yang dikumpulkan aplikasi. Mereka juga harus dapat melihat status saat ini tanpa membaca rangkaian catatan yang panjang.

Untuk aplikasi Koder.ai, jelaskan situasi ini dengan bahasa sederhana sebelum membangun versi uji. Lalu jalankan sebagai tugas, bukan sekadar memeriksa apakah layar terlihat selesai.

Masukkan input yang salah dengan sengaja

Staf melakukan kesalahan biasa: lupa mengisi kolom, menempelkan nomor telepon dengan spasi tambahan, atau memasukkan jumlah dengan tanda yang salah. Sertakan kesalahan tersebut sebelum data nyata masuk ke aplikasi. Formulir yang hanya bekerja dengan data demo yang rapi akan gagal pada hari kerja yang sibuk.

Gunakan formulir yang sama beberapa kali dan ubah satu detail setiap kali. Dengan begitu, Anda lebih mudah melihat pemeriksaan mana yang gagal dan apakah pesannya membantu pengguna memperbaikinya.

• Biarkan kolom wajib kosong, termasuk kolom bersyarat.
• Tempel catatan pelanggan yang panjang dan teks dengan simbol, aksen, baris baru, atau emoji.
• Masukkan tanggal lampau untuk janji temu mendatang, jumlah faktur negatif, atau terlalu banyak angka desimal.
• Kirim alamat email yang sudah digunakan data lain.
• Tempel angka dengan spasi, koma, atau simbol mata uang.

Aplikasi harus menjelaskan hal yang perlu diperbaiki dengan bahasa sederhana. "Masukkan nomor telepon dengan sedikitnya 10 digit" memberi staf langkah berikutnya. "Kesalahan validasi" tidak membantu. Jika memungkinkan, letakkan pesan di dekat kolom dan tetap tampilkan setelah pengguna mencoba mengirim formulir.

Periksa juga apa yang terjadi pada bagian formulir lainnya. Jika Maria menghabiskan lima menit untuk memasukkan klien baru lalu salah mengetik kode pos, aplikasi harus mempertahankan catatan, detail kontak, dan pilihan yang sudah benar. Maria cukup memperbaiki satu kolom dan mengirim ulang, bukan memulai dari awal.

Pengiriman yang diblokir harus memiliki jalan keluar yang jelas: perbaiki kolom yang ditandai, batalkan dengan aman, atau simpan sebagai draf jika pekerjaan belum lengkap. Hindari pop-up kesalahan yang menghilang sebelum sempat dibaca staf atau tombol yang tidak merespons setelah percobaan gagal.

Saat membuat aplikasi dengan Koder.ai, sertakan kasus ini dalam permintaan untuk setiap formulir. Minta aturan kolom yang jelas, pemeriksaan duplikasi, pesan kesalahan yang mudah dipahami, dan data yang sudah diisi tetap tersimpan setelah pengiriman gagal. Lalu uji aplikasi dengan nilai salah yang sudah Anda daftarkan.

Jalankan satu skenario staf yang realistis

Bayangkan sebuah perusahaan pemanas dan perpipaan dengan 12 staf. Perusahaan ini mengelola klien, pekerjaan layanan, faktur, dan pembayaran dalam satu aplikasi.

Maya, manajer kantor, menerima telepon dari Jordan Lee tentang radiator yang bocor. Ia mencari Jordan dan menemukan dua data klien: "Jordan Lee" dan "J. Lee" di alamat yang sama. Maya memilih salah satu data, membuat pekerjaan untuk Rabu pagi, menambahkan masalah yang dilaporkan, lalu menugaskan teknisi Sam.

Pekerjaan dimulai dengan status "Dijadwalkan". Sam membuka aplikasi di ponselnya saat berada di lokasi. Ia menambahkan foto, mengubah status menjadi "Pekerjaan selesai", lalu memasukkan biaya suku cadang dan tenaga kerja. Label tersebut terdengar final, tetapi Maya masih perlu memeriksa biaya sebelum aplikasi membuat faktur. Staf mungkin membaca "Pekerjaan selesai" sebagai "siap ditagih", sementara Sam mungkin hanya bermaksud bahwa ia sudah meninggalkan lokasi.

Gunakan status yang lebih jelas seperti "Menunggu pemeriksaan kantor". Dengan begitu, Maya memiliki langkah berikutnya yang jelas dan aplikasi tidak mengirim faktur sebelum seseorang memeriksa harganya.

Maya melihat bahwa Jordan memiliki faktur lama yang terlambat 45 hari. Ia memutuskan bahwa pekerjaan baru tersebut memerlukan persetujuan supervisor sebelum ditagihkan. Supervisor-nya, Priya, memeriksa catatan Sam dan menyetujui diskon karena perbaikan sebelumnya gagal.

Skenario ini memeriksa apakah aplikasi menangani keputusan nyata:

• Maya harus melihat kemungkinan klien duplikat dan dapat menggabungkannya atau menandainya untuk ditinjau.
• Sam harus dapat memperbarui pekerjaan yang ditugaskan kepadanya, tetapi tidak boleh mengedit jumlah faktur atau menyetujui diskon.
• Priya harus dapat menyetujui pekerjaan tanpa mengakses penggajian atau pengaturan perusahaan yang tidak terkait.
• Faktur yang terlambat harus muncul sebelum Maya mengirim tagihan baru, tetapi tidak boleh menghalangi pekerjaan perbaikan yang mendesak.
• Setiap status harus memberi tahu staf siapa yang bertindak berikutnya dan tindakan apa yang masih tersedia.

Jalankan skenario dengan data yang terasa nyata: alamat jalan, catatan pekerjaan yang beragam, satu suku cadang seharga $18.75, dan faktur dengan tanggal pembayaran yang berbeda. Minta penguji bekerja secara terpisah, lalu bandingkan arti setiap status menurut mereka.

Jika Sam dapat menyetujui diskon dari ponselnya, perbaiki aturan izin. Jika Maya tidak dapat mengetahui apakah "Pekerjaan selesai" berarti sudah ditagihkan atau hanya selesai di lokasi, ganti nama status tersebut sebelum staf bergantung padanya.

Jalankan sesi pengujian sederhana dan catat hasilnya

Sesi pengujian yang singkat dan terarah sering menemukan masalah yang luput dari demo yang rapi. Beri setiap penguji satu tugas normal, seperti menambahkan pelanggan, menyetujui pengeluaran, atau mencari faktur yang terlambat. Minta mereka bekerja sendiri dan jangan membimbing setiap klik.

Jika mereka berhenti, memilih menu yang salah, atau bertanya arti sebuah label, catat. Momen tersebut menunjukkan bagian yang memerlukan kata-kata lebih jelas atau alur yang lebih sederhana.

Buat log masalah sederhana. Tabel bersama sudah cukup untuk tim kecil. Catat halaman tempat masalah muncul, tindakan dan data sampel yang digunakan, hasil yang diharapkan, hal yang benar-benar terjadi, serta peran pengguna. Orang yang memperbaiki masalah harus dapat mengulanginya tanpa menebak-nebak.

Urutkan masalah sebelum sesi berakhir. Dahulukan penghambat, lalu kegagalan izin yang membuka data pribadi atau memungkinkan seseorang mengubah data yang seharusnya hanya dapat dilihat. Label yang membingungkan dan klik tambahan tetap penting, tetapi biasanya tidak memerlukan respons yang sama mendesaknya.

Setelah perbaikan dilakukan, ulangi pengujian yang sama dengan peran, data sampel, dan langkah yang sama. Periksa juga halaman terkait seperti hasil pencarian dan ekspor. Perbaikan pada satu halaman pelanggan mungkin tidak memperbaiki masalah yang sama di tempat lain.

Koder.ai mendukung snapshot dan rollback, yang dapat membantu tim mempertahankan versi yang sudah diketahui berjalan baik sebelum melakukan perubahan besar. Simpan log masalah bersama proyek agar tetap berguna saat peran dan alur kerja baru ditambahkan.

Gunakan pemeriksaan ini sebelum peluncuran pertama untuk staf

Tinjau salinan aplikasi menggunakan data sampel yang realistis. Layar yang terlihat rapi tetap dapat gagal ketika resepsionis, manajer, dan pengguna keuangan bekerja di dalamnya pada pagi yang sama dan sibuk.

Minta setiap orang masuk dengan perannya dan menyelesaikan tugas biasa dari awal sampai akhir. Karyawan penjualan mungkin menambahkan pelanggan, memperbarui kesepakatan, mencari percakapan lama, dan membuat tindak lanjut. Manajer mungkin meninjau kesepakatan yang sama dan menyetujui diskon tanpa mengedit pengaturan akun.

Pastikan setiap peran dapat menyelesaikan pekerjaan hariannya, tindakan yang dibatasi tetap tidak tersedia, dan kolom sensitif tersembunyi dari orang yang salah. Uji pencarian, filter, ekspor, laporan, dan layar seluler dengan jumlah data yang cukup agar aplikasi terasa sedikit berantakan.

Pengujian izin membutuhkan lebih dari sekadar tombol menu yang hilang. Jika karyawan biasa tidak boleh menghapus faktur, masuk sebagai karyawan tersebut dan coba hapus faktur dari setiap layar yang menampilkan faktur. Aplikasi harus memblokir tindakan tersebut dan menjelaskan alasannya.

Tambahkan nama pelanggan duplikat, data lama yang sudah ditutup, kolom opsional yang kosong, tanggal dari beberapa bulan, dan catatan panjang. Cari "Smith", filter berdasarkan status, urutkan laporan, lalu buka hasil yang sama di ponsel. Sekumpulan data kecil sering menyembunyikan halaman yang lambat, label yang membingungkan, dan filter yang gagal ketika data bertambah banyak.

Buat akun uji terpisah untuk setiap tingkat izin, bukan memakai satu login bersama. Ini membuat masalah akses lebih mudah diulang dan diperbaiki.

Sebelum mengimpor data bisnis nyata, hapus setiap akun uji dan data sampel. Pastikan alamat email uji, nomor telepon, lampiran, dan ekspor juga sudah dihapus. Lalu buat snapshot bersih agar tim memiliki titik awal yang jelas untuk peluncuran.

Siapkan putaran pengujian berikutnya

Anggap pengujian sebagai siklus yang dapat diulang, bukan tugas sekali jalan sebelum peluncuran. Pilih satu alur kerja yang sering digunakan staf, seperti membuat data pelanggan, menetapkan pemilik, dan memperbarui statusnya. Uji jalur tersebut setiap kali ada perubahan penting, bukan memenuhi setiap layar dengan data sampel acak.

Simpan paket data fiktif yang dapat digunakan kembali. Beri setiap data tujuan yang jelas: pelanggan normal, pelanggan dengan dua kontak, faktur yang terlambat, nama yang tampak duplikat, atau data dengan detail opsional yang belum diisi. Menggunakan data yang sama membuat perubahan perilaku yang diharapkan lebih mudah terlihat.

Simpan paket tersebut di satu tempat bersama dan catat hasil yang diharapkan untuk setiap pengujian. Manajer akun boleh mengedit nomor telepon pelanggan, tetapi tidak boleh melihat kolom penggajian. Pengguna keuangan boleh melihat faktur, tetapi tidak boleh menghapus data pelanggan. Ekspektasi yang singkat mencegah perdebatan tentang apakah suatu hasil merupakan bug.

Gunakan mode perencanaan Koder.ai sebelum membuat versi berikutnya. Jelaskan peran staf, tugas yang tepat, kolom yang dapat diedit, dan aturan validasi. Contoh: "Agen dukungan dapat membuat tiket, memilih pelanggan, menambahkan catatan, dan menetapkan prioritas. Agen tidak dapat menutup tiket yang ditugaskan ke tim lain. Wajibkan subjek dan tolak tanggal lampau untuk panggilan tindak lanjut."

Bangun perubahan setelah rencana mencerminkan pekerjaan nyata. Lalu ulangi alur kerja dengan data fiktif, termasuk input yang salah. Sebelum perubahan besar, buat snapshot dan minta kelompok kecil menguji versi baru. Jika perubahan menimbulkan masalah, lakukan rollback sambil memperbaikinya.

Log pengujian sederhana harus mencakup tanggal dan versi, alur kerja dan data yang digunakan, hasil yang diharapkan dan hasil aktual, penguji, serta keputusan untuk memperbaiki sekarang, meninjau nanti, atau mempertahankannya. Saat menambahkan izin, kolom, atau alur kerja, jalankan kembali kasus yang relevan sebelum staf bergantung padanya.