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.

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.

Zobacz też

QA InPost in Test, czyli jak testujemy oprogramowanie

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.

Oferty pracy z

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.

Zobacz też

QA Od programisty do testera. Jak doświadczenie programistyczne pomaga w byciu lepszym QA

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.