Polkomtel SA, jako jedna z nielicznych firm w Polsce, ma samodzielny zespół QA specjalizujący się w testowaniu wydajności aplikacji.

Polkomtel SA, jako jedna z nielicznych firm w Polsce, ma samodzielny zespół QA specjalizujący się w testowaniu wydajności aplikacji.

Polkomtel SA, jako jedna z nielicznych firm w Polsce, ma samodzielny zespół QA specjalizujący się w testowaniu wydajności aplikacji.

Testowanie aplikacji tworzonych w Polkomtel SA odbywa się w kilku etapach - testowanie wydajności jest jednym z nich. Wstępne testy, polegające głównie na debugowaniu kodu, są przeprowadzane jeszcze w dziale rozwoju oprogramowania. Po wstępnym oczyszczeniu programu jest on przekazywany do Zespołu Testów Systemowych, gdzie jest poddawany testom integracyjnym, funkcjonalnym i testom regresji. Na tym etapie systemy są testowane przez osoby znające ich kod źródłowy. Gdy wyniki testów są zadowalające, aplikacje trafiają do Zespołu Zapewniania Jakości (QA), w którym są poddawane obserwacji pod kątem funkcjonalności i wydajności. Na tym etapie testerzy nie mają już możliwości wglądu w kod źródłowy. Jedyne, na czym mogą się oprzeć, to sprawdzanie poprawności biznesowej oraz pomiar czasu wykonania poszczególnych operacji.

Polkomtel SA, jako jedna z nielicznych firm w Polsce, ma samodzielny zespół QA specjalizujący się w testowaniu wydajności aplikacji.

Adam Suskiewicz, kierownik Zespołu QA

Sprawdzeniu podlega nie tylko jakość aplikacji tworzonych samodzielnie przez Pion Informatyki, ale także systemów, które Polkomtel SA ocenia pod kątem potencjalnego zakupu. Programy kupowane na zewnątrz trafiają do Zespołu QA. "Jakakolwiek aplikacja, która ma zostać użyta w trybie produkcyjnym, musi przejść przez nasze ręce. W przypadku systemów kupowanych na zewnątrz wymagamy, by to dostawca wykonał pierwsze testy i przedstawił nam z niego raport" - mówi Adam Suskiewicz, kierownik Zespołu QA w Pionie Informatyki Polkomtel SA w Warszawie.

Kombinacje na dwie głowy

Adresatami testów wydajności są w Polkomtelu różne kategorie pracowników: użytkownicy, analitycy biznesowi, projektanci i administratorzy aplikacji, kierownicy działów, szefowie i sponsorzy projektów itp. Każda grupa ma własne potrzeby i oczekiwania, które zespół QA musi rozpoznać i obsłużyć. Proces testowania systemu jest więc poprzedzony wywiadem ze zlecającym, którego rolą jest określenie celu testów i poziomu oczekiwań co do wyników. Dopiero wtedy jest wybierany zakres funkcji i danych, które mają być objęte testami. To na podstawie tych wytycznych są określane przypadki testowe i scenariusze testów."Dobrą ilustracją rozbieżności oczekiwań są aplikacje webowe. W przypadku witryny wyświetlającej stronę WWW składającą się przykładowo z 20 ramek użytkownika interesuje łączny czas całkowitego załadowania strony. Projektant systemu będzie starał się dociec, dlaczego, załóżmy, pobieranie ramki nr 8 trwa dłużej niż wszystkich pozostałych razem wziętych. Analityk biznesowy, mający baczenie na ocenę produktywności pracowników i koszty, zwróci uwagę na to, czy czasy pobierania stron przez użytkowników są w miarę powtarzalne. Z kolei kierownik działu funkcjonalnego będzie chciał ustalić, czy aplikacja jest w stanie obsłużyć wymaganą liczbę użytkowników. Kierownik i sponsor projektu będą chcieli ustalić to samo, tyle że pod kątem potencjalnego wpływu wyników testów na terminy i budżety"- wylicza Tomasz Wodziński, analityk w Zespole QA.

Polkomtel SA, jako jedna z nielicznych firm w Polsce, ma samodzielny zespół QA specjalizujący się w testowaniu wydajności aplikacji.

Ścieżka testowania aplikacji w Polkomtel SA

Do przygotowania testów i późniejszego ich wykonania pracownicy Polkomtela używają specjalizowanych narzędzi. W Zespole Testów Systemowych do oceny jakości oprogramowania są wykorzystywane narzędzia Load Runner firmy Mercury Interactive. Dodatkowym wsparciem jest pakiet QARun firmy Compu-ware, służący do nagrywania i odtwarzania testów funkcjonalnych. Zespół QA wykonuje testy analogiczne co do celu i zakresu, lecz inne co do metody niż te prowadzone w Zespole Testów Systemowych. Inne są także narzędzia - Zespół QA używa pakietu IBM Rational TeamTest.

Narzędzia stosowane w Dziale Testów Systemowych i w Zespole QA łączą narzędzia do wstępnego "nagrywania" przypadków testowych w formie skryptów, możliwość ich modyfikowania i przechowywania w postaci "bibliotek", narzędzia do analizy poprawności i debugowania programów testujących oraz działające na stacjach roboczych symulatory użytkowników. Zastosowanie dwóch narzędzi o podobnym zakresie funkcjonalnym nadaje wykonywanym testom obiektywizm i zabezpiecza przed powstawaniem błędów w ocenie wynikających z konstrukcji czy konfiguracji pojedynczego systemu testującego.

Dociskanie i odpuszczanie

Polkomtel SA, jako jedna z nielicznych firm w Polsce, ma samodzielny zespół QA specjalizujący się w testowaniu wydajności aplikacji.

Tomasz Wodziński, analityk w Zespole QA

Polkomtel testuje wydajność aplikacji na kilka sposobów. Pierwszy rodzaj testów, stosowany zwykle wobec aplikacji testowanych po raz pierwszy, to tzw. dociskanie aplikacji mające na celu określenie granic jej wydajności. W tym celu w równych odstępach czasu oprogramowanie symulacyjne stopniowo zwiększa liczbę użytkowników systemu. "Aby wyniki testu nadawały się do wyciągania wniosków, poszczególne etapy obciążania muszą trwać na tyle długo, aby ich w czasie zostało wykonanych dostatecznie dużo pełnych transakcji. Wszystko zależy oczywiście od specyfiki aplikacji, zwykle jednak nie schodzimy poniżej pół godziny, a bywa że pojedynczy etap trwa ponad godzinę" - wyjaśnia Tomasz Wodziński.

Drugi rodzaj testów, wykorzystywany do testowania aplikacji testowanych regularnie, np. w związku z wprowadzaniem nowych wersji, poprawek czy łat, polega na stopniowym zwiększaniu, a następnie zmniejszaniu liczby użytkowników. "Reakcje aplikacji na zmniejszanie obciążenia są tak samo ważne, jak jej reakcje na zwiększanie obciążenia. Czasy odpowiedzi mierzone na tych samych pułapach liczby użytkowników są podczas zmniejszania obciążenia zwykle nieco dłuższe niż podczas jego zwiększania. Jest tu pewna analogia do korku ulicznego: tworzy się szybko, rozładowanie go zajmuje jednak nieco więcej czasu. Jeżeli jednak liczone w procentach różnice w czasie odpowiedzi na jakimś poziomie obciążenia odbiegają od przeciętnych różnic obserwowanych na innych poziomach, oznacza to, że z aplikacją dzieje się coś niedobrego" - tłumaczy Tomasz Wodziński.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200