Głównym problemem i największą przeszkodą w projektach informatycznych są niedostatki inżynierii wymagań. Tak jak najlepszy scenariusz nie zastąpi aktorom prób, tak najdoskonalsze wymagania nie są gwarancją, że podczas budowy systemu wszystko się powiedzie. Trzeba więc testować i sprawdzać, a im wcześniej, tym lepiej. Jednak żeby móc dokonać takiego próbnego rozruchu systemu informatycznego, trzeba mieć do dyspozycji odpowiednie środowisko, dane testowe, możliwość symulowania brakujących kawałków systemu oraz innych systemów.

Dziesiątki razy pytałem testerów, zespoły i działy testowania, z czym mają największe kłopoty. Co zajmuje im najwięcej czasu? Odpowiedzi są nużąco niezmienne: to środowiska testowe. Problemy z nimi naprawdę potrafią sparaliżować każdy projekt.

Zobacz również:

• 5 priorytetów, które obniżają koszty chmury i usprawniają operacje IT
• Cyfrowa transformacja z AI - co nowego na Google Cloud Next 24

Kłopoty ze środowiskami testowymi

Oto typowe kłopoty ze środowiskami testowymi, które pochłaniają niekiedy nawet 50% czasu i budżetu projektów informatycznych.

Koszt środowiska

Środowisko testowe kosztuje. Płacimy za sprzęt, oprogramowanie, administrowanie, kopie zapasowe, a przede wszystkim za konieczność modyfikacji i dostosowywania do nowych potrzeb. Kiedy w skład środowiska wchodzą komputery typu mainframe i terabajtowe bazy danych - co jest typowe dla wszelkich systemów ERP, dla banków, dla firm ubezpieczeniowych - koszty mogą przebić "barierę dźwięku".

Odpowiedzialność za środowisko

Przykłady kłopotów:

- Testy automatyczne zaplanowane na weekend zostają przerwane już w sobotę, bo administrator systemu wykorzystuje weekend na… serwis serwera. Dział testów domaga się więc własnego serwera.

- Zespół testowy ma mnóstwo trudności z uzyskaniem odpowiednich konfiguracji, uprawnień, haseł. Wiecznie stoją, jako petenci, w kolejce do adminów!

- Różni użytkownicy, różne zespoły testowe niechcący psują sobie nawzajem środowisko testowe i jego konfigurację. Zajmuje to mnóstwo czasu i powoduje wiele złej krwi.

A przecież czas goni.

Dublowanie środowisk

Różnych środowisk, od środowiska programisty aż po docelowe (produkcyjne), może być nawet kilkanaście. Widuje się osobne środowiska do testów funkcjonalnych, do testów systemu A i do testów systemu B, do testów wydajności, do testów z danymi produkcyjnymi, do testów systemowych, środowisko przedprodukcyjne, kopię środowiska produkcyjnego, specjalne środowisko testów szybkiej ścieżki… Wszystko to generuje ogromne koszty.

Dostęp do środowiska

Przykłady:

- Zdalny dostęp powoduje kłopoty z nadzorowaniem, kto w danej chwili co robi, jakie zasoby wykorzystuje. Rozwiązaniem jest specjalna aplikacja, umożliwiająca rezerwację dostępu i sterowanie nim, czasochłonna w utrzymaniu, kłopotliwa w użyciu.

- Po zgłoszeniu pierwszych błędów coraz częstszymi gośćmi w laboratorium testowym stają się programiści - łowcy bugów. Odtworzyć przyczyny awarii mogą tylko w środowisku testowym. Ustalenie zasad współżycia społecznego zajmuje wtedy dużo czasu.

Symulacja

Stworzenie symulatora (emulatora) to zwykle osobny duży projekt, a jego nieustanne zmiany pochłaniają mnóstwo pracy. Co gorsza, każdorazowy negatywny wynik testu oznacza żmudną konieczność sprawdzenia, co działa niepoprawnie - testowana aplikacja czy symulator? Czasem w projekcie budowa symulatorów pochłania więcej wysiłku niż testowanie oprogramowania. Kiedy podsystem A buduje się i testuje w jednym miejscu, a podsystemy B i C w innych, to zespół piszący A posługuje się własnymi symulatorami B’ i C’, zespół B - symulatorami A’ i C" i tak dalej. Jest to kłopotliwe, kosztowne i powoduje mnóstwo błędów.

Projekty rozproszone, usługi internetowe, SOA i chmura

Każdy z terminów użytych w tytule tego akapitu oznacza, że opisane kłopoty wzmagają się jeszcze wielokrotnie.

Ratunek w wirtualizacji

Pomysł, aby brakujący czy kosztowny fragment środowiska testowego zastąpić jego wirtualną namiastką, nie jest niczym nowym. Ma tyle lat, ile informatyka i budowanie systemów. Tyle tylko, że w tradycyjnej formie jest to metoda kłopotliwa i kosztowna. Wirtualizację można jednak realizować o wiele prościej. I to jest właśnie nowość, która dziś jeszcze nie jest w pełni zrozumiana i doceniana, a za kilka lat trudno będzie sobie wyobrazić, jak kiedyś radziliśmy sobie bez niej.

Nie trzeba przecież naśladować działania całej aplikacji, tylko te jej fragmenty, które są potrzebne do wykonania niezbędnych testów. Nie trzeba symulować działania aplikacji, lecz wyłącznie jej interfejs, jej widoczne zachowanie się. To jest o wiele prostsze: symulator wie, jaki meldunek wysłać w odpowiedzi, ale nie powiela żadnych obliczeń, nie wykonuje przetwarzania wewnętrznego. Stąd nazwa: wirtualizacja zachowania się aplikacji (application-behaviour virtualization). Taka wirtualizacja jest prostsza, wydajniejsza, łatwiejsza do wdrożenia i modyfikowania niż symulacja pełna, tradycyjna.

Co więcej, aby stworzyć wirtualizację, niekoniecznie trzeba samemu w pocie czoła pisać program. Można bowiem posłużyć się dobrze znaną metodą: zarejestruj-odtwórz. Korzystając z krótkotrwałego dostępu do prawdziwej aplikacji, można przy pomocy wirtualizatora zarejestrować, jak komunikuje się ona z systemem, który testujemy, a później odtwarzać tę komunikację wielokrotnie, w potrzebnym do testowania miejscu i zakresie.

Dzięki wirtualnym środowiskom testowym można podczas integracji oraz testowania systemów znacznie złagodzić problemy wynikające z:

- brakujących lub niestabilnych komponentów;

- środowisk będących dopiero w trakcie budowy, niedostępnych lub kosztownych oraz systemów należących do firm trzecich;

- systemów zbyt kosztownych, skomplikowanych albo poufnych, by móc wykorzystać je w testach (mainframe, finansowe, ERP);

- zasobów - wewnętrznych i zewnętrznych - mających wielu użytkowników i właścicieli, co komplikuje dostęp i konfigurację;

- stosowania metodyk agile - wiele niezależnych zespołów pracujących w trybie agile i potrzebujących dostępu do własnego środowiska testowego;

- wielkiej liczby różnorodnych systemów, z którymi budowany system musi być zintegrowany.

- potrzeby dostępu do środowiska testowego z różnych lokalizacji rozproszonego projektu, w którego ramach budowany jest rozproszony system: wirtualne środowisko testowe można udostępnić w trybie chmury, prywatnej lub publicznej.

Jak działa wirtualizator

Nie wirtualizuje się całej funkcjonalności danego komponentu czy systemu - bazy danych, pakietu obliczeniowego, usługi internetowej (web service) podającej kursy walut czy aplikacji ERP - a tylko te ich działania (zachowania), które są potrzebne dla danych testów, przypadków użycia lub scenariuszy biznesowych.

Dane testowe to taki właśnie, na pozór drobny, ale przytłaczający w praktyce problem. Teoretycznie - prosty do rozwiązania, w projektach - ogromnie czasochłonny. Zbudowanie i utrzymanie bazy danych, wypełnienie jej danymi - to wielkie przedsięwzięcie. Aby go uniknąć, wystarczy zbudować, np. dla bazy danych SQL, tzw. wirtualną maszynę SQL - aplikację, która na określone zapytania SQL wysyła zdefiniowane odpowiedzi. Działanie takiego wirtualnego zasobu można sparametryzować tak, aby służył różnym testom, na różnych poziomach testowania, dla różnych zespołów, a nawet - jeśli udostępnimy go w chmurze - w różnych częściach świata!

Budowanie wirtualnego środowiska testowego składa się z trzech etapów:

Nagrywanie

Celem tej fazy jest rejestracja działania na poziomie protokołu i interfejsu komunikacyjnego, potrzebnego do integracji i testów aplikacji tak, aby móc je następnie, w fazie trzeciej, dostarczyć innym.

- Jeśli ma się dostęp do systemu, którego działanie chce się wirtualizować, narzędzie do wirtualizacji, skonfigurowane jako serwer pośredniczący (proxy), rejestruje strumienie wiadomości płynących do i z aplikacji i zapisuje je w celu późniejszego odtworzenia.

- Wirtualizator może też pozyskiwać zgromadzoną w logach transakcji informację o sekwencjach komunikatów (diagramy sekwencji) i na jej podstawie tworzyć scenariusze swojego działania.

- Jeśli system, którego zachowanie chce się wirtualizować, jeszcze nie istnieje, można to zachowanie i tak zdefiniować w wirtualizatorze, wykorzystując do tego specyfikację jego interfejsu.

Konfiguracja

Stworzony w fazie pierwszej wirtualny zasób można następnie udoskonalać i dostosowywać (kalibrować) do różnych zastosowań. Szczególnie przydatne może być konfigurowanie i symulowanie różnych awarii - niepoprawnych działań systemu, trudnych do zrealizowania na prawdziwym systemie, a niezbędnych do osiągnięcia pełnego pokrycia testowego wymagań.

Dostarczanie

Dostawa funkcjonalności wirtualnego zasobu (wirtualnego środowiska testowego) może być zarówno lokalna, jak i globalna. W globalnych, rozproszonych projektach jeden symulator - wirtualny zasób - można wykorzystywać zarówno do testów jednostkowych, systemowych -funkcjonalnych - jak i do testów wydajności

Wirtualne środowisko testowe może służyć zarówno do testów wykonywanych ręcznie, jak i automatycznych.

Nadchodzi zmiana

Jak każde duże usprawnienie wdrożenie wirtualnych środowisk testowych nie spotka się od początku z jednoznacznie entuzjastycznym przyjęciem. Jest armia ludzi przywykłych do obecnego stanu rzeczy, ba - czerpiących uzasadnioną, zawodową dumę z radzenia sobie wśród chaosu, trwogi i drżenia, potu, krwi i łez. Trzeba pamiętać jednak o tym, że rozwiązania wirtualne będą coraz powszechniejsze.

Wirtualne środowiska testowe znajdują się obecnie w takiej samej fazie rozwoju jak chmura obliczeniowa dziesięć lat temu. Dlatego warto wskoczyć do tego pociągu już dzisiaj, zanim na peronie zrobi się tłoczno.

Bogdan Bereza jest dyrektorem zarządzającym w firmie Victo.