Redakcja
Załóżmy, że środowisko testowe aplikacji zbudowane jest w oparciu o PC. Załóżmy również, że naszym celem nie są aplikacje webowe dostępne przez przeglądarkę, ale aplikacje natywne.
Sam komputer jest kluczowym elementem, ale niekoniecznie całością. Ważne są również jego tzw. peryferia. Poniższy rysunek prezentuje coś, co w można by nazwać środowiskiem pracy lub środowiskiem testowym dla aplikacji.
Idąc po kolei mamy:
- skaner
- procesor
- pamięć RAM
- karty
- zasilacz
- odtwarzacz płyt
- dysk
- karta główna
- głośniki
- monitor
- system plików
- aplikacja
- klawiatura
- mysz
- router [?]
- drukarka
Środowisko możemy przeanalizować pod kątem urządzeń wejściowych oraz wyjściowych. To ciekawy aspekt, ponieważ pozawala nam przyjrzeć się z bliska kontekstowi użycia oprogramowania oraz wymyślania przeróżnych testów.
Centralnym elementem środowiska będzie nasza aplikacja. Wejście to element, który pozwala nam na podanie pewnej informacji do aplikacji. Co ciekawe praktycznie każde z urządzeń i elementów może być wejściem, ponieważ jego awaria może doprowadzić do nieoczekiwanego zachowania aplikacji. Takim wejściem będzie np. zasilacz, którego awaria może być testem niezawodności, czyli co wydarzy się z aplikacją, kiedy nagle zabraknie zasilania. Test może wydać się absurdalny, ponieważ oczywiste jest, że brak zasilania doprowadzi do wyłączenia aplikacji. Z testerskiej perspektywy interesuje nas jednak jak zachowa się oprogramowanie, kiedy znowu zostanie włączone. Czy aplikacja się otworzy? W jaki sposób się otworzy (tryb awaryjny?)? Czy element, na którym pracowaliśmy został uszkodzony (np. plik)? Ile danych zostało uszkodzonych albo niezapamiętanych przez wyłączenie? Itd. Pomijając jednak awarię i koncentrując się na standardowych wymuszeniach, możemy wyróżnić następujące wejścia: skaner (1), odtwarzacz płyt (6), klawiatura (13), mysz (14).
Wyjścia to urządzenia, które pozwolą nam obserwować reakcję naszej aplikacji na sygnały wejściowe. Są to: odtwarzacz płyt (6, jeśli umożliwia również nagrywanie), głośniki (9), monitor (10), drukarka (16).
Teraz pozostaje nam, korzystając z tych elementów, by wymyślać testy. Przykłady.
Skaner może dostarczać dokumenty lub zdjęcia do testów, odtwarzacz płyt może umożliwiać nam instalator aplikacji, klawiatura i mysz pozwalają nam uzupełniać pola formularza. Oczywiście możemy również pomyśleć o testach negatywnych i skaner może dostarczyć plik za duży i nie obsługiwany w naszej aplikacji, a klawiatura może podać chińskie znaczki do formularza przygotowanego na rynek polski.
Od strony wyjść możemy oceniać, czy zachowanie jest tym oczekiwanym, ale również odpowiedzieć sobie na inne pytania. Czy nie posiadając głośników lub mając wyciszony dźwięk możemy posługiwać się aplikacją? Czy wydruki są poprawne?
Pamiętajmy, że całe środowisko testowe powinno zostać zinwentaryzowane. Przez inwentaryzację rozumiemy opisanie kluczowych komponentów przy pomocy ich parametrów, wersji hardware, wersji sterowników itp. Będzie to szczególnie ważne, gdy dany komponent ma bezpośredni wpływ na zachowanie aplikacji. Taki wpływ na pewno może mieć procesor, za to z bardzo niewielkim prawdopodobieństwem wpływ na aplikację będzie miał model klawiatury jaki posiadamy. Jeśli nie mamy pewności jaki komponent wpłynął bezpośrednio na (nie)poprawne zachowanie aplikacji najlepiej opisać możliwie najwięcej informacji o nim.
