Testowanie oprogramowania krok po kroku. Zobacz, jak tworzymy strategię testowania
Czy istnieje jeden uniwersalny sposób na stworzenie idealnej strategii, świętego graala testowania? Każdy zapytany o to Tester, Quality Assurance, czy osoba odpowiedzialna za jakość w projektach powie zdecydowane: “Niekoniecznie”. Istnieją jednak pewne fundamenty, na których możemy budować naszą strategię i o nich, z perspektywy testera automatycznego, warto opowiedzieć.
Sławek Stankiewicz. Quality Assurance Automation Engineer (po polsku – Tester Automatyczny) w SYZYGY Warsaw od 2022. Absolwent Politechniki Wrocławskiej na kierunku informatyka. Testowaniem oprogramowania dla różnych branż i z użyciem różnych technologii zajmuje się się już prawie 4 lata. Wolny czas wypełnia graniem na instrumentach – chciałby tworzyć jazz, ale zwykle wychodzą szanty.
Maciej Puczyński. W branży IT już od 10 lat, od 3 jako Quality Assurance Manager & Analyst (po polsku – Tester Manualny) w SYZYGY Warsaw. Z niejednego pieca chleb testował, a obecnie rozwija się w kierunku biznesowym.
Spis treści
A komu to potrzebne?
Zanim przejdziemy do opisu strategii testowania, odpowiedzmy sobie na jedno niezwykle ważne pytanie. Czy testowanie jest nam w ogóle potrzebne? Oczywiście, że tak! To wręcz niezbędny element pracy projektowej, wszak oprogramowanie stało się w końcu częścią naszego codziennego życia. Jako twórcy software’u musimy mieć pewność, że jego jakość jest na wysokim poziomie i że działa ono poprawnie.
Właśnie dlatego, w fazie tworzenia softu, testy oprogramowania, polegające między innymi na wyszukiwaniu błędów i tego, w jaki sposób się one objawiają, są bardzo istotne. Równie ważne jest wychwytywanie braku zgodności z założeniami biznesowymi, ciągłe dbanie o proces i podnoszenie jakości pisanego kodu.
Strategia szyta na miarę
Ustalmy fakty: projekt projektowi nierówny. Wymagania, budżet, zasoby ludzkie, rodzaj aplikacji i nastawienie poszczególnych członków zespołu do testów, wpływają na to, jaką strategię testowania przyjmiemy. Teoretycznie cel jest prosty: sprawdzać możliwie jak najwięcej, testując od najbardziej krytycznych części aplikacji po te mniej ważne, w jak najkrótszym czasie, w możliwie najtańszy sposób. Przy tym wszystkim, testowanie ma tę niesamowitą cechę – można je przeprowadzać bez końca i nigdy nie będziemy pewni, czy nasz obiekt zadziała w stu procentach poprawnie.
Co zatem możemy zrobić, by nie dać się złapać w tę pułapkę? Jak planować testy i z czego powinny się składać? Jak uzyskać choć minimalną pewność, że produkt, który dostarczamy, jest dobrej jakości? Jak stworzyć optymalną strategię?
Po pierwsze: zwinność
Dobre rozwiązania w jakiejkolwiek branży są często wynikiem wielomięsięcznych, jeśli nie wieloletnich, ciągłych usprawnień, dyskusji i wkładu różnych osób. Nie inaczej jest w tym przypadku. Przyznanie się do tego, że w ogóle istnieje możliwość popełnienia błędu w procesie rozwoju metod i we flow testowania (i nie tylko!) powinno pozwolić nam na ich ciągłą optymalizację i eksperymentowanie. Zwinne podejście oraz odpowiednie nastawienie pod kreowanie właściwych dla danego projektu metodyk, to absolutna konieczność w tworzeniu optymalnej strategii. Nie bój się popełniać błędów! Sprawdzaj, szukaj dziury w całym i usprawniaj, gdzie tylko uznasz to za słuszne, a ewentualna porażka niech będzie dla Ciebie wskazówką, na co należy zwrócić uwagę w przyszłości.
Po drugie: automatyzacja
Jesteśmy szczerymi zwolennikami automatyzacji i wszystkiego, co da się zautomatyzować. Mówi się, że same testy automatyczne są drogie i – chcąc nie chcąc – przyznaję, że to prawda. Zdarza się, że koszt testera automatycznego bywa półtora raza większy niż manualnego. Zakładając, że myślimy o rozbudowanym systemie SOA z mikroserwisami, bazą danych i szerokimi funkcjonalnościami. Niemniej koszt takich testów bardzo szybko się zwraca w czasie i częstości samych wykonań, w porównaniu do adekwatnej liczby testerów manualnych.
Jednym z najważniejszych czynników podnoszących jakość produktu jest fakt, że testujemy często, a nawet bardzo często. Im częściej, tym lepiej! Testy automatyczne (i myślę o testach wszelkiego rodzaju) – funkcjonalne, integracyjne, API, E2E, świetnie odpowiadają na tę potrzebę. Skrypty nie wymagające większej ingerencji człowieka, niż samo ich puszczenie, powinny lecieć codziennie, a już na pewno przy każdej nowej, dodanej funkcji.
Dodatkowy aspekt dobrego testowania stanowi możliwie wczesna weryfikacja błędów w cyklu życia aplikacji. Możesz przetestować nowy feature zanim wejdzie na główny branch? Puścić paczkę testów? Zrób to! Zmniejszaj ryzyko wpuszczenia buga w głównych środowiskach. Oczywiście łatwiej powiedzieć niż to faktycznie zrobić. Rzeczywistość okazuje się zazwyczaj brutalna, a pułapek, w jakie można wpaść, jest cała masa.
Przykładowo choćby utrzymywalność testów a rozwój aplikacji, problem pestycydów i uodparniania się aplikacji na testy, czy pisanie ich tak, żeby po prostu przechodziły, a nie wykrywały błędy. Jak tego uniknąć? Propozycją idącą prosto z naszego projektu są małe, zdefiniowane paczki testów, możliwie najprostsze, pomijając jednostkowe – integracyjne i E2E.
Po trzecie: Praca zespołowa przede wszystkim
Na forum zespołu ustala się maksymalny czas wykonywania testów przed mergem do głównego potoku. Przykładowo 15 minut. Pracujesz z cierpliwymi programistami? Może być i pół godziny, akurat zdążą zrobić sobie kawę i tosta. Takie rozwiązanie warto wypracować na forum całego zespołu. Dlaczego to takie ważne? Raz, że w ten sposób będzie to (i powinno być) stałym elementem CI/CD, a dwa – jest duża szansa, że wszyscy, włącznie z programistami, a później i BI, PO, vendor będą zaangażowani w testowanie.
Niezwykle ważne jest, aby tester edukował nie tylko klienta, ale przede wszystkim swój zespół. Świadomość i wiedza na temat testów automatycznych pozwalają szybciej wykrywać błędy, wcześniej reagować na zmiany i zapobiegają zjawisku silosowania wiedzy. Nie ma większej wartości w branży IT, niż dobrej jakości software tworzony przez świadomych specjalistów.
Testuj, testuj, testuj
Przy całej wartości, jaką wnoszą testy automatyczne, przynajmniej raz dziennie, o określonej porze, najlepiej w nocy, warto puścić paczkę wszystkich testów, jakimi jest pokryta aplikacja. W ten sposób optymalnie wykorzystujemy zasoby na środowiskach i stale monitorujemy stan aplikacji, ale też testów samych w sobie. Czy faktycznie testują? Czy pojawiły się jakieś błędy? Jeśli tak, to jakie i czy związane z aplikacją, czy skryptem?
Praca nad usprawnianiem i poprawianiem jakości powinna być ciągła i jeśli już iść na kompromis, to zdecydowanie lepiej sprawdzać produkt częściej i mniejszymi partiami, z pomocą działających testów, niż próbować puszczać i przeanalizować jednorazowo nie wiadomo jak dużą, niepewną paczkę, często zakopując się w zadaniach z obszaru maintanance.
Czy są jakieś granice?
Istnieje pewne zagrożenie płynące z testowania stricte automatycznego. Wraz z rozwojem oprogramownia rośnie ilość potencjalnych obszarów do pokrycia testami, nie wspominając już o zmianach, jakie w trakcie zachodzą w miejscach już otestowanych. Nie ma złotego środka, który powie, w którym momencie należy przestać rozwijać testy automatyczne i zostać tylko przy utrzymaniu. Temat jest tak złożony, że można by się posilić o osobny artykuł, jednak na potrzeby tej publikacji uprościmy sprawę, sprowadzając ją do miksu decyzji klienta i np. głównego testera.
Spotkaliśmy się zarówno z projektem, w którym budżet był ogromny, a aplikacja do tworzenia wycen ubezpieczeń samochodów (i nie tylko) była pokryta w 100% testami automatycznymi za pomocą gigantycznego frameworka, jak i z projektem małym, gdzie jeden tester testował i manualnie i pisał pojedyncze skrypty w puppeteerze. W obu przypadkach istniały mocne i słabe strony przyjętych działań, ale to jedynie pokazuje, jak elastyczna i dopasowana do projektu może i powinna być strategia testowania.
Muszę wspomnieć, że niemal w każdym projekcie trafią się takie przypadki funkcjonalności, których nie będzie się opłacało pokrywać testami automatycznymi, a to ze względu na samą trudność solidnego przetestowania automatycznego, czy to ze względu na dynamikę strony, czy… <- tu wstaw własny powód, dla którego nie napiszesz skryptu.
Podsumowując
Najważniejsza jest umiejętność złapania optymalnego balansu między automatyzacją, a testowaniem manualnym, a także edukowanie o znaczeniu testów samych w sobie. Podjęcie odpowiedniej decyzji o tym, jak będzie wyglądać cały proces dostarczenia wysokiej jakości oprogramowania i dopasowania odpowiednich procesów pod całą aplikację, to wypadkowa decyzji ekspertów z minimum trzech dziedzin. Przy jednym stole powinni usiąść deweloperzy, testerzy i biznes, wypracowując kompromis między czasem potrzebnym na szeroko pojęte testy, a jakością.
Złota zasada, o której wspomnieliśmy wcześniej – nie da się przetestować wszystkiego. Przy takiej złożoności, jaką prezentują aplikacje webowe, zawsze znajdzie się jakiś błąd, jakiś sposób i okoliczności, które sprawią, że funkcjonalność nie będzie działać zgodnie ze swoim przeznaczeniem. Rola każdego zaangażowanego specjalisty w zespole sprowadza się do dbania o jakość i podniesienie swoich kompetencji w tym zakresie. Na koniec dnia wszyscy chcemy przecież jednego i tego samego – sprawnie działającej, bezpiecznej i użytecznej aplikacji.
Podobne artykuły
Pair testing: jak developerzy i testerzy wspólnie dbają o jakość
Jako twórcy aplikacji mało wiemy o odbiorcach. O użyteczności i dostępności w IT
Klienci chcą rozwiązań problemów, a nie fajerwerków. O zjawisku overengineeringu
Zmienił się apetyt na ryzyko. Organizacje w końcu kładą nacisk na budowę kultury jakości
Automatyzuj przewidywalną część pracy. Zaoszczędzony czas poświęć na dogłębną analizę kodu
Czy każdy programista powinien umieć testować? Devdebata
Za jakość odpowiada nie tylko dział QA, ale wszyscy członkowie zespołu. Wywiad z Radosławem Inczewskim
