Jak znaleźć buga w aplikacji (oprogramowaniu, systemie, czy co akurat przyszło nam testować)? Pytanie proste, a odpowiedź na nie niezwykle złożona, ponieważ obejmuje wiele różnych aspektów. Nie istnieje zatem jedno rozwiązanie, jedna uniwersalna rada, trik czy technika, która zagwarantuje nam efektywność w każdej możliwej sytuacji. Próżno też szukać ogólnej metody, podejścia czy strategii skutecznej w każdym przypadku.
Testowanie oprogramowania mające na celu wykrycie defektów, samo w sobie jest bardzo szeroką dyscypliną, a zapoznanie się z każdym jej aspektem wymaga wielu lat praktyki zawodowej.
Zebraliśmy dla Was parę użytecznych sugestii i trików, które mogą okazać się pomocne w pracy testera. Nie traktujcie jednak tej listy, jako jedynej słusznej i obowiązującej. Branża IT cały czas się rozwija i stawia przed nami nowe wyzwania. Dlatego metod, sposobów czy rad na znalezienie robaka w aplikacji jest wiele, sporo z nich ewoluuje, dużo traci swoja wartość i sporo nowych się pojawia. Wy, drodzy Czytelnicy, możecie mieć zupełnie inną perspektywę, techniki, podejścia czy strategie. Podzielcie się nimi w komentarzach, by poszerzyć naszą wspólną wiedzę. 😀
Jeśli chcecie zapoznać się z cyklem życia buga, zachęcamy do odwiedzenia
jednego z naszych wcześniejszych wpisów tutaj.
Przed rozpoczęciem testowania…
- Postaraj się zapoznać z całą aplikacją, programem czy modułem. Zadaj sobie pytanie, co dana aplikacja ma w ogóle robić. Jakie ma wymagania? Do jakich użytkowników jest skierowana? W jaki sposób powinna działać, gdy zachowuje się poprawnie? Jakie są jej różne przepływy funkcjonalne? Czego oczekuje od aplikacji użytkownik końcowy? Odpowiedzi na tak postawione pytania pomagają zrozumieć, w jaki sposób przepływają dane w obrębie aplikacji. Czy człowiek nie czuje się pewniej, gdy wie, co dokładnie robi i dlaczego?
- Przygotuj odpowiednie przypadki testowe. Połóż nacisk na testy funkcjonalne, które obejmują główne ryzyko związane z działaniem aplikacji.
- Utwórz odpowiednią bazę danych testowych, która zawierać będzie warunki przypadku testowego, a także rekordy bazy danych, jeśli zadaniem jest przetestowanie bazy danych.
- Zdefiniuj role działające w obrębie aplikacji. Ten krok polega na ustaleniu granic zaufania; wyznaczeniu reguł dotyczących tego, kim jest użytkownik i co wolno i czego nie wolno mu robić. Zadaj sobie kilka pytań, wcielając się w potencjalnego odbiorcę; co powinienem móc zrobić bez kwalifikacji/uprawnień/pozwoleń, co trzeba zrobić, by uzyskać kwalifikacje/uprawnienie/pozwolenie na poziomie użytkownika, co powinienem móc zrobić, korzystając z danych logowania na poziomie administratora czy jakie poziomy zaufania występują w granicach między różnymi komponentami systemu?
Testując…
- Staraj się wykonywać powtarzające się testy w różnych środowiskach testowych.
- Spróbuj znaleźć wzór wyników, by później móc porównywać nowe rezultaty do modelu.
- Wykorzystaj poprzedni model danych do przeanalizowania bieżącego zestawu testów.
- Postaraj się wykorzystać standardowe przypadki testowe, dla których znalazłeś błędy w innych aplikacjach. W przypadku badania wejściowych pól tekstowych możesz spróbować wstawić znaczniki HTML jako dane wejściowe i sprawdź dane wyjściowe na stronie wyświetlania. Pamiętaj jednak, by nie trzymać się ich kurczowo; pozwól sobie na badanie kodu w inny sposób. Przypadki testowe są ważne i mogą być bardzo skuteczne. Ale jednym z głównych problemów przy testach jest to, że trudno jest osiągnąć prawie 100% pokrycia testowego przy użyciu przypadków testowych, ponieważ niemożliwe jest uzyskanie tak zwanego produktu w 100% wolnego od błędów. Wraz z przypadkiem testowym spróbuj także zbadać funkcjonalność. To dość skuteczna metoda wychwytywania większej ilości błędów, które czają się wokół funkcjonalności, ale nie są w jakiś sposób objęte przypadkami testowymi.
- Podążaj za danymi dokładnie tak samo, jak w kryminałach; śledzisz ścieżkę przekazywania pieniędzy, by znaleźć złodzieja, to w testowaniu śledzisz dane, by znaleźć słabości kodu. Proces ten obejmuje identyfikację każdego miejsca, w którym dane mogą być wprowadzone do aplikacji czy programu. Śledzenie, przez jakie systemy i podsystemy przepływają i w którym miejscu się kończą, może odkryć przed tobą defekt kodu. Przykładem danych wejściowych są chociażby parametry ciągu zapytania – referrer, nagłówki. Jeśli możesz zapisywać dane w bazie danych z usługi peryferyjnej, która jest następnie pobierana i odczytywana przez usługę podstawową, masz źródło wejściowe i także potencjalnie uprzywilejowane.
- Jeśli uważasz, że wykonałeś już większość warunków testowych i kiedy czujesz się już zmęczony -> zmień taktykę. Spróbuj małpiego testowania. Zaatakuj system, starając się wprowadzić go w stan paniki, wprowadzając losowe dane. Jeśli pole jest wymagane, pozostaw to pole puste. Jeśli interfejs użytkownika implikuje przepływ pracy, spróbuj wybrać inną trasę. Jeśli pole wejściowe wyraźnie ma być liczbą, spróbuj wpisać słowo lub zbyt wysoki numer. Umiejętność ta jest stosunkowo łatwa do opanowania, a kiedy osiągniesz wprawę, taka sesja prawdopodobnie spowoduje kilka błędów.
- Zwróć uwagę na szczegóły. Formularze, interfejs użytkownika, przepływy funkcjonalne, integracje, dane zaplecza, błędy, wszystko. Skrupulatność to bardzo poszukiwana umiejętność testera.
- Nie zapominaj o wykorzystaniu dostępnych narzędzi, ale też nie polegaj na nich bezrefleksyjnie. Wiele osób chce się tylko dowiedzieć, jakiego narzędzia należy użyć, żeby znaleźć defekt w kodzie. Sprawa nie jest tak prosta, a jej wieloaspektowość wymusza korzystania z innych sposobów wyszukiwania bugów. Pamiętaj, że to, co testujesz, determinuje podejście, jakie powinieneś zastosować. Innych narzędzi i metod użyjesz przy testowaniu aplikacji mobilnej na system Android, a innych przy badaniu strony mailingowej.
- Nie zrażaj się tym, że testy bywają nudne, monotonne i czasem bezowocne. Bądź wytrwały. Testowanie nie zawsze będzie porywające, kreatywne i angażujące. Nie zawsze też uda ci się wykryć błąd przy pierwszym podejściu. Pamiętaj, że powszechne i wartościowe jest też znajdowanie nieprzydatnych aspektów programu, które mogą obnażyć słaby punkt całości lub po prostu mogą być lepiej napisane.
Po testach…
- Obecnie testowany przez ciebie moduł czy aplikacja działa poprawnie. Rozpoczęto proces wdrażania. To wspaniale! Ale jutro będziesz mieć nowe zadanie, z innym zestawem ryzyk. Będziesz musiał udowodnić nową funkcjonalność, a także upewnić się, że nic się nie zepsuło. Chcesz przekonać się, że oprogramowanie nie uległo regresowi, przez coś, co dziś zawiodło, a jeszcze wczoraj działało poprawnie. Najlepszym rozwiązaniem jest sporządzenie listy “udarowych” modułów/funkcji i ponowna weryfikacja (regres) w celu znalezienia błędów.
Ale przede wszystkim…
Zastanów się, dlaczego w ogóle testujesz oprogramowanie. Aby potwierdzić, że spełnia wymagania? Żeby sprawdzić poprawność działa zgodnie z oczekiwaniami? By zweryfikować jego zachowanie funkcjonalne? Czy też celem jest znalezienie błędów? Tak!
Zamiar znalezienia błędów różni się od sprawdzania poprawności aplikacji względem niektórych pisemnych wymagań. Masz inne nastawienie. Jako łowcy defektów, twoja praca jest dobrze wykonana, jeśli jesteś w stanie ekstrapolować wymagania lub odkryć te ukryte czy jeśli umiesz znaleźć błędy na obszarze, na którym programiści się nie popisali. To właśnie robi różnicę. Poza tym każdy może wykonać test, czytając wymagania i zatwierdzając aplikację.
Jako tester, polowanie na robaki musi być jedną z głównych sił napędowych twojego zestawu umiejętności. Intencją jest znalezienie bugów – myślenie poza programistami, tak by użytkownik końcowy mógł swobodnie eksplorować wszystko w aplikacji, aby mógł wprowadzać dowolne dane, aby mógł się bawić!
Nie rozczaruj się, jeśli nie będziesz w stanie znaleźć błędów przy pierwszym czy drugim podejściu. Testowanie oprogramowania to umiejętność, która poprawia się wraz z praktyką. Doświadczenie odgrywa ważną rolę, więc nie zrażaj się i szlifuj swoje kompetencje! 🙂
