Kullanıcı Hikayesi ve Kabul Kriterleri (Örnekler) nedir

Misal:

Bir WhatsApp kullanıcısı olarak, fotoğraflarımı tıklayıp tüm arkadaşlarımla eşzamanlı olarak paylaşabilmem için sohbet yazma kutusunda fotoğraf çekip göndermek için bir kamera simgesi istiyorum.

Kabul Kriterleri nedir?

Bir kabul kriteri, Ürün Sahibi / Paydaşlar tarafından kabul edilebilmesi için işlevselliğin veya özelliğin karşılaması ve karşılaması gereken bir dizi kabul edilmiş koşul veya iş kuralıdır.

Bu, kullanıcı hikayesini tamamlamanın çok önemli bir parçasıdır ve Ürün Sahibi ve İş Analisti tarafından çok titizlikle çalışılmalıdır çünkü tek bir kriteri kaçırmak çok maliyetli olabilir. Bu, basit numaralı veya madde işaretli bir listedir.

Formatı aşağıdaki gibidir:

' Bir eylem yaptığımda bir ön koşul verildiğinde sonucu bekliyorum ”.

kara kutu testi ile beyaz kutu testi arasındaki fark

Örnek (w.r.t'den yukarıdaki kullanıcı hikayesine):

• Bir arkadaşımla sohbet ettiğimi ve bir fotoğraf çekebileceğimi düşünelim.
• Bir resme tıkladığımda, resme göndermeden önce bir başlık ekleyebilmeliyim.
• Telefon kameramı başlatırken bir sorun varsa, 'Kamera başlatılamadı' gibi bir hata mesajı. vb. uygun şekilde gösterilmelidir.

Dolayısıyla, Kullanıcı öyküsü herhangi bir işlev veya özellik için gereksinimi tanımlarken, Kabul Kriterleri kullanıcı öyküsü veya gereksinim için 'Tamamlandı tanımı' nı tanımlar.

Kalite Güvencesi olarak, 'testin başlangıcında' tek bir şüphe kalmadan kullanıcı hikayesini ve kabul kriterlerini derinlemesine anlamak çok önemlidir. İlerlerken, kullanıcı öykülerini ve kabul kriterlerini 'derinlemesine' araştırmanın neden son derece önemli olduğunu anlayalım.

Kullanıcı hikayelerinin derinliklerine inmek

Başlangıç ​​olarak, önce temel ve temel bir şeyin 'derinlemesine' çalışmasının önemini anlayalım, örn. Kullanıcı hikayeleri.

Aşağıdaki durumlar benim gerçek deneyimlerimdir.

Dava 1:

3 yıl önce Mobil Uygulama Projesi üzerinde çalışıyordum ve ürün teslimatçılara yönelik tasarlanmış bir uygulamaydı.

Teslimat için yerinize gelen bir teslimat görevlisi görürdünüz. Ve teslimattan sonra imzanızı vermenizi istedikleri bir cep telefonları var. Bu imza, DTDC, FedEx vb. Gibi kurye hizmeti sağlayıcılarının portalına yansır.

Mobil uygulamanın yeni piyasaya sürüldüğünü ve portallarının halihazırda mevcut ve çalışır durumda olduğunu varsayalım.

Sorun: Bir Sprint için Ürün sahibinizin bu mobil uygulama için bir kullanıcı hikayesi vardır. 'Portal Yöneticisi olarak, teslimat sırasında teslimat görevlisinin attığı imzayı görebilmeliyim' . Burada portal (web uygulaması) imzayı yansıtacak şekilde değiştirilir ve güncellenir.

QA olarak, mobil uygulamada yakalanan imzanın portalda beklendiği gibi yansıtılıp yansıtmadığını doğrulamanız gerekir.

Bu kullanıcı öyküsüne bakarsanız, basit görünür, ancak burada gizli bir gereklilik vardır: 'Geçmiş teslimatlar için imza yansıtma işlevi yoktu, öyleyse portaldaki görevliler geçmiş teslimatları görüntülerse ne olur?' Geçmiş veriler silinmeli mi? Bu tür veriler için çökmelere veya hatalara izin vermeli miyiz?

Tabii ki hiç de değil, bu nezaketle ele alınmalıdır.

Çözüm: İmza konumu için yeni bir sütun eklemek üzere ilgili DB tabloları güncellendiğinde, eski verilerin kontrol edilmesi gereken bir NULL veya 0 değeri olmalı ve 'İmza yok' mesajı gösterilmelidir.

Bu, Ürün Sahibi veya İş Analisti tarafından hata olarak adlandırılabilir, ancak bunun yapılması gerekir. Bir özelliği başarıyla uygulamak, ancak onunla birlikte bir şeyi bozmak müşteriler tarafından istenmez. Bu, aynı kullanıcı hikayesi ile birlikte ve aynı sprint içinde yapılmalıdır.

Örnek 2

6 yıl önce, CA, Finans Danışmanları gibi finans uzmanlarının yatırım planlarını, tasarrufları vb. Farklı para birimleri için kullanabileceği küresel bir uygulama olan Emeklilik Planlama Finans Uygulaması (BA'sız) üzerinde çalışıyordum. müşterilerine büyük dönem.

Sorun: Ürün Sahibi size bir Kullanıcı Hikayesi verir 'Bir Danışman olarak, müşterimin raporunu sağlanan mali ayrıntılara göre görüntülemek istiyorum'.

Burada 2 gizli gereksinim vardı ve bunu eksik bir hikaye olarak adlandırabilirim çünkü:

için) Raporlar, son görüntülenen rapordaki gibi geçmiş olanı değil, günlük para birimi dönüştürme oranını dikkate almalıdır ve

b) Müşterinin finansal ayrıntılarını sağladıktan sonra para birimi değiştirilirse, raporlar değiştirilen para biriminde gösterilmelidir.

Çözüm: Bu endişeyi doğrudan Ürün Sahibimize ilettim ve her ikisinin de mümkün olan en kısa sürede yapılması gerektiğini ona bildirdim. Benimle aynı fikirde ve gelecek sprintler için öncelikli olarak 2 farklı hikaye oluşturdu.

Paket servisi: Bunlar, hepimizin ürünleri, tasarımlarını, yapılarını vb. Çok iyi bildiğimiz için yakalandı. Bu tür bilgiler ancak ürünü tamamen anlayarak, modüllerin birlikte çalışabilirliğini anlayarak ve kullanıcı hikayesini derinlemesine inceleyerek elde edilebilir. 2 astar.

İşleri kolaylaştırmak ve BA'lar ve geliştiricilerle düşünceleri hakkında tartışmak için notlar alın.

Kabul Kriterlerine Derinlemesine Bakış

Kabul kriterlerini ve diğer tüm koşulları ve kuralları kapsamlı bir şekilde anlamak, bir kullanıcı hikayesini anlamaktan daha önemlidir. Çünkü bir gereksinim eksik veya belirsizse, sonraki sprintte ele alınabilir, ancak bir kabul kriteri kaçırılırsa, kullanıcı hikayesinin kendisi serbest bırakılamaz.

Sanırım hepimiz bir noktada net bankacılığı kullanırdık ve çoğumuz bunu her gün kullanıyoruz ve ben tarihsel ifadelerimi çok indiriyorum. Dikkatlice gözlemlerseniz, indirmek için belirli özel seçenekler mevcuttur.

Ekstrenizi indirmek için dosya türünü seçme seçeneği vardır. Yalnızca Krediler / Borç / her ikisini de indirmek isteyip istemediğinizi seçme seçeneği vardır.

Şimdi, Ürün Sahibi'nin size şu Kullanıcı hikayesini verdiğini hayal edin 'Müşteri olarak, belirli bir dönem için yapılan tüm işlemlerimi görebilmem için hesap özetimi indirmek istiyorum'.

Aşağıdaki Kabul Kriterleri ile:

• Geçmiş Bildirimi İndir Sayfasında olduğumu göz önünde bulundurarak, beyanı indirmek istediğim dönemi seçmeliyim.
• Geçmiş Özeti İndir Sayfasında olduğumu düşünerek, beyanı indirmek istediğim hesabı seçmeliyim.
• Geçmiş Bildirimi İndir Sayfasında olduğumu göz önünde bulundurarak, ilerideki 'Son' tarih için bildirimi indirmeme izin verilmemeli.
• Geçmiş Bildirimi İndir Sayfasında olduğumu göz önünde bulundurarak, geçmişte 10 yıl sonrasındaki 'Başlangıç' tarihini seçmeme izin verilmemelidir.
• Ekstremi indirdiğimi düşünürsek, indirilen dosyayı görüntüleyebilmeliyim.
• Geçmiş Bildirimi İndir Sayfasında olduğumdan dolayı, bildirimimi doc, excel ve pdf formatlarında indirebilmeliyim.

Bu kabulü tamamlarsanız, burada eksik olan 3 şey var:

• İndirilecek dosya adının adı ve biçimi.
• Dosyada hangi bilgiler (Sütun adları) görüntülenecek.
• Müşterinin ne tür bir işlem istediğini, yani yalnızca borçları veya yalnızca alacakları veya her ikisini de seçmek için seçenekler listesi.

Bu tür durumlar arada bir meydana gelebilir, ancak yine de her kabul kriteri hakkında iyi çalışın ve kullanıcı hikayesine göre bunu görselleştirmeye çalışın. Koşullar ve iş kuralları hakkında ne kadar derinlemesine çalışırsanız, özellikle ilgili bilginiz o kadar fazla olacaktır.

İlk aşamada bulunan hataların, 'test' aşamasında olabileceklerine kıyasla hiçbir maliyeti yoktur.

Kullanıcı Hikayesi / Kabul Kriterlerinde Tutarsızlık Bulmanın Önemi

Geliştirme veya test başlamadan önce bile erken bir aşamada kullanıcı hikayelerine ve kabul kriterlerine derinlemesine bir dalış yapmak her zaman önemlidir.

Çünkü şunları içerir:

# 1) Zaman Kaybı:

Kullanıcı öyküsü / kabul kriterlerindeki tutarsızlıklar veya hatalar geliştirme devam ederken veya testler devam ederken bulunursa, kalan sprint süresinde çok sayıda yeniden çalışma yapılması gerekebilir.

Ürün Sahibi birkaç şeyi gözden kaçırmış olsa bile, kullanıcı hikayesini gelecek sprint'e taşıyacak değildir. % 95 şans, takımdan gerekli uygulamayı yapmasını ve aynı sprintte serbest bırakmasını istemeleridir.

Ekstra zaman harcamak, hafta sonları gelmek veya gece geç saatlerde çalışmak zorunda kaldıkları için ekip için bir kabusa dönüşür. Bu, mümkün olan en erken aşamada kullanıcı hikayesini / kabul kriterlerini inceleyerek ve tartışarak önlenebilir.

# 2) Çaba Kaybı:

Geliştiriciler ve Kalite Güvencesi, uygulanan kodu ve senaryoları tekrar gözden geçirmek zorundadır. Gereksinime göre güncelleme, ekleme ve çıkarma kolay bir iş değildir. Zaten zamanında doğum yapma baskısı olduğu için çok acı verici hale geliyor.

Böyle bir durumda, geliştirme veya test aşamasında hata olasılığı vardır. Böyle bir durumla karşılaşırsanız 'DevQA Eşleştirme' yi seçin. Pastaya krema olarak, ekstra iş için tazminat alamayabilirsiniz.

Sonuç

Kullanıcı Hikayesi ve kabul kriterlerinin derinlemesine anlaşılması, ancak üzerinde çalışmak için çok fazla zaman harcayarak elde edilebilir.

Piyasada bunu sizin için yapacak belirli bir araç veya kurs yoktur, çünkü bu tamamen mantıksal düşünme, deneyim ve ürün hakkında bilgi ile ilgilidir.

Ön plan toplantısına aktif olarak katılmak, iş idaresi ile konuşmak, kendi başınıza çalışmak sadece bunu başarmanıza yardımcı olabilir. Ne kadar çok çaba gösterirseniz, o kadar çok öğrenir ve gelişirsiniz.

İster QA'lar ister geliştiriciler olsun, herkes kullanıcı hikayeleri ve kabul kriterleri hakkında aynı sayfada olmalı, ancak o zaman müşterinin beklentileri başarıyla gerçekleştirilebilir.

Kullanıcı Hikayeleri ile çalışma deneyimlerinizi bizimle paylaşacak yeni bir şeyiniz var mı? Lütfen düşüncelerinizi aşağıda belirtin !!

Önerilen Kaynaklar

• MongoDB Kullanıcı Oluşturun ve Örneklerle Rol Atayın
• Örneklerle Kabul Testi Raporu için Örnek Şablon
• MongoDB'de Kullanıcı Kimlik Doğrulaması
• Kullanıcı Tanımlı Değişkenleri Kullanarak JMeter Veri Parametrelendirmesi
• Unix İzinleri: Örneklerle Unix'te Dosya İzinleri
• Kabul Testi Nedir (Eksiksiz Kılavuz)
• Kullanıcı Kabul Testi (UAT) Nedir: Eksiksiz Bir Kılavuz
• Örneklerle Python DateTime Eğitimi