Metoda weryfikacji przez braki lub niedorzeczności

Zespół Van Halen w swoim kontrakcie miał zapis, że podczas koncertu za sceną ma stać miska z M&Msami, ale ma nie być w niej żadnych brązowych cukierków. Co to ma wspólnego z jakością?

Kontrakt na organizację koncertu to złożony dokument z wieloma wytycznymi i wymaganiami organizacyjnymi. Zespół Van Halen umieszczał w nim wiele wytycznych odnośnie bezpieczeństwa na scenie, zabezpieczenia PPOŻ czy ochrony muzyków, ale w 126 punkcie swoich wymagań miał zapis o M&Msach. Dodatkowo niespełnienie tego oczekiwania gwiazd mogło się skończyć zerwaniem umowy, odwołaniem koncertu z koniecznością uiszczenia pełnej gaży. Po latach manager przyznał, że nie jest to niedorzeczny wymysł gwiazdy, ale metoda kontroli jakości. Brak draży albo obecność brązowych był informacją o tym, że ktoś nie przeczytał albo nie przyłożył się do sprawdzenia wytycznych. Tak więc podczas sprawdzenia przygotowań do koncertu manager traktował niespełnienie tego kryterium jak zapalenie się czerwonej lampki i zaczynał szczegółowo weryfikować wszystkie inne wytyczne. Podobno często gdy nie pojawiały się M&Msy, to okazywało się również, że np. drzwi ewakuacyjne były zamknięte na klucz.

Ta metoda ma wiele wariacji i równie wiele zastosowań. Poniżej prezentujemy kilka przykładów ze świata IT.

 

Przykład 1.

Umieszczanie niedorzecznych rzeczy w wymaganych przez proces dokumentach pozwala nam zweryfikować, czy manager je czyta. Można również stosować metodę nieumieszczania pewnych informacji. 

Przykład 2.

Jako analityk biznesowy lub jako klient tworzysz małe wymaganie, które jest tak niedorzeczne, że każdy programista powinien je skomentować i nie implementować np. każdy użytkownik powinien mieć unikalne hasło.

Przykład 3.

Jako lider testów w zestawie testów umieszczasz przypadek testowy z zupełnie innego obszaru albo po prostu niemożliwy do wykonania. Dzięki temu możesz określić, czy rzeczywiście ktoś uruchomił specyfikację ze zrozumieniem. Brak komentarzy do tego przypadku po jego uruchomieniu jest silnym sygnałem do usprawnień.

Przykład 4.

Jako programista umieszczasz oczywisty defekt w części oprogramowania, które właśnie wrzucasz na serwer testowy. Dzięki zgłoszeniu będziesz wiedział, czy Twój kod był już testowany i w jaki sposób.

Przykład 5.

Istnieją specjalne typy testów (jak np. posiew defektów), które są testami na testy. Przykładowo zmienia się w kodzie "a>b" na "a=b" i dzięki temu wiemy, czy testy (głównie automatyczne) mają pokrycie w tym obszarze. 

 

Jak widać na przykładzie przez niedorzeczności lub braki jesteśmy w stanie sprawdzić jakość czyjejś pracy, ale również to, czy ktoś w ogóle analizuje temat nad którym pracuje. Trzeba jednak przyznać, że jest to metoda podszyta nieufnością do ludzi i może wskazywać na dość poważne patologie projektowe.

Źródło obrazów: mms.com, cgm.pl
 
 

Najbliższe terminy szkoleń

 

7-8 listopada - Warszawa

TestComplete od podstaw


7-8 listopada - Kraków

Administracja JIRA na poziomie projektowym


18-20 listopada - Katowice

ISTQB Poziom Podstawowy


18-20 listopada - Kraków

Python dla testerów oprogramowania

 

Partnerzy

Narzędzia testerskie