Redakcja
Często uważa się, że posługiwanie się przymiotnikami w opisywaniu zdarzeń od razu determinuje wysoki poziom subiektywizmu. Nie powinno się pisać, że coś jest niepowtarzalne, innowacyjne czy idąc w drugą stronę obrzydliwe i zaściankowe, bo są to opinie, a nie informacje. Dziennikarze, tak jak i testerzy powinni koncentrować się na mierzalnych wartościach i zero-jedynkowych zdarzeniach. Podobnie jest również i w pracy osób odpowiadających za zapewnienie jakości w projektach informatycznych.
W naszej pracy wymagania sformułowane jako "oprogramowanie ma być wydajne", "oprogramowanie ma być użyteczne" czy też "oprogramowanie ma być bezpieczne" nic absolutnie nie mówi. Dlaczego? Ponieważ jest niemierzalne. Tak sformułowany zapis bez dalszych szczegółów traktujemy jako błąd inżyniera wymagań lub analityka biznesowego wychwycony przez QA.
Niemierzalne oznacza tu brak możliwości określenia miary potrzebnej do implementacji lub weryfikacji. Załóżmy, że wymagania o wydajnym oprogramowaniu trafia do programisty. Zaimplementowana przez niego funkcja zwraca odpowiedź w ciągu 100 milisekund. Czy to oznacza, że działa wystarczająco wydajnie? Jak sprawdzić, czy taki produkt uzyska akceptację? Nie da się bez doprecyzowania wymagania.
Idąc dalej tester oprogramowania, który posługuje się określeniem typu "oprogramowanie jest dobre" nie dostarcza żadnej wartościowej informacji. Może jedyne sugerować, że w jego subiektywnej opinii oprogramowanie spełnia jakieś niezdefiniowane kryteria. Dlatego też ISTQB® tak mocno stawia w swoim podejściu na miary. Zdanie pojedynczego testera ma wartość opinii eksperckiej, ale na jej podstawie nie można decydować o wydaniu oprogramowania. Dopiero metryki takie jak liczba defektów, liczba lub czas przeprowadzonych testów mogą mówić coś więcej o jakości. Współcześnie, skracając czas uzyskania informacji zwrotnej od klienta do zespołu, jesteśmy w stanie pozwolić sobie na pewne uproszczenia w definiowaniu kryteriów akceptacji oprogramowania. Nie możemy sobie jednak pozwolić na skróty myślowe, jeśli klienta reprezentuje tester, a sam klient nie jest zaangażowany (lub nie chce się angażować) w proces akceptacji oprogramowania. W takim przypadku potrzebujemy wymagań bez przymiotników
Oto lista 10 przymiotników oraz ich antonimów, które ze swojego słownika powinien wykreślić każdy członek zespołu projektowego IT ze szczególnym wskazaniem na inżyniera wymagań, analityka biznesowego oraz testera*:
- wydajny – niewydajny,
- bezpieczny – niebezpieczny,
- użyteczny – nieużyteczny,
- przyjazny - nieprzyjazny,
- dobry – niedobry,
- wspaniały – beznadziejny,
- duży – mały,
- wysoka – niska,
- długi – krótki,
- lepszy – gorszy;
*) Oczywiście słówka te są w pełni akceptowalne, jeśli przypisane są do nich właściwe miary oraz kiedy używane są przez klienta (ponieważ klient ma zawsze rację).
