QA czy QC

Problem, z którym borykam się praktycznie od początku swojego życia zawodowego jest nazewnictwo. Czy „testowanie oprogramowania” to jest Quality Assurance czy Quality Control.

Chciałbym z góry zaznaczyć, że jeśli mówimy tylko o testach oprogramowania (bez znaczenia czy mówimy o białej czy o czarnej skrzynce, czy też o krzyżówce tych dwóch) to jestem zwolennikiem Quality Control.

Quality Control czyli po polsku „kontrola jakości” jest procesem kontrolowania jakości oprogramowania (bo o takim kontekście mówimy). W żaden sposób nie wpływa ten proces nie wpływa na jakość a jedynie kontroluje ją, w znaczeniu mierzy poprzez wykonywanie procedur testowych na danym oprogramowaniu.

Quality Assurance czyli po polsku “zapewnienie jakości”, zapewnia tą jakość poprzez implementację rozmaitych rozwiązań, narzędzi czy procesów. QA ma o wiele większy wpływ na „zwiększanie” lub „zmniejszanie” jakości poprzez nakładanie miar, dokonywanie audytów. Czyli Zapewnianie jakości określa kontrolę jakości ale nie odwrotnie.

Szukając porównania do tych dwóch aktywności doszedłem do takiego wniosku:

„Zapewnianie jakości ma się do kontroli jakości tak jak klimatyzacja do termometru. Termometrem możemy jedynie zmierzyć temperaturę powietrza natomiast na podstawie tego pomiaru klimatyzacja może podwyższyć lub obniżyć temperaturę powietrza.”

Oczywiście nie wiem czy jest to do końca słuszne spostrzeżenie. Jakkolwiek istotne dla mnie jest aby kierownicy projektów zrozumieli, iż testy w żaden sposób nie „dodadzą” lub nie „dostarczą” jakości do testowanego oprogramowanie. Testy jedynie zmierzą tą jakość przy pomocy miar zdefiniowanych przez dział testów (w mojej opinii gorsze wyjście ale bardziej popularne) lub stworzonych w oparciu o firmowe kryteria i narzucone przez dział „Zapewniania jakości”.

Przy tworzeniu działów testów – co wydaje się pierwszym krokiem w kierunku jakości – w firmach, naturalnym wydaje się wybranie ścieżki „czarnej skrzynki”. Dzieje się tak z różnych względów, których nie będę tutaj omawiał. Ja uważam, ze o wiele elastyczniejszym rozwiązaniem byłoby wprowadzenie działu zapewniania jakości – nawet w postaci komórki jednoosobowej.

Odpowiedź na pytanie „dlaczego” jest bardzo prosta. Jeśli wyposażymy tą komórkę w odpowiednie upoważnienia na poziomie organizacji, będzie ona w stanie wykreować „zachowania testujące” nawet bez konkretnego działu testów.

Nazywanie działów testujących oprogramowanie jest niepoprawne – moim zdaniem – z wielu względów (wymienię tutaj tylko trzy):

• zamazuje to rzeczywistą potrzebę stworzenia takiego działu w organizacji
• powoduje, iż osoby wykonujące testy skupiają się na „mitologicznej jakość idealnej” gubiąc w swoich obowiązkach kontekst biznesowy
• po pewnym czasie zgłaszają aspiracje do kompetencji do których tak naprawdę nie posiadają zdolności.

Niebezpieczeństwo zamazanie prawdziwej potrzeby takiego działu w organizacji objawia się z reguły zwiększonymi oczekiwaniami do działu testów względem „dodawania” jakości. Taki uproszczony schemat, że im więcej testów tym więcej jakości. Wydaje się przy tym pojawiać fenomen przypisywania działowi testów umiejętności, których on nie posiada (np. wpływanie na kształt developmentu, wpływanie na jakość produktów developmentu) co prowadzi o zaostrzania metryk przyjmowania oprogramowania do testów tworzonych przez samych testerów co finalnie spowalnia proces wytwarzania oprogramowania.

Niebezpieczeństwo mitologicznej jakości idealnej objawia się w tym, iż testerzy zaczynają fantazjować na temat cudownych procesów (których nota bene nigdy nie zbudują) zapewniających im komfort spędzania czasu przy projektowaniu bardzo wyrafinowanych i chytrych przypadków testowych, znajdujących głęboko ukryte i bardzo poważne defekty. Powoduje to, odwrócenie ich uwagi od rzeczywistych zadań związanych z projektowaniem i wykonywaniem przypadków testowych w pierwszym rzędzie sprawdzających czy system spełnia wymagania i w drugim rzędzie czy system spełnia normy.

Niebezpieczeństwo zgłaszania nieuprawnionych aspiracji do kompetencji objawia się zaostrzaniem oczekiwań co do jakości oprogramowania, próba kreowania sztucznych procesów w żaden sposób nie sprzęgniętych z logiką biznesową organizacji ani jej potrzebami. Skutkuje to „wyorbitowaniem” zespołu testów poza kontekst biznesowy.