Dlaczego oprogramowanie zawiera defekty?

• Wprowadzone przez człowieka na każdym z etapów SDLC, począwszy od etapu analizy wymagań na instalacji gotowego produktu kończąc.
• Sprzęt/środowisko. "Błędy" z tej grupy nie są wynikiem źle napisanego, czy nieprzetestowanego kodu, ale jego brakiem, np. brak funkcji obsługującej sytuację, w której zerwane zostaje połączenie sieciowe w trakcie przesyłania danych przez aplikację.
• Złożoność systemu. Złożoność systemu może być trudna do zrozumienia dla kogoś bez doświadczenia w funkcjonującym dzisiaj sposobie tworzenia oprogramowania. Interfejsy wzorowane na oknach, technologia klient-serwer, aplikacje rozproszone, komunikacja danych i relacyjne bazy mają swój udział w szybko przyrastającej złożoności oprogramowania/systemów. Również użycie technik obiektowych, zamiast uprościć może skomplikować projekt, jeżeli nie jest on dobrze skonstruowany.
• Błędy w kodzie. Programiści, jak każdy z nas, popełniają błędy. Część z nich może powstać w wyniku interpretacji źle lub niewystarczająco jasno zdefiniowanych wymagań. Zakładając, że błędów nie da się uniknąć i że zostaną one odnalezione przez testerów, jest ważne, aby być przygotowanym do zarządzania nimi za pomocą narzędzi komercyjnych, np. Rational lub opensource, np. Mantis.
• Zmieniające się wymagania. Klient może nie być świadomym efektów zmian lub chce je wprowadzić pomimo ryzyka, z którego zdaje sobie sprawę – redefiniowanie wymagań, estymacja liczby godzin przeznaczonych na dodanie/modyfikację funkcjonalności, wpływ zmian na równoległe projekty, konieczność ponownego wykonania tej samej pracy lub porzucenia części działającego i przetestowanego już kodu, zmiana wymagań sprzętowych (zazwyczaj w górę).
  
  Wiele drobnych lub kilka dużych zmian może wpłynąć na wytworzone (zdefiniowane lub nieformalne) zależności wewnątrz projektu i stać się przyczyną problemów, podobnie jak rosnąca złożoność procesu zarządzania.
• Presja czasu. Planowanie w projektach informatycznych jest w najlepszym przypadku trudne, częściowo opiera się na przewidywaniu. Może zdarzyć się, że zbliżający się termin oddania aplikacji staje się jedynym wyznacznikiem jakości kodu.

Powyższy artykuł jest przedrukiem z wygasłego bloga testerskiego testowanie.net.