Quality Assurance i Quality Control - testowanie oprogramowania i zapewnienie jakości w pigułce

Quality Assurance (QA) to systemowe działania, które mają zapobiec błędom na wszystkich etapach projektowania produktu.

Jak wygląda proces QA w praktyce?

Działania QA prowadzi się już na początku prac, na długo przed napisaniem pierwszej linijki kodu. Można je podzielić na trzy duże etapy:

A koszty błędów w IT tylko rosną w toku projektu. Według danych z badań IBM oraz amerykańskiego NIST zebranych przez Synopsys, naprawienie błędu krytycznego w oprogramowaniu na etapie wdrożenia jest nawet do 30 razy droższe niż rozwiązanie problemu jeszcze na etapie projektowania!

1. Analiza wymagań – bardzo ważny etap. Zespół QA dokładnie weryfikuje wszystkie oczekiwania wobec produktu – funkcjonalne, techniczne, biznesowe – i wychwytuje w nich potencjalne zagrożenia dla projektu, na przykład sprzeczne lub nieprecyzyjne wymagania.
2. Definiowanie standardów – na tym etapie należy określić zasady obowiązujące w całym cyklu życia oprogramowania. Chodzi tu m.in. o standardy kodowania i tworzenia dokumentacji, wytyczne do zgłaszania błędów, akceptowalne normy jakości i procedury weryfikacji wymagań.
3. Opracowanie strategii testów – przygotowanie planu – co, kiedy i jak będzie testowane – jeszcze przed pojawieniem się gotowego środowiska do audytu.

Jakie są efekty działań QA?

Efektem pracy zespołu QA nie są raporty z błędami, tylko konkretne zasady określające ich wykrywanie:

• plany testów;
• przypadki testowe (test cases), według których sprawdzane będą poszczególne funkcje produktu;
• zestawy standardów jakościowych, które będą punktem odniesienia dla całego zespołu.

Dzięki temu wszyscy wiedzą, jak powinien wyglądać sam proces projektowy i czym jest dobry produkt.

Quality Control (QC) – czyli kontrola jakości – to proces wykrywania błędów w gotowym produkcie. W przeciwieństwie do QA, które koncentruje się na zapobieganiu problemom, metody QC sprawdzają, czy działanie produktu lub usługi jest zgodne z wymaganiami i nie zawiera krytycznych błędów.

Jak wygląda proces QC w praktyce?

Proces QC przeprowadza się na działającym już kodzie; czy to w wersji testowej, czy produkcyjnej. I tutaj również można wyróżnić trzy etapy:

1. Wykonanie testów – dotyczy to zarówno tych manualnych, jak i automatycznych. Testerzy sprawdzają funkcje aplikacji, integracje z innymi systemami, działanie UI czy zachowanie systemu w nietypowych sytuacjach. Większość testów przeprowadza się zgodnie z test cases, chociaż cenne są też testy eksploracyjne, które pozwalają odkryć nieoczywiste błędy.
2. Identyfikacja i raportowanie błędów – stanowią ogromną część pracy testerów. Każdy problem powinien być dokładnie opisany; tester musi pokazać krok po kroku, jak odtworzyć błąd, najlepiej ze zrzutami ekranu lub nagraniami. Konieczne jest też porównanie błędu ze stanem idealnym i określenie jego priorytetu.
3. Retesting – gdy developerzy wprowadzą już poprawki, testy trzeba przeprowadzić jeszcze raz, aby upewnić się, że błąd faktycznie został naprawiony i że nie pojawiły się przy okazji nowe problemy (regresja).

Jakie są efekty działań QC?

Po przejściu przez cały proces QC, testerzy powinni wypracować:

• raporty z informacjami o liczbie wykonanych testów, stopniu ich pokrycia oraz wynikach;
• zgłoszenia błędów (bug reports), uporządkowane i przypisane do odpowiednich osób lub zespołów;
• historię poprawek i retestów.

To wszystko ma ułatwić pracę developerom. Jeśli proces QC będzie dobrze opisany – najlepiej zgodnie z dobrymi praktykami ISTQB – cały zespół będzie dokładnie wiedział, gdzie leżą problemy, gdzie pojawiają się regresje i czy kod jest stabilny przy nietypowych zachowaniach użytkowników albo wysokich obciążeniach.

Oba procesy są do siebie bardzo zbliżone – nawet definicje brzmią całkiem podobnie, jednak różnią się kluczowymi słowami. Błędem jest jednak stawianie QA i QC na równi ze sobą i używanie tych pojęć zamiennie.

Oczywiście nieraz faktycznie trudno ustalić, czy dane działanie należy do Quality Assurance, czy Quality Control, bo obie procedury mają na celu dbanie o jakość oprogramowania. Często adresują te same kwestie, jednak w odmienny sposób. Właśnie dlatego warto zapoznać się z poniższym zestawieniem, obrazującym kluczowe różnice między QA a QC.

Quality Assurance oraz Quality Control nie są opcjonalne. Nie można też określić, czy jeden proces jest bardziej wartościowy od drugiego. QA polega na ustalaniu standardów w celu przygotowania bezpiecznego, skutecznego procesu. Działania QC weryfikują kolejne etapy tworzonego oprogramowania. Oprócz tych procedur w grę wchodzą jeszcze działania z zakresu testowania software’u. Jak one przebiegają?

Test oprogramowania to weryfikacja zgodności funkcjonowania software’u z oczekiwaniami. Ważne jest także dopilnowanie tego, aby oprogramowanie nie miało wad. Ocena konkretnych funkcji wymaga uruchomienia oprogramowania w całości lub tylko jednego z komponentów. Testy pomagają również w identyfikacji błędów, luk i brakujących elementów w odniesieniu do ustalonych wymagań. Proces ten wykonywany jest ręcznie lub przy użyciu zautomatyzowanych narzędzi.

Wyróżnia się kilka kategorii testów software’u. Ich podział potrafi różnić się w zależności od źródeł. Zobacz najważniejsze z nich.

Testowanie funkcjonalne (czarnej skrzynki)

Chyba najbardziej oczywisty typ testów. Testy funkcjonalne sprawdzają, czy system umożliwia użytkownikowi końcowemu wykonanie przewidywanych czynności za pomocą aplikacji. Co ważne, tester ocenia jedynie działanie aplikacji z zewnątrz, z perspektywy użytkownika; w ogóle nie interesuje go kod. Stąd właśnie testy „czarnej skrzynki”.

A jak to wygląda w praktyce? Weźmy prostą funkcję – formularz logowania. Tester będzie musiał sprawdzić kilka scenariuszy:

• Czy gdy wpisze prawidłowy login i hasło, to zaloguje się poprawnie do systemu?
• Czy gdy wpisze błędne hasło lub nieistniejący adres e-mail, system wyświetli komunikat o błędzie i nie przepuści użytkownika?
• Czy po kliknięciu przycisku Zapomniałem hasła zostanie przekierowany na formularz resetowania hasła, gdzie może podać e-mail i otrzymać dalsze instrukcje?

Mamy więc tylko jeden mechanizm, ale trzeba dla niego sprawdzić przynajmniej kilka scenariuszy testowych… i dopiero gdy każdy zakończy się sukcesem, można powiedzieć, że funkcja działa.

Testowanie niefunkcjonalne

Testy niefunkcjonalne koncentrują się nie na tym, co system robi, ale jak to robi. Wyróżnia się m.in.:

• testy wydajnościowe – sprawdzają, jak oprogramowanie działa pod normalnym obciążeniem: czy aplikacja reaguje szybko, czy strona główna ładuje się w mniej niż 2 sekundy, ile operacji można wykonać w danym czasie;
• testy obciążeniowe – określają, jak system zachowuje się przy obciążeniu większym niż zazwyczaj. Chodzi o to, aby znaleźć punkt, w którym wydajność zaczyna spadać i gdy pojawiają się pierwsze problemy po stronie użytkownika;
• testy przeciążeniowe – „ekstremalna” wersja poprzednich testów; sprawdzają, jak software zachowuje się po przekroczeniu zakładanych limitów wydajności;
• testy bezpieczeństwa – oceniają odporność aplikacji na próby uzyskania nieautoryzowanego dostępu, manipulacji danymi czy ataki typu SQL injection. Jeśli zastanawiasz się, czy Twój projekt potrzebuje tego typu testów – wg raportu State of Software Security opublikowanego przez Veracode, w 2023 roku ponad 74% (!) aplikacji webowych w Europie miało przynajmniej jedną lukę bezpieczeństwa z listy OWASP Top 10, czyli z tych najczęściej wykorzystywanych przez hakerów.

Testowanie strukturalne (białej skrzynki)

Testy strukturalne skupiają się – w przeciwieństwie do funkcjonalnych – na samym kodzie programu i pozwalają ocenić, czy ten w całości funkcjonuje poprawnie oraz zapewnia właściwy przepływ informacji. Tester analizuje m.in. pętle, warunki logiczne, instrukcje sterujące i zależności między modułami.

Załóżmy, że mamy fragment kodu, który odpowiada za przetwarzanie koszyka sklepowego. Dla każdego produktu tworzy się pętla, która nalicza cenę, rabat i wartość całego zamówienia. Podczas testu strukturalnego można sprawdzić, co się stanie, gdy koszyk będzie pusty: czy kod nie wyrzuci błędu i czy system prawidłowo rozpozna brak produktów.

Testowanie związane ze zmianami

Jak ocenić, czy wcześniejsze testy oprogramowania pozwoliły faktycznie wykryć i usunąć błędy? Albo czy zmiany wprowadzone przez developerów nie spowodowały nowych problemów? Temu służą:

• retesty – testerzy ponownie przechodzą przez scenariusz testowy i weryfikują, czy developerzy skutecznie naprawili zgłoszone błędy;
• testy regresji – sprawdzają, czy w wyniku zmian w kodzie nie przestały działać wcześniej wdrożone funkcje. Po wprowadzeniu do sklepu, powiedzmy, nowego systemu naliczania rabatów, to właśnie testem regresji sprawdzimy, czy cały proces checkoutu dalej działa poprawnie.

W nowszych modelach projektowych QA i QC zajmują jedne z najważniejszych miejsc. W tych tradycyjnych nie do końca tak było – kontrolę jakości odsuwano raczej na sam koniec, dopiero po zakończeniu developmentu.

Tymczasem w Agile zakłada się, że QA jest integralną częścią całego cyklu rozwoju produktu i trzeba ją przesunąć jak najbliżej początku procesu; o tym mówi koncepcja shift-left testing. Takie podejście ma o tyle dużo sensu, że pozwala wykrywać błędy na bardzo wczesnym etapie prac, plus angażuje w proces zapewniania jakości cały zespół. Podobnie wygląda to z QC. W zwinnych metodykach, zamiast czekać z testami na zakończenie sprintu, testy funkcjonalne i regresyjne przeprowadza się na bieżąco, przy każdej iteracji kodu.

Dostarczenie wysokiej jakości kodu wymaga wielu procedur. Tylko w ten sposób można mieć pewność, że wszystko będzie działać sprawnie. W tym celu warto korzystać z usług profesjonalnych agencji, które dopilnują, by wykorzystywane przez Ciebie oprogramowanie było najwyższej jakości.