Redakcja
Choć ISTQB® unika grafik, to dla lepszego zrozumienia relacji między dokumentami używanymi w procesie testowania, warto odwołać się do prostego ich zwizualizowania. Poniższa grafika pokazuje w jakiej kolejności powstają "dostawcy z testów" (tzw. test deliverables)
Relacja między produktami testowania. Wizualizacja autorstwa R. Smilgin
Podstawa testów jest dokumentem, który pokazuje, jak system powinien się zachowywać. Dostarczany jest zazwyczaj przez analityka. W prawdziwym życiu sprowadza się to jednak do specyfikacji wymagań. Nie jest to produkt testowania.
Warunki testowe stanowią pierwsze produkty testowania. Są to pomysły, obrazujące na co warto zwrócić uwagę przy testowaniu aplikacji. Nawet w projektach formalnych, na etapie zbierania pomysłów na testy, warunek testowy rzadko kiedy ma formę dokumentu. Z tego powodu dostawa testów, w większości, będzie jedynie obiektem wirtualnym. Co ciekawe, odpowiednikiem warunków testowych w testowaniu eksploracyjnym, są tzw. idee testowe, które wpisywane są zazwyczaj do karty testów.
Przypadki testowe, zasilone danymi testowymi, to opisy wykonania testów z warunkami początkowymi, końcowymi oraz oczekiwanym rezultatem. Zgodnie z najnowszym syllabusem ISTQB® poziomu podstawowego, przypadek testowy może zawierać akcje, czyli coś co zazwyczaj nazywamy w projektach "krokami testu".
Dane testowe mogą być osobnym, niepowiązanym z testem, bytem. Na przykład może to być plik z wartościami, jakie można podać podczas uruchamiania testów.
Procedury testowe to poukładane w logiczną całość przypadki testowe. W tym wypadku, w projektach, mówimy zwykle o "scenariuszach testowych".
Skrypty testowe wraz z danymi, jednoznacznie wskazują na automaty. Warto podkreślić, że tworzenie skryptów w oparciu o przypadki testowe, zazwyczaj uznaje się za złą praktykę.
Harmonogram wykonania testów to zbiór przypadków, procedur i skryptów testowych, jakie należy uruchomić dla danej wersji oprogramowania.
Więcej o produktach testowania dowiecie się z sylabusa poziomu podstawowego
