Testujemy, aby udowodnić, że działa czy żeby pokazać, że nie działa?

Testujemy, aby udowodnić, że działa czy żeby pokazać, że nie działa?
  Testując oprogramowanie musimy sobie odpowiedzieć na pytanie, która szkoła testowania jest nam bliższa: Szkoła Defektów: Testujemy, aby znajdować defekty, więc aby udowodnić, że nie działa. Szkoła Jakości: Testujemy, aby pokazać, że działa - defekty są jedynie produktem ubocznym.  

W zależności od tego jaki jest nasz cel (lub cel naszej organizacji), testowanie będzie wyglądało inaczej.

Szkoła Defektów jest podejściem, które łączy zarówno ISTQB, jak i Michaela Boltona z jego Rapid Software Testing. Według tego ostatniego We don’t test to find out if something works. We test to find out if it doesn’t work.", czyli testujemy, aby przekonać się, że coś nie działa. Podejście to ma swoje zalety i wady. Oprogramowanie ma zawsze jakieś defekty, stąd jeśli odpowiednio długo będziemy je testowali, to udowodnimy w końcu, że nie działa. Jednak czy ciągłe wątpienie i negacja opłacają się? Co ciekawe, firmom oferującym testowanie oprogramowania opłaca się pokazywać słabą jakość. Klienci, którzy korzystają z ich usług chcą słyszeć, że jakość oprogramowania jest niska. Jeśli przekazuje się informację, że defektów nie ma, to klient uznaje, że praca nie została wykonana.

Szkoła Jakości uznaje, że każde oprogramowanie ma jakąś jakość. Wątpliwość jaka się pojawia to to jak bardzo przymykamy oko na złą jakość, aby dostrzec zalety. Takie podejście ma więcej zalet, gdy dotyczy tzw. klienta wewnętrznego, który nie lubi złych wiadomości. Chce on wiedzieć, że wszystko jest OK, ale są też rzeczy, które można by ulepszyć.

Można do tego dorzucić szkołę neutralną, która nie robi założeń, a jedynie dostarcza informacji o jakości. Takie bezemocjonalne podejście do pracy nie jest jednak pożądane przez pracodawców.

 

A jaka jest Twoja szkoła?

 

 

To powinno Cię zainteresować