Odwrócona piramida testów – testowanie oprogramowania
Dziś wracamy do tematyki piramidy testów, o której mogliście przeczytać już w tym artykule -> piramida testów
W tym poście zajmiemy się odwróconą piramida testów czyli tak zwanym — Testing Ice-Cream Cone. Czym jest, skąd się bierze, jakie są plusy i minusy oraz czy powinno się ją stosować?
Dla przypomnienia normalna piramida testów wygląda tak:
Natomiast kiedy ją odwrócimy, zyskujemy taki obraz, który może nam przypominać rożek na lody:
Pytanie, co się stanie w projekcie, jeśli odwrócimy proporcje testów i zamienimy rzeczywistość na taką gdzie:
a) testy jednostkowe są w małej ilości bądź nie istnieją
b) testy integracyjne, których mamy też mało, bądź praktycznie wcale
c) dużo testów na warstwie UI, zarówno automatycznych jak i manualnych
Historia dwóch projektów
Projekt A: Wyobraźmy sobie projekt, który jest przykładowym idealnym przykładem prawidłowej proporcji testów na każdej warstwie.
Developer podczas pisania kodu ma informację zwrotną czy jego kod nie spowodował innych błędów, a także, czy od strony integracyjnej również nie posiada błędów.
Okazuje się, że testy pokazały błąd — kod ten zostaje poprawiony, jeszcze w trakcie developmentu nie zabierając czasu zespołowi QA, do którego trafi już przetestowany wstępnie kod.
Po przejściu pozytywnie dwóch najważniejszych warstw zostaje tylko uruchomienie testów UI oraz ewentualne testy manualne sprawdzające aspekty zgodności z wymaganiami.
Projekt ten ma znacząco małe szanse na to, że zawiera w sobie błędy krytyczne.
Projekt B: Drugi projekt był developowany w inny sposób. Z różnych powodów projekt ten posiadał znikome testy jednostkowe, jak i integracyjne. Projekt taki następnie trafiał na testy UI, które trwały kilkadziesiąt minut bądź całe godziny.
Testy dawały informacje, że na warstwie UI nie działa funkcja X. Następnie developer musiał sprawdzać kodzie co się dokładnie spowodowało błąd na warstwie UI, jakie było flow testu i co tak naprawdę zadziało się w kodzie. Pozostały również pytanie, czy ten sam kod nie dotyka innych obszarów, których nie pokrywały testy UI.
Jak widzimy aplikacja developowana w ten sposób ma w sobie o wiele więcej niewiadomych w porwównaniu do projektu A.
Wyszukiwać czy zapobiegać?
Pierwsze, na co można zwrócić uwagę, odwracając piramidę testów to fakt, że całkowicie zmienia ona swoją rolę. Jak to się dzieje?
Wyobraźmy sobie proces developmentu, w którym przez brak testów jednostkowych czy małą ilość testów integracyjnych dana wersja oprogramiania/feature trafia na dużą ilość testów UI oraz testów manualnych.
Dopiero tutaj następuje sprawdzenie aplikacji i danie feedbacku developerowi. Tak naprawdę taki proces nie jest już zapobieganiem powstawania błędów a znajdywaniem ich.
W alternatywnym świecie ten sam kod może mieć unit testy/integracyjne, które dadzą informacje, czy kod nie posiada błędów we wcześniejszym stadium developmentu. Nie zapominajmy także o aspekcie czasu jaki potrzebny jest na ewentualne późniejsze poprawki po zgłszeniu błędów przez dział QA.
Świat nie jest idealny
Co zrobić, jeśli w aplikacji, której testujesz, testy na niższych warstwach nie istnieją? Jako ambasador jakości możesz zacząć od rozmowy z developerami, dlaczego tak jest. Możliwe, że nie ma wytworzonej kultury pisania testów bądź sam kod jest trudny do pokrycia przez testy jednostkowe.
Czasami co możemy zrobić jako QA to dodanie energii w taką zmianę w projekcie. Czasami dobrze jest zrobić warsztaty i porozmawiać z zespołem o tym, jak możemy to zmienić. Jakie odniesiemy w ten sposób korzyści.
W innym projekcie może okazać się, że takie testy są trudne do implementacji, co nie zmienia faktu, że wraz z zespołem można szukać sposobu jak zbudować proces, który będzie zapobiegał powstawaniu błędów, niż je wyszukiwał, może duża ilość testów UI nie jest najlepszym pomysłem i można znaleźć optymalną ścieżkę.
Więcej o podstawach testowania oprogramowania możesz przeczytać pod tym linkiem — postawy testowania oprogramowania.
Żródło: Ice-Cream Cone
