Oprócz amerykańskich konferencji poświęconych jakości oprogramowania
STAREAST i
STARWEST funkcjonuje ich europejska wersja pod nazwą
EuroSTAR. Najbliższa odbywa się pod hasłem "
Defining the Profession". Organizatorzy uważają, że do rozwikłania zagadki tego hasła prowadzą odpowiedzi na poniższe pytania:
- Czy uważasz siebie za testera i profesjonalistę? Czy inni uważają Cię za takiego?
- Co pozwala Ci na takie stwierdzenie?
- Czy istnieje podstawowy zbiór umiejętności? Czy są to umiejętności techniczne czy społeczne, a może dwojakie?
- Jaka jest Twoja jedna, najbardziej cenna umiejętność? Czy potrafisz ją objaśnić innym?
- Czy kwalifikacje mogą określać profesjonalnego testera?
- Czy Twoja organizacja wnosi dobre praktyki do profesji?
Ponieważ próba odpowiedzi na te pytania wydała mi się wyzwaniem, postanowiłem zmierzyć się z nim. Ale postanowiłem to zrobić na ogólnym poziomie nie wchodząc w szczegóły, chyba że jest to uzasadnione.
Czy uważasz siebie za testera i profesjonalistę?
Kto może nazwać siebie testerem...? Czasami jako testera określa się osobę zawodowo zajmującą się weryfikowaniem czy to co miało być zrobione zostało rzeczywiście zrobione! Jednak w mojej opinii nie jest to definicja kompletna. Tester bowiem, to osoba, która nie tyle zajmuje się weryfikowaniem czy to co zaplanowane zostało zaimplementowane - jest to produkt bardzo ważny ale pośredni pracy testera. Tester to osoba, która z pełną świadomością przepuszcza oprogramowanie przez specjalnie w tym celu zaprojektowane procedury, których celem jest weryfikacja czy został osiągnięty określony i zdefiniowany poziom jakości i która to osoba do projektowania procedur testowych korzysta w wielu technik! Gdy poziom jakości nie jest określony i zdefiniowany formalnie to i tak bardzo pomocne jest nieformalne określenie tego parametru.
Mówi się, że dobry tester jest w stanie przetestować wszystko... i rzeczywiście kilka lat pracy w zawodzie formułuje specyficzne podejście charakteryzujące się "testowaniem" otoczenia. Jak słusznie zauważył James Bach, istotne jest umiejętne posługiwanie się sceptycyzmem i krytycyzmem co w mojej ocenie jest wyższym stopniem wtajemniczenia w ten zawód. Łatwo jest bowiem popaść w bezproduktywne narzekanie, że system nie jest doskonałej jakości a bardzo trudno jest ustrzec się przed domniemaniem pewnych oczywistości. I tak np. łatwo jest powiedzieć, że
dany obszar funkcjonalny jest źle napisany bo zostało do niego zaraportowanych dużo defektów ale dużo trudniej jest tak skonstruować testy aby przy minimalnym, potrzebnym nakładzie pracy (w sensie czasu i zasobów) przetestować dokładnie ten obszar a następnie efektywnie zweryfikować efekt prac naprawczych.
Jak można zdefiniować profesjonalistę...? Uważam, że profesjonalista to człowiek skupiony na celach, potrafiący je osiągać korzystając z dostępnych środków oraz dobierać nowe środki w sposób optymalny. Ale jednocześnie profesjonalista to taki ktoś, kto dążąc do realizacji tych celów, potrafi dać swój wkład w środowisko pracy... to np. taka osoba, która widzi szerszy kontekst swojej działalności. Osoba, która biorąc cokolwiek od innej osoby (wiedzę, informację, zasoby, czas, itp) potrafi uczynić to we właściwy sposób i jednocześnie dać coś w zamian. To ktoś w towarzystwie kogo przebywając jednocześnie uczymy się, ktoś do kogo ma się zaufanie. To ktoś kto ma misję!
Dla mnie taką misją jest "
minimalizowanie ryzyka związanego z realizowanym produktem/projektem". To minimalizowanie realizuję poprzez dostarczanie innym uczestnikom procesu, z jednej strony informacji na temat jak można przy zastanych zasobach i historii projektu zrealizować efektywnie testy a z drugiej strony wiarygodną informację na temat poziomu jakości tego produktu w odniesieniu do czynników zewnętrznych takich jak jakościowe oczekiwania klienta, otoczenie biznesowe, przeznaczenie systemu, itp. W ten sposób chronię zarówno swojego pracodawcę przed utratą renomy a z drugiej strony chronię odbiorcę przed stratami spowodowanymi wadliwym działaniem systemu.
Często spotykam się z mniej lub bardziej jawny antagonizowaniem testera i programisty. Dla mnie takie ujęcie jest zupełnie bezprzedmiotowe. Nie ma znaczenia tak naprawdę kto "bardziej zbawia świat". Znaczenie ma jaki się ma stosunek do wykonywanego zawodu. Testowanie dla osoby zainteresowanej tym zawodem i świadomej możliwości jest takim samym wyzwaniem jak zaprogramowanie testowanego systemu.
Co więcej, antagonizowanie działu testów z działem rozwoju w poważny sposób zakłóca komunikację między tymi dwoma działami co w konsekwencji najczęściej powoduje z jednej strony reglamentację wiedzy na temat stosowanych rozwiązań a z drugiej strony nadmierny nakład pracy związanej z testami oraz zbyt detaliczne raportowanie defektów.
Testowanie jako odrębna dziedzina daje duże możliwości wielokierunkowego rozwoju i zdobywania wiedzy weźmy choćby pod uwagę automatyzację testów, projektowanie testów, standaryzację testów, itp.
Czy inni uważają Cię za takiego?
Nie jestem w stanie odpowiedzieć na to pytanie! Nie znam myśli innych ludzi. Ale mogę odwrócić to pytanie i sformułować je tak "co powoduje, że myślisz o innych jak o profesjonalnych testerach?" Jako profesjonalnego testera określam taką osobę, która potrafi pomóc kierownikowi projektu lub innej osobie odpowiedzialnej za realizację przedsięwzięcia określając, jak i które obszary powinny być testowane w zależności od takich czynników jak czas, historia produktu/projektu oraz historia testów, dostępne zasoby, jakość tych zasobów, itd. Jednym zdaniem, według mnie
profesjonalny tester to taki, który potrafi trafnie i wiarygodnie odpowiedzieć na pytanie "jak powinien być przetestowany" system, program, moduł czy jednostka. "Trafnie" oznacza tutaj sposób pozwalający w świadomy sposób wyeliminować ryzyko czyli taki, który umożliwi znalezienie istotnych defektów. Wymaga to z kolei umiejętności klasyfikowania defektów nie tylko z punktu widzenia systemu ale także całego projektu.
Do znajdowania, opisywania i klasyfikowania defektów, dysponuje jednocześnie całym wachlarzem narzędzi takich jak techniki testowania, znajomość kontekstu biznesowego, historii system oraz samego systemu.
Nie chcę przez to powiedzieć, że tester jest odpowiedzialny za całość przedsięwzięcia a jedynie chcę podkreślić fakt, iż do obowiązków testera nie należy tylko samo testowanie ale także osadzanie wiedzy o testowanym systemie w jego kontekście w takim zakresie w jakim jest to dla niego osiągalne w zależności od jakości komunikacji w projekcie, zakresu odpowiedzialności (analityk testów, wykonawca testów, lider/manager testów, lider/manager do spraw jakości procesów).
Co pozwala Ci na takie stwierdzenie?
Przystępując do nowego projektu, jako jeden z moich "prywatnych" celów wyznaczam sobie rolę źródła pomocy kierownikowi projektu w realizacji zadań projektowych. Nie każdy kierownik projektu, jest świadom tego, że "oszczędzając czas i zasoby" na testach tak naprawdę oszczędza na zapobieganiu ryzyka. Dostarczenie oprogramowania z dużym opóźnieniem do testów i następnie wymaganie zrealizowania pierwotnego planu testów, w żaden sposób nie zaowocuje dobrymi rezultatami. W najgorszym wypadku, raport z testów może pokazywać, że wszystkie funkcjonalności zostały przetestowane. Ale żaden raport nie pokaże jakiej jakości były te testy. Nie odpowie na pytanie czy mała liczba defektów jest wynikiem znakomitej pracy programistów, czy testów dokonywanych w pośpiechu i pobieżnie. Dlatego uważam, ze każdy odpowiedzialny kierownik testów dużo uwagi powinien poświęcać monitorowaniu realizacji harmonogramu projektu aby wcześnie reagować na ograniczanie czasu przeznaczonego na testy jak najwcześniej. Jednocześnie powinien być świadom, iż skracanie czasu testów oznacza w swojej istocie zmniejszenie zakresu testów a więc zwiększenie ryzyka związanego z produktem.
Czy istnieje podstawowy zbiór umiejętności? Czy są to umiejętności techniczne czy społeczne, a może dwojakie?
Groucho Marx powiedział kiedyś "Zamierzam żyć wiecznie lub umrzeć próbując". Z całą pewnością istnieje podstawowy zbiór umiejętności wyróżniający testera spośród innych inżynierów. Przede wszystkim - u dojrzałego testera - jest to świadomość "że świat nie jest taki piękny jak się wydaje a nawet jeśli jest to należy to sprawdzić".
Same umiejętności podzieliłbym na kilka poziomów: warsztatowe, produktowe techniczne, produktowe nietechniczne oraz społeczne.
Umiejętności warsztatowe to przede wszystkim biegła znajomość technik projektowania przypadków testowych. To jest warunek
sine qua non bycia testerem. To właśnie od tego zależy to czy wykonujemy testy w sposób kontrolowalny, wiarygodny, weryfikowalny i jednoznaczny. Skonstruowanie i uruchomienie przypadku testowego bez jednej z tych cech często okazuje się pracą bezcelową, nie przynoszącą odpowiedzi na podstawowe pytanie.
Umiejętności produktowe techniczne to wszystkie te informacje, które są związane ze sposobem w jaki dany produkt powstaje. Mam na myśli tutaj technologię, sposób implementacji danych funkcjonalności, znajomość ograniczeń technicznych systemu, itp.
Umiejętności produktowe nietechniczne to generalnie znajomość i zrozumienie celu, dla którego powstaje produkt. Innych funkcji oczekujemy przecież od sytemu księgowego a innych od systemu przetwarzania sygnału telewizji cyfrowej, inaczej będzie działał wygaszacz ekranu na komputerze a zupełnie inaczej na dekoderze telewizji cyfrowej. Bez znajomości kontekstu w jakim osadzony jest produkt trudno jest mówić o "dobrym testowaniu".
Umiejętności społeczne to przede wszystkim umiejętności komunikacji i współpracy. Bardzo istotne jest z punktu widzenia testera zrozumienie chociażby tak prostego faktu, że defekty w oprogramowaniu nie wynikają ze złej woli programisty lub uporu architekta ale z faktu, że każdy z nas jest człowiekiem i popełnia błędy. I oczywiście odwrotnie, ważne jest aby osoba odpowiedzialna za całość przedsięwzięcia była świadoma, że testowanie jest sztuką szacowania opartym na krytycznym podejściu do oprogramowania dostarczonego do testów oraz na sceptycznym podejściu do deklarowanej jakości tego systemu, zakresu zmian, możliwych efektów pobocznych, itp.. (Nad wyraz często spotykam się z sytuacją, w której raporty defektów są po prostu ignorowane lub przetwarzane wsadowo co tak naprawdę przynosi gorszy efekt niż po prostu pozostały by one w statusie początkowym).
Te cztery warstwy "zanurzone" są w czymś co nazwałbym "intuicją testera". Rodzi się ona i rozwija się z czasem i doświadczeniem (udziałem w różnych projektach, w różnych organizacjach, w różnych kontekstach biznesowych itp.). Pozwala ona testerowi na wydajne czerpanie z wszystkich czterech warstw w zależności od etapu procesu testowego (analizy wymagań, projektowania przypadków testowych, wykonywania testów lub raportowania defektów, oraz od etapu produkcji oprogramowania.
Jest ona również bardzo istotna w procesie wyjaśniania wszelkich niejasności jakie powstają w trakcie czytania dokumentacji. Warto tutaj dodać, iż w sytuacji kiedy reputacja testerów jest umniejszana jako "tych co nie programują" to wtedy, bardzo skuteczną bronią jest stawianie odpowiednich pytań przez testerów. Jeśli charakter zadawanych pytań będzie zdradzał ignorancję testera lub niezrozumienie działania i celu systemu, negatywna postawa programisty utrwali się. Jeśli natomiast pytania testera przyniosą tę korzyść programiście, że zwrócą mu lub jej uwagę na szczegóły, które są istotne a nie zostały uwzględnione w analizie, bardzo szybko testerzy staną się ośrodkiem wiedzy na temat całościowego działa testowanego systemu. Testerzy - w naturalny niejako sposób - stają się jedynym ośrodkiem w procesie wytwarzania oprogramowania, który posiada w miarę całościową wiedzę na temat rzeczywistego działania produktu. Wynika to właśnie z faktu konieczności zrozumienia zasady działa i celowości całego systemu a nie tylko jej fragmentu. Konieczność ta, z kolei jest warunkiem istotnym do prawidłowego przetestowania systemu.
Jaka jest Twoja jedna, najbardziej cenna umiejętność? Czy potrafisz ją objaśnić innym?
James Bach w jednej ze swoich
prezentacji zadaje pytanie; "jaka jest Twoja misja?", "Czy potrafisz opisać ją w 5 minut?" Moją misję zdefiniowałbym jako; "
wsparcie kierownictwa projektu w zakresie określania i eliminowania zagrożeń związanych z dostarczeniem wadliwego oprogramowania". Chodzi o to aby mieć świadomość, że kiedy kierownik projektu przychodzi do nas z pytaniem "
na kiedy mogę mieć to przetestowane", to tak naprawdę zadaje on pytanie "
w jaki sposób - mając do dyspozycji określony czas i zasoby - mogę się dowiedzieć jak najszybciej jakie ryzyko niesie ze sobą wyprodukowane oprogramowanie". To tester musi wiedzieć co, jak długo i w jaki sposób przetestować tak samo jak programista musi wiedzieć co, jak i jak długo będzie programował.
Na tej podstawie, jako swoją najbardziej cenną umiejętność w tym zawodzie określiłbym otwartość. Otwartość rozumianą jako rozumienie zarówno potrzeb projektu jak i klienta oraz znajdowanie kompromisu pomiędzy tymi dwoma żywiołami.
Czy kwalifikacje mogą określać profesjonalnego testera?
Na tak postawione pytanie nie da się chyba odpowiedzieć... wszystko zależy od ludzi. Posiadanie certyfikatów nie dowodzi niczego choć na pewno jest pomocą w poszukiwaniu pracy oraz w zdobywaniu zawodowej pewności siebie, co także jest istotne. Czy tester z kilkuletnim doświadczeniem powinien robić certyfikat z testowania? Jeśli chce "ulepszyć" swoje CV to na pewno tak, ale jeśli chce się czegoś nauczyć to nie ma to sensu bo dowie się o podstawowym zakresie stosowania technik, które zna biegle (a jeśli ich nie zna to nie wykonywał pracy testera).
Na pewno doświadczenie jest tym co bardzo pomaga w realizacji zadań testowych. Ale to nie jest, żadna myśl odkrywcza gdyż doświadczenie jest wszędzie przydatne. Jeśli natomiast jest to pytanie o profil wykształcenia oraz wynikającego w konsekwencji doświadczenia zawodowego to nie potrafię na to odpowiedzieć. Spotykałem wielu testerów. Byli wśród nich i absolwenci filozofii jak i absolwenci fizyki czy informatyki. Ale nie umiem powiedzieć czy wykształcenie ma jakikolwiek wpływ na to czy jest się dobrym lub złym testerem. Z całą pewnością znajomość i wiedza z zakresu inżynierii oprogramowania, programowania, czy generalnie informatyki jest czymś niezbędnym. Z moich obserwacji wynika, że testerzy o informatycznym profilu wykształcenia doskonale sobie radzą z problemami czysto technicznymi takimi jak zrozumienie działania skomplikowanej funkcjonalności ale z drugiej strony często spotykałem tutaj tendencje do poprawiania a nie testowania tej funkcjonalności co zżerało czas i zasoby. I nie chodzi mi tutaj o to, że doszukiwali się źródeł problemu ale o to, że często zamiast poświęcać czas na identyfikację defektów poświęcali czasz na poszukiwanie odpowiedzi na pytanie "jak to naprawić" co jest powinnością programisty.
Ludzie o wykształceniu nie technicznym są znacznie bardziej wyczuleni na defekty. Powoduje to, że czasami przesadzają z oceną wagi defektu oraz zajmują sztywniejsze stanowisko w procesie weryfikacji naprawionych defektów. Często także - powodowani swoją niepewnością wynikającą ze świadomości braku wykształcenia informatycznego - komplikują zagadnienia w fazie analizy co utrudnia im znacznie zrozumienie podstawowych kwestii.
Nie wiem, która opcja jest lepsza... Ale wiem, że za każdym razem kiedy pracowałem w zespole testerów, to tworzył się inny niż u programistów świat... świat, w którym ludzie otwarci są na wiedzę i dzielenie się nią, w którym czują się spojeni misją, którą mam nadzieję każdy z nich potrafi sobie zdefiniować. Świat który jest jednak mocno sceptyczny. Z drugiej jednak strony powstaje wiele patologii takich jak tworzenie "mitycznej jakości" lub zbyt szczegółowe podejście do zagadnień testowych co powoduje niepotrzebne wydłużenie cyklu testowego.
Reasumując, definiowanie profesji testera z całą pewności jest pożądane. Dobrze, że powstają firmy certyfikujące i standaryzujące. Dobrze, że jest mnóstwo wolnych strzelców i ludzi pracujących na własnymi metodykami. Taka dychotomia jest symptomem tego, że jest to jeszcze bardzo młoda dziedzina. Ale bez względu na to czy pracujemy w środowisku extreme, agaile, V, W, iteracyjnym czy w modelu kaskadowym, z całą pewnością powinniśmy w naszych codziennych obowiązkach testera zapewniać spełnienie podstawowych warunków takich jak kontrolowalność, wiarygodność, weryfikowalność i jednoznaczność przy optymalnym stosowaniu technik testowych.
