3 kroki przed testami
Czyli co trzeba ustalić, aby przeprowadzić wiarygodne testy.
Wiem, że w dobie szybkiego dostarczania zmian, organizacje kładą duży nacisk na zwiększania tempa programowania, jak i testowania. Nie zmienia to jednak faktu, że do testów każdego zlecenia / ticketa / taska (wybierzcie swoje ulubione określenie) czy po prostu nowej funkcjonalności warto się porządnie przygotować.
Nie mówię tu o szczegółowych przypadkach testowych (choć jeśli macie czas i możliwości, to czemu nie), ale o zdobyciu odpowiedzi na 3 kluczowe pytania:
Co zmieniono w aplikacji?
Dlaczego wprowadzono zmiany?
Na co wpływają modyfikacje?
Jeśli już teraz zastanawiacie się do kogo zwrócić się z takimi pytania, to niestety, nie ma tu jednoznacznego wyjaśnienia. W idealnym świecie powinien to być Product Owner (jeszcze lepiej, gdy cała wiedza zawarta jest w opisie zmian), ale czy takie stanowisko w ogóle istnieje w Waszej firmie - nie mam pojęcia. Dlatego skupię się na samych pytaniach, a odpowiednie osoby musicie znaleźć już sami.
Co zmieniono?
Przede wszystkim musicie dowiedzieć się, co zostało zmienione w aplikacji. I chodzi tu o konkretne informacje, a nie o niewiele mówiące "dodano obsługę...". Gdzie wprowadzono zmiany? Na backendzie? Frontendzie? A może zmieniono połączenia z jakimiś zewnętrznymi systemami?
Szczegółowa wiedza pozwoli Wam lepiej zrozumieć modyfikacje, a co za tym idzie - skuteczniej przeprowadzić testy. Ustalcie, czy są to nowe ścieżki dla użytkowników końcowych czy techniczne zmiany niewidoczne na pierwszy rzut oka.
Dlaczego to zmieniono?
Równie ważna jest świadomość celu wprowadzania zmian. Oprogramowania raczej nie modyfikuje się bez powodu - za zmianami stoją realne problemy lub potrzeby użytkowników. Bez zrozumienia wymagań klienta nie da się przeprowadzić wiarygodnych testów - no bo przecież nie będziemy potrafili określić, czy rozwiązanie rzeczywiście pomogło.
Dowiedzcie się, dlaczego aktualne funkcjonalności nie spełniły potrzeb użytkowników i czy wprowadzenie zmian pozytywnie wpłynie na odczucia związane z działaniem aplikacji.
Na co to wpływa?
Przechodzimy do ostatniego pytania, dzięki któremu określimy, jakie obszary aplikacji zostały objęte modyfikacjami. Jest to szczególnie ważne przy projektowaniu planu testów i wyznaczaniu najbardziej podatnych na zmiany (i tym samym ryzykownych) części oprogramowania.
Bez tej wiedzy nie przeprowadzicie efektywnych testów regresji, co zwiększa szanse na pominięcie potencjalnych błędów. Wyznaczcie elementy aplikacji, na które mogły wpłynąć wprowadzone zmiany i upewnijcie się, że działają one prawidłowo.
Jasne, to wszystko brzmi banalnie, ale tak jak wspomniałem na początku, w dzisiejszych czasach szybkiego dostarczania zmian klientom, czasami zapominamy, że testowanie powinno być oparte na konkretnych danych, a nie chaotycznym klikaniu po oprogramowaniu.
Chcesz być na bieżąco? Zapisz się do newslettera!
W każdy czwartek o 10:00 wyślę Ci wiadomość o moich nowych wpisach. Oprócz tego, dorzucę ciekawe artykuły, filmy czy inne materiały ze świata IT - oczywiście, związane głównie z testowaniem oprogramowania. To świetny sposób na naukę i ciągłe zdobywanie wiedzy.
Dziękuję, że czytasz mojego bloga!
Masz jakieś pytania? Z chęcią odpowiem :)
