Dobra architektura powinna pozwalać na stworzenie biblioteki skryptów testowych ogólnego przeznaczenia, do których skrypty wyższego rzędu mogą się w późniejszym czasie odwoływać. Gdy architektura jest zła, efekty pracy wykonanej wcześniej nie nadają się do ponownego użycia i nie mogą przyspieszyć testowania kolejnych modułów czy systemów, co stawia pod znakiem zapytania całe przedsięwzięcie. Po drugie, programy testujące o złej architekturze są bardzo kosztowne w utrzymaniu i z tego właśnie powodu stają się najczęściej "kurzołapami".

Niebezpieczne nagrywanie

W ten sposób doszliśmy do pułapki szóstej: ryzyka niewłaściwego zastosowania oferowanych przez kilkuset producentów narzędzi typu "nagraj-odtwórz". Narzędzia tego rodzaju, stosowane głównie do testowania graficznych interfejsów typowych aplikacji biznesowych i systemów internetowych, to w istocie dwa różne narzędzia połączone w jedno.

Narzędzia służące do automatycznego wykonywania testów wg programów sterujących ich pracą (część "odtwórz") mogą bez wątpienia okazać się przydatne każdemu testerowi. Tego nie da się jednak powiedzieć o narzędziach do automatycznego tworzenia tych programów (skryptów) testujących za pomocą "nagrywania" zadań testowych wykonywanych ręcznie. Cechą programów testujących napisanych w całości metodą "nagrywania" jest ich zasadniczo zła architektura. Tej wady nie da się usunąć: nawet najlepszy program do generowania kodu metodą nagrywania testów ręcznych nie jest w stanie domyślić się, ile razy tester zamierza wykonać to samo zadanie z różnymi danymi - musi więc generować ten sam kod kilkaset razy pod rząd.

Zastosowanie narzędzi "nagrywających" powinno sprowadzać się głównie do tworzenia niskopoziomowych "klocków", wykorzystywanych później przez skrypty testowe wyższego rzędu. Mając np. do napisania skrypt klikający na przycisk OK, nie trzeba zastanawiać się nad zawiłościami poszczególnych instrukcji języka. Wystarczy nagrać pojedyncze wykonanie tej operacji. Poprawne architektonicznie skrypty wyższego poziomu należy stworzyć automatycznie. Narzędzia tego typu można też wykorzystać do względnie szybkiego, jednorazowego wykonania pewnej liczby skryptów testowych dla już stabilnego i gotowego systemu, którego zmienność będzie minimalna lub wręcz zerowa. Celem tu będą np. testy regresji po zainstalowaniu poprawek czy rozszerzeń funkcjonalnych.

Uwaga: Jeśli tak sporządzone skrypty mają być później wykorzystywane np. do testowania poprawności instalacji systemu u różnych użytkowników, warto sprawdzić, czy wówczas dostawca narzędzia nie zażąda opłaty licencyjnej za każdą kopię lub każde wykonanie testu.

Ostrożnie z próbnikiem

Rzadko dostrzegane zjawisko, stanowiące bez wątpienia pułapkę siódmą, to zagadnienie tzw. intruzywności narzędzi do automatycznego wykonywania testów. Gdy narzędzie do automatycznego wykonywania testów działa na tym samym komputerze co testowany system, już jego obecność wpływa na stan środowiska wykonywania się badanej podczas testu aplikacji (tzw. efekt próbnika).

Można z tego wysnuć wniosek, że testy wykonywane automatycznie odbywają się w warunkach wyraźnie innych niż w przypadku ręcznej obsługi systemu przez użytkownika. Kontynuując ten tok rozumowania, można mieć uzasadnione wątpliwości, co do wiarygodności prowadzonych testów. Aby się ich pozbyć, na wybranej/wylosowanej próbce zadań testowych trzeba porównać wyniki testów ręcznych i automatycznych.

Bogdan Bereza-Jarociński jest niezależnym konsultantem pracującym m.in. dla szwedzkiej firmy Enea. Można się z nim kontaktować pod adresem: [email protected].