1. Strona główna
  2. Sylabus ISTQB – Poziom podstawowy (wersja 2011.1.3)
  3. 6. Testowanie wspierane narzędziami
  4. 6.2 Skuteczne użycie narzędzi, potencjalne korzyści i ryzyko
  5. 6.2.1 Potencjalne korzyści i ryzyko wsparcia narzędziowego dla testów (dla wszystkich narzędzi)

6.2.1 Potencjalne korzyści i ryzyko wsparcia narzędziowego dla testów (dla wszystkich narzędzi)

Sam zakup narzędzia lub wzięcie go w leasing nie gwarantuje jeszcze sukcesu. Każdy typ narzędzia może wymagać wykonania dodatkowego wysiłku do osiągnięcia prawdziwych i trwałych korzyści. Z używaniem każdego narzędzia wiążą się potencjalne korzyści i możliwości, ale wiąże się też z tym pewne ryzyko.

Potencjalnymi korzyściami z używania narzędzi są:

  • zredukowana zostaje powtarzająca się praca (np. uruchamianie testów regresywnych, powtórne wprowadzanie tych samych danych testowych oraz sprawdzanie zgodności ze standardami kodowania)
  • zwiększa się spójność i powtarzalność (np. testy wykonywane przez narzędzie w tej samej kolejności i z tą samą częstością oraz testy wywiedzione z wymagań)
  • ocena jest obiektywna (np. miary statyczne, pokrycie)
  • łatwiejszy jest dostęp do danych o testach i testowaniu (np. statystyki i wykresy obrazujące postęp testów, współczynniki występowania incydentów oraz wydajność)

Ryzyko związane z narzędziami do testowania obejmuje:

  • nierealistyczne oczekiwania od narzędzia (co do funkcjonalności lub łatwości użycia)
  • niedoszacowanie czasu, kosztów oraz pracochłonności wstępnego wdrożenia narzędzia (włączając w to szkolenia oraz ekspertów zewnętrznych)
  • niedoszacowanie czasu i pracochłonności potrzebnych do osiągnięcia znaczących i trwałych korzyści z narzędzia (włączając w to potrzebę wykonania zmian w procesie testowym oraz ciągłe doskonalenie sposobu wykorzystania narzędzia)
  • niedoszacowanie pracochłonności utrzymania artefaktów testowych wygenerowanych przez narzędzie
  • zbytnie poleganie na narzędziu (zastąpienie narzędziem projektowania testów lub wykorzystywanie narzędzia, gdy testowanie ręczne byłoby lepsze)
  • niewykorzystywanie kontroli wersji testaliów w narzędziu
  • lekceważenie zależności i problemów z współpracą krytycznych narzędzi takich jak, narzędzia do zarządzania wymaganiami, narzędzia do kontroli wersji, narzędzia do zarządzania incydentami, narzędzia do śledzenia defektów oraz narzędzia od różnych dostawców
  • słaba reakcja dostawcy w ramach wsparcia, nowych wersji oraz poprawiania usterek
  • ryzyko wstrzymania projektu dla narzędzia darmowego / open-source
  • nieprzewidziane, takie jak niezdolność do wspierania nowej platformy