Polkomtel SA, jako jedna z nielicznych firm w Polsce, ma samodzielny zespół QA specjalizujący się w testowaniu wydajności aplikacji.
- 13.10.2003
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.
Adam Suskiewicz, kierownik Zespołu QA
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.
Ścieżka testowania aplikacji w Polkomtel SA
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
Tomasz Wodziński, analityk w Zespole QA
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.