Co zespół wie o QA?

Każdy z nas wykonuje swoją pracę najlepiej jak tylko potrafi, niezależnie od tego, którego momentu procesu wytwarzania oprogramowania ona dotyczy. Staramy się, aby nasza praca wnosiła wartość i była ogniwem, które pozwala na wytworzenie produktu zgodnego z wymaganiami oraz specyfikacją. Jednak samo staranie się może nie być wystarczające do osiągnięcia założonego celu i o tym będzie niniejszy artykuł.

Pracując na stanowisku junior testera, doświadczyłam postrzegania mojej osoby jako debugera, czyli narzędzia, którego używają programiści by wnikliwie sprawdzić działanie kodu i ewentualnie go poprawić. Początkowo mało mi to przeszkadzało, bo moja świadomość procesu testowego była niska. Z biegiem czasu, kiedy zaczęłam brać czynny udział w wytwarzaniu dokumentacji testowej, planowaniu testów, pojęłam że ten proces nie kończy się na samym wykonywaniu zaplanowanych przypadków testowych. Aktualizacja dokumentacji testowej zaczęła być trudna ze względu na informacje, które płynęły od klienta, a mnie omijały. Pomijanie mnie --- osoby odpowiedzialnej za kontrolę jakości produktu --- w łańcuchu informacji miało taki skutek, że nie miałam pojęcia o zmianach w kluczowych funkcjonalnościach oraz innych istotnych dla mojej pracy ustaleniach.

W pierwszym momencie moją reakcją na zaistniałą sytuację były czysto ludzkie uczucia, jak złość i frustracja. Po pewnym czasie zaczęłam się jednak zastanawiać i głębiej drążyć temat, starając się uzyskać odpowiedź na pytanie, dlaczego tak się dzieje? Dlaczego dowiaduję się o zmianach po fakcie, kiedy jest już "musztarda po obiedzie", czyli w realiach mojej pracy: zgłoszenie o statusie "Do przeglądu" zostanie przypisane do mnie? Analizując sytuację zaczęłam rozumieć, że nie wynika to ze złej woli, lecz być może z niezrozumienia, niewiedzy, czym jest zapewnienie jakości. Postanowiłam to zmienić, aby usprawnić proces wytwarzania, ulepszyć proces zapewniania jakości i podnieść świadomość dotyczącą QA w całym zespole. W celu upewnienia się, że moja teza --- zespół nie rozumie, czym jest zapewnianie jakości, jest słuszna --- przeprowadziłyśmy ankietę wśród osób zajmujących się dostarczaniem oprogramowania. Wyniki ankiety wraz z jej analizą przedstawimy w dalszej części publikacji, natomiast zanim do tego dojdzie, współautorka niniejszego artykułu --- Karolina Zmitrowicz, wyjaśni samo pojęcie zapewnienia jakości.

Zapewnienie jakości --- czym jest, czym nie jest?

Bazując na obserwacjach rynku IT oraz "zbiorowej wiedzy" społeczności IT, można wysunąć wniosek, iż pojęcie zapewnienia jakości jest w większości mylnie interpretowane. Zarówno rekruterzy, jak i sami pracownicy IT (często właśnie na stanowiskach związanych z QA) mają błędne pojęcie o istocie, zadaniach i celach procesu zapewniania jakości. W wielu przypadkach, w wielu firmach, QA jest utożsamiane z testowaniem produktu i traktowane jako synonim testów. Jest to błędne pojmowanie stanu rzeczy.

Testowanie, jak i zapewnienie jakości są niewątpliwie związane z tematem jakości, jednak każde na nieco inny sposób. Pragnąc wyjaśnić koncepcję zapewnienia jakości, należy spojrzeć na  zagadnienie w nieco szerszej perspektywie i rozpocząć od przedstawienia koncepcji jakości i zarządzania jakością.

Istnieje wiele definicji jakości --- od tych nawiązujących do zgodności z wymaganiami, po definicje skupiające się na wartości rynkowej produktu (https://www.jakosc.biz/definicje-jakosci/) Samo pojmowanie jakości jest przedmiotem wielu analiz, wśród których w szczególności pragnę wyróżnić pozycję "Doktryna jakości" Andrzeja Blikle oraz krótszą, bardziej kompleksową analizę przedstawioną przez współautorkę niniejszego artykułu w publikacji "W poszukiwaniu straconej jakości". Bazując na analizie rynku, zachowań odbiorców produktów i usług, doświadczeniu autorki oraz kompilacji istniejących źródeł związanych z obszarem jakości, w tej ostatniej publikacji zaproponowano następującą definicję jakości:

Jakość --- stopień, w jakim proponowane rozwiązanie dostarcza wartość określonym interesariuszom w ich środowisku biznesowym, technologicznym i kulturowym

Definicja ta kładzie nacisk na dostarczanie wartości --- czyli rzeczywistych, mierzalnych korzyści (niekoniecznie finansowych) --- określonej grupie odbiorców. To właśnie wartość jest determinantem jakości --- nie, jak zdarza się zakładać osobom zaangażowanym w testowanie, wykonane czy niewykonane przypadki testowe i liczba usterek. Informacje o testach czy usterkach rzecz jasna pomagają ocenić poziom dostarczanej wartości i skonfrontować go z pożądanym zakładanym stanem rzeczy, jednak same w sobie o jakości nie informują. Znając już koncepcję jakości, przyjrzyjmy się tematowi zarządzania jakością. Czym jest zarządzanie jakością? Pojęcie, o którym wiele osób słyszało, lecz względnie mało osób rozumie, a jeszcze mniej --- potrafi zastosować w realiach projektowych? Zarządzanie jakością to pewne podejście do zarządzania przedsięwzięciem wytwórczym, którego podstawowym celem jest wprowadzenie metod i środków umożliwiających dostarczenie produktów i usług o określonej (zadeklarowanej) jakości. Warunkiem wstępnym umożliwiającym wdrożenie zarządzania jakością jest oczywiście zrozumienie i zdefiniowanie samego pojęcia jakości --- można się w tym miejscu powołać na słowa przypisywane Demingowi: „Jeśli nie możesz czegoś zmierzyć, nie możesz tym zarządzać". Punktem wejściowym o rozmowy o zarządzaniu jakością jest więc sama definicja jakości. Sam proces zarządzania jakością obejmuje co najmniej kilka elementów. Zgodnie z normą ISO 9001 dotyczącą systemów zarządzania jakością przyjmuje się, że zarządzanie jakością obejmuje cztery główne elementy:

• planowanie jakości,
• zapewnienie jakości,
• kontrola jakości,
• doskonalenie jakości.

Już wstępny rzut oka na wymienione wyżej procesy pozwala w pewien sposób umiejscowić przedmiot niniejszego artykułu --- koncepcję zapewnienia jakości --- w szerszej perspektywie.

Pierwszym elementem procesu zarządzania jakością jest planowanie jakości. Jest to jeden z kluczowych procesów planistycznych realizowanych podczas każdego przedsięwzięcia i powinno być wykonywane równolegle do opracowania planu projektu. Najogólniej planowanie jakości można wyjaśnić jako określenie lub wybór standardów i wymagań jakościowych, którymi musi cechować się wynik przedsięwzięcia (np. produkt informatyczny). Plan jakości określa więc nie tylko pożądaną definicję jakości tworzonego produktu, ale i wszelkie czynności, techniki, metody, narzędzia niezbędne do osiągnięcia tej jakości.

Plan jakości realizowany jest poprzez czynności zapewnienia jakości, rozumiane jako zestaw systematycznych działań pozwalających upewnić się, że spełnimy określone wymagania jakościowe. Zapewnienie jakości jest często wyjaśniane jako czynności umożliwiające „wbudowanie" jakości w dany produkt czy proces.

Kolejny proces zarządzania jakością --- kontrola jakości --- umożliwia systematyczne monitorowanie wyników realizacji prac projektowych celem stwierdzenia czy osiągnięto określone wymagania jakościowe. Elementem kontroli jakości jest więc testowanie, rozumiane jako sprawdzanie zgodności rezultatów prac z przyjętymi założeniami (np. wymaganiami). W przypadku wystąpienia odchyleń od pożądanego stanu, podejmowane są działania korygujące (np. naprawa zgłoszonych defektów).

Ostatnim procesem związanym z zarządzaniem jakością jest doskonalenie jakości. Warto zwrócić szczególną uwagę na to zagadnienie, jest ono bowiem dość często pomijane w przedsięwzięciach IT. Doskonalenie jakości to obowiązkowy element dojrzałego zarządzania jakością --- umożliwia bowiem ciągłe doskonalenie procesów organizacji a tym samym stałą poprawę jakości, zarówno procesów, jak i tworzonych produktów. Samo testowanie, czy nawet zapewnienie jakości nie wystarcza by kompleksowo zwiększyć jakość tworzonych w organizacji produktów --- skupia się bowiem na sprawdzeniu aktualnego poziomu jakości i jego ewentualnej poprawie w drodze napraw. Nie daje to bezpośredniej informacji o źródłach problemów i możliwych usprawnieniach, których wdrożenie pozwoliłoby uniknąć podobnych błędów w przyszłości, innymi słowy: w większości przypadków nie wspiera doskonalenia procesów wytwórczych, a jedynie jednorazowo eliminuje usterki w produkcie.

Z punktu widzenia dojrzałości organizacji pragnącej w przewidywalny, kontrolowany sposób dostarczać wartość interesariuszom (w tym klientom, użytkownikom), istotne jest wdrożenie kompleksowego procesu zarządzania jakością.

Wyniki ankiety

W ankiecie wzięło udział 131 osób, które pracują w branży IT na stanowiskach związanych z wytwarzaniem oprogramowania. W tej liczbie zawiera się 35 programistów, 6 kierowników projektów, 79 testerów oraz 11 osób na stanowiskach, które nie odpowiadają powyższym grupom. Sama ankieta składała się z 10 pytań, z których to 8 pomogło w zweryfikowaniu wiedzy respondentów. Pozostałe 2 to metryczka --- zajmowane stanowisko i przepracowany na nim staż. Większość pytań była pytaniami wielokrotnego wyboru. Ze względu na małą grupę badanych, nie zagłębiałyśmy się w analizę wyników pod kątem stażu pracy. Takie zgłębianie tematu miałoby sens dopiero w momencie, kiedy dla każdej z grup byłoby minimum 100 odpowiedzi. Dopiero taka próbka pozwoliłaby na uzyskanie rzetelnych wyników w kontekście stażu pracy.

Analiza wyników

Pierwszym pytanie brzmiało: Jak rozumiesz pojęcie zapewnienia jakości (QA)?

Na powyższym wykresie widać, że 71% respondentów (bez rozróżniania stanowiska oraz stażu pracy) rozumie zapewnienie jakości jako "Wszystkie procesy, techniki i metody mające na celu upewnienie się, że proces wytwarzania oraz sam produkt spełnia minimalny określony wcześniej poziom jakości". Jednocześnie 60% badanych wskazało na "Testowanie produktu lub jego części (modułu)" oraz 67% "Wszystkie czynności testowe wykonywane w związku z upewnieniem się, że wytworzony produkt będzie miał najwyższą jakość", co jest znacznym zawężeniem spojrzenia na proces zapewnienia jakości, ponieważ odpowiedzi te odnoszą się jedynie do części procesu jaką jest testowanie produktu. 48,9% respondentów zgodziło się ze stwierdzeniem, że zapewnienie jakości to "Tworzenie dokumentacji testowej i wykonywanie testów". Najrzadziej wybieranymi odpowiedziami były: "Przeglądy dokumentacji projektowej" (42%) oraz "Nie wiem" (2,3%).

Kolejne spojrzenie na odpowiedzi dotyczące pytania pierwszego, to klasyfikacja respondentów pod względem stanowiska pracy.

Analizując wykres można dostrzec, że większość grup, z wyjątkiem testerów, odpowiedziała, że zapewnieniem jakości jest "Testowanie produktu lub jego części (modułu)". Drugą najczęściej wybieraną odpowiedzią była "Wszystkie procesy, techniki i metody mające na celu upewnienie się, że proces wytwarzania oraz sam produkt spełnia minimalny określony wcześniej poziom jakości.". Grupa kierowników projektów uważa natomiast, że zapewnienie jakości to "Projektowanie i wytworzenie produktu zgodnego z określonymi wymaganiami jakościowymi".

Pytanie w ankiecie przewidywało możliwość wpisania własnej odpowiedzi. Dwóch kierowników projektów ze stażem powyżej 7 lat skorzystało z tej możliwości i odpowiedziało następująco: "Razem z przeglądami dokumentacji --- przegląd kodu, przegląd testów" oraz "Testy autmoantyczne dla bardziej zaawansowanych projektów" (pisownia oryginalna). Obie odpowiedzi są zawężeniem spojrzenia na rozumienie procesu zapewnienia jakości, bo odnoszą się stricte do czynności testowych i nie wykraczają poza tę strefę. Jeden z testerów ze stażem pracy 1-3 latach udzielił odpowiedzi: "Poszukiwanie potencjalnych zagrożeń, które mogą wpłynąć na produkt oraz jego jakość" (pisownia oryginalna), co jest trafną uwagą, jednak wymienionych czynności należy doszukiwać się w odpowiedzi "Wszystkie procesy, techniki i metody mające na celu upewnienie się, że proces wytwarzania oraz sam produkt spełnia minimalny określony wcześniej poziom jakości". W grupie pozostałych stanowisk pojawiła się odpowiedź od osoby ze stażem 5-7 lat: "Zaznaczona odpowiedz jednak nie zgadzam sie z osiagnieciem minimalnego poziomu jakosci" (pisownia oryginalna). Proces zapewnienia jakości musi zakładać jakieś minimum (minimalny akceptowalny przez interesariuszy poziom jakości), które musimy osiągnąć. Jeśli jest możliwość, budżet i czas należy dążyć do zapewnienie możliwie wysokiego poziomu jakości, co nie zawsze jest łatwe.

Kolejnym pytaniem w ankiecie było pytanie: czym jest koszt jakości? Respondenci w tej kwestii byli w zdecydowanej większości zdecydowani, że jakość to "suma wszystkich kosztów operacyjnych związanych z osiągnięciem jakości" (94,7%). Natomiast niespełna 5% respondentów przyznała, że nie wie czym jest jakość. Natomiast jedynie 0,8% respondentów uważa, że jakość jest kosztem jedynie testowania.

Przyjrzyjmy się teraz rozłożeniu odpowiedzi względem zajmowanego stanowiska

Najbardziej zdecydowane grupy, które jednogłośnie wybrały odpowiedź "Sumą wszystkich kosztów operacyjnych związanych z osiągnięciem jakości", to kierownicy projektów oraz respondenci mieszczący się w grupie "pozostałych stanowisk". Największe wątpliwości mają programiści, którzy najliczniej odpowiedzieli, że nie znają odpowiedzi na to pytanie (14,3%), ale 85,7% programistów odpowiedziało wskazało właściwą odpowiedź. Testerzy, mimo tego, że sami należą do części procesu testowego mieli wątpliwości. Zdecydowana jednak większość, bo aż 97,5%, wiedziała, że "suma wszystkich kosztów operacyjnych związanych z osiągnięciem jakości" jest prawidłową odpowiedzią. Jednak 1,3% odpowiedzi testerów uważa, że jest to koszt testowania i taka sama część przyznaje, że nie wie.

Kolejne pytanie dotyczyło określenia wysokości kosztów zapewnienia jakości.

Większość badanych (69,5%) odpowiedziała, że koszt jakości jest "zależny od etapu projektu, w którym zostają wprowadzone czynności zapewnienia jakości". Kolejną najczęściej wybieraną odpowiedzią było "nie wiem" (9,9%). Na trzecim miejscu, pod względem wybierania, jest "Zwykle zbyt wysoka w stosunku do budżetu projektu" (7,6%). Jest to ciekawe, ponieważ można się domyślać skąd to przekonanie wśród respondentów. Być może projekty, przy których pracują, w szacunkach i budżecie nie są przewidywane czynności zapewnienia jakości. Warto także zwrócić uwagę na kolejną odpowiedź, która uzyskała 5,3% odpowiedzi --- "Mały w przypadku mniejszych projektów, wysoki w przypadku złożonego oprogramowania". Koszt jakości zawsze jest wpisany w koszt projektu. Koszt jakości może być różny głównie w zależności od złożoności projektu, a nie od jego wielkości. Jeśli proces zapewnienia jakości jest dobrze skonstruowany i wpisany w proces wytwarzania, koszt jakości nie powinien być w żaden sposób zaskoczeniem. Jednak 4,6% respondentów uważa, że koszt jakości jest "niemożliwym do ustalenia na etapie realizacji projektu". Natomiast 2,3% respondentów utrzymuje, że koszt zapewnienia jakości jest "niewspółmiernie wysoki w stosunku do możliwych do uzyskania efektów". Spójrzmy jeszcze na odpowiedzi poszczególnych grup.

Na pierwszy rzut oka widać, że testerzy skupili się głównie (81%) na odpowiedzi "Zależy od etapu projektu, w którym zostają wprowadzone czynności zapewnienia jakości", a następną w kolejności, z dużo mniejszym procentem sięgającym 7,6%, była "zwykle zbyt wysoka w stosunku do budżetu projektu". 3,8% testerów określiło koszt jako "niemożliwy do ustalenia na etapie realizacji projektu" oraz tyle samo przyznało, że "nie wie". Pozostałe grupy również w dominującej części opowiedziały się za odpowiedzią "Zależy od etapu projektu, w którym zostają wprowadzone czynności zapewnienia jakości" --- programiści 48,6%, kierownicy projektów 50%, pozostałe stanowiska 63,6%. Programiści przyznali także, że nie wiedzą (28,6%) jaki jest koszt zapewnienia jakości. Trzy grupy: programiści, kierownicy projektów oraz, co ciekawe, testerzy wybrali odpowiedź, że "zwykle zbyt wysoki w stosunku do budżetu projektu". Rozkład procentowy dla tej odpowiedzi kolejno: 8,6%, 16,7%, 7,6%.

5,7% programistów oraz 9,1% stanowisk nie wpisujących się w żadną z grup odpowiedziało, że wysokość kosztów zapewnienia jakości jest "niewspółmiernie wysoka w stosunku do możliwych do uzyskania efektów". Pozostałe stanowiska oraz kierownicy projektów w blisko ⅕ swoich odpowiedzi uznali, że koszt ten jest "niemożliwy do określenia na etapie realizacji projektów". Podobnego zdania jest niewielki (3,8%) odsetek testerów. W odpowiedziach dodatkowych pojawiła się wypowiedź kierownika testów z ponad 7 letnim stażem, który napisał: "W zależności od stopnia skompliwkowania projektu i jego ewentualnego maintenance później. Zakres QA w projekcie nalezy oszacować i uwzglednić w fazie planowania projektu." (pisownia oryginalna). Drugą odpowiedzią autorską była odpowiedź testera ze stażem pracy między rokiem a 3 latami: "W zależności od projektu i podejścia, ale przy dobrym podejściu jest to duży koszt, lecz wciąż niski w porównaniu do kosztów jakie poniesiemy nie zapewniając jakości (kary finansowe, strata klientów, straty związane ze rozdaniem zbyt dużej ilości nagród, itp.)" (pisownia oryginalna).

Kolejne pytanie brzmiało: jaka jest rola zespołu QA w zespole projektowym? A oto w jaki sposób odpowiedzieli respondenci:

Respondenci uważają, że podstawową rolą zespołu QA w zespole projektowym jest "zapewnienie technik, metod i procesów dla osiągnięcia założonego poziomu jakości" (80,2%). Kolejne, najczęściej wybierane odpowiedzi: "Zminimalizowanie ryzyka związanego z niepowodzeniem projektu" oraz "Kontrola jakości prac projektowych", zebrały 58,8%. 48,9% badanych uważa, że zadaniem zespołu QA jest "wsparcie procesu wytwarzania", a 45% "doskonalenie procesu wytwarzania". 5,3% respondentów opowiedziało się za "zarządzaniem procesami kierowniczymi". Najmniej, bo niecały procent, przyznaje, że nie wie jaką rolę pełni zespół QA.

Poniżej znajduje się procentowe zestawienie odpowiedzi z podziałem na grupy.

Programiści postawili w 68,6% na odpowiedź trafiającą w określenie roli zespołu QA, czyli "zapewnienie technik, metod, procesów dla osiągnięcia założonego poziomu jakości". Następną częstą odpowiedzią była "kontrola jakości prac projektowych", która to już określa jedynie część procesu zapewnienia jakości --- testowanie. Na tę odpowiedź postawiło 65,7% badanych programistów, a następnie pojawia się odpowiedź "Zminimalizowanie ryzyka związanego z niepowodzeniem projektu". Ciekawe, że 37,1% programistów odpowiedziało, że rolą QA jest "doskonalenie procesu wytwarzania" oraz 28,6% "wsparcie procesu wytwarzania". Zespół zapewnienia jakości powinien doskonalić proces zapewnienia jakości, który może przekładać się na doskonalenie procesu wytwarzania, jednak sam zespół QA nie doskonali procesów wytwórczych.

Dla kierowników projektów najważniejszym zadaniem QA jest "zminimalizowanie ryzyka związanego z niepowodzeniem projektu" (83,3%). Kolejne dwie odpowiedzi uzyskały wynik 66,7%, a są nimi "Wsparcie procesu wytwarzania" oraz "Zapewnienie technik, metod i procesów dla osiągnięcia założonego poziomu jakości". Połowa badanych kierowników projektów uważa, że rolą zespołu zapewnienia jakości jest "doskonalenie procesu" i równie dużo badanych z tej grupy uważa, że rolą tą jest "kontrola jakości prac projektowych". Zaskakująco spory odsetek badanych odpowiedziało, że rolą QA jest "zarządzanie procesami kierowniczymi" (16,7%).

Testerzy w zdecydowanej większości określili, że rolą QA jest "zapewnienie technik, metod, procesów dla osiągnięcia założonego poziomu jakości". Testerzy także uważają, że "wsparcie procesu wytwarzania" (58,2%), "zminimalizowanie ryzyka związanego z niepowodzeniem projektu" (57%) oraz "kontrola jakości prac projektowych" (55,7%) należą do roli zespołu zapewnienia jakości. Z dwoma pierwszymi nie można się nie zgodzić, jednak ostatnia mówi jedynie o prowadzeniu prac testowych. Sami testerzy w blisko połowie głosów postawili na "doskonalenie procesu wytwarzania" (49,4%). To niespodziewanie wysoki odsetek. Pozostałe stanowiska, nie zawierające się w żadnej z grup, aż 90,9% odpowiedzi postawiły na "zapewnienie technik, metod, procesów dla osiągnięcia założonego poziomu jakości". Kolejną było "Zminimalizowanie ryzyka związanego z niepowodzeniem projektu" (72,7%). Wysoką pozycję zajęła odpowiedź "kontrola jakości prac projektowych" (63,6%), a dalej z takim samym wynikiem 36,4% "wsparcie procesu wytwarzania" i "doskonalenie procesu wytwarzania". Ostatnią wymienioną odpowiedzią z wynikiem 27,3% było "zarządzanie procesami kierowniczymi". Zdaniem jednego z kierowników projektów z ponad 7-letnim stażem pracy na tym stanowisku "Dobra jakość przekłada sie na późniejszy duzy koszt bugfixingu" (pisownia oryginalna). Wypowiedź znalazła się w odpowiedzi na pytanie dotyczące roli zespołu zapewnienia jakości. W tym miejscu znalazła się jeszcze jedna wypowiedź. Tym razem testera ze stażem pracy między 3 a 5 lat: "weryfikacja i monitorowanie wykonania zadań, przewidywanie możilwych miejsc wystąpienia błędów, eksplorowanie aplikacji pod katem możliwych działań użytkownika końcowego w poszukiwaniu luk i błędów" (pisownia oryginalna).

Kolejne pytanie w ankiecie odnosiło się do zadań QA. Respondenci zostali poproszeni o ich wymienienie. Na wykresie zostały zestawione wszystkie odpowiedzi bez rozróżnienia na grupy.

Zadania zespołu zapewnienia jakości także oscylują wokół samych testów. Najpopularniejszą odpowiedzią, która uzyskała 87% była "planowanie testów, wybór warunków testowych, nadzór nad testami, projektowanie i wykonywanie przypadków testowych", kolejna to "Uruchamianie i weryfikacja działania produktu" (72,5%), następna "raportowanie defektów oprogramowania" (69,5%), "monitorowanie procesu i produktów" (68,7%). 64,9% uważa, że zadaniem QA jest automatyzacja, 63,4% "wybór metryk służących do oceny jakości produktu i procesu". Dopiero w tym miejscu pojawiają się odpowiedzi mówiące o tym, co zapewnienia jakości dotyczy, czyli "opracowanie standardów służących zapewnieniu jakości w projekcie/organizacji" (62,6%), "budowanie świadomości pro-jakościowej w zespole" (61,8%). Niewiele ponad połowa (55% oraz 51,1%) uznało "raportowanie informacji o poziomie jakości interesariuszom" i "opracowywanie strategii jakości dla projektu lub organizacji" za leżące w obowiązku zespołu zapewnienia jakości. Tylko 38,2% uznało "wykorzystanie doświadczeń i lessons learned do ulepszania procesów wytwórczych" za zadanie, które QA mogliby wykonywać. Ciekawe, że ⅕ respondentów widzi zespół zapewnienia jakości jako osoby odpowiedzialne za "pozyskiwanie i analizę wymagań interesariuszy". Marginalnymi odpowiedziami, ale takimi, które także widnieją na wykresie są "debugowanie" (11,5%), "ustalanie harmonogramu prac projektowych" (8,4%), "realizacja szkoleń dla użytkowników systemu" (7,6%). 2,3% badanych odpowiedziało, że nie zna zadań QA.

Trzy pierwsze grupy (programiści 82,9%, kierownicy projektów 100%, testerzy 89,9%) uważają, że głównym zadaniem QA jest "planowanie testów, wybór warunków testowych, nadzór nad testami, projektowanie i wykonywanie przypadków testowych". Pozostałe stanowiska na tę odpowiedź postawiły 72,7%. Kierownicy projektów na równi z wspomnianą już odpowiedzią postawili "opracowanie standardów służących zapewnieniu jakości w projekcie/organizacji" (100%). Jednak tej odpowiedzi udzieliło tylko 64,6% testerów i 45,7% programistów. Kierownicy projektów wysoko punktowali "Uruchamianie i weryfikację działania produktu", "Monitorowanie jakości procesu i produktów" oraz "raportowanie defektów w oprogramowaniu". Wszystkie trzy otrzymały po 83,3%. Testerzy także uznali odpowiedzi "Uruchamianie i weryfikację działania produktu" (74,7%), "Raportowanie defektów w oprogramowaniu" (74,7%) za niezwykle istotne. Natomiast trzecia odpowiedź ("Monitorowanie jakości procesu i produktów") ma 68,4% odpowiedzi, na równi z "automatyzacją testowania". Dla pozostałych stanowisk na równi są "Budowanie świadomości pro-jakościowej", "planowanie testów, wybór warunków testowych, nadzór nad testami, projektowanie i wykonywanie przypadków testowych" oraz "Uruchamianie i weryfikację działania produktu" (72,7%). Sami programiści i kierownicy projektów nie widzą w zadaniach QA "budowania świadomości pro-jakościowej". Ta odpowiedź jest u programistów na poziomie 45,7% a u kierowników projektów 33,3%. Podobnie "wykorzystanie doświadczenia i lessons learned do ulepszenia procesów wytwórczych" plasuje się dla obu wymienionych wyżej grup.

Pytaniem następnym postawionym przed respondentami było: O czym powinno się informować zespół QA?

Najczęściej wybieranymi odpowiedziami były kolejno "o zmianach wymagań" (90,8%), "o zmianach w zakresie projektu" (90,1%) oraz "o nowych wersjach aplikacji dostarczonych do testów" (84%) . W dalszej kolejności, wciąż często wybieranymi, były opcje: "o planach wydań wersji produktu" (78,6%), "o statusie rozwiązania problemów (defektów)" (77, 9%) i "o zmianach zewnętrznych wpływających na postrzeganie jakości produktu (np. zmiana przepisów)" (74%). Najrzadziej wskazywane odpowiedzi to: "o zawartości umowy" (14,5%) oraz "o kosztach projektu" (7,6%). 3,8% respondentów odpowiedziała, że nie wie o czym należy informować zespół zapewnienia jakości.

Wszystkie grupy uznały, choć w różnym rozłożeniu procentowym, że QA powinni być informowani o "zmianach wymagań" i "zmianach w zakresie projektu". Do tych odpowiedzi w przypadku kierowników projektów należy dodać "o nowych wersjach aplikacji dostarczonych do testów", "o statusie prac deweloperskich", "o zmianach zewnętrznych wpływających na postrzeganie jakości produktu (np. zmiana przepisów)". Wszystkie te odpowiedzi znajdują się na poziomie 83,3% odpowiedzi. Pozostałe odpowiedzi kierowników projektów utrzymują się na poziomie 66,7%. Wyjątkiem jest "o zawartości umowy z klientem", gdzie procent odpowiedzi jest równy 16,7%. Pozostałe grupy odpowiadały bardziej zróżnicowanie, chociaż w miarę zgodnie. Testerzy i respondenci na pozostałych stanowiskach zgodzili się (72,7%), że QA powinni być informowani o "zmianach w harmonogramie", gdzie programiści odpowiedzieli na to pytanie jedynie w połowie (51,4%). Na poziomie 72,7% uplasowała się także odpowiedź "o statusie prac deweloperskich" w przypadku pozostałych stanowisk, testerzy 73,4%, a programiści 48,6%. Testerzy i pozostałe stanowiska bardzo podobnie, z różnicą jednej setnej, opowiedziały się za "o statusie prac analitycznych" (54,4%, 54,5%). Tę odpowiedź warto byłoby uszczegółowić, by dowiedzieć się, jakich konkretnie informacji oczekują od analityków biznesowych testerzy. Programiści natomiast nie uznali tej informacji za aż tak znaczącą --- w tej grupie widnieje w tym miejscu procent 31,4%. Najrzadziej wybieranymi odpowiedziami dla wszystkich grup były: "o zawartości umowy z klientem", "o kosztach projektu". 11,4% programistów oraz 1,3% testerów odpowiedziało, że nie wie o czym powinni być informowani pracownicy działu zapewnienia jakości. W tym pytaniu pojawiła się dodatkowa odpowiedź jednego z testerów ze stażem pracy między 3 a 5 lat. Brzmi ona następująco: "Zespół QA powinien mieć najlepsze informacje o aktualnych wyaganiach aby zapewnić, że produkt odpowiada na potrzeby oraz że jest jak najwyższej jakości względem tych potrzeb" (pisownia oryginalna).

Ostatnie pytanie było pytaniem otwartym i brzmiało: Jaką wartość wnosi zespół zapewnienia jakości do projektu/organizacji? Na to pytanie odpowiedziało jedynie około połowy respondentów (47%). Spora ich część odnosiła się stricte do samych testów. Oto kilka z nich (pisownia oryginalna): "Testujemy produkt, określamy, czy są błędy, ewentualnie sugerujemy, co można by usprawnić", "im częściej wypuszczana jest nowa wersja, tym mniejsze pawdopodobieństwo wprowadzania błędów niezwiązanych bezpośrednio z zakresem zmian w releasie", "Wykrywa defekty oprogramowania, zanim zostanie ono wypuszczone na produkcję", "Informacje o jakości produktów oraz listę błędów.". Pojawiały się też inne głosy (pisownia oryginalna): "Buduje projakościową świadomość w organizacji, wspomaga wytwarzanie lepszego produktu, zmniejsza ryzyko wytworzenia wadliwego produktu, usprawnia procesy, pośrednio wpływa na większe zadowolenie klienta ", "Zespół QA wnosi niesamowitą wartość do projektu --- stoi na straży jakości, tworzy atmosferę szacynku dla produktu, klienta i pracy całego zespołu biorącego udział w projekcie.", "Zmniejsza prawdopodobieństwo niepowodzenia projektu; pomaga zmniejszyć koszty wynikające z błędów w projekcie (w tym większym stopniu, im wcześniej zostanie włączony w prace projektowe).", "Zwiększenie odpowiedzialności za jakość w całym zespole/organizacji.". Większość wypowiedzi, które nie dawały nacisku na samo testowanie pochodzi od testerów i oni też chętniej odpowiadali na to pytanie.

Na zakończenie chcemy pokazać jaki procent badanych pracował kiedykolwiek z osobami na stanowisku QA.

Wnioski

Na początku artykułu została postawiona teza. Pozwolę ją sobie w tym miejscu przypomnieć --- zespół nie rozumie, czym jest zapewnienie jakości. Wyniki badania pokazują, że zespoły mimo, że raczej rozumieją czemu służy proces zapewnienia jakości, to jednak pomijają składowe tego procesu i patrzą na samą kontrolę jakości jako zapewnienie jakości, co jest błędne. Często sami testerzy nie dostrzegają rozpiętości procesu zapewnienia jakości, chociaż to właśnie po nich można by się spodziewać najszerzej wiedzy na ten temat.

Największym zaskoczeniem jest niewątpliwie fakt, że zespoły projektowe widzą w osobie odpowiedzialnej za zapewnienie jakości wiele funkcji, których ta osoba nie reprezentuje. W tym wszystkim pomijane jest budowanie świadomości pro-jakościowej, doskonalenie procesu zapewnienia jakości, co naturalnie wymusza na organizacji wprowadzenie standardów, a właśnie to działanie przekłada się na ulepszenie procesu wytwórczego.

Jedynym rozwiązaniem dla takiego stanu rzeczy jest uświadamianie zespołu na temat zapewnienia jakości, dbanie o komunikację w zespołach. Dobrym punktem wyjścia dla lepszego zrozumienia roli i zadań osób na stanowiskach związanych z zapewnieniem jakości, jak i pozostałych członków zespołu, może być stworzenie macierzy odpowiedzialności, która w jasny i precyzyjny sposób określi stanowiska w organizacji i powiązane z nimi zakresy odpowiedzialności, a tym samym rozwieje wszelkie wątpliwości, nakreślając obraz działu zapewnienia jakości wszystkim pracownikom.

Wracając do słów, które zostały napisane na samym początku, samo staranie się by nasza praca dawała wartość, to jeszcze mało. Ważne jest by patrzeć na procesy jako całość, a odpowiedzialności zespołu powinny być jasno nakreślone, by nie było wątpliwości i domysłów. W przeciwnym razie odpowiedzialność się rozmyje, a procesy nie będą ulepszane.