Środowisko testowe – słów kilka

W tym materiale postaram się Wam przybliżyć nieco temat środowisk, a w szczególności skupić się na środowiskach testowych. Na samym początku musimy sobie zadać podstawowe pytanie: „Czym w ogóle jest środowisko w kontekście pracy dowolnej aplikacji?”

Środowisko – to zbiór niezbędnych elementów infrastruktury technicznej / softwarowej, który stanowi podstawę do działania danej aplikacji.

Środowisko testowe jest jednym z kilku typów środowisk.  Poza wspomnianym środowiskiem testowym są jeszcze inne, takie jak:

Środowisko testowe jak już mówi sama nazwa – powinno być przeznaczone  do przeprowadzania testów aplikacji. Środowisko testowe jest jednym z punktów, które dostarczają nam informacji na temat jakości i zachowania testowanej aplikacji. Mówiąc prościej – środowisko testowe ma za zadanie zapewnić nam rozwiązanie – niezbędne do przeprowadzania testów danej aplikacji.

Dobre środowisko testowe powinno posiadać kilka charakterystycznych, specyficznych właściwości.

Po pierwsze powinno być stabilne – przynajmniej do tego stopnia, aby testerzy mogli swobodnie i bez nieplanowanych przerw (spowodowanych niedostępnością środowiska) testować manualnie lub automatycznie wskazaną aplikację. Dlatego też środowisko testowe powinno być jak najbardziej zbliżone do docelowego (produkcyjnego) środowiska, pod kątem jego funkcjonalności i konfiguracji zarówno hardwarowej, jak i softwarowej.

Oczywiście wierne odwzorowanie środowiska produkcyjnego (1:1) jest zwykle bardzo trudne, a często nawet nieosiągalne. Takiej praktyki nie stosuje się głównie również z uwagi na koszty, gdyż wierne odwzorowanie wszystkich parametrów środowiska produkcyjnego – byłoby po prostu bardzo kosztowne. Zwykle takie idealne odwzorowanie środowiska produkcyjnego jest również niepotrzebne, gdyż środowisko testowe służy jednak do innych celów, niż środowisko produkcyjne. Mogę tutaj, chociażby zwrócić uwagę na to, że na środowisku testowym będą pracowali tylko testerzy, czy też osoby zaangażowane w development.

Natomiast na środowisku produkcyjnym będą działać klienci, których często może być wiele tysięcy (pracujących jednocześnie) więc środowisko produkcyjne, musi być dużo bardziej wydajne i bogato wyposażone w zasoby.

Środowisko testowe powinno być wyizolowane. Co to konkretnie oznacza?

Oznacza to, że środowisko powinno być przeznaczone tylko do określonych celów – w tym przypadku do testów. Podążając tym tokiem myślenia – środowisko to powinno być przeznaczone tylko dla testerów manualnych, automatycznych i nie powinni na nim pracować developerzy.  Środowisko powinno być bardziej stabilne, dopracowane i wydajne niż środowisko developerskie (na którym powinni pracować właśnie developerzy). Niestety to właśnie te cechy środowiska testowego jak stabilność i wydajność – często zachęcają programistów do działania właśnie na środowisku testowym – nie jest to jednak dobra praktyka i zwykle konsekwencje takiej pracy są bardzo negatywne.

Oczywiście zdarza się, że czasami drobne prace developerskie mogą być przeprowadzone bezpośrednio na środowisku testowym – gdyż czasami jest to jedyna, szybka możliwość na realizację pewnych zadań developerskich. Takie prace jednak trzeba przeprowadzać z głową, gdyż zdecydowanie nie powinny się zdarzać takie sytuacje, w których testerzy nie mogliby wykonywać testów z powodu prowadzenia właśnie prac developerskich.

Częste ingerencje programistów w środowisko testowe znacznie obniżają stabilności takiego środowiska. Z powyższego wywodu płynie jeszcze jeden bardzo ważny wniosek. Wszelkie niedoskonałości, problemy ze środowiskiem testowym mogą wpłynąć negatywnie na  jakość całego produktu końcowego. Zachowanie poprawności i ciągłości działania środowiska testowego jest punktem kluczowym dla całego procesu testowego. Oczywiście to środowisko, jak i każde inne również będzie miało przerwy w działaniu podyktowane, chociażby pracami konserwacyjnymi, aktualizacyjnymi czy podgrywaniem nowej wersji aplikacji.

Ważne, aby takie przerwy były planowane z wyprzedzeniem i aby o ich ewentualnym zaistnieniu wiedzieli pracujący na nim testerzy. Dlaczego informacje o planowanej niedostępności środowiska, bądź jego czasowym niestabilnym działaniu są takiego ważne? Istnieją dwa główne powody takiego stanu rzeczy. Przede wszystkim – bywa tak, że samo przygotowanie do testu danych testowych, tekstyliów oraz samej aplikacji, często bywa dłuższe, niż samo wykonanie testu, dlatego musimy unikać sytuacji, w których przez nieplanowaną niestabilność środowiska tracimy naszą pracę, a przy tym nasz cenny. Po drugie – kiedy środowisko jest niestabilne, mogą pojawiać się błędy w aplikacji, które normalnie nie mają prawa się zdarzyć i przez to dajemy mylny obraz aktualnego stanu jakościowego aplikacji.

W jednym projekcie może istnieć więcej niż jedno środowisko testowe. Spotkałem się już z sytuacjami, w których testerzy manualni mieli swoje odseparowane środowisko testowe, testerzy automatyzującym mieli inne środowisko testowe, a klienci, którzy zamówili aplikację, mieli jeszcze inne swoje środowisko do swoich testów.

Główne elementy tworzenia środowiska testowego

Postawienie środowiska testowego wymaga wielu elementów, o których musimy pamiętać.

Najważniejsze punkty to:

  • Stworzenie danych testowych i poprawne ich zaimplementowanie
  • Bazy danych
  • Infrastruktura hardwarowa
  • Infrastruktura softwarowa
  • Konfiguracja sieci
  • Komunikacja z innymi wymaganymi rozwiązaniami, systemami
  • Pliki konfiguracyjne, dokumentacje
  • Frontendowe środowisko uruchomieniowe

Zarządzanie środowiskiem testowym

Bardzo ważnym elementem środowiska testowego jest jego zarządzanie. Zarządzanie środowiskiem skupia się głównie na pracach konserwacyjnych, aktualizacyjnych, rozwiązywaniem pojawiających się problemów, monitorowanie oraz utrzymywaniem ciągłości działania. Te czynności zwykle realizują dedykowani dla środowiska – administratorzy.

Lista zadań, które należą do administratorów środowisk to:

  • Utrzymanie centralnego repozytorium kodu
  • Zarządzanie środowiskiem zgodnie z wymaganiami i oczekiwaniami osób na nim pracujących
  • Monitoring, śledzenie aktywności i wszelkich anomalii
  • Aktualizacje oprogramowania, sprzętu
  • Koordynacja prac prowadzonych na środowisku
  • Informowanie o planowanych niedostępnościach  środowiska

Jak zorganizować wiele środowisk do testowania

Moim zdaniem najbardziej efektywnym sposobem zarządzania środowiskami testowymi jest automatyzacja. Dzięki automatyzacji kompilacji i wdrażania możemy znacznie zoptymalizować pracę ze środowiskami – nie tylko testowymi.

Narzędzia do ciągłej integracji (CI), takie jak Jenkins, Bamboo, CircleCI, GitLabCI doskonale nadają się do tego celu. Tego typu narzędzia nie tylko pomagają zautomatyzować wdrożenia środowiskowe, ale także pomagają w uruchamianiu testów automatycznych.

Innym podejściem do zarządzania środowiskami testowymi jest posiadanie szczegółowej dokumentacji opisującej na przykład sposób tworzenia dokładnej repliki innego środowiska. Jednak to bardziej manualne podejście jest znacznie bardziej czasochłonne i narażone na błędy ludzkie – niż proces CI.

Autor: Tomasz Stelmach

Notatka o autorze:

Zajmuję się testowaniem, zabezpieczaniem i zapewnianiem jakości oprogramowania od ponad 13 lat. Rozpocząłem swoją karierę od testów manualnych i analizy biznesowo-technicznej. Obecnie prowadzę firmę Quality Island, która zajmuje się szeroko pojętym testowaniem oprogramowania oraz szkoleniami dla przyszłych i obecnych testerów oprogramowania. Moją specjalnością są testy automatyczne aplikacji webowych oraz budowa procesów automatyzacji i robotyzacji. Od 8 lat prowadzę aktywnie szkolenia oraz konsultacje z tych tematów i wykonuję zlecenia dla firm trzecich jako konsultant, ekspert oraz audytor. Współpracuję również z firmami jako osoba do rekrutacji i weryfikacji technicznych. Interesują mnie głównie tematy związane z architekturą IT oraz zagadnienia DevOps/TestOps, ponieważ ściśle wiążą się z zapewnianiem jakości oprogramowania.

 

Tomasz Stelmach

CEO&Founder

 

0 komentarzy

Wyślij komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *