Tworzenie strategii jakości

Opublikowano ponownie za zgodą Kristin i jej znakomitego bloga thinkingtester.

W moim ostatnim wpisie przedstawiłam koncepcję modelu dojrzałości jakości: szeregu zachowań powiązanych z cechami jakości, które pomagają zespołom osiągać różne cechy jakości w tworzonym oprogramowaniu.

Warto zauważyć, że przyjęcie modelu dojrzałości jakości wymaga zaangażowania całego zespołu w zapewnianie jakości.

Jakość nie jest czymś, co należy „przerzucić przez mur” testerom; jest raczej celem wspólnym dla programistów i testerów.

Ale jak sprawić, żeby cały zespół wziął odpowiedzialność za jakość?

Jednym ze sposobów jest stworzenie strategii jakości. Jest to dokument, na który wspólnie zgadza się cały zespół. Potraktujcie go jak umowę opisującą sposób, w jaki zespół będzie tworzyć, testować i wydawać oprogramowanie wysokiej jakości. 

W tym miejscu omówię kilka pytań, na które warto odpowiedzieć w strategii jakości zespołu.

Tworzenie i dopracowywanie historyjek

Pytanie: W jaki sposób zespół decyduje, nad którymi historyjkami pracować? 

Może o tym decydować cały zespół albo wyłącznie właściciel produktu. Priorytetyzację może też przeprowadzać osoba spoza zespołu.

Pytanie: Kto dopracowuje historyjki, aby przygotować je do realizacji? 

Może to robić cały zespół albo jego część. Najlepiej, aby uczestniczyli w tym co najmniej właściciel produktu, jeden programista i jeden tester.

Proces tworzenia oprogramowania

Pytanie: W jaki sposób zespół decyduje, kto zajmie się daną historyjką?

Programiści mogą wybierać dowolną historyjkę z tablicy albo każdy z nich może mieć do wyboru historyjki z określonych obszarów funkcjonalnych. 

W niektórych zespołach testerzy oprogramowania zajmują się również prostymi historyjkami programistycznymi, takimi jak zmiana słów lub kolorów na stronie internetowej albo dodanie identyfikatorów automatyzacji, aby ułatwić automatyzację.

Pytanie: Jak wygląda stan „Gotowe” w przypadku tej historyjki? Czy mierzy się go spełnieniem wszystkich kryteriów akceptacji określonych w historyjce? Czy programista musi dodać testy jednostkowe, zanim historyjkę będzie można uznać za gotową? Skąd wiadomo, że funkcja jest gotowa do testowania? 

W wielu zespołach oczekuje się, że programista przeprowadzi wstępne testy, aby sprawdzić, czy napisany przez niego kod jest gotowy do dalszych testów.

Przekazanie funkcji

Pytanie: W jaki sposób historyjka zostanie przekazana do testowania?

W niektórych zespołach odbywa się to po prostu przez przeniesienie historyjki do kolumny „Testowanie” na tablicy historyjek. W innych zespołach wymagane jest bardziej formalne przekazanie, podczas którego programista demonstruje działającą historyjkę i przedstawia sugestie dotyczące dalszych testów.

Pytanie: Kto wdraża kod w środowisku testowym? 

Może się to wydawać błahostką, ale w rzeczywistości może być przyczyną wielu nieporozumień i dużej straty czasu. Jeśli programista uważa, że wdrożenie kodu w środowisku testowym należy do testera, a tester zakłada, że zrobił to programista, tester może rozpocząć testowanie i nie zauważyć braku nowego kodu, dopóki nie spędzi znacznej ilości czasu na pracy z aplikacją.

Pytanie: Kto będzie przeprowadzać testy? 

W niektórych zespołach programiści mogą podejmować się prostych historyjek testowych, aby zwiększyć tempo pracy nad produktem, podczas gdy bardziej złożone historyjki pozostawia się ekspertom ds. testowania.

Tworzenie planu testów

Pytanie: Kto będzie tworzyć plany testów? W jaki sposób będą tworzone? Gdzie będą przechowywane? 

Niektóre zespoły mogą preferować doraźne testowanie eksploracyjne z minimalną dokumentacją. Inne mogą korzystać z rozbudowanych systemów zarządzania przypadkami testowymi, w których dokumentowane są wszystkie testy produktu. Istnieje też wiele rozwiązań pośrednich. 

Wybrane rozwiązanie powinno być odpowiednie dla zespołu i produktu.

Pytanie: Kto będzie pisać testy automatyczne?

W niektórych zespołach programiści piszą testy jednostkowe, a testerzy testy API i interfejsu użytkownika. W innych programiści piszą testy jednostkowe i API, a testerzy tworzą testy interfejsu użytkownika. Jeszcze lepiej, gdy programiści i testerzy wspólnie odpowiadają za tworzenie i utrzymywanie testów API oraz interfejsu użytkownika. 

W ten sposób programiści mogą wnieść swoją wiedzę dotyczącą zarządzania kodem, a testerzy — swoją wiedzę o tym, co należy testować.

Pytanie: Kto będzie przeprowadzać inne rodzaje testów, takie jak testy bezpieczeństwa, wydajności, dostępności i doświadczenia użytkownika? 

Niektóre większe firmy mogą mieć dedykowanych inżynierów ds. bezpieczeństwa i wydajności, którzy zajmują się tymi testami. Małe startupy mogą mieć tylko jeden zespół programistyczny, który musi odpowiadać za wszystko.

Narzędzia testowe

Pytanie: Jakie narzędzia będą używane do testów manualnych i automatycznych? 

Wybór narzędzi testowych jest bardzo ważny, jeśli chcesz, aby cały zespół był odpowiedzialny za testowanie. Deweloperzy najprawdopodobniej będą chcieli używać narzędzi wykorzystujących ten sam język, którego używają podczas tworzenia oprogramowania, ponieważ minimalizuje to konieczność przełączania kontekstu.

Utrzymanie testów

Pytanie: Kto odpowiada za utrzymanie testów? 

To niesamowite, jak szybko automatyzacja testów może się zdezaktualizować. Jedna zmiana słowa na stronie może oznaczać nieudany test. Najlepiej, aby zespół miał zasadę „jeśli coś zepsujesz, napraw to”, zgodnie z którą testy naprawia osoba, która zatwierdziła kod powodujący ich nieprawidłowe działanie.

Jeśli nie jest to możliwe, przynajmniej upewnij się, że każdy członek zespołu rozumie, jak działają testy i jak je naprawić w sytuacji, gdy potrzebna jest szybka poprawka.

Błędy i dług techniczny

Pytanie: Jak postępujecie z błędami znalezionymi podczas testów? Czy omawiają je deweloper i tester, czy cały zespół ustala ich priorytety, czy też są rejestrowane w rejestrze zadań do późniejszego rozpatrzenia?

Często dobrym pomysłem jest naprawianie błędów od razu po ich znalezieniu, ponieważ deweloper już pracuje w tej części kodu.

Pytanie: Jak zespół będzie radził sobie z długiem technicznym?

Czy zespół ma ustalenie, że w ramach każdego sprintu zajmie się określoną ilością długu technicznego? Niektóre zespoły mają zasadę, zgodnie z którą gdy deweloperowi kończą się historyjki do wykonania, zajmuje się zadaniami związanymi z długiem technicznym z rejestru zadań.

Wydania

Pytanie: Jakiego rodzaju testy przeprowadzicie przed wydaniem? Czy będzie istniał plan testów regresji, który cały zespół będzie mógł wspólnie zrealizować? A co z testami eksploracyjnymi?

Jeden z bardzo wydajnych zespołów, które znam, spotyka się na testy eksploracyjne tuż przed wydaniem. Dzięki tej strategii wykryli trudne do znalezienia błędy i naprawili je, zanim oprogramowanie zostało udostępnione na produkcji.

Pytanie: W jaki sposób oprogramowanie będzie wydawane?

W niektórych firmach za realizację wydania odpowiada kierownik wydań. W innych firmach członkowie zespołu na zmianę wydają oprogramowanie. Bardzo pomocną techniką jest ciągłe wdrażanie, w ramach którego oprogramowanie jest automatycznie wdrażane, a testy są uruchamiane automatycznie w celu zweryfikowania wdrożenia w każdym środowisku, co pozwala wszystkim zaoszczędzić czas i wysiłek.

Powiązany artykuł: JAK URUCHAMIAĆ TESTY DYMNE API W POTOKU CIĄGŁEGO WDRAŻANIA

Utrzymanie

Pytanie: Jak zmierzycie powodzenie wydania? 

Po wydaniu oprogramowania zespołom deweloperskim łatwo jest o nim zapomnieć; jednak to właśnie wtedy użytkownicy zaczynają z niego korzystać. Jakich wskaźników można użyć do pomiaru tego, jak dobrze działa produkt? Możesz śledzić defekty zgłaszane przez klientów albo analizować dzienniki pod kątem nieoczekiwanych błędów.

Pytanie: Jak będziecie monitorować kondycję aplikacji?

Dobrym pomysłem byłoby skonfigurowanie alertów, aby można było dowiedzieć się o problemach z aplikacją, zanim zrobią to użytkownicy. 

Pytanie: Jakich zachowań należy szukać?

Strategie jakości mogą być tak różnorodne jak płatki śniegu. Wyobraź sobie różnice między małym start-upem zatrudniającym dziesięć osób i tworzącym mobilną aplikację czatową a firmą zatrudniającą dwadzieścia tysięcy osób i projektującą oprogramowanie sterujące samolotami. Te dwie firmy będą potrzebować zupełnie różnych strategii! 

Możesz opracować strategię jakości, która dobrze sprawdzi się w twoim zespole, omawiając wspólnie te pytania i tworząc projekt strategii, na który wszyscy możecie się zgodzić.

Aby znaleźć narzędzia i technologie pomocne w procesach, zapoznaj się z tą listą 10 NAJLEPSZYCH NARZĘDZI DO ZARZĄDZANIA DANYMI TESTOWYMI.