W ramach naszej witryny stosujemy pliki cookies. Kontynuując przeglądanie strony, wyrażasz zgodę na używanie przez nas plików cookies. Dowiedz się więcej tutaj
X

Księgarnia PWN

   

   

   

   

.

.

   

   

   

   

Bezpłatny newsletter


Etyka testowania

Etyka testowania

Chyba każdy pracujący w obszarze zapewnienia i kontroli jakości przeżył kiedyś dylemat – mówić o problemach, czy nie? Informować klienta, że jakość tworzonej aplikacji znacznie odbiega od oczekiwań (i często zapewnień kierownictwa projektu ze strony dostawcy oprogramowania)? Ulec presji developerów i Kierownika Projektu i „nie zauważać” pewnych błędów w testowanym systemie? Skrócić czas testów i pominąć pewne przypadki testowe, ponieważ z powodu przeciągania się developmentu „zabrakło czasu” na testy?

Wprowadzenie

Osoba odpowiedzialna za testowanie – czy ogólnie za Quality Assurance – w projekcie często doświadcza dylematów tego typu. Nieraz Kierownik Testów stawiany jest w sytuacji, w której zmuszany jest do świadomej rezygnacji z sumiennego wykonania prac testowych i godzenia się na odstąpienie od założonego Planu Jakości – na przykład wtedy, gdy Kierownik Projektu „tnie” czas przeznaczony na wykonanie testów, aby zmieścić się w harmonogramie (zagrożonym poprzez wynikłe w fazie analizy czy development opóźnienia). 

Czy zawsze trzeba i powinno się ulegać takim naciskom? Co lepsze – „spokój” ze strony kierownictwa, czy świadomość rzetelnego wykonania swoich obowiązków i dbania o dobro klienta? A zapewnienie i weryfikacja jakości oprogramowania jest w istocie działaniem w interesie klienta – co więcej, w większości przypadków jest obowiązkiem dostawcy oprogramowania wymienionym w umowie o wykonanie systemu. Obowiązkiem, który aż za często jest wykonywany z niewystarczającą dbałością i spychany na dalszy plan. Wszak testy są mniej ważne, niż np. development – to development tworzy system, testerzy „tylko” mają go przeklikać. A jeśli nie zdążą – cóż, system i tak będzie testował jeszcze klient.

Jak Kierownik Testów powinien reagować na takie sytuacje? Odpowiedź na to pytanie tkwi w samej definicji testowania – a konkretnie, w celach postawionych przed testami. Zgodnie z wszelkimi definicjami i źródłami, celem testowania oprogramowania jest:

  • znalezienie błędów w oprogramowaniu jeszcze przed wdrożeniem
  • określenie, czy oprogramowanie spełnia założenia (czy robi to, co powinno)

Niektórzy dodają, że celem testowania jest też maksymalizacja ilości i znaczenia (“severity”) znalezionych błędów na wydanego dolara (czy w naszym przypadku złotówkę). W praktyce oznacza to, że testować należy jak najwcześniej – im później znajdujemy błąd, tym koszt jego naprawy jest większy. Jak więc widać, sama definicja testowania mówi nam, co powinniśmy robić i co należy do zakresu naszych obowiązków – czyli i etyki zawodowej.

Etyka? Ale o co chodzi?

Czym jest etyka (w kontekście niniejszego artykułu – etyka zawodowa)? Wikipedia podaje, że „pojęcie etyki zawodowej odnosi się przede wszystkim do norm postępowania danej grupy zawodowej (np. nauczycieli). W tym sensie etyka zawodowa jest etyką normatywną, starającą się opisać wzór osobowy pedagoga, cele etyczne zawodu, normy postępowania w praktyce pedagogicznej i typowe konflikty etyczne mogące się pojawić w praktyce zawodowej”.

Etyka w pracy testera odnosi się do celów wykonywanej pracy – jakim jest zapewnienie i kontrola jakości oprogramowania (często również innych produktów projektu, jak na przykład specyfikacji systemu); norm postępowania – czyli sposobów, w jakie tester powinien wykonywać swą pracę, by sprostać wymienionym celom; wreszcie – konfliktów etycznych, które mogą zaistnieć w środowisku wykonywania pracy. W praktyce etyka przejawia się głównie w opisanych niżej aspektach.

Sumienność

Etyka to między innymi sumienna realizacja obowiązków (np. staranne planowanie i projektowanie testów, uwzględniające wszelkie możliwe źródła informacji wejściowej – przykładowo nie tylko dokumentację przypadków użycia, ale i normy obowiązujące w określonym zakresie, własne doświadczenie etc.). Niektórzy traktują pracę jako nieprzyjemny obowiązek, który należy jak najszybciej (i często „byle jak”) wykonać i „zapomnieć” o nim. Tymczasem etyka zawodowa polega m.in. na wykonywaniu pracy z zaangażowaniem i tak, by jej wyniki umożliwiały spełnienie postawionego przed określonym zadaniem celu. Celem tworzenia przypadków testowych jest zbudowanie projektu testów, umożliwiającego weryfikację aplikacji w jak największym stopniu – nie osiągniemy tego, tworząc przypadki „z grubsza” obejmujące funkcjonalność aplikacji. Projekt testów musi być przemyślany i uwzględniać też aspekty, które nie wynikają bezpośrednio ze specyfikacji systemu, czy też innych dokumentów stanowiących podstawę testowania. W analizie często jest tak, że niektórych rzeczy w ogóle się nie opisuje, jako że są one poniekąd oczywiste (np. działanie przycisku Wstecz, czy też proste operacje arytmetyczne) – co nie oznacza jednak, że można pominąć ich weryfikację. Nie zawsze funkcje „oczywiste” będą poprawnie zaimplementowane – tester musi i to przewidzieć.

Ponadto – pełna dokumentacja testów pomaga nie tylko ich autorowi. Umożliwia również innym osobom dołączającym do zespołu testowego szybko i sprawnie wdrożyć się do pracy (gdyż nie muszą domyślać się luk w specyfikacji testów – wszystko jest opisane precyzyjnie i kompletnie). Często dokumentacja testów przekazywana jest klientowi i korzysta z niej jego zespół testowy. Im lepsze będą nasze testy, tym efektywniej będzie pracować zespół klienta – i tym lepsze wrażenie sprawimy jakością naszej pracy.

Powyższy wywód nie oznacza konieczności dokumentowania wszystkich możliwych przypadków testowych – równie dobrze można wspomóc się testami eksploracyjnymi i ad hoc i niektóre testy wykonywać bez dokumentacji. Ważne jest jedynie, by zarejestrować wyniki takich nieformalnych testów i w razie konieczności (np. jeśli za pomocą pewnych scenariuszy znajdziemy błąd krytyczny) uzupełnić dokumentację przypadków testowych.

Sumienność powinna przejawiać się również w sposobie raportowania błędów. Raporty muszą być wykonane starannie i wystarczająco dokładnie, by programista otrzymujący zgłoszenie błędu, wiedział, co jest problemem, jak go odtworzyć i w jaki sposób powinien być naprawiony. Nie wystarczy zgłosić, że „ta funkcja nie działa” – po pierwsze, funkcja może nie działać na wiele sposobów (np. wyszukiwarka – może nie znajdować wyników zgodnych z wprowadzonymi kryteriami wyszukiwania, może nie znajdować wyników tylko dla kombinacji pewnych kryteriów, a może w ogóle nic nie znajdować – która z tych sytuacji jest opisana błędem „funkcja nie działa”?); po drugie niewystarczający opis problemu często skutkuje tym, że zgłoszenie zostaje odrzucone (ponieważ programiści nie wiedzą, co autor miał na myśli) i tym sposobem traci się cenny czas na poprawienie treści zgłoszenia i ponowne skierowanie go do naprawy. Prawidłowo skonstruowany opis problemu musi zawierać co najmniej: podsumowanie umożliwiające jednoznaczne określenie rodzaju i zakresu błędu, dokładny opis (czyli scenariusz reprodukcji defektu), warunki początkowe oraz – wszędzie tam, gdzie jest to istotne dla przebiegu procesu – dane testowe.

Niezwykle istotna jest też odpowiednia klasyfikacja błędu – często testerzy mają skłonność do określania każdego defektu jako „ważny” lub wręcz „krytyczny” – ponieważ według nich nawet drobna usterka musi być natychmiast naprawiona, a z reguły błędy naprawiane są według priorytetu – co oznacza, że błąd „mało ważny” będzie naprawiony na samym końcu. Niewłaściwe określanie priorytetu błędów wprowadza niepotrzebne konflikty i chaos – konflikty, ponieważ programiści otrzymują dziesiątki krytycznych błędów sugerujących, iż kondycja aplikacji jest bardzo słaba; chaos – ponieważ tym sposobem fałszuje się stan faktyczny (i na przykład klient mający wgląd do repozytorium błędów widzi jedynie błędy wysokiego priorytetu – co naturalną koleją rzeczy budzi jego niepokój i wątpliwości, co do jakości prac dostawcy).

Lojalność wobec klienta

Etyczny specjalista QA przejawia nastawienie „customer oriented” – klient jest odbiorcą oprogramowania i oczekuje produktu działającego zgodnie z wymaganiami i stabilnego. Obowiązkiem testera jest możliwie najdokładniej zweryfikować aplikację i znaleźć możliwie najwięcej błędów, które z kolei zostają przekazane do naprawy. Naciski w rodzaju prób skrócenia czasu przeznaczonego na testy, godzą w interesy klienta – gdyż z dużym prawdopodobieństwem spowodują, że niektóre (często nawet krytyczne) błędy nie zostaną znalezione przez zespół testowy… a odkryje je klient – czym rzecz jasna nie będzie zachwycony. Zadaniem testera – a właściwie Kierownika Testów, opierającego się na opinii swojego zespołu – jest przekonanie kierownictwa projektu, że pomysł z „cięciem testów” nie jest najszczęśliwszy i może jedynie przyczynić się do niezadowolenia i rozczarowania klienta po oddaniu mu systemu. Jeśli zaś argumenty za utrzymaniem zaplanowanego czasu testów nie skutkują – Kierownik Testów powinien nalegać przynajmniej na poinformowanie klienta o zaistniałej sytuacji i przekazaniu mu informacji o tym, co przetestowano i z jakimi wynikami, a czego nie – da to klientowi pewien podgląd na sytuację i wskazówki, gdzie może spodziewać się problemów.

Często zdarza się również, że development decyduje, iż określone zgłoszone błędy nie są naprawiane. Dlaczego? Ponieważ: nie ma czasu, błąd ma niski (wg oceny programisty) priorytet, błąd nie jest błędem (bardzo częsty argument ze strony programistów). Zadaniem Kierownika Testów jest rozwiązywanie tego typu problemów. Jak?

Jeśli błąd nie jest naprawiany z powodu braku czasu, Kierownik Testów powinien poinformować Kierownika Projektu o zaistniałej sytuacji i zasugerować przedłużenie czasu naprawy błędów – lub przydzielenie dodatkowych zasobów do tego zadania. Jednym z celów zespołu testowego jest znajdowanie błędów – jednak jeśli owe błędy nie są naprawiane – sens pracy staje pod znakiem zapytania. 

Jeżeli błąd nie jest naprawiany ponieważ wg programisty ma on niski priorytet (choć my uważamy inaczej), należy w pierwszej kolejności omówić sprawę z tym programistą i wyjaśnić wątpliwości. Często zdarza się, że developerzy nie są świadomi ryzyka biznesowego związanego z określonym błędem (np. dla programisty jakiś błąd jest tylko brakiem walidacji – dla klienta będzie to defekt krytyczny umożliwiający wykonanie niedozwolonej operacji finansowej w systemie) i dlatego warto porozmawiać i uświadomić im potencjalne zagrożenie. Mogą też być nieświadomi logiki, jaką przeciętny użytkownik kieruje się korzystając z aplikacji. Mogą to też być kwestie użyteczności (usability) – może niezbyt istotne z punktu widzenia poprawności biznesowej aplikacji, lecz mające duże znaczenie dla użytkownika końcowego.

Natomiast jeżeli zgłoszony błąd „wisi” z adnotacją, że zdaniem programistów nie jest to błąd, należy wpierw wyjaśnić rozbieżności w interpretacji zachowania systemu (dla testera coś jest ewidentnym błędem, dla programisty – nie). Najlepszym na to sposobem jest weryfikacja specyfikacji systemu – jeżeli system zachowuje się w sposób opisany w dokumentacji, a tester nadal uważa, że działanie to jest błędne, Kierownik Testów powinien przekazać problem do rozwiązania analitykom. Często w wyniku takiej akcji okazuje się, że specyfikacja zawiera poważne błędy. Dzięki interwencji testera mogą one zostać naprawione, a następnie może być poprawiona implementacja – co w efekcie daje nie tylko lepszą jakość systemu, ale i dokumentacji projektowej.

Uczciwość

Etyka oznacza uczciwość – względem współpracowników, szefów, klienta. O problemach mówi się otwarcie, nie próbuje ich zatajać, czy też zrzucać odpowiedzialność na innych. Kierownik Testów odpowiada za pracę swojego zespołu przed Kierownikiem Projektu oraz często bezpośrednio przed klientem.  Musi być lojalny i uczciwy w stosunku do wszystkich tych stron – co nieraz jest niezwykle trudne i wymaga umiejętności negocjacji oraz rozwiązywania konfliktów. Nie tylko powinien dbać o komfort pracy swoich podwładnych i określenie jasnych celów i zasad zadań stawianych przed nimi, ale i uczciwie informować o problemach, reagować na nieprawidłowości oraz błędy.

Analogicznie w przypadku relacji z przełożonymi czy klientem – lepiej otwarcie mówić o problemach związanych z pracami testowymi, niż je ukrywać i liczyć, że „sprawa się nie wyda”. Na przykład – jeśli Kierownik Testów wie, że w określonym przez harmonogram czasie nie jest możliwe wykonanie wszystkich zaplanowanych prac – albo jakość wykonania nie będzie wystarczająca – powinien szczerze poinformować o tym kierownictwo projektu. Czasem argumenty (zwłaszcza jeśli są przedstawione w odpowiednio przekonujący sposób) odnoszą pożądany skutek i harmonogram ulega modyfikacji. Lecz nawet jeśli skończy się tylko na rozmowie bez zmiany planu testowania, przynajmniej kierownictwo jest świadomie ryzyka związanego z nie dość staranną realizacją testów (czyli zazwyczaj ryzyka pominięcia błędów, braku pokrycia testów w wymaganym stopniu etc.). O takim ryzyku powinien być również poinformowany klient – nie ma nic gorszego, niż trzymanie klienta w przekonaniu, że aplikacja, którą otrzyma do testów – lub użytkowania – działa poprawnie, a w praktyce okazuje się, że wręcz przeciwnie: roi się w niej od błędów. Taka sytuacja nie tylko irytuje klienta, ale i podważa wiarygodność dostawcy oprogramowania.

Kodeks etyczny zawodu informatyka wg DIS (zaczerpnięte z http://www.dis.waw.pl)

W szeroko rozumianym zawodzie informatyka – nie tylko testera – powinien obowiązywać określony kodeks etyczny. Podjęto już próbę jego stworzenia. Postulaty przedstawione są poniżej.

1.Informatyka jest wiedzą służebną wobec jej różnorodnych zastosowań dziedzinowych. Ma pomagać w rozwoju tych dziedzin, a nie przeszkadzać im.

2.Narzędzia i algorytmy informatyki nie stanowią celu, lecz są środkiem mającym przede wszystkim rozwiązywać stawiane jej problemy; z poszanowaniem zasad logiki, praw człowieka, jego środowiska naturalnego, ergonomii, ekonomii, poprawności językowej, norm jakości oraz specyfiki dziedzin szczegółowych.

3.Informatyk stale doskonali swoją wiedzę. Jednocześnie zawsze przedstawia swoje kompetencje i doświadczenie zawodowe zgodnie ze stanem aktualnym. Podobnie postępuje z produktami, które prezentuje klientowi.

4.Informatyk wzorowo szanuje własność intelektualną. Powstrzymuje się od kopiowania oprogramowania nawet nie chronionego prawem, jeśli nie ma do niego wystarczających uprawnień.

5.Informatyk szanuje prawa majątkowe swojego pracodawcy lub klienta do informacji zawartych w jego systemach informatycznych. W szczególności nie udostępnia tych informacji osobom nie upoważnionym.

6.Informatyk nie podejmuje się naruszania integralności systemów informatycznych żadnych podmiotów, nawet jeśli są to podmioty konkurencyjne do jego zleceniodawcy lub pracodawcy.

7.Informatyk prowadzący działalność dydaktyczną, przy prezentacji konkretnego produktu zawsze stara się wspomnieć o istnieniu alternatywnych produktów o analogicznej funkcjonalności oraz przeznaczeniu.

8.Informatyk prowadzący działalność naukową lub badawczo-rozwojową, zawsze powinien wyraźnie oddzielać wiedzę pewną i już udowodnioną od przyjmowanych przez siebie założeń.

9.Informatyk zawsze mówi swojemu klientowi prawdę o przewidywaniach kosztów oraz przypuszczalnym czasie trwania analizowanego przez siebie projektu lub przedsięwzięcia znajdującego się już w fazie realizacji.

10.Informatyk nie podejmuje się równocześnie prac u kilku zleceniodawców, których interesy mogłyby być ze sobą sprzeczne.

11.Informatyk stara się unikać w przedsięwzięciach jednoczesnego pełnienia ról wzajemnie opozycyjnych: np. zleceniodawcy- zleceniobiorcy, podwykonawcy- kontrolera, programisty-testera itp.

Kodeks został opracowany przez DiS, w dniu 6.11.2000. Propozycja ta został skierowana do środowisk profesjonalistów informatyki polskiej, przede wszystkim PTI; jednakże do dziś środowiska te nie przyjęły żadnej propozycji kodeksu etycznego. Ciekawe dlaczego?

Podsumowanie

W każdym zawodzie ważne są nie tylko umiejętności i doświadczenie, ale i stosowanie się pracownika do zasad obowiązującej w danej branży etyki. Nawet najlepszy specjalista nie będzie „wartością dodaną”, jeżeli nie wykazuje zaangażowania w to, co robi i nie przykłada do tego odpowiedniej wagi. W zawodzie testera, czy specjalisty QA zaangażowanie takie jest szczególnie ważne – gdyż pracownik działu jakości ma dbać o jakość „własności” klienta, jaką jest produkowany system informatyczny. Obowiązkiem testera jest wykonywanie pracy z należytą starannością – czyli nie tylko realizacja zaplanowanych działań i informowanie o ich wynikach, ale i reagowanie na potencjalne i realne problemy mogące zagrozić jakości produktu.

Autor: Karolina Zmitrowicz

Polecamy

Partnerzy