Redakcja
Z jakiegoś niepojętego powodu testowanie musi dzielić się na poziomy, typy, etapy i dziesiątki innych kategorii, które nie są aplikowane w większości znanych autorowi i (jak mniemam) również czytelnikowi projektach. Podziały te są jednak na tyle mocno rozpowszechnione i opisane, że trudno się do nich nie odwołać. Zakładamy przy tym, że są to pewnego rodzaju praktyki, które można wdrożyć, jeśli planujemy naszą organizację prowadzić w zgodzie z wybranymi wzorcami tak zwanego dobrego testowania.
Poziomy testów mają swoją czasową kolejność następowania w procesie testowania. Co ciekawe, podział ten uwzględnia, że swoistym wstępem do danego poziomu jest przegląd dokumentacji źródłowej i projektowanie przypadków testowych dla odpowiadającego mu dokumentu. Możemy więc założyć, że czynności, takie jak przegląd czy określanie testowalności, są jedynie preludium do właściwego poziomu testowania.
Przykładowo możemy wyróżnić poziomy:
• poziom testów programistycznych (testowanie jednostkowe)
• poziom testów integracji (testowanie integracyjne)
• poziom testów zintegrowanego systemu (testowanie systemowe)
• poziom testów odbiorowych (testowanie akceptacyjne).
Podział jest sam w sobie niepełny i dotyczy jedynie produktu pojedynczej aplikacji, a nie systemu zbudowanego z wielu systemów.
Choć kolejność podawania wiąże się bezpośrednio z kolejnością wykonywania poszczególnych testów, to model V (opisany w dalszych rozdziałach), z którego zapożyczono poziomy mówi wyraźnie, że kolejność prac jest odwrotna do kolejności wykonywania przypadków testowych. Pierwsza czynność na poziomach testowania to przygotowanie się do... testów odbiorowych.
Wszelkie próby sklasyfikowania testów przestają mieć jakikolwiek sens w obliczu Agile, gdzie nie mają znaczenia poziomy, bo nikt o nich nie mówi. Po prostu testujemy!
Oryginalna publikacja pochodziła z 07/02/2012 i została zaktualizowana.
