Błędy testowania

20 lat temu Brian Marick opisał najważniejsze błędy testowania. Wiele z nich ciągle powtarzamy.

 

Prezentujemy nasze tłumaczenie dla klasycznej publikacji Some Classic Testing Mistakes.

 

Rola testowania

Myślenie, że zespół testerski jest odpowiedzialny za zapewnienie jakości.
Myślenie, że celem testowania jest znajdywanie defektów.
Nieznajdywanie ważnych defektów.
Nieraportowanie defektów użyteczności.
Brak szacowania jakości (i jakości estymaty).
Raportowanie defektów bez osadzania ich w kontekście.
Rozpoczynanie testowania zbyt późno (wykrywanie zamiast redukowania defektów).

 

Planowanie wysiłku testerskiego

Zorientowanie testowania tylko na testy funkcjonalne.
Niedocenianie testowania konfiguracyjnego.
Wykonanie testów obciążeniowych i przeciążeniowych na ostatnią minutę.
Brak testów dokumentacji.
Brak testów procedur instalacyjnych.
Zbytnia wiara pokładana w testach beta.
Kończenie jednego zadania testerkiego przed ruszeniem do następnego.
Niepowodzenie w identyfikacji obszarów ryzyka.
Uparte realizowanie planu testów.

 

Zagadnienia personalne

Użycie testowania jako przejściowej pracy dla przyszłych programistów.
Rekrutowanie testerów spośród nieudanych programistów.
Testerzy nie są ekspertami dziedzinowymi.
Brak poszukiwania testerów wśród ludzi wspierających użytkowników (np. help desk) lub też specyfikatorów technicznych.
Naleganie, by testerzy umieli programować.
Niezróżnicowany zespół testerski.
Fizyczne odseparowanie testerów i programistów.
Wiara, że programiści potrafią testować własny kod.
Programiści nie są ani wyszkoleni, ani zmotywowani do testowania.

 

Tester w pracy

Zwracanie większej uwagi na uruchamianie testów, a nie na ich projektowanie.
Nieprzejrzane projekty testów.
Bycie zbyt zorientowanym na dane wejściowe i procedury.
Niezauważanie i nieeksplorowanie "niepokojących" zachowań.
Sprawdzanie, czy produkt robi to, co powinien, ale brak sprawdzania, czy nie robi tego, czego nie powinien.
Zestawy testów zrozumiałe tylko dla jego twórcy.
Testowanie tylko na poziomie interfejsu użytkownika.
Słabe raportowanie defektów.
Dodawanie testów regresji tylko, gdy znaleziono defekt.
Nieumiejętne robienie notatek poczas testowania.

 

Automatyzacja testowania

Próba zautomatyzowania wszystkich testów.
Oczekiwanie, że automaty odtworzą testy manualne.
Użycie narzędzi nagrywająco-odtwarzających pracujących na GUI (capture/replay tools) do zredukowania kosztów projektowania testów.
Oczekiwanie, że testy regresywne znajdą dużo defektów.

 

Pokrycie testowe

Przekonanie, że w pokryciu kodu chodzi o proste liczby.
Usuwanie testów z zestawu testów regresywnych, ponieważ nie zwiększają pokrycia.
Użycie pokrycia jako miary efektywności testera.
Rezygnacja z pokrycia.

 

Źródło: http://www.exampler.com/testing-com/writings/classic/mistakes.html

 

PS. Wiele z tych elementów znajdziemy również w sylabusach ISTQB.

 

 

 

Najbliższe szkolenia

 

29-31.05.17 - Katowice

ISTQB Poziom Podstawowy (Foundation Level)


1-2.06.17 - Warszawa

Dobry Tester - Laboratorium


12-14.06.17 - Warszawa

ISTQB Poziom Podstawowy (Foundation Level)

 

Partnerzy

Narzędzia testerskie