what is user story acceptance criteria
Doskonały przewodnik po kryteriach akceptacji historii użytkownika ze scenariuszami z życia wziętymi:
W branży rozwoju oprogramowania słowo „wymaganie” określa, jaki jest nasz cel, czego dokładnie potrzebują klienci i co sprawi, że nasza firma rozwinie swoją działalność.
Niezależnie od tego, czy jest to firma produktowa, która wytwarza oprogramowanie, czy firma usługowa, która oferuje usługi w różnych dziedzinach oprogramowania, podstawową podstawą dla wszystkich z nich jest wymóg, a sukces zależy od tego, jak dobrze wymagania są spełnione.
Termin „wymaganie” ma różne nazwy w różnych metodologiach projektowych.
W Wodospad , jest określany jako „ Dokument wymagań / specyfikacji ', w Agile lub SCRUM jest określany jako „Epic”, „User Story”.
W modelu Waterfall dokumenty wymagań to ogromne dokumenty liczące 200 lub więcej stron, ponieważ cały produkt jest wdrażany w jednej fazie. Ale tak nie jest w przypadku Agile / SCRUM, ponieważ w tych metodologiach wymagania są podane dla małych funkcjonalności lub funkcji, ponieważ produkt jest przygotowywany krok po kroku.
W tym artykule starałem się podzielić całym moim 4-letnim doświadczeniem w pracy z Historiami użytkowników i powiązanymi z nimi Kryteriami akceptacji, a także łatwymi i prostymi scenariuszami z życia wziętymi dla lepszego zrozumienia.
Wróćmy najpierw do podstaw.
Czego się nauczysz:
- Co to jest historia użytkownika?
- Co to są kryteria akceptacji?
- Zagłębianie się w historie użytkowników
- Dogłębne spojrzenie na kryteria akceptacji
- Znaczenie znajdowania rozbieżności w historyjkach użytkownika / kryteriach akceptacji
- Wniosek
- rekomendowane lektury
Co to jest historia użytkownika?
Historia użytkownika jest wymagana dla każdej funkcji lub funkcji, która jest zapisana w jednym lub dwóch wierszach i maksymalnie w 5 wierszach. Historia użytkownika jest zwykle najprostszym możliwym wymaganiem i dotyczy jednej i tylko jednej funkcji (lub jednej funkcji).
Najczęściej używany standardowy format tworzenia historii użytkownika jest określony poniżej:
Jak
Przykład:
Jako użytkownik WhatsApp chcę, aby ikona aparatu w polu zapisu czatu służyła do przechwytywania i wysyłania zdjęć, aby móc jednocześnie klikać i udostępniać zdjęcia wszystkim znajomym.
Co to są kryteria akceptacji?
Kryterium akceptacji to zbiór zaakceptowanych warunków lub reguł biznesowych, które funkcjonalność lub cecha powinna spełniać i spełniać, aby została zaakceptowana przez Właściciela Produktu / Interesariuszy.
Jest to bardzo ważna część wypełniania historyjek użytkownika i powinna być bardzo skrupulatnie przestudiowana przez właściciela produktu i analityka biznesowego, ponieważ pominięcie jednego kryterium może dużo kosztować. To jest prosta lista numerowana lub wypunktowana.
Jego format jest następujący:
' Biorąc pod uwagę pewne warunki wstępne, kiedy wykonuję jakąś czynność, spodziewam się wyniku ”.
jaki typ testu jest używany do sprawdzenia, czy wszystkie programy w aplikacji działają poprawnie?
Przykład (w.r.t do powyższej historii użytkownika):
- Rozważmy, że rozmawiam ze znajomym i powinienem być w stanie zrobić zdjęcie.
- Po kliknięciu zdjęcia powinienem być w stanie dodać podpis do obrazu przed wysłaniem.
- Jeśli wystąpi problem z uruchomieniem aparatu w moim telefonie, pojawi się komunikat o błędzie typu „Nie można uruchomić aparatu”. itp., powinny być odpowiednio pokazane.
W związku z tym historyjka użytkownika definiuje wymaganie dotyczące dowolnej funkcjonalności lub funkcji, podczas gdy kryteria akceptacji definiują „definicję ukończenia” dla historyjki użytkownika lub wymagania.
Podczas kontroli jakości bardzo ważne jest, aby dogłębnie zrozumieć historię użytkownika i kryteria akceptacji, tak aby na „początku testowania” nie pozostała żadna wątpliwość. Idąc dalej, zrozumiemy, dlaczego niezwykle ważne jest zagłębianie się w historie użytkowników i kryteria akceptacji.
Zagłębianie się w historie użytkowników
Na początek zrozummy, jak ważne jest dogłębne badanie podstawowej i fundamentalnej rzeczy, tj. Historie użytkownika.
Poniższe przypadki są moimi własnymi prawdziwymi doświadczeniami.
Przypadek 1:
Przed 3 latami pracowałem nad Projektem Aplikacji Mobilnej, a produktem była aplikacja przeznaczona dla osób dostarczających.
Widziałbyś dostawcę przychodzącego na twoje miejsce po dostawę. I mają telefon komórkowy, na którym proszą Cię o złożenie podpisu po dostawie. Podpis ten znajduje odzwierciedlenie na portalu dostawców usług kurierskich, takich jak DTDC, FedEx itp.
Wyobraźmy sobie, że aplikacja mobilna została właśnie uruchomiona, a jej portale już istnieją i działają.
Problem: W przypadku Sprintu właściciel produktu ma historię użytkownika tej aplikacji mobilnej, która „Jako administrator portalu powinienem mieć wgląd w podpis złożony przez dostawcę w momencie dostawy” . Tutaj portal (aplikacja internetowa) jest odpowiednio zmieniany i aktualizowany w celu odzwierciedlenia podpisu.
W ramach kontroli jakości musisz sprawdzić, czy podpis przechwycony w aplikacji mobilnej jest zgodny z oczekiwaniami w portalu.
Jeśli spojrzysz na tę historię użytkownika, wygląda to na proste, ale istnieje ukryty wymóg, że „W przypadku dostaw historycznych nie było funkcji odbicia podpisu, więc co powinno się stać, jeśli faceci z portalu zobaczą historyczne dostawy?” Czy dane historyczne powinny zostać usunięte? Czy powinniśmy pozwolić na awarie lub błędy w przypadku takich danych?
Oczywiście, że nie, należy to traktować łaskawie.
Rozwiązanie: Gdy odpowiednie tabele DB zostaną zaktualizowane w celu dodania nowej kolumny dla lokalizacji podpisu, stare dane powinny mieć wartość NULL lub 0, którą należy sprawdzić i powinien zostać wyświetlony komunikat „Brak podpisu”.
Można to nazwać brakiem ze strony właściciela produktu lub analityka biznesowego, ale należy to zrobić. Wdrożenie jednej funkcji z powodzeniem, ale zerwanie czegoś wraz z nią nie jest pożądane przez klientów. Należy to zrobić razem z tą samą historią użytkownika i podczas tego samego sprintu.
Przypadek 2
6 lat temu pracowałem nad aplikacją finansową do planowania emerytalnego (bez licencjatu), która była aplikacją globalną, w której finansiści, tacy jak CA, doradcy finansowi mogli używać jej dla różnych walut do wyświetlania planów inwestycyjnych, oszczędności itp. duży okres dla swoich klientów.
Problem: Właściciel produktu przedstawia historię użytkownika „Jako doradca chcę zobaczyć raport mojego klienta na podstawie dostarczonych danych finansowych”.
Tutaj były 2 ukryte wymagania i nazwałbym to niepełną historią, ponieważ:
do] Raporty powinny uwzględniać dzienny kurs wymiany walut, a nie historyczny, jak w ostatnio przeglądanym raporcie i
b] Jeśli waluta zostanie zmieniona po podaniu danych finansowych klienta, raporty powinny być przedstawione w zmienionej walucie.
Rozwiązanie: Poruszyłem tę kwestię bezpośrednio z naszym Właścicielem Produktu i uświadomiłem mu, że oba te działania należy zrobić jak najszybciej. Zgodził się ze mną i stworzył 2 różne historie na nadchodzące sprinty z priorytetem.
Na wynos: Zostały one złapane, ponieważ wszyscy byliśmy bardzo dobrze świadomi produktów, ich projektu, struktury itp. Taką wiedzę można osiągnąć jedynie poprzez pełne zrozumienie produktu, zrozumienie współdziałania modułów i dokładne przestudiowanie historii użytkownika, nawet jeśli jest to 2 wkładka.
Rób notatki, aby ułatwić sobie pracę, i omawiaj z licencjatami i programistami ich sposób myślenia.
Dogłębne spojrzenie na kryteria akceptacji
Zrozumienie kryteriów akceptacji i wszystkich innych warunków i zasad jest nawet ważniejsze niż zrozumienie historii użytkownika. Ponieważ jeśli wymaganie jest niekompletne lub niejasne, może zostać podjęte w następnym sprincie, ale jeśli kryterium akceptacji zostanie pominięte, to sama historyjka użytkownika nie może zostać opublikowana.
Wydaje mi się, że wszyscy kiedyś skorzystalibyśmy z bankowości internetowej, a większość z nas korzysta z niej codziennie i często pobieram moje historyczne wyciągi. Jeśli przyjrzysz się temu uważnie, dostępne są określone opcje ich pobrania.
Istnieje możliwość wybrania typu pliku do pobrania wyciągu. Istnieje możliwość wyboru, czy chcesz pobrać tylko Kredyty / Debet / oba.
Teraz wyobraź sobie, że właściciel produktu przekazuje Ci tę historię użytkownika „Jako klient chcę pobrać wyciąg z konta, aby móc przeglądać wszystkie moje transakcje wykonane za określony okres”.
Z następującymi kryteriami akceptacji:
- Biorąc pod uwagę, że jestem na stronie pobierania wyciągu historycznego, powinienem wybrać okres, za który chcę pobrać wyciąg.
- Biorąc pod uwagę, że jestem na stronie pobierania wyciągu historycznego, powinienem wybrać rachunek, dla którego chcę pobrać wyciąg.
- Biorąc pod uwagę, że jestem na stronie pobierania wyciągów historycznych, nie powinienem mieć możliwości pobrania wyciągu na przyszłą datę „Do”.
- Biorąc pod uwagę, że jestem na stronie pobierania zestawienia historycznego, nie powinienem mieć możliwości wybrania daty „Od” 10 lat później.
- Biorąc pod uwagę, że pobrałem moje oświadczenie, powinienem być w stanie wyświetlić pobrany plik.
- Biorąc pod uwagę, że jestem na stronie pobierania wyciągów historycznych, powinienem być w stanie pobrać moje oświadczenie w formatach doc, excel i pdf.
Jeśli przejdziesz przez tę akceptację, brakuje tutaj 3 rzeczy:
- Nazwa i format nazwy pliku, który zostanie pobrany.
- Jakie informacje (nazwy kolumn) mają być wyświetlane w pliku.
- Lista opcji umożliwiająca wybór rodzaju transakcji, której chce klient, tj. Tylko obciążenia lub tylko kredyty lub oba.
Takie przypadki mogą się zdarzyć od czasu do czasu, jednak nadal dobrze zapoznaj się z każdym kryterium akceptacji i spróbuj zwizualizować to w odniesieniu do historyjki użytkownika. Im więcej będziesz studiować warunków i reguł biznesowych, tym większa będzie Twoja wiedza na temat tej funkcji.
Błędy wykryte na początkowym etapie nic nie kosztują w porównaniu z kosztami na etapie „testowania”.
Znaczenie znajdowania rozbieżności w historyjkach użytkownika / kryteriach akceptacji
Zawsze ważne jest, aby zagłębić się w historie użytkowników i kryteria akceptacji na wczesnym etapie, nawet przed rozpoczęciem tworzenia lub testowania.
Ponieważ obejmuje:
# 1) Strata czasu:
Jeśli rozbieżności lub błędy w historyjkach użytkownika / kryteriach akceptacji zostaną znalezione podczas tworzenia lub testowania, może być konieczne wykonanie wielu poprawek w pozostałym czasie sprintu.
Nie zdarza się, że nawet jeśli właściciel produktu przeoczył kilka rzeczy, to przeniesie historyjkę użytkownika na nadchodzący sprint. 95% jest szans, że poproszą zespół o wykonanie niezbędnej implementacji i zwolnienie go w tym samym sprincie.
Dlatego dla zespołu staje się to koszmarem, ponieważ muszą spędzać dodatkowy czas, przychodzić w weekendy lub pracować późno w nocy. Można tego uniknąć, studiując i omawiając historię użytkownika / kryteria akceptacji na jak najwcześniejszym etapie.
# 2) Marnotrawstwo wysiłków:
Programiści i QA muszą ponownie zajrzeć do zaimplementowanego kodu i przypadków testowych. Aktualizowanie, dodawanie i usuwanie zgodnie z wymaganiami nie jest łatwym zadaniem. Staje się to zbyt bolesne, ponieważ istnieje już presja, aby dostarczyć na czas.
W takiej sytuacji są szanse na błędy na etapie rozwoju lub testowania. Jeśli napotkasz taką sytuację, wybierz „Parowanie DevQA”. Jako wisienka na torcie możesz nie otrzymać rekompensaty za dodatkową pracę.
Wniosek
Głębokie zrozumienie historii użytkownika i kryteriów akceptacji można osiągnąć tylko poprzez poświęcenie ogromnej ilości czasu na jej studiowanie.
Na rynku nie ma żadnego konkretnego narzędzia ani kursu, który mógłby to zrobić za Ciebie, ponieważ chodzi o logiczne myślenie, doświadczenie i wiedzę o produkcie.
Aktywne uczestnictwo w spotkaniu Pre-plan, rozmowa z licencjatem, samodzielna nauka mogą ci w tym pomóc. Im więcej wysiłku włożysz, tym więcej się uczysz i rozwijasz.
Niezależnie od tego, czy chodzi o kontrolę jakości czy deweloperów, wszyscy muszą być na tej samej stronie o historiach użytkowników i ich kryteriach akceptacji, tylko wtedy można pomyślnie spełnić oczekiwania klienta.
Czy chcesz podzielić się z nami czymś nowym na temat swoich doświadczeń związanych z pracą z Historiami użytkowników? Proszę wyrazić swoje myśli poniżej !!
rekomendowane lektury
- MongoDB Utwórz użytkownika i przypisz role z przykładami
- Przykładowy szablon raportu z testu akceptacji z przykładami
- Uwierzytelnianie użytkownika w MongoDB
- Parametryzacja danych JMeter przy użyciu zmiennych zdefiniowanych przez użytkownika
- Uprawnienia w systemie Unix: Uprawnienia do plików w systemie Unix z przykładami
- Co to jest test akceptacyjny (kompletny przewodnik)
- Co to jest test akceptacji użytkownika (UAT): kompletny przewodnik
- Python DateTime Tutorial z przykładami