Aby świadczyć usługi na najwyższym poziomie, korzystamy z plików cookies. Korzystając z naszej strony internetowej, oznacza to, że zostaną one umieszczone na Twoim urządzeniu. Możesz w każdej chwili zmienić ustawienia przeglądarki. Zapoznaj się z naszą polityką dotyczącą plików cookie.
Autorzy
- Krzysztof Grabowski
Autorzy
- Krzysztof Grabowski
Spis treści
Kategorie
Wstęp
Drogi czytelniku, zapraszam Cię do nowego cyklu artykułów poświęconych testowaniu.
Będziemy zgłębiać tajniki pracy testerów/QA oraz analizować, co dzieje się podczas procesu testowania. Przyjrzymy się głównym zasadom, którymi kierują się testerzy, ich podejściu do różnych sytuacji oraz celom, jakie przyświecają ich pracy.
Dlaczego warto wiedzieć więcej o procesie testowania? Jeśli pracujesz w branży IT, ale nie zajmujesz się technikaliami, to najpewniej z testowaniem nie miałeś zbyt dużego kontaktu. Może wydawać się, że to proste zadanie, ale jak w każdej dziedzinie, po głębszym przyjrzeniu się okazuje się bardziej skomplikowane. Warto poznać pewne zasady i zagadnienia, aby lepiej je zrozumieć.
Dla programistów testowanie jest codziennością, gdyż nieustannie sprawdzają swój kod. Jednak dla osób pracujących bardziej biznesowo czy projektowo, ten cykl może być niezmiernie przydatny w zrozumieniu, jaki wpływ testowanie ma na cały cykl pracy nad projektem.
Na początek omówimy siedem głównych zasad testowania. Są one istnym dekalogiem każdego testera, a niestety osoby zarządzające projektem nie zawsze zdają sobie z nich sprawę, co może prowadzić do błędnych założeń.
Będziemy zgłębiać tajniki pracy testerów/QA oraz analizować, co dzieje się podczas procesu testowania. Przyjrzymy się głównym zasadom, którymi kierują się testerzy, ich podejściu do różnych sytuacji oraz celom, jakie przyświecają ich pracy.
Dlaczego warto wiedzieć więcej o procesie testowania? Jeśli pracujesz w branży IT, ale nie zajmujesz się technikaliami, to najpewniej z testowaniem nie miałeś zbyt dużego kontaktu. Może wydawać się, że to proste zadanie, ale jak w każdej dziedzinie, po głębszym przyjrzeniu się okazuje się bardziej skomplikowane. Warto poznać pewne zasady i zagadnienia, aby lepiej je zrozumieć.
Dla programistów testowanie jest codziennością, gdyż nieustannie sprawdzają swój kod. Jednak dla osób pracujących bardziej biznesowo czy projektowo, ten cykl może być niezmiernie przydatny w zrozumieniu, jaki wpływ testowanie ma na cały cykl pracy nad projektem.
Na początek omówimy siedem głównych zasad testowania. Są one istnym dekalogiem każdego testera, a niestety osoby zarządzające projektem nie zawsze zdają sobie z nich sprawę, co może prowadzić do błędnych założeń.
1. Testowanie ujawnia usterki, ale nie może dowieść ich braku
Brzmi jak wymówka? Bierzemy się za testowanie, ale od razu zaznaczamy, że jeśli pojawią się dodatkowe bugi, to nie jest nasza wina?
Często, gdy coś nie działa, pada pytanie: „Kto to testował?” albo „Czy to w ogóle było testowane?”. Wydaje się oczywiste, że jeśli coś przeszło testy, to nie ma w tym błędów. Rzeczywistość jest jednak bardziej skomplikowana i warto to głośno powiedzieć.
Owszem, testowanie ujawnia usterki, ale nigdy nie można mieć pewności, że znaleziono wszystkie defekty. Im dłużej produkt jest testowany, tym mniejsza szansa na występowanie w nim usterek, ale czy na pewno nic nie przeoczyliśmy? Pewności nigdy mieć nie możemy, bo niektóre błędy mogą być ukryte i pojawić się w określonych warunkach, np. podczas zmiany czasu z letniego na zimowy czy przy zmianie sprzętu.
W praktyce, na początku procesu testowania częściej znajdujemy defekty. Z czasem ich liczba maleje i musimy podjąć decyzję, że produkt jest gotowy. Testowanie powinno trwać tak długo, jak udaje nam się znajdować nowe błędy. Po przetestowaniu wszystkich scenariuszy testowych, należy przeprowadzić chłodną kalkulację, czy warto kontynuować testy. Dobry tester potrafi intuicyjnie ocenić, kiedy można zakończyć testowanie.
Często, gdy coś nie działa, pada pytanie: „Kto to testował?” albo „Czy to w ogóle było testowane?”. Wydaje się oczywiste, że jeśli coś przeszło testy, to nie ma w tym błędów. Rzeczywistość jest jednak bardziej skomplikowana i warto to głośno powiedzieć.
Owszem, testowanie ujawnia usterki, ale nigdy nie można mieć pewności, że znaleziono wszystkie defekty. Im dłużej produkt jest testowany, tym mniejsza szansa na występowanie w nim usterek, ale czy na pewno nic nie przeoczyliśmy? Pewności nigdy mieć nie możemy, bo niektóre błędy mogą być ukryte i pojawić się w określonych warunkach, np. podczas zmiany czasu z letniego na zimowy czy przy zmianie sprzętu.
W praktyce, na początku procesu testowania częściej znajdujemy defekty. Z czasem ich liczba maleje i musimy podjąć decyzję, że produkt jest gotowy. Testowanie powinno trwać tak długo, jak udaje nam się znajdować nowe błędy. Po przetestowaniu wszystkich scenariuszy testowych, należy przeprowadzić chłodną kalkulację, czy warto kontynuować testy. Dobry tester potrafi intuicyjnie ocenić, kiedy można zakończyć testowanie.
2. Testowanie gruntowne jest niemożliwe
Nie jest możliwe przetestowanie wszystkiego — każdej kombinacji, wszystkich danych, pokrycia każdego możliwego wyniku. W praktyce sprawdza się możliwie wszystkie scenariusze, które mogą się pojawić, używając tzw. wartości brzegowych poszczególnych warunków w aplikacji. Weryfikuje się poprawność wywołań podstawowych zachowań pozytywnych i negatywnych danej części aplikacji, aby mieć pewność, że kluczowe wartości wywołują odpowiednie zachowanie. Przetestowanie wszystkiego byłoby nieefektywnym wykorzystaniem budżetu, dlatego nie warto przesadzać z testami, dbając o kieszeń klienta.
Warto sprawdzić, zakwestionować poprawne działanie systemu i udowodnić sobie, że faktycznie działa, aby klient otrzymał sprawny produkt. Jak w każdej dziedzinie, należy zachować zdrowy rozsądek. Czy naprawdę przetestujemy 10 000 różnych kombinacji numerycznych? Oczywiście, że nie, ponieważ jest to fizycznie nierealne. Ważne jest, aby mieć tego pełną świadomość.
Warto sprawdzić, zakwestionować poprawne działanie systemu i udowodnić sobie, że faktycznie działa, aby klient otrzymał sprawny produkt. Jak w każdej dziedzinie, należy zachować zdrowy rozsądek. Czy naprawdę przetestujemy 10 000 różnych kombinacji numerycznych? Oczywiście, że nie, ponieważ jest to fizycznie nierealne. Ważne jest, aby mieć tego pełną świadomość.
3. Wczesne testowanie oszczędza czas i pieniądze
Na ten temat można by napisać osobny artykuł, a nawet całą książkę. Testowanie można rozpocząć od samego początku pracy nad produktem, testując koncepcje i szukając w nich wad. Można również testować dokumentację w poszukiwaniu nieścisłości. O ile tańsze jest poprawienie kilku zdań w pliku tekstowym niż przebudowywanie kodu przez zespół programistów? Tester zaangażowany od samego początku projektu jest w stanie wyłapać pewne problemy na wczesnym etapie, co jest bardzo tanie w naprawie. Walidując wczesne makiety, diagramy przejść i oceniając użyteczność, można wyeliminować problemy, zanim jeszcze powstaną.
Niestety, wciąż króluje podejście, że testuje się dopiero działający produkt. Jednak wczesna inwestycja w testowanie może przynieść wymierne oszczędności na późniejszych etapach projektu. Im bardziej rozrasta się kod aplikacji, tym bardziej kosztowna i skomplikowana jest jego modyfikacja.
Dla dobra budżetu projektu testerów zazwyczaj angażuje się na ostatnim etapie wytwórczym, ale jest to podejście, które przyszło do nas z metodyk waterfallowych. Dojrzałe organizacje, które wytwarzają oprogramowanie w nowoczesnych metodykach, wiedzą już, że testowanie od samego początku się opłaca. Badania pokazują, że oszczędności w czasochłonności poświęconej na naprawę błędów mogą wynosić nawet 70%.
Niestety, wciąż króluje podejście, że testuje się dopiero działający produkt. Jednak wczesna inwestycja w testowanie może przynieść wymierne oszczędności na późniejszych etapach projektu. Im bardziej rozrasta się kod aplikacji, tym bardziej kosztowna i skomplikowana jest jego modyfikacja.
Dla dobra budżetu projektu testerów zazwyczaj angażuje się na ostatnim etapie wytwórczym, ale jest to podejście, które przyszło do nas z metodyk waterfallowych. Dojrzałe organizacje, które wytwarzają oprogramowanie w nowoczesnych metodykach, wiedzą już, że testowanie od samego początku się opłaca. Badania pokazują, że oszczędności w czasochłonności poświęconej na naprawę błędów mogą wynosić nawet 70%.
4. Kumulowanie się defektów
Zasada ta jest niezwykle prosta, ale jakże prawdziwa i wielokrotnie potwierdzona w praktyce — niektóre komponenty lub moduły oprogramowania mogą zawierać więcej defektów lub odpowiadać za więcej awarii niż inne. Defekty mają tendencję do kumulowania się i eskalowania problemów na resztę aplikacji. Wynika to z wielu czynników, na przykład z faktu, że aplikacja nie jest tworzona przez jedną osobę, a różne części aplikacji są różnie skomplikowane. W efekcie defekty nie są równomiernie rozłożone w całym systemie, lecz występują grupowo.
Jeśli tester zaczyna znajdować defekty w jednym miejscu, to z większym zaangażowaniem szuka ich tam dalej. Im więcej defektów znajdzie, tym łatwiej będzie programistom odnaleźć prawdziwe źródło awarii, które może być bardziej złożone niż tylko pojedynczy defekt, który na pierwszy rzut oka nie wygląda na część większego problemu.
Aplikacji nie powinno testować się równomiernie, lecz skupić na najbardziej problematycznych modułach.
Jeśli tester zaczyna znajdować defekty w jednym miejscu, to z większym zaangażowaniem szuka ich tam dalej. Im więcej defektów znajdzie, tym łatwiej będzie programistom odnaleźć prawdziwe źródło awarii, które może być bardziej złożone niż tylko pojedynczy defekt, który na pierwszy rzut oka nie wygląda na część większego problemu.
Aplikacji nie powinno testować się równomiernie, lecz skupić na najbardziej problematycznych modułach.
5. Paradoks pestycydów
Zasada ta mówi, że gdy testujemy aplikacje w jednolity sposób, z biegiem czasu mogą pojawić się defekty, które nie będą wykrywalne przez podstawowe scenariusze testowe. Będą one prześlizgiwać się przez testy i ujawniać podczas bardziej skomplikowanych czynności.
Testowanie automatyczne cierpi właśnie w tym kontekście. Testy mogą przechodzić "na zielono", ale w systemie może istnieć defekt powodujący awarię, który nie został wykryty. Stąd testowanie manualne — choć mniej wydajne i bardziej czasochłonne — długofalowo jest bardziej dokładne. Człowiek podchodząc do testów za każdym razem ma świeże podejście (a przynajmniej powinien!) i często zdarza się, że defekty wyłapuje się przy kolejnych spotkaniach z testowaną aplikacją, a nie przy pierwszej wizycie — choć bardzo byśmy chcieli, aby było inaczej. Za każdym razem podchodzimy do testów inaczej i wymyślamy inne dane.
Zasada ta jest wieloznaczna. Mówi o tym, abyśmy nie testowali aplikacji w jednolity sposób, ale też pokazuje, jak ważna jest różnorodność w podejściu do testowania i jak zgubne może być ścisłe trzymanie się scenariuszy testowych. Ludzkie podejście jest bardzo ważne. Podczas wielokrotnego testowania tego samego może wkraść się rutyna i łatwo stracić czujność. Dlatego tak ważne jest, aby ciągle pozwalać sobie na dziecięcą ciekawość, którą mamy w sobie. Za każdym razem próbować czegoś nowego i zawsze starać się bawić w detektywa.
Wchodząc w erę AI, musimy być świadomi tego, czym powinniśmy wyróżniać się jako ludzie — pomysłowością i kreatywnością, działaniem nieschematycznym i ciągłym generowaniem nowych pomysłów. W testowaniu okazuje się to bardzo istotne.
Testowanie automatyczne cierpi właśnie w tym kontekście. Testy mogą przechodzić "na zielono", ale w systemie może istnieć defekt powodujący awarię, który nie został wykryty. Stąd testowanie manualne — choć mniej wydajne i bardziej czasochłonne — długofalowo jest bardziej dokładne. Człowiek podchodząc do testów za każdym razem ma świeże podejście (a przynajmniej powinien!) i często zdarza się, że defekty wyłapuje się przy kolejnych spotkaniach z testowaną aplikacją, a nie przy pierwszej wizycie — choć bardzo byśmy chcieli, aby było inaczej. Za każdym razem podchodzimy do testów inaczej i wymyślamy inne dane.
Zasada ta jest wieloznaczna. Mówi o tym, abyśmy nie testowali aplikacji w jednolity sposób, ale też pokazuje, jak ważna jest różnorodność w podejściu do testowania i jak zgubne może być ścisłe trzymanie się scenariuszy testowych. Ludzkie podejście jest bardzo ważne. Podczas wielokrotnego testowania tego samego może wkraść się rutyna i łatwo stracić czujność. Dlatego tak ważne jest, aby ciągle pozwalać sobie na dziecięcą ciekawość, którą mamy w sobie. Za każdym razem próbować czegoś nowego i zawsze starać się bawić w detektywa.
Wchodząc w erę AI, musimy być świadomi tego, czym powinniśmy wyróżniać się jako ludzie — pomysłowością i kreatywnością, działaniem nieschematycznym i ciągłym generowaniem nowych pomysłów. W testowaniu okazuje się to bardzo istotne.
6. Testowanie zależy od kontekstu
Metody i rodzaje zastosowanych testów mogą różnić się w zależności od rodzaju i kontekstu aplikacji czy systemu. Nie wszystko testuje się tak samo, ponieważ różne produkty są różnie zbudowane. Początkowo zasada wydaje się prosta: testuje się to, co zostało zbudowane, aby potwierdzić pełne i poprawne działanie. Jednak testuje się także z myślą o użytkowniku i wadze systemowej, czyli o tym, co jest w danej aplikacji najważniejsze.
Gdy mamy do czynienia z panelem administracyjnym, nie będziemy zwracać dużej uwagi na kwestie wizualne. Z kolei część przeznaczona dla użytkownika końcowego musi być pod tym względem perfekcyjna. Inaczej będziemy testować aplikację internetową przeznaczoną dla osób niepełnosprawnych, a inaczej tę będącą galerią sztuki. Co innego będzie ważne w aplikacji, w której odbywają się transakcje finansowe, a co innego w blogu, gdzie użytkownicy są tylko odbiorcami treści.
Testowanie jest zależne od kontekstu i każdy produkt testuje się inaczej. Nie ma kilku identycznych aplikacji, tak samo jak nie ma identycznych sposobów na przetestowanie wszystkiego.
Gdy mamy do czynienia z panelem administracyjnym, nie będziemy zwracać dużej uwagi na kwestie wizualne. Z kolei część przeznaczona dla użytkownika końcowego musi być pod tym względem perfekcyjna. Inaczej będziemy testować aplikację internetową przeznaczoną dla osób niepełnosprawnych, a inaczej tę będącą galerią sztuki. Co innego będzie ważne w aplikacji, w której odbywają się transakcje finansowe, a co innego w blogu, gdzie użytkownicy są tylko odbiorcami treści.
Testowanie jest zależne od kontekstu i każdy produkt testuje się inaczej. Nie ma kilku identycznych aplikacji, tak samo jak nie ma identycznych sposobów na przetestowanie wszystkiego.
7. Przekonanie o braku błędów jest błędem
Jest to kolejna wieloznaczna zasada. Po części odwołuje się do pierwszej zasady — nigdy nie możemy być pewni, że błędów nie ma. Nawet jeśli produkt działa bez zarzutu i przeszedł testy, które nie wykryły żadnych problemów, to jest to jedynie stan na dany moment, w konkretnej wersji aplikacji, na danym urządzeniu. Nie wiadomo, jak aplikacja zachowa się następnego dnia, gdy zmieni się data, wersja systemu operacyjnego, czy przeglądarki.
Inna interpretacja tej zasady mówi o tym, że poprawność działania od strony technicznej nie musi być wystarczająca, by mówić o sukcesie produktu. Testowanie nie skupia się wyłącznie na technicznej stronie, ale może obejmować także inne aspekty. Możemy testować na przykład użyteczność aplikacji, gdzie wciąż mogą występować problemy, np. niewystarczająco płynny flow czy nieprzejrzysty interfejs użytkownika.
Aplikacja sprawna technicznie nie musi być koniecznie tą dobrze działającą.
Inna interpretacja tej zasady mówi o tym, że poprawność działania od strony technicznej nie musi być wystarczająca, by mówić o sukcesie produktu. Testowanie nie skupia się wyłącznie na technicznej stronie, ale może obejmować także inne aspekty. Możemy testować na przykład użyteczność aplikacji, gdzie wciąż mogą występować problemy, np. niewystarczająco płynny flow czy nieprzejrzysty interfejs użytkownika.
Aplikacja sprawna technicznie nie musi być koniecznie tą dobrze działającą.
Podsumowanie
Testerzy znają te siedem zasad testowania i mają je zawsze z tyłu głowy. Zasady te stanowią dla nich drogowskaz w codziennej pracy. Ważne jest, aby osoby zarządzające projektem również były ich świadome, aby lepiej zrozumieć proces testowania oraz jakość produktu.
Zasady te pokazują również, że testy nie gwarantują absolutnej pewności. Warto testować i eliminować problemy, które można i trzeba naprawiać, ale nigdy nie można być stuprocentowo pewnym tego, co przyniesie przyszłość.
Stąd płynie bardzo ważny wniosek o konieczności ciągłej pielęgnacji i utrzymania produktu. Nigdy nie wiadomo, kiedy pojawią się kolejne problemy z oprogramowaniem. Posiadanie zaufanego partnera, który będzie w stanie natychmiast zareagować i przystąpić do naprawy, jest niezwykle ważne. Utrzymywanie własnego zespołu programistycznego w firmie może być dobrym pomysłem, ale jeśli błędów będzie mało, może to prowadzić do niepotrzebnych kosztów stałych. Dlatego zaufany partner, który przystąpi do prac na żądanie, może być idealnym rozwiązaniem.
Zasady te pokazują również, że testy nie gwarantują absolutnej pewności. Warto testować i eliminować problemy, które można i trzeba naprawiać, ale nigdy nie można być stuprocentowo pewnym tego, co przyniesie przyszłość.
Stąd płynie bardzo ważny wniosek o konieczności ciągłej pielęgnacji i utrzymania produktu. Nigdy nie wiadomo, kiedy pojawią się kolejne problemy z oprogramowaniem. Posiadanie zaufanego partnera, który będzie w stanie natychmiast zareagować i przystąpić do naprawy, jest niezwykle ważne. Utrzymywanie własnego zespołu programistycznego w firmie może być dobrym pomysłem, ale jeśli błędów będzie mało, może to prowadzić do niepotrzebnych kosztów stałych. Dlatego zaufany partner, który przystąpi do prac na żądanie, może być idealnym rozwiązaniem.