Udoskonalone testy zapewniania jakości — samouczek dotyczący przepływu użytkownika

Ponieważ produkty i usługi wdrażają się coraz szybciej, zapewnianie jakości (QA) musi dostosowywać się do zmieniającego się środowiska, czasami osiągając ten sam poziom pokrycia w krótszym czasie. Jak uniknąć pomyłki ilości nad jakością ? W jaki sposób kryjemy więcej, zwiększamy efektywność i nadal jesteśmy skuteczni w naszej pracy?

Wszyscy wiemy, że tworzenie przypadków testowych zajmuje dużo czasu. Musimy stosować różne techniki, typy testów i dokumentować warunki wstępne, kroki i oczekiwane wyniki. Dodatkowo musimy stworzyć plan testów.

Specjaliści ds. zapewnienia jakości często znajdują się poza czasem, zwłaszcza gdy próbują ukończyć wszystkie etapy procesu zapewniania jakości. Największym problemem jest faza planowania i projektowania testów, obracająca się wokół tworzenia przypadków testowych i dokumentacji testów. Wykonanie całej pracy może zająć wiele godzin, a czasem nawet dni, a zazwyczaj wybierają pominięcie niektórych wyników i zamiast tego podsumowują, pomijając ważne informacje, które mogą prowadzić do zapomnienia o teście. Powoduje to również utratę korzyści z dzielenia się wiedzą.

Tradycyjne testy QA spotykają się z przepływem użytkowników

Jestem wielkim fanem tradycyjnych przypadków testowych i planów testów. Nie tylko pomagają zidentyfikować mnóstwo przypadków testowych, ale także bardzo dobrze dokumentują produkt. Możesz ich używać podczas treningu, a każda osoba w zespole je rozumie. Nie musisz nadmiernie polegać na doświadczeniu, aby ktoś zaczął testować. Plany testów zawierają dodatkowe informacje, takie jak szczegółowy zakres, elementy testu, funkcje, które testujesz, i te, którymi nie jesteś. Istnieje również analiza ryzyka, która wchodzi w plan testów. To tylko niektóre z korzyści, jednak ogólny czas, jaki zajmuje to w wielu przypadkach, jest zbyt długi.

Celem planu testów jest sposób komunikacji i porozumienia między interesariuszami projektu. Pomaga szczegółowo określić cele, wymagane zasoby oraz wszelkie podejście lub strategię testowania produktu. Plan pomaga upewnić się, że wszystko jest przemyślane i daje interesariuszom pewność, że proces zapewniania jakości jest strategicznie zainwestowany. Nie ma konkretnej reguły, że plan ten musi mieć 10 stron. Możemy go przedefiniować, aby dopasować go do szybko działającego zespołu.

Alternatywą jest uproszczenie tradycyjnych przypadków testowych i planu testów w sposób, który skróci wymagany czas inwestycji, ale zapewni taki sam, jeśli nie większy zakres i dokumentację, która ma sens dla wszystkich interesariuszy. Wiąże się to z jednym źródłem prawdy, przepływem użytkowników z niespodzianką. Dzięki ustrukturyzowaniu i utrzymaniu przepływu użytkowników, większość projektu przypadku testowego zostanie już za Ciebie wykonana. Można to zastosować do dowolnego produktu lub zespołu i jest wszechstronne pod względem szczegółów i struktury.

Korzystanie z metody przepływu pomoże skrócić czas realizacji dokumentacji testowej. Dotyczy to nie tylko ręcznej kontroli jakości, ale także automatyzacji. Przepływ może również przyczynić się do niektórych sekcji planu testów.

Idąc z prądem

Bez dalszej zwłoki zajmijmy się budowaniem przepływu użytkowników dla prostej witryny do przesyłania wiadomości.

Najpierw będziemy potrzebować darmowego narzędzia do mapowania myśli. Osobiście używam XMind. Możesz pobrać dowolne narzędzie, które Ci odpowiada — będziemy używać tylko podstawowych funkcji, takich jak rysowanie schematu blokowego, dodawanie „notatek” do niektórych tematów, kolorowanie różnych warunków i używanie etykiet.

Naszym pierwszym krokiem jest zrozumienie produktu. Zwykle będziesz odwoływać się do makiety lub makiety. Jeśli żaden z nich nie jest dostępny, szybka rozmowa telefoniczna z deweloperem da dokładnie takie ekrany, jakich można się spodziewać. Nie krępuj się śledzić i ćwiczyć w miarę postępów. Przepływ jest nie tylko ograniczony do interfejsu użytkownika, ale może być również używany do mapowania wywołań interfejsu API do interfejsu API, diagramów bazy danych, struktur zależności i nie tylko. Obowiązują te same zasady.

Warunki, stany, działania

Ograniczamy nasz przepływ, używając tylko trzech aktorów. Będziesz mieć warunek , który jest jak użytkownik o określonej roli, wyczyszczona pamięć podręczna lub użytkownik logujący się po raz pierwszy. Po drugie, mamy State/Page , który jest rzeczywistym komponentem GUI, takim jak strona główna lub okno logowania. Następnie pojawia się Action , które jest fizyczną interakcją użytkownika, która powoduje zmianę stanu. Zobaczmy to w akcji.

Analiza wymagań

To jest nasza strona główna, czyli państwo. Mamy dwie możliwe akcje: Zarejestruj się i Zaloguj się.

Następnie mamy okno logowania, inny stan. Czynności tutaj to Wstecz i Zaloguj się. Zauważ, że nie klasyfikujemy pól wejściowych jako akcji. Serdecznie zapraszamy do tego. Z mojego doświadczenia wiem, że podczas pracy nad złożonymi systemami, które działają na kilka dziesiątych głębokości, jest to trochę trudne w utrzymaniu, ale w przypadku prostych aplikacji może to być świetne dopasowanie.

Na koniec dochodzimy do pulpitu nawigacyjnego, na którym użytkownik przejdzie po pomyślnym zalogowaniu. Tutaj mamy trzy czynności — możemy utworzyć, edytować lub usunąć wiadomość.

Mamy teraz wystarczającą ilość informacji, aby rozpocząć przepływ użytkowników. Podsumujmy to, co mamy. Notujemy stany produktu. Z tego, co widzimy, są cztery strony:

1. Strona główna
2. Okno logowania
3. Okno rejestracji
4. Deska rozdzielcza

Zapisujemy nasze działania na każdej stronie/stanie, z którym można „wchodzić w interakcję”:

1. Strona główna
   1. Zaloguj sie
   2. Zarejestrować
2. Okno logowania
   1. Zaloguj się
   2. Anulować
3. Okno rejestracji
   1. Do ustalenia (w zależności od produktu)
4. Deska rozdzielcza
   1. Tworzyć
   2. Edytować
   3. Usunąć

Zaczynamy od nazwy produktu , którą można zmienić w celu dostosowania do Twojego środowiska, ale pasuje ona do większości zespołów i ich produktów, a także stanowi dobry punkt wyjścia. Poniżej zauważymy znak zapytania obok Zarejestruj .

Wiele razy natkniesz się na komponent w Agile, który nie jest jeszcze w zakresie lub nie jest planowany w przyszłej wersji. Zwróć uwagę na jego istnienie, ale pozostaw to jako nieznane, dopóki nie otrzymamy więcej informacji.

Rysowanie schematu przepływu

Rysujemy powyższe w XMind, aby wyglądało tak:

Zauważysz, że po prostu koduję kolorami, co jest stanem, a co akcją. Dodałem również wiersz z akcji Anuluj do strony głównej, aby dokładnie przedstawić ten przepływ. Widzimy również dwa warunki, gdy użytkownik wybierze „Zaloguj się”. Chociaż oba trafiają do deski rozdzielczej, nadal chcemy przetestować oba możliwe warunki.

Fajną rzeczą w XMind jest to, że jeśli pracujemy nad dużą, złożoną aplikacją, możemy tworzyć różne poziomy diagramu, więc jeśli chcesz podzielić przepływ na wiele przepływów, ale zachować je połączone, jest to bardzo łatwe dzięki łączeniu tematy na osobnych arkuszach. Możesz wybrać wstawienie hiperłącza, a z wyskakującego okienka kreatora możesz wybrać "Stan", do którego prowadzi akcja. Oznacza to, że jeśli wybierzesz „Zaloguj się” w XMind i pojawi się hiperłącze do „Pulpitu nawigacyjnego”, kursor myszy przeskoczy do „Pulpitu nawigacyjnego”, nawet jeśli znajduje się na innym arkuszu. Całkiem fajne.

To, czego brakuje w naszym przepływie, to etykiety. Nadajemy produktowi etykietę 0, ponieważ jest to źródło przepływu. Następnie dla każdego Stanu (niebieski) dodajemy etykietę S#, dla każdej Akcji (zielona), dodajemy etykietę A# i na koniec do każdego Warunku (niebieskozielony) dodajemy etykietę C#. Każda etykieta musi być niepowtarzalna. Kończymy z poniższym:

Aby śledzić numer, którego ostatnio użyłeś — ponieważ wraz ze wzrostem produktu próba znalezienia największej liczby może być trudna — przechowuję to w głównym temacie przepływu, jak poniżej:

Przechodzimy teraz do części tworzenia przypadków testowych. Skoncentrujemy się na oczekiwanych wynikach, które są prawdopodobnie najważniejszą informacją w przypadku testowym i częścią kryteriów akceptacji funkcji. Dodam tytuł dla każdej sekcji lub testu, a następnie wypiszę pod nim oczekiwane wyniki. Zrobię to tylko dla podzbioru, aby ten artykuł był zwięzły:

Następnie okno logowania:

Następnie akcja logowania:

To naprawdę nabiera kształtu. Zwróć uwagę na dodane testy graniczne i bezpieczeństwa. Możesz nazwać to tak, jak chcesz, w zależności od tego, co jest dla Ciebie najłatwiejsze do otagowania. Czasami taguję tytuł z typem testu, takim jak Security – JS Inject – Email Field, a następnie wypisuję oczekiwane wyniki poniżej.

W większości zespołów zmiany wymagań są kłopotliwe w utrzymaniu. Już nie. Powiedzmy, że właśnie dowiedzieliśmy się, że wszyscy nowi użytkownicy muszą otrzymać okno Ts i Cs i muszą zaakceptować to przed przejściem do swojego pulpitu nawigacyjnego — nie ma problemu. Stan i akcje możemy dodać stosunkowo łatwo, jak poniżej:

Widzimy teraz wpływ dodania nowego stanu. Zauważ, że na początku numeracja może być dziwna, ale o ile pamiętamy, liczby służą wyłącznie do jednoznacznej identyfikacji każdego aktora — podobnie jak klucz podstawowy w bazie danych. Nie zapomnij zaktualizować notatek „Ostatnio używane”, aby śledzić używane numery.

Tworzenie przypadków testowych z Flow

Po tych wszystkich postępach przechodzimy teraz do łatwiejszej części: tworzenia przypadków testowych. Pozwólcie, że podkreślę kilka ważnych punktów. Mamy etykiety dla każdego aktora, mamy tytuły dla każdego testu i spodziewaliśmy się wyników dla każdego testu, z warunkami wbudowanymi jako część naszego przepływu. Brzmi to jak przepis na przypadek testowy, nie zgadzasz się?

Wszystko, co teraz robimy, to kopiowanie i wklejanie tego, co znajduje się w naszym przepływie, do dowolnego narzędzia do zarządzania przypadkami testowymi, witryny Confluence lub dokumentu Excel. Nadal używam starego, dobrego, sprawdzonego Excela. Wszystkie moje przypadki testowe przechowuję w jednym pliku o nazwie „Baseline” – bardzo oryginalnym. Gdy skończę kopiować i wklejać, kończę z poniższym:

Możesz dodać kolumny dla typów testów, statusu testów i konfiguracji testów zgodnie z wymaganiami. Warunki mogą być lepiej ustawione przed akcją „Zaloguj się”, jednak nie ma dobrego lub złego sposobu, aby to zrobić, zależy to od osobistych preferencji i sposobu, w jaki się zorganizujesz.

Jest kilka rzeczy do podkreślenia. Po pierwsze, scaliłem komórki, które dzielą te same informacje — nie ma potrzeby wielokrotnego kopiowania i wklejania, to marnuje czas i jest trudniejsze w utrzymaniu. Kolejną pozycją są kroki. Zauważysz, że dwa z testów mają kroki, które zawierają numery Stanu i Działania. Można to wykorzystać, gdy w zespole masz przepływ jako część SDLC. Wszyscy interesariusze przyczyniają się następnie do przepływu, dostarczając informacje, makiety, podnosząc ryzyko itp. Oznacza to, że podając liczby przepływów, każdy w zespole będzie wiedział, co robić, a jeśli pojawi się nowy członek zespołu, jest to równie łatwe jako „podążaj ścieżką, odnieś się do notatek”.

Pomaga to również w automatyzacji. Każdemu krokowi lub działaniu możesz nadać unikalne odniesienie. Tworząc pakiet automatyzacji o strukturze podobnej do przepływu, przekonasz się, że struktura automatyzacji, którą możesz zbudować, może być wysoce niezawodna, modułowa i kompatybilna w całej aplikacji. Będzie wykorzystywał obiekty stronicowania na większą skalę, co skróci czas konserwacji i umożliwi wymianę funkcji testowych na nowe.

Przepływ może być jedynym źródłem prawdy dla całej dokumentacji produktu, w tym specyfikacji technicznych, specyfikacji funkcjonalnych, przypadków testowych, przejść między stanami, przepływów danych itp.

Uproszczone podejście do planu testów

A co z planami testów?, musisz pomyśleć. To jest proste. Plan testów zawiera sekcje takie jak:

1. Wprowadzenie i zakres
2. Przedmioty testowe
3. Funkcje do przetestowania
4. Funkcje nie do przetestowania
5. Założenia
6. Kryteria wejścia
7. Kryteria wyjścia
8. WBS
9. Zagrożenia
10. Wymagania środowiskowe

Wstęp i zakres będzie dotyczył historii JIRA lub dowolnego zadania lub historii w innym narzędziu. Pozycje testowe to po prostu wersje oprogramowania lub numery zatwierdzenia aktualnie wdrożone w Twoim środowisku, które można połączyć z biletem JIRA lub w trakcie testu w Confluence lub narzędziu do zarządzania testami.

Funkcje, które mają być testowane i Funkcje, które nie mają być testowane , są w rzeczywistości Twoimi przypadkami testowymi. Przypadki testowe wybrane do wykonania w tej historii JIRA to „Funkcje do przetestowania”, a wszystko, co nie jest wymienione, to „Funkcje, które nie będą testowane”. Po prostu wypisz stany i działania, które będziesz testować na bilecie fabularnym.

Założenia, zagrożenia, a nawet wymagania środowiskowe można skompilować w dokumencie lub dodać do komentarzy w JIRA, a czasem nawet umieścić na Confluence i połączyć z historią.

WBS to oszacowanie, które przypisujesz do historii pod względem punktów lub godzin, w zależności od projektu. Kryteria wejścia i wyjścia będą już częścią historii.

Jeśli chcesz być blisko „tradycyjnych” planów testów, możesz poprosić dewelopera lub innych interesariuszy o skomentowanie historii za pomocą Tak lub Nie, aby sprawdzić, czy zgadzają się z planem QA, czy nie. Z technicznego punktu widzenia służy to jako Twój podpis cyfrowy. Wszystko to można dość łatwo uwzględnić w procesie kontroli jakości i pomóc w usprawnieniu dokumentacji kontroli jakości.

Czego się nauczyliśmy?

Przepływ użytkowników przy powyższym podejściu i planach testów usprawnionych w celu korzystania z dostępnych obecnie narzędzi pomoże nam zredukować powtarzalną pracę i pomoże QA w osiągnięciu szybszego czasu realizacji bez poświęcania jakości.

Takie podejście pomogło mi zachować porządek, uwzględnić każdą podstawę i zbudować dokumentację, którą rozumie cały zespół. W Agile to naprawdę się przyda, a najlepsze w tym jest to, że nadal przestrzegamy jednego z podejść Agile: „Uprość dokumentację”.

Mam szczerą nadzieję, że informacje okazały się pomocne. Wszystko zależy od Ciebie jako czytelnika. To nie jest konkretny zestaw zasad, których należy przestrzegać, to tylko wskazówki, które dają Ci pomysły na rozwój i poprawę Twojej wydajności. Żadna technika nie będzie pasować do każdego projektu, zespołu czy produktu, ale może utorować drogę do kolejnego innowacyjnego pomysłu.