Strona 1 z 13 Na ostrzu chmury Nadciąga rewolucja w IT: jednorazowe środowisko testowe na zamówienie! Stare potrzeby, nowe technologie Przenośny, kieszonkowy telefon jest dziś czymś tak oczywistym, że wprost trudno sobie przypomnieć, jak kiedyś dało się żyć bez niego. Przecież on zaspokaja prastarą ludzką potrzebę, żeby się dogadać, porozumieć, dowiedzieć na czas. Komórka wyparła bo jest sprawniejsza i skuteczniejsza - afrykańskie tam-tamy, indiańskie sygnały dymne, kanaryjski język gwizdów silbo, posłańca spod Maratonu i sygnalizację semaforami, stosowaną w napoleońskiej Francji. Gdyby przy pomocy maszyny czasu przenieść w dzień dzisiejszy grupę ludzi sprzed 10.000 lat, zastosowanie telefonu komórkowego pojęliby w mig. Kiedy jednak nowa technologia pojawia się po raz pierwszy, niełatwo dostrzec jej oczywistość. Czujemy się wręcz zawstydzeni, że kłopoty, które wcześniej pochłaniały tyle czasu i trudu, można rozwiązać w tak porażająco prosty sposób. Czemu nikt tego nie wymyślił wcześniej? Czy to może być aż takie proste? O takiej technologii jest ten artykuł. O tym, jak przy jej pomocy można już dziś wyprzedzić innych, zamiast za kilka lat ścigać w pocie czoła uciekającą konkurencję. Co jest największą przeszkodą w projektach informatycznych? Pochwała chaosu No właśnie, co? Zanim odpowiem, przyznam się do pewnej słabości: otóż fascynuje mnie bałagan i niepowodzenia rozmaitych przedsięwzięć. Z wypiekami na twarzy czytam, albo oglądam w telewizji informacje o tym, że nie udało się zorganizować na czas pierwszego meczu na Stadionie Narodowym w Warszawie, że do oficjalnego otwarcia jakiegoś nowego mostu zabrakło dwóch zezwoleń i trzeba teraz na nie czekać kolejny miesiąc, a już prawdziwą frajdę sprawiało mi obserwowanie nieprawdopodobnego zamieszania, jakie pojawiło się w związku w wdrożeniem niedopracowanej ustawy refundacyjnej! Za każdym razem dziwię się jak można było o czymś tak oczywistym nie pomyśleć zawczasu? Jak można było nie sprawdzić zawczasu, czy coś będzie działać? Ależ można było sprawdzić wcześniej pod dwoma warunkami!
Bogdan Bereza Na ostrzu chmury, strona 2 z 13 Niech żyją wymagania! Pierwszy warunek, to potrzeby, nawyki, metody i narzędzia, aby przed przystąpieniem do działania starannie zaplanować i opisać, co też właściwie chce się osiągnąć. Mówiąc językiem IT pod warunkiem, że starannie zbiera się i opisuje wymagania. Tak, deficyt inżynierii wymagań jest główną przyczyną niepowodzeń projektów, choć większość wciąż jeszcze łudzi się, że można wykręcić się sianem i chować głowę w piasek modnych metodyk zwinnych oraz technologicznych nowinek. Dlaczego nie pomyślano, zawczasu znów wykorzystam przykład nieszczęsnego Stadionu Narodowego że policja będzie chciała korzystać w jego kazamatach ze swoich krótkofalówek? Domyślam się, że to był temat zbyt banalny, nieatrakcyjny w porównaniu z rozsuwanym dachem i innymi cudami techniki. Znamy, oj, znamy dobrze analogiczne sytuacje z przedsięwzięć informatycznych! Tak zwane oczywiste wymagania, niejednakowo oczywiste dla każdego, są najczęściej przyczyną dużych kłopotów. Zabrakło inżyniera wymagań! Jednak chcąc nie chcąc, jesteśmy dziś wszyscy na progu epoki dramatycznego wzrostu znaczenia inżynierii wymagań, więc więcej ta ten temat w moim następnym artykule w kolejnym numerze SDJ. i niech żyją próby przed premierą Jak najlepszy nawet scenariusz nie zastąpi aktorom prób, tak i najdoskonalsze wymagania nie są gwarancją, że podczas budowy systemu wszystko się powiedzie. Trzeba więc testować, trzeba sprawdzać, a im wcześniej, tym lepiej. Żeby jednak móc dokonać takiego próbnego rozruchu systemu informatycznego, trzeba mieć do dyspozycji odpowiednie środowisko, dane testowe, możliwość symulowania brakujących jeszcze kawałków systemu oraz innych systemów. Nieznośna ciężkość najprostszych spraw Dziesiątki razy pytałem testerów, zespoły i działy testowania, z czym mają największe kłopoty? Co zajmuje najwięcej czasu? Odpowiedzi są aż nużąco niezmienne. Po pierwsze, wymagania: są niejasne, nieprecyzyjne, wciąż się w niekontrolowany sposób zmieniają, a o większości ich i tak dowiadujemy w ostatniej chwili. Po drugie, środowisko testowe, któremu poświęcona jest reszta artykułu. Problemy ze środowiskiem naprawdę potrafią sparaliżować projekty! Kiedy to zrozumiemy, zrozumiemy także, że opisana dalej, przełomowa technologia wirtualnych środowisk testowych, to nie kolejna pseudo-nowość, nie atrakcyjny gadżet, tylko rzeczywista rewolucja, na miarę telefonu komórkowego! Najpierw powoli, jak żółw, ociężale typowe kłopoty ze środowiskami testowymi Typowe kłopoty ze środowiskami testowymi to one pochłaniają nawet 50% czasu i budżetu projektów.
Bogdan Bereza Na ostrzu chmury, strona 3 z 13 Kłopot 1: koszty środowiska testowego Środowisko testowe kosztuje: sprzęt, oprogramowanie, administrowanie, kopie zapasowe, a przede wszystkim konieczność jego modyfikacji, dostosowywania. Każda zmiana oprogramowania wymaga przecież przetestowania środowisko testowe to państwo w państwie, to często drugi, równoległy projekt! Kiedy w skład środowiska wchodzą komputery typu mainframe i tera-bajtowe bazy danych co jest typowe dla wszelkich systemów ERP, dla banków, dla firm ubezpieczeniowych koszty mogą przebić barierę dźwięku! Tradycyjne środowisko testowe? Kłopot 2: odpowiedzialność za środowisko testowe Typowy przykład kłopotów z rozproszeniem odpowiedzialności: 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, ale niemiłym zaskoczeniem jest konieczność samodzielnego nim administrowania. Inne przykłady: Zespół testowy ma mnóstwo trudności z uzyskaniem odpowiednich konfiguracji, uprawnień, haseł: wiecznie stoją, jako petenci, w kolejce do sys-adminów! Różni użytkownicy różne zespoły testowe nawzajem niechcący psują sobie środowisko testowe i jego konfigurację. Zajmuje to mnóstwo czasu i powoduje wiele złej krwi. Administrator systemu ma nawał zajęć, jest przede wszystkim odpowiedzialny za działanie środowiska produkcyjnego. Testerzy stoją w kolejce i tracą czas. Administrator też traci czas na realizację ich nietypowych wymagań i potrzeb.
Bogdan Bereza Na ostrzu chmury, strona 4 z 13 Kłopot 3: dublowanie środowisk Dublowanie środowisk to zbyt łagodne określenie, bowiem 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 (czytaj: prawdziwymi), do testów systemowych; środowisko przed-produkcyjne, kopię środowiska produkcyjnego, specjalne środowisko testów szybkiej ścieżki Można się zżymać, że w ogłoszeniach o miejscach pracy dla testerów zwykle więcej jest nieistotnych na pozór, detalicznych wymagań technicznych wobec kandydatów, niż wymagań dotyczących umiejętności metodycznych. Przecież tego każdy może się szybko nauczyć! To prawda, tylko że projekt jęczący pod miażdżącym ciężarem kłopotów technicznych nie ma czasu na wyrafinowane metody, potrzebuje ludzi do łopaty i do noszenia ciężarów, mogących pomóc już, natychmiast, a nie proponować usprawnienie procedur czy ulepszenie metod projektowania przypadków testowych! Kłopot 4: dostęp do środowiska Nie chcę, aby ten artykuł zamienił się z zbiór smakowitych anegdot, więc podam tylko kilka przykładów, że z dostępem do środowiska testowego zawsze były, i nadal są kłopoty. Czytelnicy niech przypomną sobie podobne historie z własnego doświadczenia! Latem lubiliśmy siedzieć w tym laboratorium, bo centrala telefoniczna wymagała klimatyzacji. Zimą było mniej przyjemnie Po stworzeniu możliwości zdalnego dostępu pojawiły się kłopoty z nadzorowaniem, kto w danej chwili co robi, jakie zasoby wykorzystuje. Rozwiązaniem okazała się 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 i zaliczeniu obowiązkowej partyjki ping-ponga ( u nas nie działa a u mnie działa i tak dalej), coraz częstszymi gośćmi w laboratorium testowym stali się programiści - łowcy bugów. U nich rzeczywiście działało i odtworzyć awarię mogli tylko na środowisku testowym. Ustalenie zasad współżycia społecznego zajmuje wtedy dużo czasu. Kłopot 5: symulowanie Stworzenie symulatora (emulatora), to zwykle osobny, duży projekt, a jego nieustanne symulatora pochłaniają mnóstwo pracy. Co gorsza, każdorazowy negatywny wynik testu oznacza żmudną pracę sprawdzania, co też działa niepoprawnie testowana aplikacja, czy symulator? Czasem projekt buduje więcej symulatorów, niż samego oprogramowania! Kiedy podsystem A buduje się i testuje w jednym miejscu, a podsystemy B i C w innych, to zespół piszący A posługiwał się własnymi symulatorami B i C, zespół B symulatorami A i C i tak dalej. Było to, delikatnie mówiąc, kłopotliwe, kosztowne i powodowało mnóstwo błędów.
Bogdan Bereza Na ostrzu chmury, strona 5 z 13 Istnieje armia ludzi już 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! Jak każde duże usprawnienie, wdrożenie wirtualnych środowisk testowych nie spotka się od początku z jednoznacznie entuzjastycznym przyjęciem. Przeciwko jego zastosowaniu pojawią się argumenty techniczne i organizacyjne tak wyrafinowane, że nikt nawet autorzy - nie będzie w stanie ich zrozumieć. Trzeba pamiętać to nie jest wcale żart! że jest armia ludzi już 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. Dlatego, jak spostrzegł niedawno profesor Martin Tornquist, właściciel największej w Brazylii 1 firmy oferującej usługi w zakresie testowania oraz inżynierii wymagań, o wiele łatwiej jest przekonać dyrektora finansowego firmy (CFO), niż dyrektora IT (CIO) do tego, że warto zainwestować w inżynierię wymagań i w testowanie. Finansowy widzi koszty pracochłonnego działu IT, które można zmniejszyć, podczas gdy techniczny z nich żyje Projekty rozproszone, usługi internetowe, SOA, i chmura Każdy z terminów użytych w tytule tego akapitu oznacza, że kłopoty, opisane wcześniej, wzmagają się jeszcze wielokrotnie. Dlatego właśnie ludzka odporność na kłopoty ze środowiskami testowymi zaczęła się wyczerpywać i pojawiło się rozwiązanie wirtualizacja środowisk testowych. Rosnąca złożoność systemów informatycznych 1 Niech nikogo nie zwiedzie, że Brazylia to jakoby trzeci świat. Brazylia jest obok Chin i Indii jedną z najszybciej rosnących gospodarek świata. W roku 2010 osiedliło się w tym kraju kilkadziesiąt tysięcy specjalistów IT z Europy, uciekających przed naszym kryzysem. Brazylijczycy patrzą na Europę jak na gromadę wojowniczych plemion, chwilowo w stanie zawieszenia broni, zwanego Unią Europejską, i czekają, aż znowu rzucimy się sobie do gardeł
Bogdan Bereza Na ostrzu chmury, strona 6 z 13 Wirtualizacja racja, pożytek z niej! Symulacja, czyi zastępowanie niedostępnego fragmentu systemu informatycznego prostszym, łatwiej dostępnym, tańszym modelem, symulatorem czy emulatorem, jest stosowana od lat. Wirtualizacja to tylko ładniejsza nazwa na to samo. Pomysł, aby brakujący czy kosztowny kawałek środowiska testowego zastąpić jego wirtualną namiastką nie jest niczym nowym: ma tyle lat, co informatyka i budowanie systemów. Tylko, że jest to w tradycyjnej formie metoda kłopotliwa i kosztowna, co - mam nadzieję - przekonująco opisałem w poprzednim rozdziale. Wirtualizację można jednak realizować o wiele, wiele prościej i to jest właśnie zapowiedzianą na początku artykułu nowością, która dziś nie jest jeszcze w pełni zrozumiała i doceniana, a za kilka lat trudno będzie wyobrazić sobie, 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 potrzebnych testów! Nie trzeba w ogóle 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, łatwiejsza do zbudowania, ma większą wydajność, jest też łatwiejsza do modyfikowania niż pełna, tradycyjna symulacja. Architektura wirtualizacji zachowania (wg Virtualization Journal 12 czerwca 2011)
Bogdan Bereza Na ostrzu chmury, strona 7 z 13 Co więcej, aby stworzyć taki symulator-wirtualizator, niekoniecznie trzeba samemu w pocie czoła pisać program, można bowiem posłużyć się metodą zarejestruj-odtwórz. Korzystając z krótkotrwałego dostępu do prawdziwej aplikacji, można przy pomocy wirtualizatora nagrać, jak ona komunikuje się 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 wytwarzania, będących dopiero w trakcie budowy; Niedostępnych lub kosztownych środowisk 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: duży projekt realizowany jest przez wiele częściowo 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, budującego rozproszony system: wirtualne środowisko testowe można udostępnić w trybie chmury, prywatnej lub publicznej. Jak naprawdę działa wirtualizator? Nie wirtualizuje się całej funkcjonalności całego komponentu czy systemu bazy danych, pakietu obliczeniowego, usługi internetowej (web service) podającej kursy walut, ani aplikacji ERP a tylko te jej 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, 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 określone 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 w różnych jeśli udostępnimy go w chmurze częściach świata!
Bogdan Bereza Na ostrzu chmury, strona 8 z 13 Budowanie wirtualnego środowiska testowego składa się z trzech etapów. Faza 1 nagrywanie Celem tej fazy jest rejestracja działania na poziomie protokołu, interfejsu komunikacyjnego potrzebnego do integracji i testów aplikacji tak, aby móc je następnie, w fazie 3, dostarczyć innym. Tworzenie wirtualnego środowiska testowego przy pomocy narzędzia Parasoft Virtualize Jeśli ma się dostęp do systemu, którego działanie chce się wirtualizować, narzędzie do wirtualizacji (odtąd będę je nazywał już tylko wirtualizatorem, ale proszę nie szukać tej nazwy w innych źródłach), skonfigurowane jako serwer pośredniczący (proxy) rejestruje strumienie wiadomości płynących do i od aplikacji, i zapisuje je w celu późniejszego odtworzenia. To działanie przypomina tworzenie skryptów do testów wydajności, poprzez nagrywanie testów wykonywanych ręcznie, przy użyciu popularnych narzędzi do automatyzacji testów obciążeniowych. Wirtualizator może też pozyskiwać informację o sekwencjach komunikatów (diagramy sekwencji) zgromadzoną w logach transakcji, 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.
Bogdan Bereza Na ostrzu chmury, strona 9 z 13 Faza 2 konfiguracja Stworzony w fazie 1-ej 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, bardzo trudnych do zrealizowania na prawdziwym systemie, a niezbędnych do osiągnięcia pełnego pokrycia testowego wymagań. Konfiguracja wirtualnego środowiska testowego przy pomocy narzędzia Parasoft Virtualize Faza 3 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 wówczas 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. Sterowanie wirtualnym środowiskiem testowym można wykonywać z wielu znanych narzędzi do zarządzania testami, komercyjnych i wolnodostępnych. Idzie nowe Pamiętacie, że ledwo pięć lat temu niemal nikt nie słyszał o żadnej chmurze obliczeniowej? Choć jej potrzebna technologia jest równie stara, jak Internet, zaś interesujące rozwiązania
Bogdan Bereza Na ostrzu chmury, strona 10 z 13 biznesowe dostarczane w trybie Platform as a Service (PaaS) też istnieją od dziesięciu lat, to jednak modne (i nadużywane 2 ) pojęcie chmury rozpowszechniło się znacznie później. Wirtualne środowiska testowe znajdują się obecnie w takiej samej fazie rozwoju, co chmura obliczeniowa dziesięć lat temu. Dlatego warto wskoczyć do tego pociągu już dzisiaj, zanim na peronie zrobi się tłoczno! Wirtualne środowiska testowe pojawiły się jako osobne produkty dość niedawno, trzy lata temu, na razie w niewielkiej skali, zainicjowane przez inteligentne firmy średniej wielkości. Parasoft (www.parasoft.com) oferuje narzędzie Parasoft Virtualize 3. ITKO (www.itko.com) oferuje narzędzie LISA 4. Schemat działania platformy LISA 2 Picceria, czyli antropologia IT : http://www.computerworld.pl/artykuly/364434/picceria.czyli.antropologia.it.html 3 http://www.parasoft.com/jsp/products/virtualize_splash.jsp 4 http://www.itko.com/solutions/lisa.jsp
Bogdan Bereza Na ostrzu chmury, strona 11 z 13
Bogdan Bereza Na ostrzu chmury, strona 12 z 13 Green Hat (www.greenhat.com) oferuje GH VIE (Virtual Integration Environment) 5. Schemat działania platformy Green Hat Ale już dinozaury też poczuły świeży pokarm! ITKO zostało zakupione przez CA 6. Green Hat został przejęty przez IBM 7. HP oferuje własne rozwiązanie server virtualization solutions 8 5 http://www.greenhat.com/products/ghvie.html 6 http://www.ca.com/us/content/integration/itko.aspx 7 http://www-01.ibm.com/software/rational/welcome/greenhat/ 8 http://www.hp.com/sbso/serverstorage/article/virtualization-oct.html
Bogdan Bereza Na ostrzu chmury, strona 13 z 13 Pierwszy krok w chmurach Opowiadanie Marka Hłaski pod tym samym tytułem można potraktować jako ostrzeżenie, żeby nowe, wspaniałe sprawy rozpoczynać w odpowiedni, bezpieczny sposób. Jak posmakować wirtualizację środowiska testowego, nie ryzykując kosztowego niepowodzenia? Oczywiście w chmurze! Współfinansowany ze środków unijnych serwis B2B Concerto projekt testowania w chmurze, współfinansowany w ramach PO IG 8.2 oferuje po zarejestrowaniu się bezpłatny, zdalny dostęp do rozwiązania Parasoft Virtualize w okresie próbnym, bez konieczności instalowania czegokolwiek. Dostęp do serwisu B2B Concerto najprościej uzyskać przez portal B2B Concerto, dostępny przez lub przez portal V!cto (victo.eu/b2b). Bogdan Bereza, V!cto, bogdan.bereza@victo.eu