Czy na pokładzie jest tester? O roli testera oprogramowania w projekcie

Pierwsza zasada brzmi: testowanie ujawnia usterki, ale nie może dowieść ich braku. Sprawdź, kim jest tester i jaka jest różnica między testami dynamicznymi a statycznymi

Zuzanna Łaska

Follow

O możliwych skutkach awarii oprogramowania słów kilka…

Jedną z najbardziej znanych i kosztownych awarii oprogramowania była katastrofa rakiety Ariane 5. W dniu 4 czerwca 1996, po niespełna 40 sekundach dziewiczego lotu, rakieta gwałtownie zboczyła ze swojej trajektorii, a siły aerodynamiczne spowodowały oderwanie się rakiet bocznych. Uruchomiło to automatycznie procedurę samozniszczenia. Straty finansowe sięgnęły miliardów dolarów.

Winowajcą katastrofy Ariane 5 okazał się być defekt kodu – oprogramowanie nie przewidywało zabezpieczenia w przypadku błędu konwersji liczby z formatu 64-bitowego do 16-bitowego. Konwertowana zmienna miała zbyt dużą wartość, by zapisać ją w za pomocą 16 bitów, czego efektem było wystąpienie awarii. Spowodowała ona, że dane diagnostyczne zostały błędnie zinterpretowane przez komputer pokładowy jako dane lotu i użyte do wyliczenia dalszej trajektorii. Co ciekawe, kawałek kodu odpowiedzialny za zmianę formatu liczb został przeniesiony z oprogramowania dla poprzedniej wersji rakiety, której parametry znacząco różniły się od tych dla nowszego modelu.

Podobny problem, choć może nie tak drastyczny w skutkach, wystąpił kilka miesięcy także w naszym kraju. 17 marca 2022, przed godziną 4 rano, systemy sterowania ruchem pociągów PKP doznały awarii w 19 lokalizacjach na terenie Polski. Kłopoty dotknęły również Indie, Tajlandię, Peru, Włochy, Szwecję i Holandię. Ruch kolejowy został sparaliżowany, pociągi miały wielogodzinne opóźnienia lub były odwoływane. Firma Alstom, odpowiedzialna za niedziałające urządzenia, wydała komunikat, że powodem problemów była usterka w oprogramowaniu – błąd w formatowaniu czasu.

Obu tym awariom prawdopodobnie można by zapobiec, gdyby przeprowadzono bardziej dogłębne testy oprogramowania przed wypuszczeniem go na rynek. Piszę prawdopodobnie, ponieważ należy pamiętać, że (zgodnie z pierwszą z siedmiu zasad testowania) testowanie ujawnia usterki, ale nie może dowieść ich braku. Z całą pewnością możemy jednak stwierdzić, że testowanie przyczynia się do obniżenia poziomu ryzyka wystąpienia awarii. Dodatkowo, wczesne testowanie pozwala zapobiec lub ograniczyć konieczność wprowadzania kosztownych (pieniężnie i czasowo) zmian na późniejszych etapach cyklu życia oprogramowania. Dla przykładu, poprawa błędnego założenia podczas precyzowania wymagań dla oprogramowania jest znacznie łatwiejsza niż modyfikacja funkcjonującego już kodu.

Testowanie dynamiczne

Słysząc o testowaniu, przeciętnej osobie przyjdą do głowy przede wszystkim testy polegające na uruchomieniu oprogramowania i identyfikacji występujących awarii. Takie testowanie nazywamy testowaniem dynamicznym. Skupia się ono na zewnętrznym zachowaniu systemu, czyli na tym, z czym ma do czynienia docelowy użytkownik. Jest to rodzaj testowania pojawiający się zdecydowanie najczęściej podczas mojej codziennej pracy – w końcu każda wprowadzona przez deweloperów poprawka powoduje konieczność sprawdzenia, czy awaria spowodowana przez naprawiony defekt rzeczywiście już nie występuje, a każda wdrożona nowa funkcjonalność wymaga skontrolowania, czy aplikacja istotnie spełnia założone wymagania. Ważną kwestią są też testy regresji, które pozwalają upewnić się, że zaimplementowane zmiany nie spowodowały pojawienia się nowych defektów lub odkrycia tych już istniejących w obszarze oprogramowania, który nie podlegał modyfikacjom.

Sam proces testowania jest oczywiście w mniejszym lub większym stopniu sformalizowany. Test przeprowadza się w oparciu o tzw. przypadek testowy, którego tworzenie i ewentualna aktualizacja również należy do obowiązków testera. Przypadkiem testowym nazywamy, wedle definicji, zestaw warunków wstępnych, danych wejściowych, akcji (w stosownych przypadkach), oczekiwanych rezultatów i warunków końcowych opracowany w oparciu o warunki testowe. W praktyce oznacza to, że dla każdej funkcjonalności - np. poprawnego logowania się do aplikacji - powinniśmy najpierw zdefiniować wymagania konieczne do przeprowadzenia testu – np. użytkownik jest zarejestrowany, jego konto jest aktywne, jest wylogowany z aplikacji, znajduje się na ekranie logowania. W naszym przykładzie danymi wejściowymi będzie login i hasło użytkownika. Akcje to kolejne kroki, które należy wykonać – wpisanie loginu i hasła w odpowiednie pola formularza i kliknięcie przycisku logowania. Oczekiwanym rezultatem będzie poprawne zalogowanie się jako podany użytkownik, przekierowanie do strony głównej, wyświetlenie komunikatu o pomyślnym logowaniu. Nasz warunek końcowy to: użytkownik jest zalogowany.

Pojedyncze przypadki testowe często łączy się w większe zestawy. W projekcie CRM Qompana, nad którym pracujemy w Engave, całkowita liczba przypadków testowych idzie w tysiące. Przejście przez każdy z nich byłoby bardzo czasochłonne, dlatego w przypadku wcześniej wspomnianych testów regresji stworzyliśmy zestaw testowy ograniczony do przypadków o największym priorytecie. Obejmuje on podstawowe funkcjonalności aplikacji i typowe ścieżki przechodzone przez użytkownika podczas korzystania z systemu. Przeprowadzenie testów regresji na podstawie tego zestawu pozwala w relatywnie krótkim czasie dosyć trafnie ocenić, czy wprowadzone zmiany negatywnie wpłynęły na dotychczasową funkcjonalność aplikacji. Tworzenie takich pakietów krytycznych scenariuszy w przypadku testów regresji jest działaniem typowym dla projektów Agile prowadzonych w metodyce Scrum, gdzie częste przyrosty funkcjonalności oprogramowania wymuszają równie częste przeprowadzanie testów regresji. Oczywiście, aby oszczędzić sobie pracy i czasu, w dzisiejszych czasach dąży się do automatyzacji testowania. Najlepszymi kandydatami do automatyzacji są te przypadki, które wykorzystuje się wielokrotnie – czyli między innymi właśnie testy regresji.

Testowanie statyczne

Równie ważnym aspektem jest również testowanie statyczne, które pozwala wykryć defekty bezpośrednio w produktach pracy, takich jak wymagania, kod czy specyfikacje. Dla przykładu, jako tester jestem zaangażowana w sprawdzanie projektów graficznych aplikacji. Dzięki temu już na tak wczesnym etapie prac jestem w stanie wykryć choćby niespójności w wyglądzie przycisków czy braki kluczowych pól w formularzach. Testowanie statyczne kodu pozwala znaleźć takie defekty jak powielony kod, zadeklarowane, ale nieużywane zmienne czy zmienne o niezdefiniowanej wartości. Testowanie statyczne wymagań pomaga natomiast odkryć wszelkie niejednoznaczności, sprzeczności czy elementy nadmiarowe.

Zaletą testowania statycznego niewątpliwie jest to, że pozwala ono ujawnić defekty, do których nie moglibyśmy dotrzeć poprzez testowanie dynamiczne, ponieważ nie powodują one awarii, albo ścieżki, na których się znajdują, są trudno dostępne. Testowanie statyczne stosowane przed rozpoczęciem testowania dynamicznego, na początkowych etapie cyklu życia oprogramowania, przyczynia się do oszczędności czasu i finansów. Niezwłoczne usuwanie defektów wykrytych tą metodą jest zazwyczaj dużo mniej kosztowne niż wprowadzanie poprawek do wdrożonego i eksploatowanego oprogramowania – szczególnie, jeśli weźmiemy pod uwagę również dodatkowe koszty wynikające z testowania potwierdzającego i testowania regresji.

Profil testera idealnego

Choć sam autor kodu powinien wykonywać testy jednostkowe, to szerszym testowaniem oprogramowania przeważnie zajmuje się tester. Dlaczego? Wynika to między innymi z odmiennego sposobu myślenia oraz cech tych osób. Programista nastawiony jest na zaprojektowanie i wykonanie produktu, zajmuje się budowaniem rozwiązań, a nie analizowaniem problemów. Dodatkowo testowanie własnej pracy może utrudniać mu efekt potwierdzenia, objawiający się oczekiwaniem, że stworzony przez niego kod będzie poprawny. Takie przeświadczenie często stanowi przeszkodę w uświadomieniu sobie popełnionych przez siebie błędów.

Tester zajmuje się weryfikacją i walidacją produktu, wyszukuje błędy i zgłasza je. Zgłoszenia, które powinny zawierać takie informacje jak opis awarii, działania, które do niej doprowadziły i oczekiwany rezultat tych działań, stają się potem podstawą pracy developerów. Z tego powodu istotne jest, by tester potrafił dokładnie zreferować problem i dbał o jakość tworzonych zgłoszeń.

Tego typu pracy sprzyja skrupulatność, kreatywność, krytyczne spojrzenie na swoje działania, ale także umiejętności interpersonalne. Ponieważ to zazwyczaj oni przekazują informacje o kłopotach związanych z produktem, testerzy powinni potrafić komunikować problemy w życzliwy i pozytywny sposób oraz wykazywać się asertywnością. Ważnym aspektem jest też niezależność testera, który ma inny punkt widzenia i inne uprzedzenia poznawcze w stosunku do autorów testowanego produktu. Dzięki temu może wykrywać inne rodzaje awarii oraz dokonywać obiektywnej oceny założeń przyjętych przez interesariuszy przy specyfikowaniu systemu.

Na testerach ciąży odpowiedzialność za zapewnienie dostatecznej jakości tworzonego oprogramowania, chociaż ich praca może być niekiedy postrzegana jako czynnik blokujący ukończenie projektu. Pamiętajmy jednak, by nie obarczać winą testerów za wszystkie awarie, które się zdarzają - w końcu gruntowne testowanie jest niemożliwe, a przekonanie o braku błędów jest błędem.

Bibliografia

Ariane 501 Inquiry Board, Ariane 5 Flight 501 Failure Report, Paryż, 19 lipca 1996

Błąd w przetwarzaniu czasu sparaliżował dziś PKP. I koleje w innych krajach też, 18 marca 2022 [1 sierpnia 2022]. Dostępne w Niebezpiecznik.pl:

[AKTUALIZACJA #3] Błąd w przetwarzaniu czasu sparaliżował dziś PKP. I koleje w innych krajach też

Stowarzyszenie Jakości Systemów Informatycznych, Certyfikowany tester Sylabus poziomu podstawowego ISTQB® Wersja 2018 V 3.1., 31 marca 2020

Stowarzyszenia Jakości Systemów Informatycznych, Słownik wyrażeń związanych z testowaniem wykorzystywanych w sylabusie CTFL 2018, 16 grudnia 2020

Zuzanna Łaska

Follow

Digitalizacja polskich przedsiębiorstw to nasza misja. Masz jakieś pytania? Chętnie Ci pomożemy!

Zapytaj o ofertę

Administratorem Twoich danych osobowych jest Engave S.A. z siedzibą w Warszawie, informacje o zasadach przetwarzania danych dostępne są w Polityce Prywatności.
Każda zgoda może zostać cofnięte w każdym momencie bez wpływu na uprzednie przetwarzanie, poprzez kontakt na: biuro@engave.pl

*Pole wymagane

Dziękujemy za zainteresowanie naszą ofertą. Skontaktujemy się Tobą w najbliższym czasie.
Przepraszamy, ale wysłanie formularza nie powiodło się. Spróbuj przesłać ponownie.

W razie problemów zapraszamy do kontaktu bezpośredniego

Więcej od Engave

Blog

W poszukiwaniu słabych sygnałów wielkich zmian w biznesie

zapraszamy do przeczytania artykułu naszej Prezes Adrianna Kilińska, w najnowszym numerze "Czerwonej Szpilki"

W poszukiwaniu słabych sygnałów wielkich zmian w biznesie

zapraszamy do przeczytania artykułu naszej Prezes Adrianna Kilińska, w najnowszym numerze "Czerwonej Szpilki"

W poszukiwaniu słabych sygnałów wielkich zmian w biznesie

zapraszamy do przeczytania artykułu naszej Prezes Adrianna Kilińska, w najnowszym numerze "Czerwonej Szpilki"

W poszukiwaniu słabych sygnałów wielkich zmian w biznesie

zapraszamy do przeczytania artykułu naszej Prezes Adrianna Kilińska, w najnowszym numerze "Czerwonej Szpilki"

W poszukiwaniu słabych sygnałów wielkich zmian w biznesie

zapraszamy do przeczytania artykułu naszej Prezes Adrianna Kilińska, w najnowszym numerze "Czerwonej Szpilki"

Blog

5 argumentów za robieniem backupu platformy Microsoft 365

Model wspólnej odpowiedzialności zakłada, że Microsoft zabezpiecza swoją infrastrukturę IT. Ty zabezpieczasz swoje dane.

5 argumentów za robieniem backupu platformy Microsoft 365

Model wspólnej odpowiedzialności zakłada, że Microsoft zabezpiecza swoją infrastrukturę IT. Ty zabezpieczasz swoje dane.

5 argumentów za robieniem backupu platformy Microsoft 365

Model wspólnej odpowiedzialności zakłada, że Microsoft zabezpiecza swoją infrastrukturę IT. Ty zabezpieczasz swoje dane.

5 argumentów za robieniem backupu platformy Microsoft 365

Model wspólnej odpowiedzialności zakłada, że Microsoft zabezpiecza swoją infrastrukturę IT. Ty zabezpieczasz swoje dane.

5 argumentów za robieniem backupu platformy Microsoft 365

Model wspólnej odpowiedzialności zakłada, że Microsoft zabezpiecza swoją infrastrukturę IT. Ty zabezpieczasz swoje dane.

Blog

Co wybrać: on premises, chmurę czy rozwiązanie hybrydowe?

Decyzja jest trudna, ale możliwa do podjęcia. Wszystko zależy od przeznaczenia danego rozwiązania i budżetu. Sprawdź >

Co wybrać: on premises, chmurę czy rozwiązanie hybrydowe?

Decyzja jest trudna, ale możliwa do podjęcia. Wszystko zależy od przeznaczenia danego rozwiązania i budżetu. Sprawdź >

Co wybrać: on premises, chmurę czy rozwiązanie hybrydowe?

Decyzja jest trudna, ale możliwa do podjęcia. Wszystko zależy od przeznaczenia danego rozwiązania i budżetu. Sprawdź >

Co wybrać: on premises, chmurę czy rozwiązanie hybrydowe?

Decyzja jest trudna, ale możliwa do podjęcia. Wszystko zależy od przeznaczenia danego rozwiązania i budżetu. Sprawdź >

Co wybrać: on premises, chmurę czy rozwiązanie hybrydowe?

Decyzja jest trudna, ale możliwa do podjęcia. Wszystko zależy od przeznaczenia danego rozwiązania i budżetu. Sprawdź >

Informacja Cookies
Na naszej stronie internetowej www.engave.pl wykorzystujemy pliki cookies. Klikając „Akceptuję wszystkie”, wyrażasz zgodę na instalację wszystkich plików cookies oraz przetwarzanie Twoich danych osobowych. Zgodę możesz wycofać w dowolnym momencie. Administratorem Twoich danych osobowych jest Engave Spółka Akcyjna z siedzibą w Warszawie, ul. Czarodzieja 16, 03-116 Warszawa. Twoje dane osobowe mogą być także przetwarzane przez strony trzecie.

Klikając „Wyłącznie niezbędne cookies”, umożliwiasz funkcjonowanie strony internetowej. Więcej informacji o przysługujących Ci prawach znajduje się w naszej Polityce Prywatności Serwisu i Polityce Plików Cookies.
Szczegóły
Akceptuj Wszystkie