Personel kullanmadan önce iş uygulamaları için gerçekçi test verileri

Personel uygulamayı kullanmaya başladığında kusursuz demolar neden başarısız olur?

Kusursuz görünen bir demoda genellikle boş ekranlar veya birkaç mükemmel kayıt kullanılır. Her müşterinin adı eksiksizdir, her siparişin durumu nettir ve herkes amaçlanan yolu izler. Bu, uygulamanın bir iş akışını gösterebildiğini kanıtlar. Personelin uygulamayı yoğun bir salı gününde kullanabileceğini kanıtlamaz.

Gerçek iş hayatı daha karmaşıktır. Bir satış görevlisi telefon numarası olmadan bir kişiyi kaydedebilir, sonra düzeltilmiş e-posta adresiyle geri dönebilir. Bir operasyon yöneticisi "Acme" diye arama yaptığında birbirine benzeyen altı kayıt bulabilir. Bir müşteri fikrini değiştirdiği için biri kapatılmış bir talebi yeniden açmak zorunda kalabilir. Gerçekçi test verileri, bu durumları üretimde karmaşaya yol açmadan önce ortaya çıkarır.

Boş ekranlar pratik soruları da gizler. Personel ilk olarak ne girmesi gerektiğini biliyor mu? Taslakla gönderilmiş talep arasındaki farkı anlayabiliyor mu? Zorunlu bir alan boş bırakıldığında uygulama eksik olanı açıklıyor mu? Sunumu yapan kişi her adımı zaten bildiği için bu boşlukları fark etmeden geçebilir.

Paylaşılan kayıtlar iş akışını değiştirir

Birçok sorun ancak aynı uygulamayı birkaç kişi kullandığında ortaya çıkar. Bir personel müşteri kaydını güncellerken başka biri eski sürümü görüntüleyebilir. Bir yönetici tüm talepleri görmek isterken bir çalışan yalnızca kendi taleplerini görmelidir. Biri bir kaydın durumunu değiştirir ama sonraki kişi için not bırakmaz.

Paylaşılan çalışmayı inandırıcı hareketlerle test edin. Benzer adlara, eksik bilgilere, eski tarihlere, yinelenen kayıtlara ve düzeltilmesi gereken bilgilere sahip kayıtlar oluşturun. Ardından iki veya üç test uzmanından aynı kayıtlar üzerinde aynı anda çalışmasını isteyin. Üzerine yazılan değişikliklere, belirsiz sorumluluklara, kafa karıştıran durum etiketlerine ve sıralanması zor arama sonuçlarına dikkat edin.

Koder.ai, ekiplerin sohbet yoluyla web, sunucu ve mobil uygulamalar oluşturmasına olanak tanır. Ancak hızlı geliştirme, insanların günlük davranışlarını test etme ihtiyacını ortadan kaldırmaz. Tüm ekip uygulamaya güvenmeden önce ilk sürümü gerçek çalışma alışkanlıklarına göre test edin.

Test verilerini gerçek bilgilerden ayrı tutun

Test sırasında uydurma adlar, e-posta adresleri, telefon numaraları ve şirket bilgileri kullanın. Kayıtları "TEST - Northside Supplies" gibi açıkça etiketleyin ki kimse bunları gerçek bir müşteriyle karıştırmasın. Müşteri listelerini, çalışan kayıtlarını, finansal bilgileri veya özel notları test ortamına kopyalamayın.

Küçük ve çeşitli bir test seti, kopyalanmış büyük bir kayıt grubundan daha değerlidir. Normal örneklere, kısmen tamamlanmış kayıtlara, yinelenen kayıtlara ve birkaç bariz hataya yer verin. Böylece personel bir şeyler deneyebilir, hata yapabilir ve gerçek bilgileri riske atmadan neyin anlaşılmadığını bildirebilir.

Personelin gerçekten yaptığı işlemlerle başlayın

Bir iş uygulaması, insanların sıradan bir salı gününde yaptığı işlerle karşılaşmalıdır. Gerçek görevleri personelin kullandığı kelimelerle yazın. Bir satış görevlisi sipariş girer. Bir yönetici para iadesini onaylar. Bir hesap sorumlusu müşterinin telefon numarasını günceller. Bunlar, "sipariş ekranını test et" gibi genel ifadelerden daha iyi başlangıç noktalarıdır.

Her görevi net bir başlangıç noktası, işlem ve beklenen sonuç içeren kısa bir senaryoya dönüştürün. Teknik yardım almadan bir çalışma arkadaşının okuyabileceği kadar sade tutun.

Örneğin: "Bir müşteri, henüz gönderilmemiş bir siparişin teslimat adresini değiştirmek için arar. Satış görevlisi siparişi bulur, adresi düzenler, kaydeder ve sipariş onayında yeni adresi görür." Bu senaryo, hangi kayıtları hazırlamanız gerektiğini ve değişiklikten sonra uygulamanın ne göstermesi gerektiğini anlatır.

Personel bu görevleri gün boyunca tekrarladığı için en çok ilgiyi rutin işlemler hak eder. Sonucu değiştiren küçük farklılıkları da kaydedin: yeni veya mevcut müşteri, bir veya beş ürün, tamamen ya da kısmen ödenmiş fatura. Kusursuz bir demoda genellikle tek bir mükemmel kayıt kullanılır. Gerçek iş hayatında durum nadiren böyledir.

Daha az sık yapılan görevleri de test edin. Personel adımları unutabilir ve uygulamayı ilk geliştiren kişi bu işlemleri hiç denememiş olabilir. Şu görevleri de ekleyin:

• Bir ayı kapatıp vadesi geçmiş faturaları kontrol etmek
• Yanlış müşteri adına girilmiş bir siparişi düzeltmek
• Yönetici onayından sonra para iadesi yapmak
• İşten ayrılmış bir çalışanın açık işlerini yeniden atamak
• Finans ekibi veya denetçi için rapor dışa aktarmak

Uygulamayı Koder.ai ile geliştirdiyseniz bu senaryoları geliştirme sırasında doğrudan sohbet istekleri olarak yazın. Personeli davet etmeden önce hazırladığınız kayıtlarla bunları tekrarlayın ve her senaryonun yanında beklenen sonuçları bulundurun.

İyi bir senaryonun net bir bitiş noktası vardır. "Müşteri bilgilerini güncelle" fazla belirsizdir. "Müşterinin fatura e-postasını değiştir, kaydı kaydet ve sonraki faturada bu e-postanın kullanıldığını doğrula" test uzmanına kontrol edebileceği belirli bir sonuç verir.

Günlük iş verilerine benzeyen kayıtlar oluşturun

Boş bir uygulama demoda temiz görünebilir, ancak sıradan bir salı gününde başarısız olabilir. Personelin yaygın bir ada sahip müşteriyi bulması, vadesi geçmiş bir faturayı kontrol etmesi, tedarikçi notunu görmesi ve iki kez el değiştirmiş bir kaydı anlaması gerekir.

Örnek kayıtları işletmenizin yönettiği bilgilere benzetin. Kurgusal adlar ve iletişim bilgileri kullanın, müşteri veya çalışan verilerini asla kopyalamayın. Mantıklı bir çeşitlilik oluşturun: yeni müşteri, uzun süredir müşteriniz olan biri, bilgileri eksik bir tedarikçi, departman değiştirmiş bir çalışan ve birkaç not içeren bir kayıt.

Tarihlerin, tutarların ve durumların çeşitlenmesi gerekir. Her faturanın toplamı aynı, her talebin durumu da "Açık" olursa personel sıralama, filtreleme ve raporların mantıklı çalışıp çalışmadığını anlayamaz. Birkaç aya yayılan, farklı tutarlara ve uygulamanıza uygun taslak, gönderildi, ödendi, gecikmiş, iptal edildi veya arşivlendi gibi durumlara sahip kayıtlar oluşturun.

Birbirinin kopyası yüzlerce kayıt yerine, gerçekçi birkaç örüntü daha fazla şey ortaya çıkarabilir:

• Bir müşterinin aynı gün iki siparişi vardır.
• Bir tedarikçinin eski bir telefon numarası ve değişikliği açıklayan yakın tarihli bir notu vardır.
• Eski bir çalışan geçmiş kayıtlarda görünür, ancak yeni iş alamaz.
• Birkaç müşteri aynı soyadını veya şirket adını paylaşır.
• Çok sayıda küçük rutin işlemin yanında tek bir yüksek tutar bulunur.

Eski kayıtları özellikle ekleyin. Yalnızca beş yeni kaydın bulunduğu bir arama sonucu, personelin geçen yılki talebi bulup bulamayacağı veya aylık raporun bilgileri doğru gruplayıp gruplayamayacağı konusunda pek fikir vermez. Eski veriler ayrıca rahatsız edici tarih biçimlerini, arşivlenmiş durumları ve aktif sorumlusu olmayan kayıtları ortaya çıkarır.

Notları sade ama inandırıcı tutun. "Müşteri, teslimatın iki ziyarete bölünmesini istedi" ifadesi "Test notu 14" ifadesinden daha faydalıdır. İç deneme bile olsa test uygulamasına gerçek adresler, hesap numaraları, telefon numaraları veya özel yorumlar eklemeyin.

Ekibi davet etmeden önce kullanıcıları ve izinleri modelleyin

Herkes aynı ekranları ve düğmeleri gördüğünde uygulama sorun çıkarır. Gerçekçi testte gerçek kişiler de bulunur: kayıtları giren personel, kayıtları onaylayan yönetici ve yalnızca ilerlemeyi kontrol eden kişi.

Rolleri yalnızca iş unvanlarına göre değil, günlük görevlere göre tanımlayın. "Yönetici" unvanına sahip iki kişinin farklı erişimlere ihtiyacı olabilir. Bir satış yöneticisi indirimleri onaylayabilir, ancak bordro ayrıntılarını görmemelidir. Bir muhasebe görevlisi fatura oluşturabilir, ancak müşteri kredi limitini değiştirememelidir.

Her rolün neler yapabileceğini yazın, ardından her rol için oluşturulmuş bir hesapla her işlemi test edin. Kullanıcıların ihtiyaç duydukları kayıtları görüntüleyebildiğini, oluşturabildiğini ve düzenleyebildiğini, kısıtlı alanların ve işlemlerin ise kullanılamadığını kontrol edin. Özel bilgiler genellikle ana kayıt sayfası yerine buralarda göründüğü için raporları, dosyaları, ayarları, dışa aktarmayı ve bildirimleri de test edin.

Yalnızca amaçlanan yolu test etmeyin. Sınırlı erişime sahip bir personel olarak giriş yapın, bir kaydı arama üzerinden açın ve kayıtlı bir tarayıcı adresiyle ona ulaşmayı deneyin. Uygulama bu işlemi engellemelidir. Menü öğesini gizlemek, yanlış kişinin erişebildiği bir sayfayı korumaz.

Bir yönetici hesabı da ekleyin ve bu hesabı dikkatle test edin. Yöneticiler çoğu zaman izinleri değiştirebilir, tüm kayıtları görebilir ve verileri silebilir. Bir personel hesabının ayarları yanlış olduğunda bu hesabın erişimi geri getirebildiğini doğrulayın.

İki haftalığına yardım eden bir yüklenici gibi geçici bir hesap da oluşturun. Bu hesaba yalnızca işin gerektirdiği kayıtları ve işlemleri verin. Geçici süre sona erdiğinde kişi, daha önce girdiği işleri silmeden erişimini kaybetmelidir.

Koder.ai planlama modunda personeli davet etmeden önce rolleri açıklayın. Ayrı test hesapları oluşturun ve aynı kısa görevleri her hesapla tekrarlayın. İzin sorunlarını uygulama hızla değişmeye devam ederken düzeltmek daha kolaydır.

Normal iş akışlarının çevresindeki zor durumları test edin

Uygulama sorunlarının çoğu temiz bir demoda değil, sıradan işlerin ortasında ortaya çıkar. İş akışının her aşamasında, günlük çalışmaya benzeyen tarihlere, adlara, notlara ve tutarlara sahip kayıtlar ekleyin.

Bir sipariş uygulaması için kimsenin dokunmadığı yeni bir sipariş, personelin hazırladığı bir sipariş, yöneticinin onayladığı bir sipariş ve ekibin geçen ay kapattığı bir sipariş oluşturun. Her aşamada personelin hangi alanları değiştirebildiğini kontrol edin. Kapalı bir sipariş, biri teslimat adresini düzenledi diye fark edilmeden "devam ediyor" durumuna dönmemelidir.

Gerçek iş hayatında yaşanan istisnaları test edin:

• Bir personel üzerinde çalışmaya başladıktan sonra siparişi iptal edin.
• Uygulama ödemeyi tamamlandı olarak kaydettikten sonra ödemeyi geri alınmış olarak işaretleyin.
• Son kullanma tarihinden sonra bir talebi açın.
• İş akışının beklediği ek dosya olmadan bir kaydı gönderin.
• Hâlâ eksik bilgileri bulunan bir öğeyi onaylamayı deneyin.

Aynı öğeyi iki kişinin değiştirmesi ayrıca test edilmelidir. Bir personelden müşterinin telefon numarasını güncellemesini, diğerinden sipariş durumunu değiştirmesini isteyin. Uygulama sonucu net biçimde göstermelidir. Her iki düzenlemeyi kaydedebilir, ikinci kişiyi kaydın değiştiği konusunda uyarabilir veya yenileme isteyebilir. Bir kişinin çalışmasını haber vermeden gizlememelidir.

Daha sonra sorular ortaya çıktığında durum geçmişi önem kazanır. Basit bir sıra test edin: Sam saat 9:10'da bir talep oluşturur, Priya 9:25'te onaylar ve müşteri aradıktan sonra Sam 10:00'da iptal eder. Talebe erişimi olan personel her değişikliği kimin yaptığını, ne zaman yaptığını ve uygulamanın topladığı nedeni görebilmelidir. Ayrıca uzun bir not zincirini okumadan mevcut durumu da görebilmelidir.

Koder.ai uygulaması için bu durumları geliştirmeden önce sade bir dille açıklayın. Ardından ekranın tamamlanmış görünüp görünmediğini kontrol etmek yerine bunları görev olarak çalıştırın.

Uygulamaya bilerek hatalı bilgiler girin

Personel sıradan hatalar yapar: bir alanı atlar, fazladan boşluk içeren bir telefon numarası yapıştırır veya tutarı yanlış işaretle girer. Gerçek kayıtlar uygulamaya ulaşmadan önce bu hataları dahil edin. Yalnızca temiz demo verileriyle çalışan bir form, yoğun bir iş gününde başarısız olur.

Aynı formu birkaç kez kullanın ve her seferinde tek bir ayrıntıyı değiştirin. Böylece hangi kontrolün başarısız olduğunu ve mesajın kişiye yardımcı olup olmadığını anlamak kolaylaşır.

• Koşula bağlı alanlar dahil olmak üzere zorunlu alanları boş bırakın.
• Uzun bir müşteri notu ile semboller, aksan işaretleri, satır sonları veya emoji içeren metinler yapıştırın.
• Gelecekteki bir randevu için geçmiş bir tarih, negatif fatura tutarı veya çok fazla ondalık basamak girin.
• Başka bir kayıtta zaten kullanılan bir e-posta adresi gönderin.
• Boşluk, virgül veya para birimi simgesi içeren bir sayı yapıştırın.

Uygulama, dikkat edilmesi gereken noktayı sade bir dille açıklamalıdır. "En az 10 hane içeren bir telefon numarası girin" personele sonraki adımı gösterir. "Doğrulama hatası" göstermez. Mümkün olduğunda mesajı alanın yanında gösterin ve kullanıcı göndermeyi denedikten sonra görünür tutun.

Formun geri kalanına ne olduğunu da kontrol edin. Maria yeni bir müşteri girmek için beş dakika harcadıktan sonra posta kodunu yanlış yazarsa uygulama geçerli notlarını, iletişim bilgilerini ve seçtiği seçenekleri korumalıdır. Baştan başlamak yerine tek bir alanı düzeltip yeniden gönderebilmelidir.

Engellenen bir gönderimde ilerlemek için belirgin bir yol bulunmalıdır: işaretlenen alanı düzeltmek, güvenle iptal etmek veya işlem tamamlanmadığında taslak olarak kaydetmek. Personel okuyamadan kaybolan hata pencerelerinden veya başarısız bir denemeden sonra yanıt vermeyi bırakan düğmelerden kaçının.

Koder.ai ile geliştirirken her form için isteğinize bu durumları dahil edin. Net alan kuralları, yinelenen kayıt kontrolleri, okunabilir hata mesajları ve başarısız gönderimlerden sonra girilen bilgilerin korunmasını isteyin. Ardından uygulamayı listelediğiniz hatalı değerleri kullanarak test edin.

Gerçekçi bir personel senaryosunu baştan sona yürütün

12 çalışanı olan bir ısıtma ve sıhhi tesisat şirketi düşünün. Şirket, müşterileri, servis işlerini, faturaları ve ödemeleri tek bir uygulamada takip ediyor.

Ofis yöneticisi Maya, radyatörü sızdıran Jordan Lee için gelen bir telefonu yanıtlar. Jordan'ı arar ve aynı adreste bulunan iki müşteri kaydı görür: "Jordan Lee" ve "J. Lee". Maya kayıtlardan birini seçer, çarşamba sabahı için bir iş oluşturur, bildirilen sorunu ekler ve teknisyen Sam'i atar.

İş "Rezerve edildi" durumuyla başlar. Sam adresteyken telefonundan uygulamayı açar. Bir fotoğraf ekler, durumu "İş tamamlandı" olarak değiştirir, parça ve işçilik bilgilerini girer. Etiket kesin bir sonuç ifade eder, ancak Maya'nın uygulama fatura oluşturmadan önce ücreti kontrol etmesi gerekir. Personel "İş tamamlandı" ifadesini "faturalandırmaya hazır" şeklinde anlayabilir. Sam ise yalnızca adresten ayrıldığını anlatmak istemiş olabilir.

Daha net bir durum kullanın: "Ofis incelemesini bekliyor". Böylece Maya'nın sonraki adımı belli olur ve biri fiyatı kontrol etmeden uygulama fatura göndermez.

Maya, Jordan'ın 45 gündür vadesi geçmiş eski bir faturası olduğunu fark eder. Yeni işin faturalandırılmadan önce yönetici onayından geçmesi gerektiğine karar verir. Yöneticisi Priya, Sam'in notlarını inceler ve önceki onarım başarısız olduğu için indirimi onaylar.

Bu senaryo, uygulamanın gerçek kararları yönetip yönetemediğini kontrol eder:

• Maya olası yinelenen müşteriyi görmeli ve kaydı birleştirebilmeli ya da inceleme için işaretleyebilmelidir.
• Sam kendisine atanan işi güncelleyebilmeli, ancak fatura tutarlarını düzenleyememeli veya indirimleri onaylayamamalıdır.
• Priya, ilgisiz bordro veya şirket ayarlarına erişmeden işi onaylayabilmelidir.
• Maya yeni bir fatura göndermeden önce vadesi geçmiş fatura görünmeli, ancak acil onarım işini engellememelidir.
• Her durum, sırada kimin işlem yapacağını ve hangi işlemlerin hâlâ kullanılabilir olduğunu anlatmalıdır.

Senaryoyu gerçek hissettiren kayıtlarla çalıştırın: sokak adresleri, farklı iş notları, 18,75 dolarlık bir parça ve farklı ödeme tarihlerine sahip faturalar kullanın. Test uzmanlarından ayrı ayrı çalışmalarını isteyin, ardından her durumun ne anlama geldiğini karşılaştırın.

Sam telefonundan indirim onaylayabiliyorsa izin kurallarını düzeltin. Maya "İş tamamlandı" ifadesinin faturalandırma mı yoksa yalnızca sahadaki işin bitmesi mi anlamına geldiğini anlayamıyorsa personel bu duruma güvenmeden önce etiketi değiştirin.

Basit bir test oturumu düzenleyin ve olanları kaydedin

Kısa ve odaklı bir test oturumu, kusursuz bir demonun kaçırdığı sorunları çoğu zaman ortaya çıkarır. Her test uzmanına müşteri eklemek, bir masrafı onaylamak veya vadesi geçmiş bir faturayı bulmak gibi normal bir görev verin. Kişilerden tek başına çalışmalarını isteyin ve her tıklamada onları yönlendirmekten kaçının.

Duraksarlar, yanlış menüyü seçerler veya bir etiketin ne anlama geldiğini sorarlarsa bunları not edin. Bu anlar, uygulamanın nerede daha açık ifadelere veya daha basit bir yola ihtiyaç duyduğunu gösterir.

Basit bir sorun kaydı tutun. Küçük bir ekip için ortak bir tablo yeterlidir. Sorunun göründüğü sayfayı, kullanılan işlemi ve örnek kaydı, beklenen sonucu, gerçekte olanı ve kullanıcı rolünü kaydedin. Sorunu düzeltecek kişi, tahmin yürütmeden aynı durumu tekrarlayabilmelidir.

Oturum bitmeden sorunları sıralayın. Önce engelleyici sorunları, ardından özel verileri açığa çıkaran veya birinin yalnızca görüntülemesi gereken kayıtları değiştirmesine izin veren izin hatalarını ele alın. Kafa karıştıran etiketler ve fazladan tıklamalar da önemlidir, ancak genellikle aynı aciliyette müdahale gerektirmez.

Bir düzeltmeden sonra aynı rol, örnek kayıt ve adımlarla tam olarak aynı testi tekrarlayın. Arama sonuçları ve dışa aktarmalar gibi ilgili sayfaları da kontrol edin. Bir müşteri sayfasındaki düzeltme, aynı sorunu başka bir yerde bırakmış olabilir.

Koder.ai anlık görüntüleri ve geri almayı destekler. Bu özellikler, ekiplerin büyük değişikliklerden önce bilinen ve çalışan bir sürümü korumasına yardımcı olabilir. Yeni roller ve iş akışları geldiğinde de işe yarayabilmesi için sorun kaydını projeyle birlikte tutun.

Personeli ilk kez uygulamaya almadan önce bu kontrolü yapın

Gerçekçi örnek kayıtlar kullanarak uygulamanın bir kopyasını inceleyin. Kusursuz görünen bir ekran, resepsiyon görevlisi, yönetici ve finans çalışanı aynı yoğun sabah içinde uygulamada çalıştığında yine de başarısız olabilir.

Her kişiden kendi rolüyle giriş yapmasını ve sıradan bir görevi baştan sona tamamlamasını isteyin. Bir satış çalışanı müşteri ekleyebilir, bir anlaşmayı güncelleyebilir, geçmiş bir görüşmeyi arayabilir ve takip görevi oluşturabilir. Bir yönetici aynı anlaşmayı inceleyip hesap ayarlarını değiştirmeden indirimi onaylayabilir.

Her rolün günlük işini tamamlayabildiğini, kısıtlı işlemlerin kullanılamadığını ve hassas alanların yanlış kişilerden gizli kaldığını kontrol edin. Uygulama biraz karmaşık hale gelecek kadar kayıt ekleyerek aramaları, filtreleri, dışa aktarmaları, raporları ve mobil ekranları test edin.

İzin testleri yalnızca eksik bir menü düğmesine bakmaktan ibaret değildir. Standart bir çalışan faturaları silememeliyse, bu çalışan olarak giriş yapın ve faturanın göründüğü her ekrandan bir faturayı silmeyi deneyin. Uygulama işlemi engellemeli ve nedenini açıklamalıdır.

Yinelenen müşteri adları, eski kapatılmış kayıtlar, boş bırakılmış isteğe bağlı alanlar, birkaç aya yayılan tarihler ve uzun notlar ekleyin. "Smith" araması yapın, duruma göre filtreleyin, bir raporu sıralayın ve aynı sonuçları telefonda açın. Küçük örnek setleri, kayıtlar çoğaldığında yavaşlayan sayfaları, kafa karıştıran etiketleri ve çalışmayan filtreleri gizleyebilir.

Tek bir kullanıcı girişini paylaşmak yerine her izin düzeyi için ayrı test hesapları oluşturun. Böylece erişim sorunlarını yeniden üretmek ve düzeltmek kolaylaşır.

Gerçek işletme verilerini içe aktarmadan önce tüm test hesaplarını ve örnek kayıtları kaldırın. Test e-posta adreslerinin, telefon numaralarının, eklerin ve dışa aktarılan dosyaların da silindiğini doğrulayın. Ardından ekibin kullanıma geçiş için bilinen bir başlangıç noktasına sahip olması amacıyla temiz bir anlık görüntü oluşturun.

Bir sonraki test turunu hazırlayın

Testi kullanıma geçmeden önce yapılan tek seferlik bir görev değil, tekrarlanabilir bir döngü olarak ele alın. Müşteri kaydı oluşturmak, sorumlu atamak ve durumunu güncellemek gibi personelin sık kullandığı bir iş akışı seçin. Her ekranı rastgele örnek verilerle doldurmak yerine, anlamlı her değişiklikten sonra bu yolu test edin.

Kurgusal kayıtlardan oluşan tekrar kullanılabilir bir paket hazırlayın. Her kayda net bir amaç verin: normal bir müşteri, iki irtibat kişisi olan bir müşteri, vadesi geçmiş bir fatura, yineleniyor gibi görünen bir ad veya eksik isteğe bağlı bilgileri olan bir kayıt. Aynı verileri kullanmak, beklenen davranıştaki değişiklikleri fark etmeyi kolaylaştırır.

Paketi ortak bir yerde saklayın ve her test için beklenen sonucu not edin. Bir hesap yöneticisi müşterinin telefon numarasını düzenleyebilmeli, ancak bordro alanlarını görmemelidir. Bir finans kullanıcısı faturaları görüntüleyebilmeli, ancak müşteri kayıtlarını silememelidir. Kısa beklentiler, bir sonucun hata olup olmadığı konusunda tartışmaları önler.

Bir sonraki sürümü geliştirmeden önce Koder.ai planlama modunu kullanın. Personel rolünü, tam görevi, düzenlenebilir alanları ve doğrulama kurallarını açıklayın. Örneğin: "Bir destek görevlisi talep oluşturabilir, müşteri seçebilir, not ekleyebilir ve öncelik belirleyebilir. Görevli başka bir ekibe atanmış talepleri kapatamaz. Konu alanını zorunlu tutun ve takip aramaları için geçmiş tarihleri reddedin."

Plan gerçek işi yansıtana kadar değişikliği geliştirmeyin. Ardından iş akışını kurgusal kayıtlarla ve hatalı girişlerle tekrarlayın. Büyük bir değişiklikten önce anlık görüntü oluşturun ve küçük bir grubun yeni sürümü test etmesini sağlayın. Değişiklik sorun çıkarırsa siz düzeltirken geri alın.

Basit bir test günlüğünde tarih ve sürüm, kullanılan iş akışı ve kayıtlar, beklenen ve gerçek sonuçlar, test uzmanı ve şimdi düzelt, sonra gözden geçir veya olduğu gibi bırak kararı bulunmalıdır. Bir izin, alan veya iş akışı eklediğinizde, personel uygulamaya güvenmeden önce ilgili testleri yeniden çalıştırın.