Jakiś czas temu w trakcie rozmowy o testach dostałem pytanie, w jakiej konfiguracji środowisk czułbym się komfortowo?
To pytanie i próba odpowiedzi na nie dało mi pomysł na dzisiejszy wpis. Z góry mówię, że nie ma jednoznacznej odpowiedzi na to, jak jest najlepiej. Jak zawsze proces wytwarzania oprogramowania jest dostosowywany indywidualnie pod wytwarzany produkt. Ja opisuję tutaj środowiska testowe, w których mi osobiście pracowało się najbardziej komfortowo.
Jeszcze tylko jedna uwaga, wpis dotyczy aplikacji webowych.
Jaka jest rola środowisk testowych w pracy testera oprogramowania?
Czym jest środowisko testowe?
Zacznę od definicji. Książkowo.
Środowisko, w skład którego wchodzi sprzęt, wyposażenie, symulatory, oprogramowanie oraz inne elementy wspierające, potrzebne do wykonania testu. [IEEE 610]
[Słownik wyrażeń związanych z testowaniem, wersja 2.0]
No dobrze definicję już masz, a teraz po jakiego grzyba nam to środowisko a może środowiska?
Oprogramowanie można tworzyć, na wydaje mi się dowolnej liczbie środowisk. Na przestrzeni lat najbardziej mi się podobało podejście z czterema środowiskami. Oczywiście miej na uwadze skalowalność tematu – aplikacja, na której wtedy pracowałem była średniej wielkości.
Pierwsze środowisko to był „Rozwój”.
Środowisko, na którym pracowaliśmy nad wytwarzaniem nowych funkcjonalności. Środowisko to tylko częściowo symulowało realny system, na którym finalny użytkownik będzie siedział i pracował. Środowisko to było stworzone w celu całościowego testowania naszej aplikacji pod względem funkcjonalnym jak i wydajnościowy. Mieliśmy w nim bardzo rozbudowany system generatorów danych wewnątrznych aplikacji, które były podłączone do mock-ów oraz stub-ów.
Pewnie część z was teraz śmieje się z tego rozwiązania, bo jak na jednej wielkiej symulacji mam dowieść, że to oprogramowanie trafiając do Kowalskiego, będzie działało poprawnie?
Plusem tego rozwiązania było to, że byłem w stanie wykonać proces od stanu zero do stanu końcowego w około 3 minuty, gdzie bez korzystania z symulowanych elementów zajmowało to około 12 minut (prędkość zwiększona około czterokrotnie). Co mi to dało? Dało mi to możliwość szybkiej weryfikacji aplikacji pod kątem funkcjonalnym i integracji pomiędzy modułami.
Drugie środowisko to środowisko „Integracyjne”.
To środowisko testowe było bardzo zbliżone do środowiska klienckiego. W dużej mierze uzupełniało testy ze środowiska Rozwój, ponieważ na nim mogłem sprawdzić wszystkie przepływy oraz integracje z systemami zewnętrznymi. Bardzo ważnym czynnikiem była stabilność środowisk i przede wszystkim to, że od strony funkcjonalnej aplikację już miałem „przeklikaną”.
Trzecim środowiskiem było środowisko „Prod”.
Służyło ono przede wszystkim do weryfikacji zgłoszeń zauważonych przez użytkowników aplikacji. Oczywiście robiłem to zawsze w wyodrębnionym obszarze, dzięki czemu użytkownicy nie odczuwali moich testów. Potwierdzenie obecności błędu na produkcji oznaczało, że błąd jest i trzeba go poprawić :).
Do tego służyło ostatnie środowisko „Branch”.
Na tym środowisku przeważnie instalowałem wersję produkcyjną wzbogaconą o poprawkę błędu. Dzięki temu mogłem sobie na odizolowanym środowisku zretestować zgłoszenie.
Środowiska testowe a wersja zainstalowanej aplikacji
Jeśli miałbym te środowiska połączyć z wersjami aplikacji, to wyglądałoby to następująco:
- Prod miał wersję 1.0.
- Branch miał wersję 1.1 – końcówka wynika z różnicy pomiędzy wersją na środowisku Prod a dodanym kodem.
- Rozwój miał wersję 2.0, ponieważ jak sama nazwa wskazuje, pracowaliśmy tutaj nad rozwinięciem aplikacji do nowszej wersji.
- Integracyjne miało zawsze wersję finalną ze środowiska Rozwój, wynikało to z wykonywanych na nim testów.
Oczywiście po udanym wdrożeniu wersji, wartości ulegały zmianie na:
- Prod – 2.0,
- Branch – 2.1 analogicznie co wyżej,
- Rozwój – 3.0,
- Integracja – finalna wersja z rozwoju.
Środowiska testowe to nie tylko te serwery z wersjami aplikacji.
Ok rozpisałem się o tym, jak wyglądały wersje oprogramowania na środowiskach testowych, ale nie wspomniałem o części równie ważnej!
Środowiska testowe to nie tylko te serwery z wersjami aplikacji. To przede wszystkim wspomniany na początku sprzęt, oprogramowanie itp.
Ważną rolę moim zdaniem odgrywa kontrakt, jaki firma ma podpisany na tworzoną aplikację. W nim mamy zapisane przeważnie informację, na czym ma nasza aplikacja działać, w jakich warunkach. Wydaje mi się, że akurat na ten temat też może sporo powiedzieć specyfikacja czy to w formie papierowej np. SRS, czy też w formie Story (Scrum).
Dzięki informacjom zawartym w tych dokumentach możemy się przygotować na nadchodzące testy.
Przykładowo poprzez instalację odpowiedniego oprogramowania np. przeglądarki. Jeśli testy mają być wykonywane na przeglądarkach, warto brać pod uwagę, w jakim kraju będzie ta aplikacja używana, a następnie zweryfikować ranking przeglądarek dla danego kraju. Na tej podstawie wybrać przeglądarki najważniejsze i mniej ważne dla danego kraju.
Możemy też zgłosić zapotrzebowanie na sprzęt np. na mniejszy monitor lub też planować tak pracę, żeby móc się wymienić sprzętem z kolegą/koleżanką, która takowy posiada, żeby móc wykonać potrzebne testy. Możemy również zainstalować różnego rodzaju symulatory (to się tyczy np. wymagań, mówiących o tym, że aplikacja ma działać na Windows 7 i 8 czy też starych przeglądarek typu Internet Explorer 10, czy też 11).
Podsumowanie
Mam nadzieję, że ten artykuł rozjaśnił nieco kwestię środowisk testowych. Przedstawiłem trochę mojego doświadczenia, które chciałbym, żeby dało Ci jakiś obraz.
Pamiętaj, żeby nie brać tego jako idealne rozwiązanie, które wszędzie zadziała. Możesz wówczas doprowadzić do przypowieści o kotlecie, z którą możesz się zapoznać np. tutaj:
https://www.facebook.com/watch/?v=617743818794570
Tydzień temu udostępniłem tekst o danych testowych. Myślę, że oba tematy wiążą się ze sobą, dlatego, jeśli go jeszcze nie czytałeś, zachęcam.
