How to demo?

Use Case, Kryteria akceptacji, Przypadki testowe – jest wiele sposobów na to, żeby zdefiniować wymagania i zweryfikować poprawność ich implementacji.

Ich wyszukane nazwy mogą być jednak odstraszające, klienci mogą nie być zachwyceni, że muszą się czegoś nowego nauczyć. Dlatego podoba mi się określenie “How to demo?”.

Opisz co musiałbym zrobić z systemem, żeby udowodnić Ci, że Twoje wymaganie zostało zaimplementowane?

Na przykład historyjka

Logowanie do systemu:
wchodzę na stronę główną, wpisuję poprawne dane do logowania, po kliknięciu zaloguj widzę spersonalizowaną stronę startową (spersonalizowana, to taka, która mówi ‘witaj, Grzegorz’, o ile zalogował się Grzegorz)

Proste, prawda?

Oczywiście UMLowiec powie, że trzeba w tym Use Casie dodać alternatywne, błędne ‘przebiegi’. Ja jednak powiem, że załatwią to osobne historyjki:

Nieudane logowanie do systemu
wchodzę na stronę główną, wpisuję niepoprawne dane do logowania, system pokazuje formularz logowania z dodatkowymi informacjami:
– błędna para login/hasło
– zapomniałeś hasła? (to jest link)

i dalej,

Przypomnienie hasła
Po kliknięciu “zapomniałeś hasła” klient jest proszony o podanie adresu e-mail na który się zarejestrował, oraz kodu z obrazka. Gdy email jest w bazie, a kod prawidłowy klient dostaje e-mail z wygenerowanym, tymczasowym hasłem

następnie:

Logowanie przy pomocy tymczasowego hasła

Dalej sam już dasz sobie radę.

Myślę, że takie układanie historyjek jest szybkie, poza tym klient nie musi się tego uczyć – wystarczy, że przy odrobinie naszych wskazówek nauczy się oddzielać zadania od siebie, aby historyjki były krótkie (a przez to proste).
Oczywiście zdarzają się skomplikowane zadania biznesowe – jednak zaprawieni i wytrenowani w łatwiejszych przypadkach możecie z przyjemnością zagłębić się w ten nowy wymagający i fascynujący (mam nadzieję) temat.

Share Button

Leave a Reply

Your email address will not be published. Required fields are marked *