Redakcja
Testerzy wiele mówią o tym, jak ich praca związana jest z jakością, a często pojawiające się zastępcze nazwy stanowiska odwołują się do niej:
- inżynier QA (1) quality assurance engineer - inżynier zapewnienia jakości
- inżynier QA (2) quality assistance engineer - inżynier wsparcia jakości
- inżynier QC quality control engineer - inżynier kontroli jakości.
Istnieją dwie szkoły definiowania, czy coś jest wysokiej jakości, czy też nie - szkoła miar i szkoła subiektywnej oceny. Pierwsza ze szkół zakłada, że jesteśmy w stanie ocenić jakość przy pomocy metryk, które stosowane łącznie, pozwolą nam wyciągnąć wnioski na temat tego, czy oprogramowanie jest wysokiej jakości, czy też nie. Należą do nich:
- liczba otwartych defektów (z podziałem na krytyczność)
- procent funkcjonalności pokrytych przez testy
- procent wymagań spełnionych przez oprogramowanie
- liczba uruchomionych pozytywnie testów
- itd.
W tym podejściu testerzy oprogramowania w projekcie często stają się reprezentantami klientów. W związku z tym, że właściciel produktu lub końcowy odbiorca nie jest obecny, to tester przetwarzając specyfikację wymagań albo inne źródła informacji stara się zrozumieć, czy jakość będzie dla końcowego odbiorcy. Ta rola powinna być zarezerwowana dla analityków biznesowych, ale tu praktyka często rozjeżdża się z teorią.
Druga szkoła, która jest dużo bardziej abstrakcyjna, mówi o ogólnym zadowoleniu klienta / odbiorcy oprogramowania. Jej echa widzimy praktycznie w każdej definicji jakości.
- jakość: stopień, w jakim moduł, system lub proces spełnia określone wymagania i/lub spełnia potrzeby i oczekiwania klienta lub użytkownika (wg ISO/IEC/IEEE 247650)
- jakość jest wartością dla kogoś (wg Jerry'ego Weinberga)
- jakość jest wartością dla kogoś w pewnym czasie (wg Michaela Boltona).
Takie ujęcie tematu jest trudne do zrozumienia przez umysły inżynierskie, które wszystko traktują w kategoriach True / False i szukają jednoznacznego potwierdzenia, że coś jest OK albo NIE OK.
Do tej szkoły należą wszyscy krzewiciele poglądu, że istnieje tylko jedna miara jakości jaką jest działające oprogramowanie. W tym agileowym podejściu to, czy coś działa, czy też nie, definiowane jest przez klienta, a więc subiektywne (opisaliśmy to w artykule "Jakość jest subiektywna").
Analizując obserwowalne w projektach wdrożenia obu szkół można powiedzieć, że bardzo trudno jest zdefiniować obiektywną jakość przy pomocy miar ilościowych. Oprogramowanie z dużą liczbą defektów może być zaakceptowane przez klienta, a z dużą liczbą uruchomionych pozytywnie testów już nie. Czym mniejszą wiedzę o produkcie i jego użytkownikach ma tester, tym trudniej ocenić mu, czy produkt jest dobrej, czy złej jakości.
Z drugiej strony wiemy, że najlepszą osobą do oceny jakości produktu zawsze będzie końcowy odbiorca. Może on scedować tę odpowiedzialność na inne osoby, ale w takim przypadku istnieje prawdopodobieństwo, że subiektywna ocena pośrednika będzie różna od jego własnej. W podejściu zwinnym pojawia się rola właściciela produktu, która jest bardzo blisko zarówno zespołu wytwórczego jak i zamawiającego oprogramowanie (często to nawet ta sama osoba). Czym bardziej skrócimy więc odległość między zamawiającym a wykonawcą, to większa pewność poprawnej oceny jakości i dostarczenia akceptowalnego oprogramowania.
