Projekt okładki Hubert Zacharski

Ilustracja na okładce Shutterstock/olegganko

Wydawca Łukasz Łopuszański

Redaktor prowadzący Adam Kowalski

Redaktor Joanna Forysiak

Koordynator produkcji Anna Bączkowska

Skład wersji elektronicznej na zlecenie Wydawnictwa Naukowego PWN Marcin Kapusta / konwersja.virtualo.pl

Zastrzeżonych nazw firm i produktów użyto w książce wyłącznie w celu identyfikacji.

Książka, którą nabyłeś, jest dziełem twórcy i wydawcy. Prosimy, abyś przestrzegał praw, jakie im przysługują. Jej zawartość możesz udostępnić nieodpłatnie osobom bliskim lub osobiście znanym. Ale nie publikuj jej w internecie. Jeśli cytujesz jej fragmenty, nie zmieniaj ich treści i koniecznie zaznacz, czyje to dzieło. A kopiując jej część, rób to jedynie na użytek osobisty.

Szanujmy cudzą własność i prawo

Więcej na www.legalnakultura.pl

Polska Izba Książki

Copyright © by Wydawnictwo Naukowe PWN SA

Warszawa 2018

eBook został przygotowany na podstawie wydania papierowego z 2018 r., (wyd. I)

Warszawa 2018

ISBN 978-83-01-19754-4

Wydawnictwo Naukowe PWN SA

02-460 Warszawa, ul. Gottlieba Daimlera 2

tel. 22 69 54 321, faks 22 69 54 288

infolinia 801 33 33 88

e-mail: pwn@pwn.com.pl, reklama@pwn.pl

www.pwn.pl

Spis treści

Przedmowa
Karolina Zmitrowicz, Adam Roman

Część I. Organizacja i procesy

1. Połączenie dwóch światów. Zmiany w organizacji zarządzania kontrolą jakości w warunkach połączenia firm
Adam Romanowicz

1.1. Wstęp

1.2. Opis przypadku

1.2.1. Cele przejęcia firm

1.2.2. Charakterystyka firm kupujących

1.2.3. Charakterystyka firm kupowanych

1.2.4. Główne wyzwania z punktu widzenia firmy kupującej

1.2.5. Główne wyzwania z punktu widzenia firmy kupowanej

1.2.6. Główne wyzwania z punktu widzenia przejmowanych klientów

1.2.7. Główne wyzwania z punktu widzenia architekta systemu

1.2.8. Główne wyzwania z punktu widzenia inżynierii testów

1.3. Skalowanie systemu

1.3.1. Cel

1.3.2. Opis problemów

1.3.3. Faza 0 – stan testów niefunkcjonalnych po przejęciu firmy

1.3.4. Faza 0 – wyniki

1.3.5. Faza 0 – wnioski

1.3.6. Faza 1 – pierwsze podejście do wprowadzenia skutecznych praktyk inżynieryjnych

1.3.7. Faza 1 – wyniki

1.3.8. Faza 1 – wnioski

1.3.9. Faza 2 – dalszy rozwój testów obciążeniowych

1.3.10. Faza 2 – wyniki

1.3.11. Faza 2 – wnioski

1.3.12. Faza 3 – dalszy rozwój i wnioski

1.3.13. Wnioski końcowe

1.4. Zarządzanie błędami

1.4.1. Opis przypadku

1.4.2. Perspektywa firmy kupionej

1.4.3. Perspektywa firmy kupującej

1.4.4. Podjęte kroki wewnątrz organizacji

1.4.5. Perspektywa klienta

1.4.6. Podjęte kroki dotyczące współpracy z klientem

1.4.7. Wnioski

1.5. Wartość testów eksploracyjnych

1.5.1. Połączenie dwóch podejść

1.5.2. Wnioski

1.6. Nowy tryb pracy z klientem w obszarze testów

1.6.1. Opis problemu

1.6.2. Cel

1.6.3. Podjęte działania

1.6.4. Wnioski

1.7. Zakończenie procesu przejęcia firmy

1.7.1. Opis problemu

1.7.2. Zatrzymanie się w połowie drogi

1.7.3. Jak skutecznie zakończyć proces przejęcia firmy

O autorze

2. Trudna współpraca z klientem
Bartłomiej Prędki, Karolina Zmitrowicz

2.1. Wstęp

2.2. Punkt widzenia dostawcy oprogramowania

2.3. Rodzaje testów przeprowadzanych przez klienta

2.4. Wady i zalety przeprowadzania testów przez zespół klienta

2.4.1. Wady

2.4.2. Zalety

2.5. Zasady współpracy z zespołem klienta

2.6. Studium przypadku

2.6.1. Podejście do testów

2.6.2. Środowiska testowe

2.6.3. Organizacja pracy zespołów testerskich

2.6.4. Wyniki

2.7. Podsumowanie

O autorach

3. Zabezpieczenie środków budżetowych na rozbudowę zespołu testowego
Maciej Chmielarz

3.1. Wyzwanie

3.2. Budżet nie jest z gumy

3.3. Testowanie nie jest oczywiste

3.4. Dobre praktyki nie przekonują

3.5. Zastosowanie nie jest jasne

3.6. Jest rola do spełnienia

3.7. Efekt końcowy

O autorze

Część II. Testowanie systemów specyficznych

4. Powiedz to głośno – jak skutecznie wprowadzić użyteczne usprawnienia w aplikacji
Aleksandra Pirek, Aleksandra Sasin

4.1. Charakterystyka projektu i problemu do rozwiązania

4.2. Problemy, przed którymi stanęłyśmy

4.2.1. Od czego wszystko się zaczęło

4.2.2. Wiecznie chodzi o czas

4.2.3. Budżet?

4.2.4. Zespół

4.3. Nasza historia

4.3.1. Aplikacja webowa

4.3.2. Stara aplikacja mobilna

4.3.3. Nowa aplikacja mobilna – Android

4.3.4. Raporty i wykresy

4.4. Podejścia, techniki i technologie

4.4.1. UX (ang. user experience) a użyteczność (ang. usability)

4.4.2. Techniki testowania użyteczności

4.5. Przebieg badania użyteczności

4.5.1. Przygotowanie do testów – plan

4.5.2. Lista kontrolna

4.5.3. Zdefiniowanie person – rzecz z pogranicza projektowania i testów użyteczności

4.5.4. Rekrutacja użytkowników

4.5.5. Przygotowanie scenariuszy testowych

4.5.6. Komunikacja mailowa

4.5.7. Oświadczenia

4.5.8. Przygotowanie obserwatorów

4.5.9. Think Aloud (powiedz to głośno) – sesja z użytkownikiem

4.5.10. Role w testach użyteczności

4.5.11. Zebranie informacji zwrotnej po zakończonej sesji – ankiety

4.5.12. Wnioski i zalecenia

4.5.13. Spotkanie z biznesem

4.5.14. Wprowadzenie zmian

4.6. Nasze rozwiązanie

4.6.1. Testy użyteczności aplikacji webowej

4.6.2. Testy użyteczności aplikacji mobilnej

4.6.3. Testy użyteczności na prototypach i makietach

4.7. Wynik podjętych działań

4.8. Aplikacja webowa

4.9. Aplikacja mobilna

4.10. Raporty i wykresy

4.11. Podsumowanie

O autorkach

5. Umysł testujący: studium przypadków mobilnych
Aleksandra Kornecka

5.1. Wstęp – dlaczego powstał ten rozdział i dlaczego warto go przeczytać

5.2. Charakterystyka projektów mobilnych oraz częste typowe problemy spotykane w takich projektach

5.3. Podejście, które odpowiada na problemy oraz pomaga zapewnić jakość projektu mobilnego

5.4. Teoria Marra – przetwarzanie informacji wzrokowej

5.5. Teoria Gestalt – sposób postrzegania elementów widoku

5.6. Teoria Jamesa J. Gibsona – oferty (afordancje) błędów ukryte w aplikacji

5.7. Znajomość gestów natywnych dla danego systemu

5.8. Wynik kognitywistycznego podejścia do testowania

5.9. Wnioski i rekomendacje

5.10. Aneks – testerska pomocnicza lista kontrolna

O autorce

Część III. Testowanie sprzętu i infrastruktury

6. Testowanie sprzętu
Adam Stankiewicz

6.1. Wprowadzenie

6.2. Koncept, dokumentacja, przygotowania do testowania

6.3. Poziomy testów

6.3.1. Testowanie modułowe

6.3.2. Testowanie początkowe – smoke test

6.3.3. Testowanie integracyjne

6.3.4. Testowanie weryfikacyjne

6.3.5. Testowanie długoterminowe

6.3.6. Testowanie równoległe integracyjno-weryfikacyjne

6.4. Typy testów

6.4.1. Testy manualne

6.4.2. Testy automatyczne

6.5. Techniki testowania

6.5.1. Techniki oparte na specyfikacji (czarnoskrzynkowe)

6.5.2. Techniki oparte na strukturze (białoskrzynkowe)

6.5.3. Techniki oparte na usterkach

6.5.4. Techniki oparte na doświadczeniu

6.6. Rodzaje testów

6.6.1. Testy wydajnościowe

6.6.2. Testy obciążeniowe

6.6.3. Testy przeciążające

6.7. Proces testowy

6.7.1. Planowanie testów

6.7.2. Zarządzanie testami

6.7.3. Kryterium zakończenie testów i ich ocena

6.7.4. Testowanie kolejnych wersji sprzętu

6.8. Wnioski

O autorze

7. Testowanie nowej technologii sieci komórkowej
Ewa Marchewka, Wojciech Anzel

7.1. Opis przypadku

7.2. Problemy komunikacyjne i kulturowe

7.2.1. Problemy z przekazywaniem wiedzy – szkolenie nowego zespołu

7.2.2. Problemy podczas współpracy w wielonarodowościowym zespole: różnice kulturowe

7.3. Problemy procesowe

7.3.1. Proces dostarczania oprogramowania

7.3.2. Zmiana produktu i narzędzi

7.3.3. Współpraca z bliźniaczą organizacją

7.3.4. Rola testera w zespole

7.4. Problemy młodej organizacji i produktu

7.4.1. Nowy zespół

7.4.2. Problemy ze sprzętem

7.4.3. Optymalizowanie testów w środku wydania

7.4.4. Automatyzacja testów

7.5. Analiza końcowa

7.5.1. Jakość produktu

7.5.2. Wnioski co do automatyzacji

7.5.3. Czynnik ludzki

7.5.4. Niedojrzałość sprzętu

7.6. Podsumowanie

O autorach

Część IV. Metody i techniki

8. BDD i Continuous Integration w projekcie – korzyści, problemy i rozwiązania
Rafał Nazwalski

8.1. Wstęp

8.2. Charakterystyka projektu – dlaczego Behaviour Driven Development

8.3. Korzyści z BDD i CI

8.4. Problemy z wdrożeniem BDD. Rola utrzymania testów

8.5. Sposoby powrotu na właściwy tor

8.6. Wnioski

O autorze

9. Automat do automatów, czyli jak wygenerować kod w kilka sekund
Natalia Krawczyk-Grzegorzewicz

9.1. Wprowadzenie

9.2. Automatyzacja tworzenia kodu

9.3. Podsumowanie

O autorce

Przypisy

Przedmowa
Karolina Zmitrowicz, Adam Roman

Z przyjemnością oddajemy do rąk Czytelników drugą część Testowania w praktyce. Studium przypadków. Po życzliwym przyjęciu i przychylnych opiniach o części pierwszej zrozumieliśmy, że projekt polegający na opisywaniu testowania z czysto praktycznego punktu widzenia – przez praktyków dla praktyków – jest zdecydowanie wart kontynuacji. Społeczność testerska w Polsce rośnie w bardzo szybkim tempie. Przybywa początkujących testerów, którzy jak najszybciej chcą zdobyć wiedzę i doświadczenie. Z kolei ci z dłuższym stażem pracy nieustannie szukają źródeł inspiracji dla swojej codziennej pracy w obszarze jakości oprogramowania. Mamy nadzieję, że niniejsza książka przynajmniej w jakimś stopniu przyczyni się do osiągnięcia tych celów.

Monografia składa się z dziewięciu rozdziałów podzielonych na cztery części.

Organizacja i procesy. W tej części opisano zagadnienia związane z mniej lub bardziej nietypowymi aspektami zarządzania projektem testowym oraz kwestie psychologiczne – często niedoceniane, lecz niezwykle istotne w codziennej pracy testera.

W artykule Połączenie dwóch światów. Zmiany w organizacji zarządzania kontrolą jakości w warunkach połączenia firm Adam Romanowicz przedstawia ciekawy przypadek problemów zarządzania jakością w sytuacji połączenia kilku firm. Tekst skupia się nie tylko na sukcesach, lecz także zagrożeniach i kłopotach, jakie sprawiło przyjęcie takiej, a nie innej strategii do definiowania procesu w połączonej organizacji.

Rozdział Trudna współpraca z klientem Bartłomieja Prędkiego i Karoliny Zmitrowicz to z kolei studium przypadku skupiające się na skomplikowanych relacjach z klientem w kontekście wykonywania testów. Poza opisaniem teoretycznych zagadnień związanych z tym problemem Autorzy przedstawiają studium przypadku dla projektu, w którym brali udział.

W ostatnim rozdziale tej części, Zabezpieczenie środków budżetowych na rozbudowę zespołu testowego, Maciej Chmielarz przedstawia z pozoru prostą kwestię zatrudniania nowych testerów do zespołu. Jednak, jak się okazuje, aby skutecznie przekonać menedżerów o konieczności powiększenia zespołu, trzeba wykorzystać wiedzę z zakresu podstaw testowania, co często jest zaniedbywane.

Testowanie systemów specyficznych. Piękno testowania polega na tym, że jego poszczególne obszary to praktycznie zupełnie odmienne światy – inne podejścia, technologie, metody, sposoby działania. W tej części opisano zagadnienia dotyczące dwóch takich światów: testowania użyteczności oraz testowania urządzeń mobilnych.

Aleksandra Pirek i Aleksandra Sasin w bardzo obszernym rozdziale Powiedz to głośno – jak skutecznie wprowadzić użyteczne usprawnienia w aplikacji przedstawiają wyczerpujące studium testowania użyteczności systemów do zarządzania magazynami. To pouczający, praktyczny wykład na temat tego, jak powinno się przeprowadzać testy użyteczności zgodnie ze sztuką.

Aleksandra Kornecka w artykule Umysł testujący: studium przypadków mobilnych przedstawia kognitywistyczne podejście do testowania aplikacji moblinych.Omawia kilkanaście praktycznych problemów, z jakimi spotykają się testerzy tego typu aplikacji, a także proponuje ich rozwiązania.

Testowanie sprzętu i infrastruktury. Część trzecia publikacji poświęcona jest zagadnieniom rzadko pojawiającym się w fachowej literaturze czy też na różnych konferencjach testerskich, mianowicie testowaniu sprzętu oraz złożonych, skomplikowanych systemów stanowiących rozbudowaną infrastrukturę.

Adam Stankiewicz w artykule Testowanie sprzętu przedstawia metodycznie klasyczne zagadnienia testowe: poziomy i typy testów, techniki testowania, rodzaje testów i proces testowy. Opisuje je jednak w bardzo specyficznym kontekście – testowania sprzętu. Sprawia to, że wiele z tych kwestii staje się nieoczekiwanie trudniejsze lub po prostu odmienne od ich „software’owej” wersji.

Ewa Marchewka i Wojciech Anzel przedstawiają równie wymagające wyzwania związane z testowaniem stacji nadawczych sieci komórkowych, a więc de facto z testowaniem infrastruktury sieci telekomunikacyjnych. Ten typ testowania również niesie ze sobą wiele problemów nieobecnych w „klasycznej” kontroli jakości.

Metody i techniki. Ostatnia część niniejszej publikacji poświęcona jest specyficznym technikom stosowanym w testowaniu. Oba rozdziały wchodzące w jej skład przedstawiają pewne podejścia do automatyzacji testowania.

Rozdział Rafała Nazwalskiego BDD i Continuous Integration w projekcie – korzyści, problemy i rozwiązania jest dobrym wprowadzeniem do BDD i CI dla testerów, którzy nie mieli do tej pory do czynienia z tymi podejściami. Autor omawia te metody w kontekście produktu opartego na architekturze mikroserwisów.

Ostatni rozdział, autorstwa Natalii Krawczyk-Grzegorzewicz, zatytułowany Automaty do automatów, czyli jak wygenerować kod w kilka sekund, przedstawia podejście do automatyzacji, które idzie o krok dalej niż to się zwykle robi. Autorka mianowicie pokazuje jak „automatyzować automatyzację” przez mechaniczną generację kodu do testów automatycznych.

***

Większość artykułów wchodzących w skład tej publikacji łączy jedno: przedstawiają one rzadko spotykane lub nietypowe sytuacje, w jakich przyszło Autorom wykonywać interesującą, ale jednocześnie trudną i pełną wyzwań pracę testera. Lektura tych tekstów będzie z pewnością pouczającym doświadczeniem. Bo testowanie takie właśnie jest: pełne niespodzianek, „dziwnych” problemów, nieoczekiwanych sytuacji, skomplikowanych problemów wymagających często wręcz detektywistycznych umiejętności. To fach trudny i wymagający, pełen pułapek i problemów, ale właśnie dlatego piękny i dający testerom wiele satysfakcji z jego wykonywania.

Każdy z Autorów tekstów tej publikacji stanął kiedyś właśnie przed takimi problemami i musiał sobie z nimi poradzić. Poszczególne rozdziały są zapisem ich dzielnej walki z trudną materią inżynierii jakości. Jako redaktorzy jesteśmy pełni podziwu dla ich inwencji, pomysłowości, zdolności analitycznych i technicznych, które wykorzystali podczas swojej pracy. Jeśli Autorzy ci są choć w części reprezentatywną próbką środowiska testerskiego w naszym kraju, to z pełnym przekonaniem możemy śmiało patrzeć na przyszłość testowania i zapewniania jakości w Polsce.

Część I

Organizacja i procesy

1
Połączenie dwóch światów. Zmiany w organizacji zarządzania kontrolą jakości w warunkach połączenia firm
Adam Romanowicz

1.1. Wstęp

Niniejszy artykuł przedstawia wybrane aspekty związane z kontrolą i zapewnianiem jakości, które musiały ulec zmianie w warunkach połączenia firm lub połączenia kupionej firmy z jednostką biznesową firmy kupującej. Artykuł ukazuje pozytywne, jak i negatywne konsekwencje działań podjętych w celu ujednolicenia podejścia do kontroli jakości w wyżej wymienionych warunkach.

Wybrane przykłady w większości przypadków stanowią element wspólny dla czterech operacji połączenia firm. Każda z tych operacji była inna pod względem procesu jej przeprowadzenia, regionu, kultury, skali operacji i jej celu. Oceniając te przedsięwzięcia z perspektywy czasu, na pierwszy plan wysuwa się skala zmian, jakie zachodzą w obydwu firmach (ze wskazaniem na firmę kupioną) w procesach, kulturze pracy, podejściu do klientów, jak i nastawieniu klientów przejętych wraz z zakupioną firmą. Kolejny widoczny aspekt to wzajemna edukacja i rozwój, które stanowią połączenie wiedzy i doświadczenia stron. W procesie tym rolę dominującą pełni firma kupująca. Tego typu przedsięwzięcia zmieniają wiele aspektów w organizacjach i w mniejszym lub większym stopniu dotyczą wszystkich działów, pracowników, procesów i narzędzi. Dodatkowym elementem mającym wpływ na te zmiany ma również technologia, w jakiej wykonane są produkty, a szczególnie jej potencjalne ograniczenia.

W artykule skupiono się na aspektach, które powtarzały się w każdym z branych pod uwagę przypadków przejęcia firm. Większość poruszanych tematów jest przedstawiana głównie z punktu widzenia działu rozwoju oprogramowania, z nastawieniem na dział kontroli jakości. Opisane zagadnienia przedstawiane są głównie z perspektywy pracowników zajmujących się inżynierią testów, począwszy od inżyniera testów, jednak głównie skupiają się na kadrze zarządzającej. Dlatego poruszane są tu tematy zarówno o małej skali i bezwładności, jak i te szersze, które mają duży wpływ na organizację, jakość produktu i trwają znacznie dłużej.

W tekście przedstawiono konieczne zmiany organizacyjne wewnątrz obu firm, z uwzględnieniem, tam, gdzie to możliwe i zasadne, perspektywwy jednego, jak i drugiego podmiotu oraz perspektywy klientów. Całość zagadnienia jest bardzo obszerna i wyczerpujące omówienie wszelkich aspektów związanych z zarządzaniem jakością oprogramowania w warunkach połączenia firm to temat na odrębną książkę. Dlatego artykuł zawiera tylko wybrane elementy, które wydają się najistotniejsze i skupiono się w nim na głównych i najbardziej widocznych zmianach.

Artykuł nie traktuje o aspektach związanych z ogólnym procesem zmiany w organizacji. Obszerna literatura dotycząca zarządzania zmianą, jak i wiedza z tego zakresu z pewnością będą pomocne w zrozumieniu kroków, jak i konsekwencji podawanych przykładów. Celem niniejszego artykułu nie jest opisywanie zmiany jako procesu, tylko konkretnych akcji oraz decyzji, które były konieczne do pozytywnego wdrożenia niezbędnych zmian w produktach przy odbywającym się w tle procesie przyłączenia jednej firmy do drugiej. Nie są celem artykułu różnice między małymi a dużymi organizacjami. Niemniej ze względu na zakres zagadnienia w sposób pośredni informacje na ten temat pojawiają się w tekście.

1.2. Opis przypadku

1.2.1. Cele przejęcia firm

Motywacje do przejęcia firm są rozmaite. W opisywanych przypadkach były to cele wymienione poniżej (jeden lub więcej, z pominięciem celów wykluczających się):

• uzyskanie patentów,

• próba wejścia na nowy rynek,

• rozszerzenie portfolio klientów przez przejęcie nowych klientów wraz z zakupionym produktem,

• wejście w posiadanie produktu z zamiarem dalszego jego rozwoju w celu uniknięcia potrzeby tworzenia go od podstaw,

• wzbogacenie wiedzy domenowej w celu dalszego rozwoju już posiadanych produktów,

• przejęcie produktu w celu rozszerzenia istniejącego portfolio produktów, aby uatrakcyjnić ofertę.

1.2.2. Charakterystyka firm kupujących

Firmy kupujące to międzynarodowe organizacje zatrudniające więcej niż 5000 pracowników i posiadające w swoim portfolio setki produktów oraz setki klientów. Firmy te mają wiele oddziałów na całym świecie i doświadczenie w prowadzeniu projektów w otoczeniu międzynarodowym uwzględniając aspekt wielokulturowości.

1.2.3. Charakterystyka firm kupowanych

Firmy przejmowane to organizacje, które zaczynały jako kilkuosobowe bądź kilkunastoosobowe przedsięwzięcia rozwijające oprogramowanie w ścisłej współpracy z jednym klientem, nierzadko w mniejszym lub większym stopniu przez niego finansowane. Miały one jeden bądź kilka zintegrowanych produktów i zatrudniały od 50 do 150 pracowników. Ich działania ograniczone były do jednego regionu geograficznego lub kraju, gdzie dysponowały jednym albo dwoma oddziałami.

1.2.4. Główne wyzwania z punktu widzenia firmy kupującej

• Dodanie kolejnego oddziału do już istniejących.

• Dodatkowy koszt związany z komunikacją ze względu na odległość geograficzną i różnice w strefie czasowej.

• Konieczność rozproszenia zespołu w celu dystrybucji wiedzy i ponowne zintegrowanie zespołu w jednej lokalizacji.

• Przejmowanie hermetycznego zespołu, który identyfikuje się z firmą macierzystą.

• Trudności w zaadaptowaniu się firmy kupowanej do praktyk firmy kupującej.

• Przejęcie produktu, który był rozwijany ze znacznie mniejszą dyscypliną inżynieryjną, co skutkuje między innymi problemami ze skalowalnością, utrzymaniem i dalszym rozwojem produktu.

• Przejęcie produktu, który w swoim założeniu nie był planowany na sprzedaż dla znacznie większych klientów niż ci, którzy obecnie go posiadają – czyli z założeniem przetwarzania znacznie większych ilości danych w tym samym czasie.

• Przejmowanie firmy z modelem biznesowym, który w swoim założeniu miał działać na znacznie mniejszą skalę, niż jest to oczekiwane przez firmę kupującą.

• Przejmowanie zespołu, który w większości ogranicza się do jednego kręgu kulturowego, co zwiększa jego hermetyczność.

1.2.5. Główne wyzwania z punktu widzenia firmy kupowanej

• Bezpieczeństwo zatrudnienia.

• Brak zrozumienia działania organizacji o większej skali:

– potencjalna konieczność zmiany istniejących praktyk i procesów, jak i wprowadzenia nowych,

– konieczność ograniczenia zakresu działania poszczególnych pracowników.

• Brak wiedzy i doświadczenia inżynieryjnego pozwalającego nadrobić zaległości technologiczne produktu.

1.2.6. Główne wyzwania z punktu widzenia przejmowanych klientów

• Konieczność formalizowania wszelkich aspektów współpracy.

• Ograniczenie dostępu do poszczególnych pracowników na rzecz działu wsparcia klienta.

• Dłuższy czas oczekiwania na wszelkie zapytania, a także na zmiany i poprawki w systemie.

• Mniejszy wpływ na dalszy rozwój produktu.

1.2.7. Główne wyzwania z punktu widzenia architekta systemu

• Systemy desktopowe napisane z użyciem technologii Microsoft w architekturze trójwarstwowej, gdzie warstwa prezentacji i warstwa logiki biznesowej stanowią jeden element. W niektórych przypadkach część logiki biznesowej była także zaimplementowana w bazie danych.

• Systemy typu klient–serwer z archaicznym podejściem typu „gruby klient” (ang. fat client applications).

• Brak jakichkolwiek dodatkowych interfejsów, API czy warstw pośrednich umożliwiających wykonywanie testów na poziomie niższym niż GUI.

• Powiększająca się ilość danych historycznych, które mają wpływ na wydajność systemu.

• Konieczność zmiany archaicznej architektury na potrzeby wewnętrzne (w celu ułatwienia utrzymania, rozwoju, testowania i skalowania systemu) i potrzeby rynku (nowe funkcjonalnoci i rozwiązania technologiczne).

• Potrzeba dostosowania produktu do przetwarzania znacznie większej ilości danych w tym samym czasie.

• Konieczność wprowadzenia nowych narzędzi kompatybilnych z technologią produktu.

1.2.8. Główne wyzwania z punktu widzenia inżynierii testów

• Brak usystematyzowanych procedur testowych.

• Nieuporządkowane i bardzo ograniczone artefakty testowe.

• Brak podstawowych metryk dotyczących jakości.

• Brak świadomości inżynierii testów.

• Brak pełnego zrozumienia problemu wydajności systemów informatycznych.

Mimo wielu braków, których lista ostatecznie jest znacząco dłuższa, istniały elementy, które z punktu widzenia inżynierii testów funkcjonowały bardzo dobrze.

• Wysoki poziom testów eksploracyjnych.

• Bardzo dobry, bezpośredni kontakt z klientem oraz współpraca z klientem w obszarze testów.

1.3. Skalowanie systemu

1.3.1. Cel

Dostosowanie produktu do przetwarzania większej ilości danych oraz obsługi większej liczby użytkowników przy zachowaniu bieżącego poziomu wydajności lub też poprawienie wydajności wybranych obszarów funkcjonalnych. Problem dotyczył systemu typu desktop używanego przez maksymalnie 100 użytkowników.

1.3.2. Opis problemów

Zakupione systemy były wykorzystywane przez klientów i poza sporadycznymi przypadkami klienci nie dostrzegali problemów wydajnościowych. Na obecnym segmencie rynku wydaje się, że inwestycja w testy wydajnościowe nie była konieczna. Jednak w omawianym przypadku proces biznesowy po stronie klienta wymaga ciągłego dostępu i przetwarzania nieustannie powiększającego się wolumenu danych historycznych. Dodatkowym wyzwaniem była chęć pozyskania klientów przetwarzających znacznie większe ilości danych z większą liczbą użytkowników, którzy korzystają z systemu w tym samym czasie.

1.3.3. Faza 0 – stan testów niefunkcjonalnych po przejęciu firmy

Zespół inżynierów rozwijających produkt w firmie, zanim została ona kupiona, stosował niestandardową praktykę wykonywania testów obciążeniowych. Polegała ona na tym, że grupa pracowników używała systemu w środowisku zbliżonym do środowiska klienta, podłączając się do systemu jednocześnie z wielu terminali. Celem była próba odzwierciedlenia rzeczywistego środowiska pracy i warunków produkcyjnych.

1.3.4. Faza 0 – wyniki

Koszt wykonania testów przy pięciogodzinnej pracy 25 ludzi, z uwzględnieniem trzykrotnego wykonania testów oraz narzutu na koordynację działań, wynosił prawie 400 godzin. Przełożyło się to na znalezienie mniej niż 10 błędów niefunkcjonalnych w systemie z ponad 3 milionami linii kodu oraz wieloletnimi zaległościami w obszarze niefunkcjonalnym, chociażby ze względu na rozwijanie systemu bez jakichkolwiek wymagań w tym zakresie.

Część znalezionych błędów okazała się pomyłką, a część miała bardzo niski priorytet. Ostatecznie zostały 3 błędy, które należało poprawić, nie licząc na możliwość ich zreprodukowania, co wynikało z tego, że ich znalezienie było uzależnione od zbyt wielu zmiennych oraz nieznanej korelacji parametrów środowiskowych.

1.3.5. Faza 0 – wnioski

Opisane wyżej podejście charakteryzowało się następującymi cechami.

• Wysoki koszt w porównaniu do potencjalnych zysków.

• Brak powtarzalności.

• Brak możliwości porównania wyników.

• Problemy z reprodukcją błędów.

• Problemy z debugowaniem.

• Brak wystarczających informacji na temat tego, co w zasadzie było przyczyną znalezionego błędu (związany również z niewystarczającym poziomem logowania i obsługi wyjątków).

1.3.6. Faza 1 – pierwsze podejście do wprowadzenia skutecznych praktyk inżynieryjnych

Bazując na opisie przypadku rozwijanego systemu, jak i głównych wyzwaniach z punktu widzenia architekta, można pokusić się o stwierdzenie, że szczególnie w obszarze niefunkcjonalnym był to system nietestowalny. W związku z tym prace nad rozwojem finalnego rozwiązania testów obciążeniowych musiały iść w parze z pracami nad zmianami architektonicznymi systemu. Przede wszystkim chodziło o rozdzielenie warstw prezentacji, logiki biznesowej i bazy danych oraz utworzenie interfejsów umożliwiających automatyzację testów z pominięciem GUI.

Na tym etapie zostały rozpoczęte inwestycje w rozdzielenie warstw, ale była to faza wstępna, więc jeszcze nie istniały wystarczające ułatwienia do pisania automatycznych testów obciążeniowych. Jednocześnie istniała duża potrzeba jak najszybszego znalezienia błędów, które będą przeszkodą w skalowaniu systemu. Było to związane z tym, że błędy niefunkcjonalne tego rodzaju w znakomitej większości przypadków wymagają dużo czasu i inwestycji w celu ich poprawy. Zdarza się, że w takich przypadkach, aby naprawić i usprawnić system, niezbędne są zmiany w jego architekturze.

W celu ograniczenia liczby czynników wpływających na potencjalnie negatywne wyniki testów oraz aby wyeliminować jeden ze znanych już problemów, pierwszym krokiem była implementacja mechanizmu archiwizacji danych historycznych w systemie i modułu do zarządzania archiwum. Dzięki temu rosnący wolumen danych nie był już czynnikiem mającym wpływ na pogorszenie wydajności systemu.

Aby uzyskać pierwsze wyniki w jak najkrótszym czasie, jednocześnie zapewniając powtarzalność testów, zdecydowano się użyć programu Load Runner, który w tym przypadku jako warstwę dostępu do systemu testowanego używał GUI MFC. Pierwsze próby pokazały, że możliwości, jakie daje Load Runner, były bardzo ubogie, jeśli chodzi o wachlarz działań, które można było wykonywać na GUI. Największym problemem okazała się jednak stabilność tego rozwiązania.

Load Runner działający na kilkudziesięciu instancjach systemu zainstalowanych na maszynach wirtualnych szybko tracił połączenie z kolejnymi serwerami. Doprowadzało to do sytuacji, w których testy zaczynały się z 50 instancjami systemu, a po godzinie wykonania Load Runner był w stanie wykonywać testy na maksymalnie 10 instancjach, co było dalece niewystarczające. Co prawda istniała możliwość ręcznego dołączania kolejnych maszyn w trakcie wykonywania testów, niemniej konieczność zastosowania obejść zamiast posiadania finalnego rozwiązania, które byłoby stabilne i przewidywalne, nie była satysfakcjonującym wynikiem. Poza tym celem była pełna automatyzacja.

Load Runner obsługuje wiele interfejsów, również w odniesieniu do GUI. Zdecydowano się zmienić warstwę komunikacji z programem Load Runner na Citrix. Okazało się, że liczba operacji, jakie można wykonać na GUI w takiej konfiguracji jest jeszcze bardziej uboga niż we wcześniejszym podejściu. Natomiast było to rozwiązanie bardziej stabilne. Load Runner nie tracił połączenia z maszynami w tak krótkim czasie, jak z użyciem RDP (ang. Remote Desktop Connection). Zastosowane rozwiązanie okazało się wystarczające jako pierwszy krok. Mimo że było dalekie od ideału, umożliwiało przeprowadzanie wielogodzinnych testów z użyciem kilkudziesięciu klientów.

1.3.7. Faza 1 – wyniki

Wyżej opisana metoda pozwoliła na znalezienie ponad 50 istotnych błędów niefunkcjonalnych w okresie około 3 miesięcy. Load Runner w takiej konfiguracji był również wykorzystywany do sprawdzenia systemu po naprawie błędów. Koszt inwestycji w pierwszą fazę był porównywalny z kosztem wykonania testów opisanych w fazie 0.