Kwalifikacja: INF.04 - Projektowanie, programowanie i testowanie aplikacji

Pojęcie dokumentacji testowej według IEEE 829-1998 jest bardzo precyzyjne, ale często właśnie myli się niektóre pojęcia. Plan Testów to taki ogólny, strategiczny dokument – mówi, co, kiedy i jak będziemy testować, jakie są założenia, jakie środowisko i narzędzia, ale nie przechowuje szczegółowych informacji o tym, które przypadki były faktycznie realizowane danego dnia przez daną osobę. Trochę jak plan meczu przed rozgrywką, a nie jego protokół. Z kolei Specyfikacja Procedury Testowej to szczegółowy opis kroków, jakie należy wykonać, żeby przeprowadzić dany test – taki „przepis na testowanie”, który daje testerowi konkretną instrukcję działania. Ona nie zbiera jednak danych o tym, kto wykonał, kiedy i z jakim skutkiem – raczej mówi „jak” niż „kto/co/kiedy”. Raport Podsumowujący Testy natomiast to taki końcowy dokument na podsumowanie całego cyklu testowego – zestawia wyniki, ilość znalezionych defektów, procent pokrycia, rekomendacje dotyczące dalszych działań; nie zawiera jednak szczegółowych wpisów o przebiegu pojedynczych przypadków. Typowym nieporozumieniem jest myślenie, że to właśnie raport podsumowujący będzie zawierał „wszystko”, ale on służy bardziej do ogólnego przeglądu i prezentacji wyników, a nie do śledzenia przebiegu każdego testu z osobna. Często też błędnie utożsamia się Specyfikację Procedury z rzeczywistym wykonaniem – a przecież można mieć procedurę, której wcale nie wykonano lub wykonano ją tylko częściowo. To właśnie Dziennik Testów jest tym bieżącym zapisem z pola bitwy, gdzie widać realny przebieg procesu testowego, kto się czym zajmował, czy pojawiły się jakieś nieprzewidziane sytuacje. W praktyce brak tego dziennika często prowadzi do chaosu i problemów z rozliczalnością – a przecież to klucz do profesjonalnego testowania, zgodnie z branżowymi standardami.