Czy QA jest konieczne na wczesnym etapie planowania projektu?

QA na wczesnych etapach projektu

Na sukces projektu wpływa wiele czynników, a jednym z kluczowych jest solidny plan już na etapie wstępnym. Dlatego coraz więcej członków zespołu dołącza do pracy wcześniej — nie tylko analitycy, ale też developerzy i QA Engineerzy. Każdy wnosi inny sposób myślenia, kompetencje i doświadczenia, co przekłada się na cenne, zróżnicowane spojrzenia na wymagania biznesowe.

Moment włączenia QA zależy od klienta i przyjętej metodyki wytwarzania oprogramowania. W Agile tester zaczyna pracę w określonym momencie cyklu życia oprogramowania, inaczej niż w podejściu waterfall. Wiele zależy od decyzji i budżetu klienta; choć wcześniejsze zaangażowanie QA oznacza dodatkowe koszty, istnieje kilka powodów, dla których to się opłaca.

Jakie korzyści daje zaangażowanie QA na wczesnych etapach projektu?

Zapewnienie najwyższej jakości oprogramowania jest kluczowe — w przeciwnym razie niezadowolenie użytkowników szybko wykorzysta konkurencja. Włączenie QA na wczesnym etapie developmentu pozwala wyprzedzać błędy. Mogą one dotyczyć samej aplikacji, jej projektu albo powstać już podczas zbierania wymagań. Zmiana w liście wymagań lub w projekcie jest prostsza (i tańsza) niż poprawki w kodzie. Wczesna detekcja i naprawa błędów podnosi jakość produktu od startu.

Nawet załatanie wcześniejszej wersji oprogramowania jest nieporównywalnie łatwiejsze i mniej czasochłonne niż naprawy aplikacji na zaawansowanym etapie. Gotowy produkt jest zwykle złożony, więc późniejsze korekty mogą wywołać kolejne usterki. Przebudowa takiego rozwiązania to więcej pracy, czasu i — co za tym idzie — pieniędzy. 

Co QA może zrobić na początku projektu

Uczestniczyć w warsztatach z klientem 

QA można włączyć już podczas warsztatów z klientem. To dobry moment na zadawanie pytań i zbieranie wymagań użytkowników. QA pomoże też wychwycić potrzeby, o których klient jeszcze nie pomyślał, a które są niezbędne do prawidłowego działania aplikacji.

Dla QA Engineera udział w warsztatach Product Discovery to szansa, by poznać klienta i lepiej zrozumieć jego potrzeby biznesowe. To również czas na doprecyzowanie, jak i dlaczego produkt końcowy ma działać. Dzięki temu QA skuteczniej oceni użyteczność aplikacji. Product Discovery to integralny element procesu wytwórczego w Startup House.

Brać udział w analizie wymagań

Podczas analizy wymagań QA Engineer potrafi wychwycić nieścisłości i/lub braki w wymaganiach. Dzięki temu dokumentację można szybko skonsultować z klientem i poprawić. QA może też współtworzyć user stories, dostarczając feedback i kryteria akceptacji.

Zaprojektować strategię testowania

Jeszcze przed startem projektu QA Engineer powinien zaplanować, jaki approach zostanie przyjęty w procesie testowym. Strategia testowania określa, co testujemy, jak to robimy i kto za to odpowiada. W zależności od wielkości projektu, budżetu i podejścia organizacji dobiera się wielkość zespołu testowego. W jednych projektach za planowanie strategiczne odpowiada Test Leader lub Test Manager, a realizacja strategii jest rozłożona na kilku testerów; w innych — jedna osoba łączy planowanie i wykonanie testów.

W ramach strategii QA określa zakres i podejście do testów, definiuje wymagania dla środowiska testowego, dobiera narzędzia oraz planuje sposób i częstotliwość raportowania postępów. Na koniec identyfikuje ryzyka projektowe oraz ustala kryteria wejścia i wyjścia.

Efektem takiego planowania jest test plan, dokument zawierający wszystkie powyższe informacje o procesie testowym w projekcie. Spisanie procesu na starcie sprawia, że dalsze prace przebiegają w sposób systematyczny i uporządkowany.

Udokumentować przepływ procesu

Początek prac to idealny moment, by wprowadzić diagramy przepływu. Taka dokumentacja pomaga wychwycić błędy logiczne i miejsca, w których nie pokryto wszystkich ścieżek decyzyjnych lub pominięto potrzebne funkcjonalności.  Jest też pomocna przy planowaniu całego procesu wytwórczego. Dzięki diagramom zarówno osoby techniczne, jak i nietechniczne lepiej rozumieją projekt.

Diagramy ułatwiają rozmowy z klientem i zrozumienie całości, a dodatkowo mogą stanowić podstawę do kolejkowania user stories do developmentu. Jeśli powstaną odpowiednio wcześnie, pomogą też w ich tworzeniu. 

Przygotować dokumentację testową

Na podstawie wymagań i projektów oprogramowania QA może przygotować większość potrzebnych przypadków testowych. Najlepiej robić to już na starcie, gdy jeszcze nie ma nic do testowania. Podobnie jak przy tworzeniu diagramów procesów, pisanie przypadków testowych potrafi ujawnić luki w logice i wymaganiach: im szybciej je wykryjemy, tym łatwiej je naprawić.

Wczesne przygotowanie dokumentacji testowej ułatwia późniejszą pracę testera. Gdy pojawiają się nowe funkcjonalności, może skupić się na testowaniu i poświęcać na nie większość czasu. Gotowa dokumentacja usprawnia planowanie przebiegów testowych: testów funkcjonalnych, end-to-end, smoke tests oraz testów regresyjnych.

Testować nowe funkcje od razu

Obecność QA Engineera na wczesnym etapie developmentu pozwala natychmiast testować nawet najmniejsze dostarczane fragmenty aplikacji. 

Gdy środowisko testowe z kodem jest gotowe, QA może zaczynać testy. Testowanie poszczególnych modułów nie wymaga działania całej aplikacji — można używać stubów i mocków. Dzięki temu QA sprawdza nowy moduł zaraz po jego powstaniu i wprowadza poprawki bez czekania na resztę systemu. Łatwiej też poprawić moduł, nad którym właśnie pracowano, co jest korzystne także dla developerów. Na tym etapie produkt jest mało złożony, więc takie poprawki nie zagrażają pozostałym elementom aplikacji.

Podsumowanie

Wczesne zaangażowanie QA Engineera umożliwia szybsze wykrywanie błędów i zmniejsza koszty ich naprawy. Lepiej znaleźć niezgodności w wymaganiach — poprawki w projekcie są znacznie tańsze niż zmiany w kodzie aplikacji.

QA wnosi też bezcenną perspektywę podczas rozmów z klientem, więc warto włączyć tę rolę od samego początku. To inwestycja, która zwraca się nie tyle dzięki naprawionym problemom, ile tym, których udało się uniknąć.

W Startup House chętnie dzielimy się wiedzą, więc jeśli chcesz dowiedzieć się więcej, napisz do nas: hello@start-up.house