Quality Assurance (QA), czyli zapewnienie jakości. To zbiór praktyk, procesów oraz narzędzi, mających na celu sprawdzenie i udokumentowanie, że tworzone rozwiązanie informatyczne spełnia standardy jakościowe, a także działa zgodnie z założeniami jego twórców. Oczywiście testy oprogramowania, aplikacji czy stron internetowych nie są nowym procesem, ale wraz z rozwojem technologii również ten obszar ewoluuje. Przyspieszona cyfrowa transformacja sprawiła, że domena QA stała się jeszcze istotniejsza, bo znacznie wzrosły potrzeby organizacji oraz ilość nowo tworzonego lub implementowanego oprogramowania, a także tempo, w jakim to się odbywa. 

„Wpływ na rozwój QA miał oczywiście również silny trend związany z automatyzacją procesów czy pojawieniem się zwinnych metodyk prowadzenia projektów.”

Początki testowania oprogramowania sięgają 1979, kiedy Glenford J. Myers, amerykański inżynier oprogramowania, pracujący wówczas w IBM, po raz pierwszy oddzielił debugowanie od testowania. Od tego czasu działania z zakresu Quality Assurance przeszły bardzo długą drogę. Z biegiem lat ukształtował się cykl produkcyjny oprogramowania, pojawiły się nowe języki, ale też kolejne etapy rozwoju technologicznego – chmura, big data czy teraz AI. Wpływ na rozwój QA miał oczywiście również silny trend związany z automatyzacją procesów czy pojawieniem się zwinnych metodyk prowadzenia projektów. Każda kolejna nowość niosła za sobą nowe potrzeby w zakresie zapewnienia jakości. Obecnie mamy kilkadziesiąt rodzajów i typów testów, które stosowane są w różnym celu i na różnych etapach produkcyjnych. Jednak nie chcielibyśmy skupiać się w tym tekście na wymienieniu ich wszystkich, bo to temat niezwykle rozległy, na inny artykuł. Najbardziej istotne w zapewnieniu jakości jest kompleksowe podejście do całego procesu oraz świadomość tego, co chcemy wykonać i jaki efekt uzyskać. 

Tester strażnikiem wymagań klienta 

W najbardziej tradycyjnym podejściu cykl życia oprogramowania składa się z 6 etapów: planowania, analizy, projektowania, rozwoju, testowania i integracji oraz utrzymania. Jest w nim przewidziana faza testów, ale to nie oznacza, że są one realizowane tylko na tym etapie. Takie właśnie podejście zawsze sugerujemy naszym klientom, zwłaszcza przy projektach, w których kompleksowo zajmujemy się  QA. Zgodnie z metodykami ich prowadzenia i dobrymi praktykami, jest zasadne, aby zespół odpowiedzialny za utrzymanie jakości został zaangażowany w prace już w fazie analizy. Wtedy też analitycy biznesowi omawiają z klientem jego oczekiwania względem tworzonego rozwiązania i przekładają wymagania biznesowe na język techniczny dla zespołu deweloperskiego. Dzięki zrozumieniu założeń biznesowych zespół QA może od samego początku zgłosić uwagi i sugestie oraz błędy w dokumentacji (których usuniecie jest niezwykle tanie), aby od samego początku wybrać odpowiednie rodzaje i techniki testów oraz skupić się na obszarach najbardziej ryzykownych lub istotnych dla klienta. To nie zawsze jest oczywiste, bo pewne założenia mogą wyglądać dobrze „na papierze”, ale sprawdzenie czy działają zgodnie z oczekiwaniami może być niekiedy trudne lub wręcz niemożliwe. Jeśli posiadamy doświadczonych specjalistów z obszaru QA i włączymy ich do projektu na wczesnych etapach ten problem często możemy wyeliminować i zaprojektować rozwiązanie „programowalne” i „testowalne”. Testerzy są tak naprawdę strażnikami wymagań klienta, których rolą jest nie tylko znalezienie błędów i sprawdzenie czy aplikacja działa prawidłowo. Oni de facto mają zweryfikować, że wymagania klienta zostają spełnione w dostarczanym produkcie.  

„Testerzy są tak naprawdę strażnikami wymagań klienta, których rolą jest nie tylko znalezienie błędów i sprawdzenie czy aplikacja działa prawidłowo. Oni de facto mają zweryfikować, że wymagania klienta zostają spełnione w dostarczanym produkcie.”

Po etapach analizy i planowania następuje faza rozwoju, w której zespół developerski przekłada wymagania klienta na kod, a zespół QA tworzy scenariusze testowe. W zależności od projektu, mogą to być testy manualne, automatyczne, testy API, testy backendowe czy inne, które są wymagane w danym przypadku. Już na tym etapie, gdy mamy dostępne środowisko testowe, możemy weryfikować pierwsze dostarczane przez developerów funkcjonalności, aby wychwycić błędy w działaniu lub spełnić wymagania odnośnie funkcji oczekiwanych przez klienta. Potem następuje właściwa faza testowania i integracji, czyli łączymy część kodu w jedno rozwiązanie i możemy przeprowadzić weryfikację całego, gotowego produktu. Ten proces nazywa się System Acceptance Testing. Wykorzystujemy wtedy opracowane wcześniej scenariusze testowe zawierające przypadki testowe które możemy przygotować wspierając się narzędziami takimi jak Microfocus ALM, Azure czy ServiceNow (w tych narzędziach możemy przygotować dokumentację, i przeprowadzamy tam egzekucję testów). Gdy rozwiązanie zostało przez nas sprawdzone, błędy wychwycone i naprawione, jesteśmy gotowi do ostatniego etapu przed uruchomieniem systemu (lub aplikacji), czyli User Acceprance Testing. Są to testy prowadzone przez użytkowników końcowych, czyli naszego klienta, który sprawdza czy produkt jest zgodny z zamówieniem. Ostatni etap to wdrożenie i przejście do fazy utrzymania.  

Oczywiście, przedstawiony wyżej przypadek to tylko teoria, bo każdy projekt jest inny, a dodatkowo cykl został opisany przy założeniu, że stosowane są kaskadowe metodyki prowadzenia projektów. Obecnie, coraz częściej jednak, zwłaszcza w Billennium, wykorzystujemy metodyki zwinne, czyli np. Scrum lub SAFe. Wtedy cykl odbywa się szybciej, z większą częstotliwością, na mniejszych częściach gotowego do oddania oprogramowania i jesteśmy w stanie w zasadzie na bieżąco wykrywać i korygować błędy.  

Cykl, który nigdy się nie kończy 

Cykl życia oprogramowania w zasadzie nigdy się nie kończy, chyba że dany system przestaje spełniać oczekiwania albo powstało nowe i lepsze rozwiązanie. W innym wypadku mówimy, że dane rozwiązanie jest w fazie utrzymania, w której poprawiane są błędy wykryte w późniejszym okresie, dodawane nowe funkcje czy aktualizacje. Praca zespołu QA też wygląda inaczej w fazie utrzymania. Na tym etapie testerzy we współpracy z użytkownikami końcowymi rozwiązują nowo powstałe problemy, ponieważ trudno przewidzieć wszystkie warianty i scenariusze, które doprowadzą do nieoczekiwanych rezultatów lub awarii. Mogą też pojawić się błędy wynikające z przyczyn niezależnych od zespołu developerskiego, np. nowych integracji czy niewłaściwych danych.  Jeśli zaś klient ma nowe potrzeby, np. chce rozbudować aplikację o dodatkowe funkcje lub zintegrować z innymi systemami, wówczas cały cykl wytwarzania oprogramowania zaczynamy od początku. Zespół musi nie tylko przetestować nowe elementy, ale również sprawdzić, czy nie wpłyną one niekorzystnie na to co już posiadamy. W fazie utrzymania wskazane są testy zautomatyzowane ze względu na rozbudowanie i stabilność aplikacji. Ich stosowanie pozwoli na nieustanne weryfikowanie poprawności. Testerzy automatyzujący wykorzystują do tego celu wcześniej przygotowane scenariusze przez testerów manualnych. Oznacza to często bardzo dużą oszczędność czasu. Możemy założyć, że w przypadku małej aplikacji opracowujemy ok. 100 przypadków testowych, które jeden tester manualny przeprowadzi w około 2 tygodnie. Dodamy tutaj, że na ten czas składają się nie tylko działania mające na celu sprawdzenie zgodności z wymaganiami czy wykrycie błędów, ale też przygotowanie dokumentacji. Oczywiście moglibyśmy proces przeprowadzić ręcznie, jednak często nie mamy tyle czasu. Dlatego popularność zdobywają właśnie testy automatyczne, które pozwalają nam zrealizować i udokumentować wspomniane 100 przypadków w 3 godziny. Różnica jest ogromna. Oczywiście przygotowanie testów automatycznych jest bardziej kosztowne, bo wymaga prac stricte programistycznych, ale inwestycja zwraca się dość szybko. Każde kolejne nowe wydanie aplikacji, będzie wymagało przetestowania, więc można będzie wykorzystać gotowe już testy automatyczne do sprawdzenia, np. wpływu nowych funkcji na działanie systemu lub jego wydajność, ale też sprawdzenie tych już istniejących. 

Walidacja – obszar QA w sektorze life science 

Jednym z ciekawych obszarów QA jest walidacja. To proces charakterystyczny dla branży life science, farmacji czy wyrobów medycznych. Stosujemy go w sektorach regulowanych, wszędzie tam, gdzie zachodzi pośredni albo bezpośredni wpływ na zdrowie i życie pacjentów. W przypadku systemów informatycznych mówimy o walidacji systemów skomputeryzowanych (CSV – Computerized System Validation). Będą to np. systemy wykorzystywane w procesach produkcyjnych, pracach badawczo-rozwojowych, badaniach klinicznych. Celem walidacji jest udowodnienie i udokumentowanie, że dane rozwiązanie działa zgodnie z założeniami oraz że spełnia regulacje wyznaczane przez organy nadzorcze, np. FDA w USA czy EMA w Unii Europejskiej. Walidacja jest obecna praktycznie na każdym etapie wytwarzania oprogramowania – od fazy analizy aż po utrzymanie i jest to proces ciągły. W momencie pojawienia się zmian, modyfikacji, aktualizacji, system powinien ponownie przejść certyfikację. Jest to o tyle istotne, że w pierwszej fazie projektu, kiedy zaczynamy określać wymagania, a później projektować dane rozwiązanie, weźmiemy pod uwagę pewne cechy systemu czy aplikacji i jej działania, które niekoniecznie zostaną uwzględnione przez biznes i analityków, a są istotne z punktu widzenia prawa i charakterystyczne dla sektora farmaceutycznego, np. integralność danych, access management czy ścieżka audytu. Walidacja nie jest procesem technicznym – działania te mają dostarczyć dowodów, że rozwiązanie działa zgodnie z założeniami, z uwzględnieniem wymogów regulacyjnych i wyeliminować działania niepożądane zagrażające zdrowiu czy życiu pacjentów.  

„W przypadku walidacji, warto też wspomnieć o pewnej zmianie podejścia, która nastąpiła w ostatnich latach, a mianowicie odejście od wspomnianego CSV na rzecz CSA, czyli Computer Software Assurance.”

W przypadku walidacji, warto też wspomnieć o pewnej zmianie podejścia, która nastąpiła w ostatnich latach, a mianowicie odejście od wspomnianego CSV na rzecz CSA, czyli Computer Software Assurance. CSV jest odpowiednim narzędziem do stworzenia systemu zgodnego z regulacjami, ale ma pewne wady. Największą jest przeciążenie dokumentacją, której opracowanie pochłania sporo czasu pracy zespołu. Testowane są np. obszary, które tego nie wymagają, bo nie mają pośredniego czy bezpośredniego wpływu na produkt końcowy. Model CSA jest tego przeciwieństwem – w pierwszej kolejności ustalamy, czy dany element jest krytyczny, sprawdzamy wymagania w kwestii zapewnienia jakości, a dopiero wtedy następuje testowanie i opracowanie dokumentacji. To zdecydowanie bardziej efektywne podejście, związane z zastosowanie krytycznego myślenia o procesach i risk based approach, aby optymalizować działania nie tylko walidacyjne, ale także testingowe. 

„Naszym wyróżnikiem jest też praca w modelu follow-the-sun, który pozwala nam na realizację projektów 24/7/365.”

QA w Billennium 

Nasze ponad 20-letnie doświadczenie w branży IT pokazało nam, że firmy na całym świecie mają bardzo zróżnicowane potrzeby względem Quality Assurance, na które staramy się odpowiedzieć swoją ofertą. Realizujemy zarówno procesy zapewnienia jakości kompleksowo, w całym cyklu wytwarzania oprogramowania, ale również dostarczamy naszych specjalistów w ramach staff augumentation, a także realizujemy audyty procesów QA w firmie oraz w projektach. Wszystko zależy od potrzeb klienta i tego, jakiego rozwiązania oczekuje oraz od jego zasobów i możliwości. W Billennium mamy obecnie ponad 230 specjalistów QA i rozwijamy ten obszar od ponad 15 lat. Wśród naszych ekspertów są min. testerzy manualni, automatyzujący, integracyjni, wydajnościowi, specjaliści od testów chmury, ETL, Big Data, walidatorzy systemów skomputeryzowanych czy test leaderzy, którzy organizują QA wewnątrz organizacji naszych klientów. Naszym wyróżnikiem jest też praca w modelu follow-the-sun, który pozwala nam na realizację projektów 24/7/365. Dzięki temu, że posiadamy oddziały i specjalistów w różnych zakątkach świata – w Polsce, Niemczech, Kanadzie, Indiach czy Malezji – praca nad rozwiązaniem dla klienta może być prowadzona praktycznie non stop, w różnych strefach czasowych.