Każdy zespół testujący może mieć różny zakres obowiązków. Jakkolwiek samo słowo „testowanie” jest dość obrazowe i wiele osób potrafi sobie wyobrazić proces „testowania”, tak już „zapewnienie jakości” ma o wiele bardziej rozmyte znaczenie. W niektórych firmach osoby testujące będą odpowiedzialne za sprawdzenie historyjek (user stories) użytkownika i przygotowanie raportu przed wdrożeniem aplikacji na produkcję, w innych testerzy będą pisać testy akceptacyjne i tworzyć scenariusze testowe, a w jeszcze innych będą zaś pisać unit testy dla programistów.

Warto też pamiętać, że nie każdy projekt potrzebuje wszystkich możliwych metod zapewniania jakości. Tutaj zalecam mocno pragmatyczne podejście do tematu. Oczywiście możemy się uprzeć i aplikować wszystkie znane nam metody testowania do projektu, ale szybko może się okazać, że po prostu przepalamy w ten sposób pieniądze. Spróbujmy pomyśleć, ile wartości jest w tym, że testerzy piszą testy „end to end” dla aplikacji, która jest PoC (Proof of Concept). Projekt w pewnym momencie robi obrót o 180 stopni i już nie tworzymy oprogramowania do produkcji skarpetek, ale aplikację okienkową umożliwiającą łatwy design nowych wzorów dla tychże skarpetek.

Aby nie zostać źle zrozumianym, pozwolę sobie podkreślić, że nie chodzi mi o zaniedbanie testów produkowanego rozwiązania. Absolutnie nie! Warto jednak skupić się na zapewnieniu takiego rodzaju i dokładności testowania, które nie spowolnią rozwoju aplikacji, a jednocześnie pozwolą się upewnić, że jakość produktu jest na satysfakcjonującym poziomie.

Należy zatem określić cel zespołu testującego i poziom testów, do jakiego dążymy. Kilka przykładów z praktyki wziętych:

• Sklep internetowy naszego klienta musi być w stanie obsłużyć ruch podczas Black Friday. Szacujemy, że będzie to kilkakrotnie większa liczba osób jednocześnie niż w zwykły dzień. Polecam zatem skupić się na testach typu Use Case (scenariusza użytkownika) i automatyzować testy End to End oraz na testach Performance’u (stress tests).

• Aplikacja mobilna dla aptek, sprawdzająca dostępność leków, musi działać na możliwie największej liczbie modeli telefonów, również na relatywnie starych modelach, oraz być dostępna dla osób z niepełnosprawnościami. Polecam skupić się ponownie na testach Use Case (mogą to być testy zarówno manualne, jak i automatyzujące), testach dostępności oraz testach na różnym sprzęcie.

• Tworzymy na lotnisko kiosk informacyjny, w którym turyści mogą sprawdzić ważne informacje o lotach. Tutaj ponownie musimy zapewnić wysoką dostępność aplikacji oraz przetestować ją lingwistycznie. Chcemy uniknąć sytuacji, w której zamiast docelowego tekstu użytkownik przeczyta „Cannot connect to translation service” w swoim ojczystym języku.
  
  
• Nasz klient zlecił nam stworzenie PoC aplikacji, który zweryfikuje, czy automatyzacja procesu biznesowego może przynieść wymierne korzyści dla firmy. W tym przypadku warto zadać sobie pytanie, czy na etapie badania hipotezy musimy zapewnić wysoką jakość i bezbłędność, czy ważniejsza jest rozwijalność naszego pomysłu w kolejnych etapach po PoC. Nie ma jednej prawidłowej odpowiedzi. Natomiast jeżeli w danym projekcie sprawdzamy, czy jesteśmy w stanie zautomatyzować proces wycinania wyrostka robaczkowego u pacjenta, to bardzo mocno zachęcam do kilkukrotnego zwiększenia dbałości o jakość.

W przypadku budowania zespołu testującego bardzo ważnym czynnikiem jest dla mnie doświadczenie osoby testującej w danej domenie. Nie widzę sensu zatrudniać senior testera gier komputerowych do aplikacji z sektora Fintech, gdy mamy dostępnego juniora, który właśnie skończył pracę w projekcie wirtualnego kantora.