Kiedy błąd trafia do środowiska produkcyjnego, przyczyną często nie jest to, że ktoś zapomniał przeprowadzić test. Chodzi o to, że nigdy nie kwestionowano wymagań, dane testowe były błędne lub nikt nie zgodził się, co oznacza „zrealizowane”. Cykl życia testowania oprogramowania rozwiązuje te problemy, nadając testom przejrzystą strukturę od pierwszego wymagania do raportu końcowego.

W tym przewodniku opisano każdą fazę, a następnie omówiono jedną ilustracyjną cechę obejmującą wszystkie z nich: stronę logowania, która blokuje konto po pięciu nieudanych próbach. Źródła nie są w pełni zgodne co do liczby faz. Zobaczysz modele z siedmioma lub ośmioma, ale przeważnie dzielą tę samą pracę inaczej. Używamy powszechnie nauczanej wersji sześciofazowej.

Co to jest STLC?

STLC to zdefiniowana seria działań testowych przeprowadzanych w celu potwierdzenia, że ​​oprogramowanie spełnia jego wymagania. Każda faza ma cel, dane wejściowe i wyniki, dzięki czemu testowanie jest zaplanowane i identyfikowalne, a nie improwizowane na końcu.

Korzyści są praktyczne. Testerzy angażują się wcześnie, gdy defekty są tańsze w naprawie. Wysiłek wiąże się z najwyższym ryzykiem. A kiedy menedżer pyta „czy jesteśmy gotowi na zwolnienie?”, zespół może odpowiedzieć, przedstawiając dowody.

Sześć faz STLC w skrócie

Kryteria wejścia to warunki, które muszą zostać spełnione przed rozpoczęciem fazy. Kryteria wyjścia to warunki, które muszą być spełnione przed zakończeniem. Powstrzymują zespół od na przykład przeprowadzenia testów na uszkodzonej kompilacji i marnowania dnia.

Faza 1: Analiza wymagań

Testerzy badają wymagania, aby dowiedzieć się, co można przetestować, a co jest niejasne. Jest to często najtańsze miejsce, w którym można zapobiec błędom, ponieważ pytanie kosztuje znacznie mniej niż poprawka produkcyjna.

• Wpis: dostępne są dokumenty dotyczące wymagań lub historie użytkowników.
• Działania: identyfikacja potrzeb funkcjonalnych i niefunkcjonalnych, zadawanie pytań, ocena ryzyka i decydowanie, co można zautomatyzować.
• Wyjście: udzielane są odpowiedzi na pytania otwarte i uruchamiana jest macierz identyfikowalności wymagań (RTM).
• Elementy dostarczane: lista wymagań, które można przetestować, oraz RTM.

Przykład logowania. Historia mówi „zablokuj konto po pięciu nieudanych próbach”. Dobry tester pyta: pięć w jakim okresie? Jak to jest odblokowane? Czy pomyślne logowanie resetuje licznik? Jaki komunikat się wyświetla? Każda odpowiedź staje się czymś, co można przetestować.

Faza 2: Planowanie testów

Zespół decyduje o zakresie, podejściu, ludziach, narzędziach, harmonogramie i ryzyku. Przewód testowy zwykle jest właścicielem tej fazy.

• Wpis: analiza wymagań i wstępna ocena ryzyka.
• Działania: zdefiniuj zakres, oszacuj nakład pracy, wybierz narzędzia, przypisz role i ustal kryteria wyjścia na późniejsze fazy.
• Wyjście: plan testów zostaje sprawdzony i zatwierdzony.
• Elementy dostarczane: plan testów i szacunki nakładu pracy.

Przykład logowania. Zakres: zasady blokowania, resetowanie i komunikaty o błędach w internecie i na urządzeniach mobilnych. Poza zakresem: jednokrotne logowanie obsługiwane przez inny zespół. Największym ryzykiem jest blokowanie prawdziwych użytkowników, więc to oni przyciągają najwięcej uwagi. Jeśli nie masz pewności, czym plan różni się od strategii, przeczytaj plan testowy a strategia testowa.

Faza 3: Opracowanie przypadku testowego

Tutaj testerzy piszą szczegółowe przypadki testowe, skrypty automatyzacji i dane testowe.

• Wpis: zatwierdzony plan testów i stabilne wymagania.
• Działania: pisanie i przeglądanie przypadków testowych, przygotowywanie danych, tworzenie skryptów automatycznych kontroli i aktualizacja RTM.
• Wyjście: przypadki testowe i dane zostały sprawdzone i gotowe.
• Elementy dostarczane: przypadki testowe, skrypty i dane testowe.

Zauważ, że TC-01 i TC-02 testują obie strony granicy, co wynika bezpośrednio z analizy wartości granicznych. Więcej informacji na temat dobrego pisania tych przypadków znajdziesz w jak pisać przypadki testowe.

Faza 4: Konfiguracja środowiska testowego

Testy wymagają realistycznego miejsca do przeprowadzenia: odpowiednich serwerów, danych, kont, przeglądarek i dostępu do sieci. Ta faza często przebiega równolegle z fazą 3 i może być obsługiwana przez programistów lub zespół DevOps.

• Wpis: plan testów, przegląd architektury i wymagania środowiskowe.
• Czynności: skonfiguruj sprzęt lub kontenery, załaduj dane, skonfiguruj dostęp i zainstaluj kompilację.
• Wyjście: środowisko jest gotowe i test dymu zakończył się pomyślnie.
• Elementy dostawy: środowisko pracy i wynik testu dymu.

Przykład logowania. Staging pobiera konta testowe w znanych stanach, wraz ze skróconym licznikiem czasu blokady, dzięki czemu testerzy nie muszą czekać. Szybki test dymu potwierdza, że ​​logowanie w ogóle się ładuje przed rozpoczęciem pełnego działania. Kontenery pomagają zachować spójność środowisk, jak pokazano w naszym samouczku Docker Compose.

Faza 5: Wykonanie testu

Testerzy przeprowadzają zaplanowane testy, porównują rzeczywiste i oczekiwane wyniki oraz zgłaszają defekty. Naprawione błędy są ponownie testowane, a powiązane obszary poddawane są testom regresyjnym.

• Wpis: przypadki testowe są gotowe, środowisko działa, a kompilacja została dostarczona.
• Czynności: uruchamianie testów, rejestrowanie wyników, rejestrowanie defektów, ponowne testowanie poprawek i aktualizacja RTM.
• Wyjście: przeprowadzane są zaplanowane testy, a defekty są naprawiane lub formalnie akceptowane.
• Dostawy: wyniki testów i raporty o defektach.

Przykład logowania. Błąd TC-04: w przypadku dwóch przeglądarek licznik osiąga tylko cztery. Tester rejestruje błąd, podając jasne kroki i dowody, zgodnie z opisem w jak napisać raport o błędzie. Po naprawieniu problemu TC-04 jest uruchamiany ponownie, a powiązane kontrole logowania przechodzą przez listę kontrolną regresji.

Faza 6: Zamknięcie testu

Ta faza jest często pomijana, a szkoda, ponieważ dzięki niej zespół się rozwija. Zespół ocenia cykl, archiwizuje swoją pracę i zapisuje to, czego się nauczył.

• Wpis: wykonanie zostało zakończone i znany jest status defektu.
• Działania: sprawdzanie kryteriów wyjścia, analizowanie trendów defektów, archiwizowanie zasobów testowych i przeprowadzanie retrospektywy.
• Wyjście: raport zamknięcia został podpisany.
• Efekty: raport zamknięcia i wyciągnięte wnioski.

Przykład logowania. Z raportu wynika, że ​​wszystkie pięć spraw zakończyło się pomyślnie po jednej naprawie. Wniosek jest taki, że współbieżność została przetestowana dopiero późno, więc przyszłe funkcje z licznikami będą uwzględniały ten scenariusz podczas projektowania.

STLC kontra SDLC

SDLC, czyli cykl życia oprogramowania, obejmuje zbudowanie całego produktu. STLC to część skupiająca się na testowaniu i działająca obok niej.

Analiza wymagań w SDLC zasila analizę wymagań w STLC, a rozwój dostarcza elementy wbudowane w wykonanie testu. Testowanie nie musi czekać do zakończenia kodowania. Wczesne rozpoczęcie pracy jest tym, co ludzie mają na myśli, mówiąc „przesunięcie w lewo”.

STLC w Agile i DevOps

Poszczególne fazy mogą wydawać się długim, jednokierunkowym procesem, ale nie muszą tak być. W Agile te same czynności są skracane i powtarzane w każdym sprincie, często w ciągu godzin, a nie tygodni:

• Analiza wymagań polega na udoskonalaniu zaległości za pomocą pytań dotyczących historii użytkownika.
• Planowanie odbywa się podczas planowania sprintu, z lekkimi notatkami zamiast długich dokumentów.
• Projektowanie testów odbywa się równolegle z kodowaniem, często jako kryteria akceptacji i testy automatyczne.
• Konfiguracja środowiska jest zautomatyzowana za pomocą kontenerów i infrastruktury w postaci kodu.
• Wykonanie przebiega w sposób ciągły w potoku CI/CD.
• Zamknięcie staje się częścią przeglądu sprintu i retrospektywy.

Zachowaj to, co przydatne, i skaluj formalności do ryzyka. Małe narzędzie wewnętrzne może wymagać krótkiej listy kontrolnej, podczas gdy system bankowy może wymagać formalnych zatwierdzeń ze względów regulacyjnych.

Typowe błędy

• Późne sprowadzanie testerów. Błędy znalezione w wymaganiach są znacznie tańsze niż te znalezione po wydaniu.
• Niejasne kryteria wyjścia. Bez nich terminy podejmują decyzję za Ciebie.
• Testowanie w złym środowisku. Awarie spowodowane złymi danymi lub konfiguracją marnują czas i podważają zaufanie.
• Pomijanie zamknięcia. Następnie zespół powtarza te same błędy w następnym cyklu.
• Podążanie zbyt rygorystycznie. STLC jest przewodnikiem. Ciężkie dokumenty nie oznaczają automatycznie lepszej jakości.

Podsumowanie

Cykl życia testowania oprogramowania to po prostu zdyscyplinowana odpowiedź na sześć pytań: co testujemy, jak, w jakich przypadkach, gdzie, co się stało i czego się nauczyliśmy? Przyjrzyj się swojej następnej funkcji i sprawdź, które z tych pytań Twój zespół zwykle pomija. Naprawienie tej jednej luki prawdopodobnie da ci największy zysk.

Najczęstsze pytania

Ucz się dalej