Tester, Quality Assurance Specialist, Software Tester, QA Engineer, QA Tester… Stanowisko osoby, której głównym zadaniem jest wyszukiwanie błędów w oprogramowaniu, nosi wiele nazw. Ich mnogość często przyprawia o zawrót głowy ludzi spoza branży. Dlatego dzisiaj przyjrzymy się dwóm pierwszym spośród wyżej wymienionych.
O pracy Testera i Quality Assurance w skrócie
Słowo „tester” kojarzy nam się z osobą, która wykonuje jakieś testy, czyli po prostu coś sprawdza. Może to być test urządzenia, przedmiotów czy nawet środków chemicznych. W branży IT tester ma za zadanie sprawdzać tworzone przez programistów oprogramowanie: wychwytywać i raportować błędy po to, aby użytkownik po publikacji aplikacji mógł korzystać z niej bez żadnych problemów. Tester najczęściej weryfikuje przypadki testowe manualnie (zależy to jednak od firmy, w której pracuje), co oznacza, że sam ręcznie sprawdza poszczególne funkcje aplikacji (bez użycia narzędzi automatyzujących).
Najbardziej podstawową formą weryfikacji oprogramowania są testy funkcjonalne. Powiedzmy, że aplikacja posiada moduł logowania i rejestracji. Test funkcjonalny w tym przypadku będzie polegał na sprawdzeniu, czy cały moduł działa prawidłowo. Pierwszą rzecz, jaką tester musi zbadać, to tzw. happy path, czyli najprostsza, oczywista ścieżka, którą przejdzie użytkownik (w tym przypadku będzie to rejestracja i logowanie przy użyciu prawidłowych danych). W następnej kolejności musi sprawdzić przypadki, które nie powinny umożliwić użytkownikowi przejścia dalej (czyli np. rejestracja/logowanie bez wpisania adresu e-mail/hasła, błędny format adresu e-mail) i zweryfikować, czy wyświetla się odpowiedni komunikat. A następnie upewnić się, że aplikacja nie zatrzyma się nieoczekiwanie w dowolnym momencie przeprowadzania testu.
Tester weryfikuje również UI (interfejs użytkownika) pod względem rozbieżności z projektem graficznym, jak np. złe umiejscowienie przycisku, niewłaściwa ikona lub jej całkowity brak, inny rodzaj fontu czy jego nieprawidłowy kolor – wszelkie różnice powinny być przekazane i wyjaśnione. Dobrą praktyką jest również zgłaszanie swoich sugestii odnośnie UI, tzn. co można zmienić, co jest mało czytelne i może stanowić problem dla użytkownika.
Kolejnym rodzajem testów są testy integracyjne, polegające na weryfikacji przepływu informacji pomiędzy modułami, a nierzadko też i innymi systemami. Są one stosowane m.in. w przypadku, gdy aplikacja łączy się z różnymi zewnętrznymi systemami czy programami (np. systemem kasowym sklepu) lub kiedy jeden moduł pobiera dane od drugiego w ramach jednej aplikacji, przy okazji korzystając z informacji zawartych w trzecim.
Tester wykonuje także testy eksploracyjne (o których więcej możecie przeczytać w tym artykule), czyli usiłuje znaleźć błąd, bazując tylko na własnej wiedzy i doświadczeniu, bez specyfikacji czy dokumentacji. Takie testy mogą być także uzupełnieniem już istniejących przypadków, które zostały uwzględnione i spisane wcześniej. Tester zawsze zakłada, że na pewno jest coś, co nie zostało znalezione dotychczas. W ten sposób zachowuje czujność, która pozwala na wykrycie niepożądanego działania aplikacji. Ponadto, dzięki tego typu testom może uaktualnić bazę przypadków do regresji.
Przed przekazaniem programu w najnowszej wersji wykonuje również testy regresji, czyli sprawdza, czy najważniejsze moduły aplikacji nie zepsuły się w toku wprowadzania poprawek i budowania poszczególnych funkcji aplikacji. Testy te, z uwagi na swoją powtarzalność, są często automatyzowane w celu zminimalizowania ryzyka przeoczenia błędu przez testera w związku z koniecznością powtarzania tego samego testu po raz kolejny.
Czym więc się różni praca Quality Assurance od pracy testera?
Czytając powyższy opis, zapewne wiele osób pomyśli „No dobrze, ale przecież QA Specialist robi to samo”. To prawda, osoby pracujące na tym stanowisku również przeprowadzają takie testy, jednak nie jest to najważniejsza część ich pracy (a przynajmniej nie jest to zgodnie z podręcznikową definicją opisywanego stanowiska). Zakres obowiązków QA jest znacznie szerszy – priorytetem dla niego, obok testów jest mierzenie ogólnej jakości oprogramowania oraz optymalizacja procesów i całego cyklu życia oprogramowania. Podczas każdego z tych etapów towarzyszy mu to samo pytanie, które jednocześnie określa nadrzędny cel: „Czy klient będzie z tej aplikacji zadowolony?” Oczywiście, częściową odpowiedź na to pytanie udzielają statystyki w postaci wyłapanych błędów i crashy aplikacji, którym udało się zapobiec. Jednak samymi liczbami nie da się określić efektu wow, który towarzyszy dobrze zrobionej, intuicyjnej i płynnie działającej aplikacji.
W skrócie – dobry QA powinien nie tylko zepsuć aplikację w każdy możliwy sposób, ale również upewnić się, że w konkretnych warunkach, w ściśle określonym środowisku (lub środowiskach) będzie ona cechowała się najwyższą jakością i niezawodnością, oraz spełniała wyznaczone kryteria.
Najważniejsze jednak jest to, aby pamiętać, co jest cechą wspólną specjalistów QA i testerów – oddanie produktu jak najwyższej jakości. Sposoby, by ten cel osiągnąć, są różne, natomiast priorytet jest ten sam.
Jak wygląda praca Quality Assurance Specialist w Appchance?
Praca przy testowaniu aplikacji wymaga ciągłej uwagi w zakresie wyszukiwania błędów (często również cierpliwości) oraz otwartości na wszelkie sugestie. Niezależnie od tego, czy jest to tylko propozycja lepszego tłumaczenia na obcy język tekstu w aplikacji (wiele osób, widząc kiepskie tłumaczenie zakłada, że reszta aplikacji jest pisana równie niedbale), czy też przebudowa całej funkcji w aplikacji, doceniana jest każda sugestia. Kształtowanie umiejętności słuchania, promowanie kultury wzajemnego feedbacku, transparentność w zakresie wymiany informacji oraz nadzwyczajna dbałość o detale przyczyniają się do spełnienia jednego celu: stworzenia produktu najwyższej jakości.
Jak my (w zarysie) robimy to w Appchance?
- Zespół zapoznaje się ze specyfikacją aplikacji przedstawioną przez Project Managera, a także z historyjkami użytkowników i projektem graficznym. W tym samym czasie zgłaszane są różne niejasności, pytamy o brakujące szczegóły (np. szczegóły walidacji pól w formularzach, grupę docelową, do której ma być skierowany produkt, sytuacje, w których aplikacja będzie używana, typy użytkowników, którzy będą korzystać z programu, rynek docelowy, na którym ma działać aplikacja), aby jak najlepiej (i najtrafniej) przygotować „grunt” do testów, czyli dane testowe.
- Przygotowujemy scenariusze i przypadki testowe, które mają odwzorować podstawową ścieżkę zachowań użytkownika dla każdej funkcjonalności w danym sprincie (tzw. happy path, czyli pożądane zachowanie aplikacji, z pominięciem zachowań niestandardowych), a następnie przekazujemy je programistom.
- Po wykonaniu pierwszych testów przeprowadzonych w danym sprincie zespół przechodzi do testów eksploracyjnych w celu znalezienia błędów i zachowań, które nie były wcześniej uwzględnione, uzupełniając nimi scenariusz testowy.
- Podczas testów funkcjonalności oraz retestów przygotowywane są kolejne przypadki zachowań w aplikacji (głównie pod nowe funkcjonalności) oraz aktualizowane są poprzednie scenariusze testowe (gdy nastąpiły zmiany w założeniach dla wcześniejszych zrealizowanych etapów).
Zdarza się, że niektóre zgłoszenia od QA dotyczące właśnie drobnych błędów są postrzegane przez programistów jako szukanie dziury w całym. Należy jednak pamiętać o tym, że jeśli uwag nie zgłosi tester, to jest bardzo możliwe, że zrobi to klient. Nie od dziś zresztą wiadomo, że to drobne elementy definiują postrzeganie całości – jeśli w aplikacji występują proste do naprawienia błędy, których łatwo było uniknąć, to klient może śmiało założyć, że reszta programu również jest w podobny sposób zaniedbana. To z kolei rzutuje negatywnie na odbiór całego produktu, czemu stara się zapobiec zespół specjalistów QA. Bowiem to zadowolenie klienta i użytkowników końcowych jest tym, na czym zależy nam najbardziej.
