Proces testowy a zapewnienie jakości – Quality Assurance i Quality Control
Artykułów o samym procesie Quality Assurance było już wiele, natomiast czy przypadkiem nie utraciliśmy zrozumienia tego terminu? Odnoszę wrażenie, że wokół projektów IT krąży informacja, która przedstawia, że za zapewnienie jakości oprogramowania w projekcie odpowiada elitarna jednostka „Quality Assurance”, w skład której wchodzą tylko testerzy oprogramowania. Dodatkowo działy HR potęgują stwierdzenie poszukując: „QA Specialist” i oferując im wykonywanie testów i zgłaszanie defektów.
Czytając poniższy artykuł:
- Dowiesz się, jakie są różnice pomiędzy Quality Assurance (QA) a Quality Control (QC)
- Poznasz propozycję zakresu czynności w projektach IT, które przybliżą tematykę QA i QC
Różnice pomiędzy procesem Quality Assurance a Quality Control
Z czego mogą wynikać wspomniane wyżej różnice? Otóż przede wszystkim Quality Assurance obejmuje swoimi aktywnościami wszystkie czynności w pracach projektowych. Rozpoczynając od współpracy z klientem (transparentność w komunikacji), określeniu ról i odpowiedzialności w zespole (definicja sposobu pracy, komunikacja, określenie procesu wytwarzania oprogramowania), kończąc na definiowaniu wymagań i cyklu ich życia.
Proces obejmuje wszystkich uczestników projektu, dając im możliwość wpływu na kształt i definicję jakości. Dzieje się to na podstawie kontekstu projektu, jego wartości biznesowej. Warto pamiętać o możliwości mierzenia i ocenianiu jednocześnie jakości oprogramowania.
Proces QA jest działaniem prewencyjnym, zorientowanym w dużej mierze na cały proces wytwórczy zarówno w firmie, jak również w stosowanym projekcie.
Natomiast Quality Control koncentruje się w dużej mierze na poszukiwaniu błędów/nieprawidłowości w działaniu aplikacji, poprzez testowanie oprogramowania na różnych poziomach testów i typach. To czynności, które weryfikują i walidują produkt pod kątem zgodności z wymaganiami i oczekiwaniami użytkownika. W dużej mierze odpowiedzialność spoczywa na roli testera oprogramowania. Jest czynnością detekcyjną.
Ilustracja poniżej, pokazuje proporcje pomiędzy czynnościami wokół testowania oprogramowania, a całym procesem zapewnienie jakości.
Inne spojrzenie na proces Quality Assurance
Schemat ten może posłużyć jako „StarterPack” w zakresie zrozumienia procesu Quality Assurance i roli testera. Nie będzie receptą na każdą sytuację, ale może pomóc w zwróceniu uwagi na zapewnienie jakości przez pryzmat zwiększonej aktywności działań w projekcie.
Zacznijmy od pracy z wymaganiami. (Więcej o terminie „3 Amigos” znajdziesz tutaj).
W kontekście jakości oprogramowania, musimy mieć na uwadze początek bliskiej współpracy pomiędzy 3 Amigos. Pojawiają się tutaj 3 role, których charakterystyka została przedstawiona poniżej:
1. Analityk biznesowy – ta rola może być zamienna, na pewno musi być to osoba, która jest związana z biznesem np. ProductOwner.
2. Programista.
3. Tester oprogramowania.
W opisanym modelu, 3 osoby spełniające powyższe funkcje, współpracują razem przy definiowaniu Wymagań (Story). To ważny moment zwrócenia uwagi na szczegół, że każda ze stron przedstawia swój punkt widzenia oraz jak rozumie poszczególne funkcjonalności (zderzenie wizji na temat Wymagania). Na tym etapie pojawia się szybki feedback i wzajemne zrozumienie. „Nie rozmawiamy po zaimplementowaniu funkcjonalności, tylko przed”. Takie działania mają duży wpływ prewencyjny w projekcie i często ujawniają wiele ryzykownych sytuacji, które jeszcze nie zmaterializowały się, więc koszt ich eliminacji może być niższy.
Przykładowe pytania np. z perspektywy testera oprogramowania:
– Do czego klient potrzebuje tej funkcjonalności
– Jak wyglądają makiety, albo czy są 🙂
– Czy nowe wymaganie, wpływa na inne komponenty w aplikacji
Oczywiście każda ze stron będzie miała inny zestaw pytań. W efekcie powinno pojawić się wspólne zrozumienie tego, co mamy dostarczyć, jaką wartość.
W wyniku takiego spotkania powstają zrozumiałe wymagania, forma natomiast jest już mocno zależna od kontekstu, zespołu. Tutaj dowiesz się, jak 3 Amigos może wyglądać w praktyce.
Gdy już wiemy, co powinno zostać dostarczone oraz co ma być wynikiem pracy, przechodzimy płynnie do etapu implementacji wymagań. Na tym etapie możemy użyć wielu metod poprawiających jakość oprogramowania, poczynając od dobrych praktyk w zakresie projektowania, pisania aplikacji poprzez zestaw czynności zorientowanych wokół testów:
– pokrycie testami jednostkowymi % zakresu kodu,
– przegląd kodu i testy integracyjne włącznie,
Ciekawy zakres tego etapu prac, to włączenie piramidy testów automatycznych, która może nieco zmienić kształt i zakres naszych testów.
Kolejnym miejscem w procesie są aktywności, które najczęściej przypadają dla szeroko rozumianych testerów oprogramowania. Jest to zbiór aktywności w zakresie weryfikacji/walidacji oprogramowania, pod kątem wspomnianych wymagań, jak również obszarów z zakresu charakterystyk jakościowych (np. Wydajność, Bezpieczeństwo).
Co dalej?
Proces Quality Assurance to coś więcej, niż tylko testowanie oprogramowania. Warto mieć to z tyłu głowy i dzielić się tą odpowiedzialnością z całym zespołem. Zapraszając i angażując ich do definiowania czynności wokół jakości oprogramowania tak, aby nasi klienci mogli być zbliżeni do motta Gucci: „Jakość pamięta się dłużej niż cenę”.
Jeżeli chcesz się dowiedzieć więcej o temacie zarządzania jakością w IT, zapraszamy do zapoznania się z naszymi publikacjami o agile i praktyce wytwarzania oprogramowania.
