Wybieramy narzędzie do automatyzacji testów

Testowanie
oprogramowania
Mariusz Chrapko
Wybieramy narzędzie
do automatyzacji testów
P
roces testowania oprogramowania jest obecny niemalże we wszystkich etapach życia
produktu informatycznego – począwszy od
fazy planowania i analizy wymagań, skończywszy na
fazie wdrożenia. Każdy tester doskonale wie, ile czasu pochłania gruntowne sprawdzenie aplikacji, zanim zostanie ona ostatecznie oddana w ręce klienta.
Czasem są to długie godziny mozolnej i – wydawać
by się mogło – nikomu niepotrzebnej pracy, którą
w wielu wypadkach mógłby wykonać automat. Wybór dobrego narzędzia do automatyzacji procesu testowania nie jest jednak tak prosty jak – na pierwszy
rzut oka – mogło by się wydawać. W niniejszym artykule przedstawię klika praktycznych wskazówek, które w takim wyborze mogą pomóc.
Od czego zacząć?
Rzut okiem na to co ma do zaoferowania rynek, nie jest
z pewnością tym, od czego powinniśmy rozpocząć nasze poszukiwania. Musimy pamiętać, iż chodzi nam
przede wszystkim o znalezienie narzędzia, które pozwoli nam na możliwie optymalną automatyzację testów, które dotychczas wykonywaliśmy ręcznie. Jeżeli nasze działania w tej materii będą nieskoordynowane, chaotyczne – może się bardzo szybko okazać,
iż w ich wyniku znajdziemy produkt, który tak naprawdę
nie spełnia naszych podstawowych oczekiwań. Gorzej,
jeżeli w działania te nie zaangażujemy odpowiednich
osób, możemy znaleźć narzędzie, które wprawdzie
– z technicznego punktu widzenia – będzie dobre, ale
pracownicy nie będą chcieli go używać. Dlatego też
przedsięwzięcie to należy potraktować jak każdy inny
projekt w firmie – tzn. na jego realizację należy przeznaczyć odpowiedni budżet, przydzielić zasoby oraz
działania rozplanować w czasie. Dlatego też pierwszą
rzeczą, od której powinniśmy zacząć, jest zbudowanie efektywnego zespołu. Czas pracy poszczególnych
uczestników projektu nie powinien być zbyt duży – ok.
3-5 dni/osobę, nie dłużej jednak niż 1 miesiąc. O wiele więcej zaangażowania wymaga już praca team leadera – osoby bezpośrednio koordynującej prace projektowe. Jak każdy team leader, powinien on wykazać
Autor pracuje w dużej firmie IT. Od strony zawodowej interesuje się problematyką jakości w inżynierii oprogramowania ze szczególnym uwzględnieniem doskonalenia procesu jego wytwarzania w oparciu o Model CMMI(I). Prywatnie lubi jazz i filozofię (głównie współczesną).
W wolnych chwilach uprawia turystykę góską, a w zimie
narciarstwo.
Kontakt z autorem: [email protected]
32
www.sdjournal.org
się posiadaniem umiejętności właściwych dla każdego
menedżera projektu – zarządzania projektem; zarządzania zespołem; umiejętności interpersonalnych; powinien wreszcie posiadać bardzo dobrą znajomość różnych obszarów procesowych w organizacji. Jeśli chodzi o członków zespołu projektowego – powinny to być
osoby o zróżnicowanych umiejętnościach, głównie zawodowych, reprezentujące różne aktywności projektowe, pełniące różne role. W jego skład mogą wejść końcowi użytkownicy, odpowiedzialni za testy akceptacyjne, testerzy którzy chcą zautomatyzować testy systemowe, a także deweloperzy, pragnący zautomatyzować testy jednostkowe czy integracyjne.
Zespół zajmujący się wyborem odpowiedniego
narzędzia do automatyzacji testów jest o tyle ważny, że stanowi on pewnego rodzaju kanał komunikacji z pozostałą częścią firmy. Odpowiada za inwestygację wszystkich obszarów procesowych związanych z życiem naszego produktu po to, by wyłonić te,
które wymagają największego wsparcia. Ponadto rola wspomnianego zespołu projektowego jest niesłychanie ważna podczas procesu implementacji narzędzia, który nastąpi bezpośrednio po jego zakupie.
Problemy,
które chcemy rozwiązać
Kiedy już powołaliśmy zespół, mający się zajmować
naszym projektem, kolejnym ważnym etapem jest
sporządzenie specyfikacji wymagań, które nasze narzędzie powinno spełniać. Przystępując do tej aktywności, musimy sobie jasno odpowiedzieć na jedno podstawowe pytanie: jaki problem bądź problemy
nasze narzędzie ma rozwiązać? Oto kilka z nich:
•
•
•
•
•
•
•
testy wykonywane ręcznie pochłaniają zbyt dużo
czasu;
zmęczenie testerów powoduje pomijanie niektórych przypadków testowych oraz wprowadzanie
błędnych danych wejściowych;
zebranie i analiza rezultatów wykonanych testów
jest żmudna i pracochłonna;
przy implementacji jednej małej zmiany, brakuje
czasu na wykonywanie testów regresyjnych;
dokumentacja testowa jest niewłaściwie zarządzana, a bardzo często wcale;
pokrycie testów (ang. test coverage) nie jest monitorowane;
testowanie jest żmudne i nieefektywne.
I tak dalej, i tak dalej. Lista może być długa. O jednym
jednak należy pamiętać: nie wszystkie problemy da się
rozwiązać za pomocą odpowiedniego narzędzia. Przed
Software Developer’s Journal 9/2006
Wybieramy narzędzie do automatyzacji testów
zakupami dobrze jest zastanowić się, które z wyszczególnionych
problemów jesteśmy w stanie rozwiązać sami, za pomocą dostępnych zasobów w firmie. Na przykład jeżeli nie potrafimy sobie poradzić z właściwym zarządzaniem dokumentacją testową,
której jest zbyt dużo, i która jest przechowywana w różnych miejscach na serwerze – może wystarczy delegować do tego jakąś
jedną osobę, która po prostu zrobi z tym porządek – wydzieli odpowiednie zasoby dyskowe, utworzy specjalne katalogi, etc. Podobnie w przypadku zapisywania i analizy rezultatów testowych.
Niekiedy zwykły arkusz kalkulacyjny może się okazać w zupełności wystarczający. W sytuacji natomiast, gdy wykonywane
przez nas testy są mało efektywne, być może należy użyć odpowiednich technik – chociażby takich jak inspekcja, która może
być stosowana zarówno w przypadku testowania samego kodu,
jak i dokumentacji. Zainteresowanych odsyłam do książki Gilba
T. i Grahama D., Software Inspection, Harlow. England: Addison
Wesley, 1993. Kiedy już odpowiemy sobie na wszystkie pytania i uznamy, że niestety naszych problemów nie jesteśmy
w stanie rozwiązać własnymi siłami, wówczas możemy przystąpić do realizacji naszego projektu.
Odpowiedni moment
Zakładając, że istnieje krótsza lub dłuższa lista problemów związanych z procesem testowania oprogramowania w naszej firmie,
oraz że zakup narzędzia do automatyzacji testów w sposób istotny przyczyni się do ich rozwiązania, kolejnym ważnym etapem
w naszym projekcie jest wybór odpowiedniego czasu na jego realizację. Musimy pamiętać, iż zakup nawet najlepszego narzędzia, dokonany w niewłaściwym czasie, może niechybnie zakończyć się klęską. Firma, decydująca się na tego typu działania,
musi liczyć się z tym, iż nie poprawi to procesu testowania bez
dodatkowych nakładów pracy ze strony jej pracowników. Kiedy
więc możemy mówić o odpowiednim momencie na realizację naszego projektu? Można wskazać ich co najmniej kilka:
•
•
•
•
kiedy nie ma żadnych ważnych działań podejmowanych
na poziomie całej firmy;
kiedy istnieje osoba, która jest odpowiedzialna za wybór
oraz implementację właściwego narzędzia;
kiedy pracownicy są niezadowoleni z przeprowadzanych
testów;
oraz, kiedy istnieje przyzwolenie i całkowita aprobata top
managementu na wspieranie wszelkich wysiłków związanych z wyborem i zakupem nowego narzędzia.
R
E
K
�����
�������������
����������������
Rysunek 1. Proces wrożenia narzędzia do automatyzacji
testów
Oczywiście niespełnienie jednego lub kilku warunków, nie spowoduje katastrofy, niemniej jednak możemy liczyć się z tym, iż
realizacja projektu może napotkać na poważne trudności.
Business case
W dalszej kolejności powinniśmy skupić się na zdefiniowaniu
mierzalnych celów naszego przedsięwzięcia, od których będzie zależał jego sukces, bądź porażka. Oto krótki przykład:
•
•
•
ręczne wykonanie określonej grupy testów obecnie wynosi
4 osobo–tygodnie;
po 3 miesiącach używania narzędzia, 50–60% egzekucji
tych przypadków zostanie zautomatyzowanych, redukując
czas wykonania wszystkich testów o 2–2.5 osobo–tygodni;
po 12 miesiącach już 80% przypadków testowych wykonywanych będzie automatycznie.
Konstruując estymaty, należy pamiętać o tym, iż początkowe
używanie nowego narzędzia przez jeszcze niedoświadczonych
w jego obsłudze pracowników, wiąże się ze zdwojonym wysiłkiem. Istotne jest, aby nie przyjmować fikcyjnych estymatów.
Z drugiej strony nie należy też być zbyt skrupulatnym. Dlatego
też z pomocą może nam tutaj przyjść opracowanie na potrzeby
naszego projektu business case’u, który w sposób prosty i przejrzysty pokaże podstawowe korzyści, które z jego realizacji mogą
wynikać. Typowy business case w tym przypadku, powinien zawierać następujące elementy:
•
L
koszt testów, które obecnie są wykonywane w firmie
w sposób niezautomatyzowany, (te dane mogą obejmować
jeden lub więcej cykli, nie muszą też być bardzo dokładne,
wystarczy jak pojawią się jedynie przybliżone liczby);
A
M
A
Testowanie
oprogramowania
•
•
•
•
•
pokrycie bieżących przypadków testowych (jak wiele
z nich jest obecnie nie przetestowanych, szczególnie z powodu różnych ograniczeń, które zakup określonego narzędzia może rozwiązać);
koszt błędów nie wykrytych przez testerów w minionym roku;
koszt pierwszego użycia narzędzia (na pozycję tę mogą
się składać: koszty zakupu narzędzia, koszty przeszkolenia pracowniku w zakresie jego używania, niekiedy dodatkowy software lub hardware, który musimy zakupić);
koszty związane z codziennym używaniem narzędzia (są
to takie koszty jak: przedłużenie licencji, zakup licencji na
nowe stanowiska, koszty związane z podtrzymywaniem
a także doskonaleniem procesu automatyzacji testów
w firmie);
kalkulacja progu opłacalności przedsięwzięcia (każdy business case powinien zawierać taką kalkulację, której
głównym celem jest pokazanie, czy zakup danego narzędzia faktycznie nam się opłaca).
Na koniec dobrze jest wyszczególnić listę założeń, którymi sugerowaliśmy przy konstrukcji naszego business case’u. Mogą to
być ogólne założenia związane z procesem testowania, takie jak:
podstawowe aktywności testowe; liczba testów, które naszym
zdaniem nie przejdą, liczba iteracji (mam tutaj namyśli ponowne
wykonanie testów po naprawieniu wykrytego błędu), nowe funkcjonalności, które będą testowane, etc.
Ograniczenia
Mając przygotowany business case, możemy wreszcie skupić
naszą uwagą na tym, co ma do zaoferowania rynek. Etap ten
jednak, dobrze jest poprzedzić krótką analizą czynników, które mogą negatywnie wpłynąć na dokonanie naszych zakupów. Można ich wymienić co najmniej kilka:
Ograniczenia środowiskowe (hardware i software)
Narzędzia do testowania są niczym innym jak zbiorem pakietów dopasowanych do określonego hardwar’eu, softwar’eu i systemów operacyjnych. Żaden z testerów, na co dzień działających w środowisku windowsowym z pewnością nie chciałby pracować na narzędziu, które doskonale funkcjonowałoby tylko na
platformie uniksowej. Czasem też trzeba dokupić większy dysk
do przechowywania skryptów testowych, dodatkowy software
do porównywania wyników testów. Możliwości jest wiele. Ważne
jest, żeby również i o tym pamiętać.
Ograniczenia handlowe
Wybór odpowiedniej firmy, u której decydujemy się na zakup naszego narzędzia spełnia niesłychanie ważną rolę i posiada duży wpływ na jakość wykonywanych przez nas testów w przyszłości. Tutaj przede wszystkim należy zwrócić uwagę na wiarygodność danej firmy na rynku informatycznym, na to – ilu i jakich ma
klientów. Można nawet spróbować się z nimi skontaktować i podpytać, czy są zadowoleni z produktu, który zakupili. Dobrze jest
także dowiedzieć się, jak często dostawca wprowadza zmiany
do wybranego produktu, ile było oficjalnych release’ów. Wreszcie
– jak wygląda suport narzędzia, w jakich godzinach jest dostępny
(należy tutaj mieć na uwadze przede wszystkim wszelkie zmiany
czasowe), czy klienci są z niego zadowoleni (tutaj również można różnymi kanałami dotrzeć do firm które korzystają z danego
narzędzia i przeprowadzić stosowną inwestygację). Relacje z fir-
34
mą dostarczającą dane narzędzia na rynek zaczynają się już
w chwili ich wyboru i ewaluacji. Jeżeli tutaj pojawią się problemy,
możemy ich być pewni także później – w trakcie wdrożenia oraz
codziennego użytkowania zakupionego narzędzia.
Ograniczenia dotyczące kosztów
Koszt stanowi zwykle najpoważniejszą determinantę. Przy czym
należy pamiętać, iż koszt związany z zakupem danego narzędzia to zaledwie czubek góry lodowej w procesie jego wdrożenia. Trzeba tutaj wziąć pod uwagę takie kwestie jak: koszt zakupu licencji, koszt szkoleń pracowników w zakresie używania narzędzia; koszty zakupu dodatkowego hardware’u (np. komputery, dodatkowe dyski, pamięci, etc.); koszt zakupu dodatkowego
oprogramowania; koszty supportu; koszty wewnętrzne (maintainance narzędzia, implementacja narzędzia w organizacji).
Ograniczenia polityczne
Są to ograniczenia bodajże najważniejsze, które w wielu wypadkach mogą uchylać pozostałe. Na pierwszy rzut mogłoby się
wydawać, iż działania projektowe w każdym wypadku powinny opierać się się na racjonalnych przesłankach. Tymczasem
w praktyce może się niekiedy okazać, iż zostaniemy zobligowani
do zakupu narzędzia, jakim posługuje się na przykład nasza firma matka; lub szef naszego szefa ma brata, który pracuje w firmie, zajmującej się dostarczaniem narzędzi do automatyzacji testów. Czynników politycznych nie należy bagatelizować i dobrze
jest je przewidzieć dużo wcześniej, zanim przystąpimy do realizacji naszego projektu.
Ograniczenia jakościowe
Tutaj mieszczą się zarówno aspekty funkcjonalne jak i niefunkcjonalne, związane z używaniem danego narzędzia. Musimy
sobie odpowiedzieć na kilka zupełnie podstawowych pytań. Ilu
użytkowników może korzystać z naszego narzędzia jednocześnie? Czy skrypty testowe mogą być współdzielone? Jak bardzo
zaawansowanym użytkownikiem trzeba być, by móc korzystać
z narzędzia w sposób wydajny? Czy do przygotowania skryptów
testowych wymagana jest umiejętność programowania? Jak wygląda sprawa z dokumentacją? Jeśli jest to, czy w wersji papierowej, czy elektronicznej? Jak bardzo jest użyteczna? Wreszcie
czy nasze narzędzie da się zintegrować z innymi, które są już
w naszej firmie powszechnie wykorzystywane (np. do zarządzania konfiguracją, zarządzania projektem, itp.)
Kupić czy stworzyć?
Jeśli po analizie wszystkich wspomnianych kwestii okaże się, iż
zakup narzędzia do automatyzacji testów jest dla naszej firmy
nierentowny, nie należy się zbyt szybko poddawać. Istnieją jeszcze narzędzia typu opensource. Tutaj zachęcam do odwiedze-
���������
�������
���������
����������������
�������������
������������
���������
��������������
���������
����������������
���������������
�����������
�����
������������
�������
Rysunek 2. Proces wyboru narzędzia do automatyzacji testów
www.sdjournal.org
Software Developer’s Journal 9/2006
Wybieramy narzędzie do automatyzacji testów
nia strony internetowej www.opensourcetesting.org, która oferuje możliwość pobrania sporej liczby darmowych narzędzi, służących usprawnieniu procesu testowania oprogramowania. Decydując się jednak na używanie tego typu oprogramowania trzeba
pamiętać o jednym – sporo funkcjonalności, których zazwyczaj
brakuje w tych narzędziach, będziemy musieli sobie dopisać we
własnym zakresie. Narzędzie te, dają nam jedynie pewną sztywną strukturę (szkielet), która aby nabrała właściwego kształtu
musi zostać wypełniona dodatkowym kodem. Niemniej jednak
gorąco zachęcam do stosowania tego typu rozwiązań. Można
je zaimplementować w organizacji przy dość znacznej minimalizacji kosztów. Mając zbudowany szkielet, dopisanie kilku funkcjonalności – w porównaniu z projektem zakupu komercyjnego
narzędzia – naprawdę nie jest problemem. Oczywiście wszystko
zależy od tego, do czego chcemy to narzędzie wykorzystywać.
Jeśli jednak okaże się, iż rozwiązania opensource’owe również nas nie satysfakcjonują, istnieje dodatkowa opcja – stworzenia własnego narzędzia, ściśle dopasowanego do wewnętrznych
potrzeb naszej firmy. Trzeba jednak mieć na uwadze fakt, iż przy
tego typu przedsięwzięciu również nie obejdziemy się bez dodatkowych kosztów. Musimy bowiem stworzyć oddzielny projekt,
przydzielić do niego odpowiednie zasoby, budżet, etc. Niemniej
jednak koszty te mogą szybko zostać zniesione w postaci zysków, jakie stworzenie tego typu narzędzia może nam przynieść.
W praktyce bowiem może się okazać, iż na potrzeby testów wykonywanych w naszej firmie, nie jest potrzebne aż tak bardzo zaawansowane technologicznie narzędzie, jak to które oferuje nam
komercyjny dostawca. W konsekwencji więc, wykorzystując własne zasoby, możemy stworzyć narzędzie o wiele prostsze i tańsze, ściśle dopasowane do naszych potrzeb.
Jednak kupić
Kiedy jednak zdecydujemy się na zakup komercyjnego narzędzia do automatyzacji testów, wówczas nie pozostaje nam nic innego jak sprawdzenie tego, co ma do zaoferowania rynek. Tego typu działania dobrze jest poprzedzić
przygotowaniem krótkiego spisu funkcjonalności, które naR
E
K
���������
���������
���������
����������
�����������������
���������
���������
���������
�������
���������
�����������
����
��������
���������
���������
Rysunek 3. Prezentacja narzędzia w siedzibie naszej firmy
sze narzędzia powinno posiadać. Wśród nich z pewnością pojawią się te, których obecność w danym narzędziu
lub jej brak, będzie rzeczą stosunkowo łatwą do stwierdzenia. Np. rejestrowanie kliknięć myszką. Istnieje jednak inna
grupa funkcjonalności, których występowanie ma charakter względny. Np. łatwość użycia – niektóre narzędzia będą bardziej przystępne dla testerów nie posiadających zaawansowanej wiedzy technicznej, będąc jednocześnie nużącymi dla osób z wiedzą programistyczną.
Mając przygotowaną listę funkcjonalności, czas poszukać co jest dostępne na rynku. Tutaj istnieje dużo możliwości. Najprościej jest zacząć od przeszukania zasobów internetowych. Osobiście mogę polecić odwiedzenie strony http://
www.qaforums.com, gdzie można znaleźć sporo informacji na
temat narzędzi do testowania oprogramowania. Zostało tam
umieszczonych wiele ciekawych linków do innych stron poświęconych testowaniu, są informacje na temat książek, linki do artykułów. Dodatkowo, można się zapisać do różnych grup dyskusyjnych, wymienić poglądy z innymi testerami, porozmawiać o narzędziach, które stosują w swoich firmach, etc. Ponadto, istnieje możliwość posłuchania ciekawych audycji popcastowych, między innymi na temat testowania oprogramowania.
Kiedy uda nam się już wybrać kilka narzędzi, pora na kontakt ze sprzedawcą. Na początek dobrze jest poprosić o przeL
A
M
A
Testowanie
oprogramowania
słanie dodatkowej dokumentacji dotyczącej produktu (jeśli firma nie umieściła jej na stronie) i zestawienie jej z listą niezbędnych funkcjonalności, które nasze narzędzie powinno posiadać.
Kiedy np. porównując trzy narzędzia A,B,C, okaże się, iż w narzędziu B istnieje interesująca nas funkcjonalność, której jednak
nie ma w narzędziach A i C – dobrze jest zapytać sprzedawcę,
czy przewidują umieszczenie tej funkcjonalności w kolejnej wersji produktu; czy jest możliwa jej implementacja obecnie, gdybyśmy się zdecydowali na zakup. Nie należy się obawiać pytań.
Firmy zawsze są bardzo elastyczne i gotowe do współpracy.
Czasem dobrze jest poprosić sprzedawcę o przedstawienie
zalet oferowanego przez niego narzędzia w porównaniu w zestawieniu z podobnym produktem konkurencji. Dodatkowo, możemy poprosić o ewentualne referencje i namiary do firm, które
korzystają z wybranego produktu. Oczywiście musimy liczyć się
z tym, iż sprzedawca poda nam kontakt jedynie do tych firm, które ogólnie są zadowolone z zakupionych u niego narzędzi. Dobrym sposobem na zaczerpnięcie informacji, poznania plusów
i minusów danego produktu jest również odwiedzenie różnego
rodzaju stron grup dyskusyjnych jemu poświęconych. Użytkownicy są bardzo chętni do dzielenia się swoimi doświadczeniami
z pracy. Ponadto tego typu dyskusje niejednokrotnie rzucają sporo cennego światła na dokonanie właściwego wyboru.
Po tym jak udało nam się zebrać określoną liczbę istotnych
informacji, kolejny etap to –próba umówienia się ze sprzedawcą
każdego z wybranych produktów, na prezentacją możliwości jego narzędzia w naszej firmie. Jeśli uda nam się zaaranżować tego typu spotkania, dobrze jest zorganizować je w dość krótkich
odstępach czasowych – np. jeżeli wybraliśmy narzędzia trzech
producentów, mogą to być np. kolejne dni tego samego tygodnia
(poniedziałek, środa, piątek). Krótki interwał czasowy sprzyja temu, iż mamy świeżo w pamięci wnioski wyciągnięte z każdego
spotkania, co wpływa z kolei na szybsze podjęcie decyzji w sprawie ewentualnych zakupów.
Przed tym jednak, jak zaprosimy wybrane firmy do zaprezentowania swoich produktów, musimy się do tego dobrze przygotować po to, aby ocena, którą dokonamy, była jak najbardziej bezstronna i wydajna. W tym celu dobrze jest przygotować sobie
dwa przypadki testowe, które będą wykorzystywane przez firmy
podczas demonstrowania możliwości ich produktów. Przypadki
te należy wcześniej wysłać do sprzedawcy, aby ten mógł się do
nich właściwie przygotować. Dobrze jest też, gdy każdy z wysłanych przypadków testowych zostanie przez nas wcześniej przetestowany, celem późniejszego porównania wyników. Dodatkowo
wskazane jest, aby mieć trzeci przypadek testowy, o którego wykonanie poprosimy sprzedawcę w trakcie prezentacji, o którym
jednak nie powinien on wiedzieć. Ponadto możemy mieć przygotowaną listę pytań, które chcielibyśmy zadać w trakcie spotkania.
W ich przygotowanie powinien zostać zaangażowany cały zespół projektowy. Po każdej prezentacji należy sporządzić krótki raport, w którym pojawią się takie kwestie jak: informacje na
temat sprzedawcy (elastyczność, zdolność do szybkiego reagowania na pojawiające się w trakcie prezentacji problemy, wiedza
techniczna) oraz informacje na temat działania narzędzia na wybranych przypadkach testowych. Bez względu jednak na to, jaką
podjęliśmy decyzję (kupujemy bądź nie) – zawsze powinniśmy
poinformować producenta o jej wyniku, wraz z podaniem krótkiego uzasadnienia. Na koniec, po przeprowadzeniu gruntownej
analizy prezentowanych produktów, dobrze jest sprawdzić dostępność supportu dla narzędzia, które najbardziej nam się po-
36
dobało. Najprościej można spróbować dodzwonić się na linię pomocy i zadać kilka technicznych pytań. Można oczywiście spróbować uczynić to drogą elektroniczną, niemniej jednak trzeba się
liczyć z tym, iż czas reakcji będzie nieco dłuższy.
Jeżeli wciąż nie jesteśmy pewni, które narzędzie wybrać,
wówczas pozostaje nam ostania możliwość (poza zdaniem się
na intuicję) – skorzystanie z wersji trialowej produktu. Ponieważ licencje tego typu wydawane są przez producentów na krótki okres czasu, (zazwyczaj są to dwa tygodnie, oczywiście okres
ten można wydłużyć), firma która chciałaby z takiej opcji skorzystać, musi się do tego dobrze przygotować (stworzenie przypadków testowych, planning, przydzielenie odpowiednich zasobów,
etc.) Skorzystanie z takiego rozwiązania ma szczególny sens
w przypadku dużych firm, gdzie określone narzędzie będzie wykorzystywane przez większą liczbę pracowników.
Zakup
Po przeprowadzeniu ewaluacji, ostatnią rzeczą jaką musimy
zrobić jest podjęcie decyzji o zakupie narzędzia. Tutaj należy
się posłużyć finalnym raportem, który powinien zostać przygotowany przez członków zespołu projektowego i zaprezentowany na spotkaniu z top managementem. Raport taki powinien zostać napisany w odniesieniu do naszego business caseu, który został wcześniej przygotowany. Jeżeli z naszego
raportu nie wynikają żadne czytelne racje przemawiające za
zakupem określonego produktu, nie powinniśmy się bać podjęcia również takiej decyzji. Jest to najlepsza rzecz, jaką w takim
momencie możemy uczynić – przede wszystkim z ekonomicznego punktu widzenia. Z drugiej jednak strony, jeśli z przeprowadzonej przez nas analizy w sposób jednoznaczny wynika, iż narzędzie, które wybraliśmy w pełni odpowiada naszym potrzebom
– jest to sygnał, iż powinniśmy podjąć stosowną decyzję. O fakcie tym należy oczywiście w miarę szybko powiadomić producenta, zwłaszcza że od momentu podjęcia przez zarząd naszej
firmy decyzji o jego zakupie do samego faktu jego używania,
może upłynąć sporo czasu (od kilku tygodni nawet do kilku miesięcy, w zależności od tego jak długo w danej firmie trwa procedura zakupu). Ponadto, krótki raport podsumowujący należy wysłać – o czym już zostało powiedziane – do pozostałych uczestników prezentacji. Dobrze jest, żeby również i oni poznali dlaczego odrzuciliśmy ich produkt.
Proces selekcji i ewaluacji narzędzia powinien być ograniczony w czasie. Po jego zakończeniu bowiem, firma powinna niezwłocznie skoncentrować swoje wysiłki na sensownym zaplanowaniu jego wdrożenia – co również jest niemałym wyzwaniem.
Zagadnienie to jednak wymaga już osobnego omówienia.
Podsumowanie
Z doświadczeń wielu firm informatycznych wynika, iż wybór dobrego narzędzia do automatyzacji testów stanowi niemały problem. Rynek zalewa nas falą ogromnej ilości produktów, z których tak naprawdę trudno jest wybrać coś dobrego – coś co rzeczywiście odpowiadałoby potrzebom naszej firmy.
Artykuł stanowi próbę rozwiązania tego typu problemów.
Jest zbiorem praktycznych wskazówek oraz dobrych praktyk,
których znajomość może okazać się niezwykle pomocna dla
wielu testerów oraz pracowników działu QA we wszelkich wysiłkach związanych z automatyzacją, a co za tym idzie poprawą wydajności procesu testowania oprogramowania w ich organizacji. n
www.sdjournal.org
Software Developer’s Journal 9/2006