„Czy testować nie może programista podczas pisania kodu ? Po co dodatkowy zespół testerów.” – To pytanie, które pojawia się nie powinno, a jednak czasami się pojawia. Co robi tester, dlaczego jego rola jest ważna podczas wytwarzania oprogramowania i czym tak naprawdę jest ten dział QA dowiesz się z tego artykułu. Zapraszam do lektury.
- QA – co to właściwie takiego ?
- Podział ról QA
- Czy ja potrzebuję tak dużego zespołu ?
- Ale… przecież programista też testuje ?
QA – co to właściwie takiego ?
QA (Quality Assurance) to zespół osób, które dbają o to, aby dostarczone oprogramowanie było wolne od wad oraz spełniało wymagania i założenia klienta. Kiedyś spotkałem się, ze stwierdzeniem, że w QA pracują osoby, które są adwokatem klienta -> doszukują się wszelkich wad, nie tyko funkcjonalnych ale też i logicznych, i nie odpuszczają dopóki one nie znikną. Mówiąc w skrócie Quality Assurance dba o to, aby klient otrzymał produkt najlepszej jakości, z którego będzie zadowolony – nie tylko w momencie odbioru, ale też podczas codziennego użytku.
Dział QA od samego początku jest zaangażowany w projekt. Menadżer zespołu bardzo dobrze zna dokumentację projektu oraz założenia i wymagania klienta. Codzienna praca QA to ciągła analiza oprogramowania oraz jego testowanie, zgodnie z wcześniej przygotowanymi wytycznymi. Testerzy tworzą dokumentację znalezionych błędów oraz sprawdzają czy te zgłoszone zostały już poprawione. Ściśle współpracują z programistami oraz analizują pokrewne rozwiązania, aby móc zgłaszać pomysły usprawniające pewne procesy zachodzące w aplikacji.
Do główny zadań QA możemy zaliczyć:
- Analiza wymagań projektowych
- Tworzenie planów i scenariuszy testów
- Realizacja testów
- Dokumentowanie znalezionych wad
- Weryfikacja naprawionych wad
- Zgłaszanie i wdrażanie rozwiązań polepszających jakość
Podział ról QA
W zależności od wielkości projektu QA można podzielić na różne role, tak aby trzymać jak największą kontrolę nad prowadzonymi testami oraz optymalizować cały proces. Im większy projekt, tym bardziej rozbudowany zespół. Wśród głównych ról możemy wyróżnić:
Analityk testów
Odpowiada za analizę wymagań (testy statyczne). Jego zadaniem jest sprawdzenie jakie są wymagania wszystkich funkcjonalności i sprawdzenie czy są one kompletne aby zrealizować oczekiwania klienta względem produktu
Projektant testów
Tworzy testy i scenariusze testów na podstawie zebranych i opisanych wymagań. Jego głównym zadaniem jest zaprojektowanie czynności, które muszą być wykonane aby sprawdzić każdą funkcjonalność produktu
Wykonawca testów
Realizuje zaprojektowane testy, weryfikuje zgodność działania poszczególnych funkcjonalności i dokumentuje wszelkie znalezione niedoskonałości w celu zlecenia ich poprawy
Menadżer testów
Jest osobą, która spina wszystkie pozostałe role w całość. Odpowiada za sukces lub porażkę przeprowadzanych testów, weryfikuje deadline’y oraz czasochłonność wszystkich zadań.
Jak widzisz, testy to nie tylko przejście przez projekt i sprawdzenie czy „na oko” wszystko gra. Proces testowania, aby był wykonany prawidłowo, wymaga złożonych operacji, które są projektowane i realizowane przez zespół osób. Tylko w ten sposób możemy powiedzieć, że przygotowany produkt został przetestowany. Tutaj muszę uczulić Cię na jeden fakt – to, że profesjonalny zespół QA przetestuje Twój projekt, to nie znaczy, że jest on w pełni wolny od wad. Wytwarzanie oprogramowania jest zawsze narażone na ludzkie błędy i tego nie da się uniknać. Testy pozwalają natomiast przygotować produkt, który błędów będzie miał jak najmniej, a na pewno w kluczowych dla Ciebie funkcjonalnościach.
Czy ja potrzebuję tak dużego zespołu ?
Oczywiście, że nie. Tak jak napisałem wyżej, wszystko zależy od wielkości projektu. Jeśli planujesz zrealizować system bankowy, który będzie odpowiadał za transakcje ogromnych kwot, musisz liczyć się z tym, że musi być przetestowany pod każdym kątem. W tej sytuacji zespół testerów może składać się nawet z kilkunastu osób. Jeśli tworzysz prostą stronę www, możesz zatrudnić doświadczonego testera, który zarówno zaprojektuje testy, przeprowadzi je i będzie weryfikował timeline – powszechnie znanego jako po prostu „Tester”. Nie będzie w tym nic złego, jeśli zatrudniona osoba ma doświadczenie i wie co robi. Zawsze powtarzam, że zespół trzeba dobierać adekwatnie do wielkości projektu i poziomu ryzyka. Jest różnica gdy najbardziej wrażliwym elementem wytwarzanego oprogramowania jest formularz kontaktowy na stronie, oraz gdy takim elementem jest system kontroli pasa ruchu w samochodzie.
Ale… przecież programista też testuje ?
Owszem. Dobry programista zawsze testuje wykonaną przez siebie pracę. Poza testami manualnymi pisze też między innymi testy jednostkowe, które mają zapewniać, że mniejsze porcje kodu działają poprawnie. Musimy tutaj tylko zrozumieć fakt, że przy jednym projekcie, programistów jest co najmniej kilku. Każdy testuje swoją część. Nikt zatem nie da nam pewności, że wdrożona część kodu nie wpłynie na pozostałą część systemu. Poza tym programista patrzy na te elementy, które wg niego są najbardziej narażone na błędy – patrzy jednostkowo. To tak jakby ktoś chciał się bawić w chowanego sam ze sobą. Tester patrzy na projekt i funkcjonalności wg scenariuszy – jego spojrzenie jest o wiele szersze, dzięki czemu jest w stanie wyłapać więcej błędów i je udokumentować.
Podsumowując – programista jak najbardziej testuje i to jest dobre. Ale jeszcze lepszym rozwiązaniem jest gdy poza programistą, nasze testy połączymy z pracą testera lub zespołu QA.
