Piramida Testów – Czyli Podróż Last Minute do Krainy Faraonów

Lubisz piramidy? Bo ja bardzo. Mam nawet swoją ulubioną i to wcale nie jest ta  w Gizie.

Mowa oczywiście o ✨ piramidzie testów ✨ i właśnie zabieram Cię w podróż prosto na jej szczyt. A uprzedzę Cię, że przewodnik ze mnie pierwsza klasa… Tak mówi moja żona, a żona ma zawsze rację. 😎

Jaka znowu “piramida testów”?

Jeśli zamiast wizji słońca i złotego piasku w Twej głowie pojawiło się to pytanie, to już spieszę z odpowiedzią.

Piramida testów przedstawia zalecaną zależność między poziomami testów a ich ilością. Wygląda to tak:

Im testy są niżej, tym powinno być ich więcej. Dlaczego? Z kilku powodów:

  • są szybsze,
  • są tańsze,
  • są łatwiejsze w utrzymaniu.

Testy jednostkowe

Na obrazku ewidentnie najniżej są testy jednostkowe, czyli idąc tym tokiem myślenia, to ich powinno być najwięcej w projekcie. I faktycznie, są to testy, które pisze się najszybciej, najłatwiej i równocześnie błyskawicznie się wykonują, a ich utrzymanie nie doprowadzi firmy do bankructwa.

Jednak jako testera, ten poziom Ciebie najmniej interesuje. 😉

Testy jednostkowe tworzone są przez programistów. W firmach często można spotkać się z takim podejściem, gdzie programista najpierw pisze testy jednostkowe pod nieistniejący moduł, a dopiero potem programuje ten moduł. W tym podejściu chodzi o to, by przewidzieć na jakie problemy można się natknąć i uniknąć ich od razu przy tworzeniu modułu.

Mówiąc prościej – programista w ten sposób pilnuje, by testy od razu przeszły na zielono.

Testy integracyjne

Zaliczamy Level Up i tadam, jesteśmy na testach integracyjnych!

Tutaj z jednej strony mamy więcej do zrobienia, z drugiej – wciąż niewiele. Skąd ta rozbieżność?

A no stąd, że testy integracyjne można podzielić na:

  • testy integracyjne modułów,
  • testy integracyjne systemów.

Z tymi pierwszymi, jako tester, również nie będziesz mieć wiele wspólnego. Jednak dobrze jest pogadać z programistą, czy przypadkiem nie zaniedbuje tej działki. 😁

Natomiast testy integracyjne systemów to już coś dla Ciebie. Tutaj możesz na przykład sprawdzić czy frontend poprawnie odczytuje dane z backendu. Albo czy w bazie danych zapiszą się poprawnie informacje, które przekażemy aplikacji, na przykład podczas tworzenia nowego użytkownika. Scena jest Twoja.

Jako, że te testy są bardziej skomplikowane, to wymagają większego nakładu pracy niż testy jednostkowe. Dlatego testy integracyjne są szczebelek wyżej i w idealnym świecie powinno być ich mniej niż testów jednostkowych. Jednak wciąż nie są tak skomplikowane jak…

Testy E2E

Skomplikowane, trudne w utrzymaniu, drogie, a jednocześnie – niezastąpione. Oto najwspanialszy faraon, Ramzes II świata testów – testy end-to-end.

Tutaj masz możliwość przetestowania całego scenariusza. Dla przykładu, jeśli testujesz stronę do zamawiania jedzenia, to jeden z przypadków testowych może wyglądać następująco:

  1. Zaloguj się;
  2. Wybierz restaurację;
  3. Wybierz danie i dodaj je do koszyka;
  4. Kliknij przycisk “Zamów teraz”;
  5. Wypełnij formularz danych adresowych;
  6. Kliknij przycisk “Zapłać”;
  7. Opłać zamówienie;

Testujesz tu działanie całej aplikacji, gdzie wiele różnych systemów komunikuje się ze sobą i wymienia między sobą mnóstwo informacji. Tu wiele rzeczy może pójść nie tak i równocześnie są one najdroższe w naprawie. Dlatego tak ważne jest zadbanie o niższe poziomy testów, gdzie naprawienie znalezionego buga zajmie programiście zdecydowanie mniej czasu.

A jeśli automatyzujesz testy, to z pewnością wiesz, jak upierdliwa może być automatyzacja testów E2E. Szczególnie, gdy zmieniają się lokatory, albo, o zgrozo, gdy zmienia się coś w aplikacji, przez co testy świecą na czerwono jak logo Rossmanna.

Z drugiej strony testy E2E mają ogromną wartość biznesową, bo to właśnie w tym momencie naśladujemy użytkownika, do którego ma trafić nasze oprogramowanie.

Co jeszcze warto wiedzieć?

Chociażby to, że przedstawiona przeze mnie piramida nie jest jedyną piramidą, którą ujrzysz w świecie testów. 😉

Na przykład ISTQB preferuje taką:

Możesz jeszcze znaleźć piramidę, która jest nieco bardziej szczegółowa i przedstawia 5 poziomów: 

  • testy modułowe, 
  • testy integracji modułów, 
  • testy systemowe, 
  • testy integracji systemów,
  • testy akceptacyjne.

No, ale jeśli spojrzymy na zdjęcia z Egiptu to zauważymy, że tam też każda piramida wygląda nieco inaczej. Zupełnie jak bloki na osiedlu. Z tą różnicą, że piramidy jednak nie podchodzą pod patodeweloperkę.

Piramida może mieć również mniej poziomów, np. dla aplikacji no-code będzie miała tylko 2 poziomy:

  • testy integracyjne
  • testy E2E. 

Wynika to z faktu, że programiści nie mają fizycznej możliwości napisania testów jednostkowych, tylko tworzą oprogramowania za pomocą narzędzi, a nie kodu. 

Czy piramida to jedyne słuszne podejście?

Piramida testów to jedna z najpopularniejszych strategii testowania, ale nie jedyna… 

Strategie testowania zawsze należy dobierać pod projekt, a nie odwrotnie! Już w przyszłym wpisie opowiem o strategiach takich jak: pizza, rożek lodowy, puchar, diament, krab czy plaster miodu. 

Daj znać, jak to wygląda u Ciebie w projekcie? Sekcja komentarzy jest Twoja!

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *