Podziel się tym wpisem!

Środowiska testowe - konfiguracja z jaką najlepiej mi się pracowało
Środowiska testowe

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. 

 

Znalazłeś błąd na tej stronie? Zgłoś mi go.
Formularz zgłoszenia błędu

Jeśli znalazłeś błąd w tekście lub na stronie to proszę, zgłoś mi go. Większość pól tego formularza nie jest wymagana. Jeśli chcesz zgłosić błąd tak, jak powinno się to zrobić, wypełnij je wszystkie.

W formularzu brakuje pola „dodaj załącznik”, ponieważ użycie tej formatki jest płatne. Jeśli jednak chcesz wysłać mi załącznik, prześlij go na e-mail waldemar.szafraniec.szkolenia@gmail.com, w tytule wiadomości napisz, że jest to załącznik do zgłoszenia błędu.

Podany e-mail będzie wykorzystany tylko w celu obsługi tego zgłoszenia - zostaniesz poinformowany, gdy błąd zostanie poprawiony. Podanie e-mail nie jest równoznaczne z zapisem na newsletter.
Tytuł powinien w sposób jasny i czytelny mówić co nie działa na stronie.
Ile prób odtworzenia błędu udaje się odtworzyć.
Dane opisowe błędu. Mogą to być informacje szczegółowe na temat tego, jaki komunikat się wyświetlił. Albo dodatkowe informacje początkowe, jakie muszą zaistnieć.

Podziel się tym wpisem!

Waldemar Szafraniec

Nazywam się Waldemar Szafraniec. Karierę testera rozpocząłem w 2012 roku. Od początku pracy w zawodzie wiedziałem, że będzie to coś więcej niż tylko praca. Obecnie praca jest również moim hobby. Jednym z moich obowiązków w obecnym miejscu pracy jest rekrutowanie nowych testerów oraz szkolenie ich. Sam stale podnoszę swoje kwalifikacje uczestnicząc w szkoleniach (ISTQB, ISTQB Advanced Level – Test Analyst). Szkolę ludzi w dziedzinie testów manualnych od 2014 roku. Jestem trenerem, ponieważ wiem, że dobrze mi wychodzi przekazywanie wiedzy, wiem jak praca testera wygląda oraz mam doświadczenie w rekrutacji.

Dodaj komentarz