Co jest przyczyną niezadowolenia testerów

Zawartość:

Margarita Trofimova

Ekspert

O autorze

Kierownik ds. Zapewnienia Jakości w ITFB. Od ponad dziesięciu lat zajmuję się ulepszaniem procesów i produktów. Wierzę, że moja praca ma pozytywny wpływ na sferę cyfrową. Wiceprezes Rosyjskiej Rady ds. Kwalifikacji Testerów Oprogramowania, jeden z organizatorów moskiewskiego klubu testerów MSTC i redaktor publikacji „Tester's Life”.

Linki

Obecnie wśród specjalistów i ekspertów panuje trend na szczerość i otwarte wyrażanie emocji. Treści takie jak „Co irytuje stewardesę” czy „10 fraz, które nie podobają się projektantowi” aktywnie pojawiają się na YouTube i w mediach społecznościowych. Emocje mają również swoje miejsce w sferze IT, a zespół ds. zapewnienia jakości (QA) ITFB postanowił opracować własną listę czynników, które irytują testerów.

To niezwykle frustrujące, gdy problemy lub defekty pojawiają się w systemie śledzenia błędów bez żadnego opisu, ograniczając się do tytułu w stylu „Nie działa, proszę to naprawić!”. Szczególnie frustrujące jest napotykanie takich raportów po testach w rzeczywistych warunkach, gdy brakuje szczegółów, takich jak kroki do odtworzenia, użyte dane, środowisko i inne krytyczne aspekty. Nie będę nawet komentował logów, zrzutów ekranu ani oczekiwanych rezultatów.

Frustrujące jest również, gdy programista przesyła kod do testów bez wykonania nawet podstawowych kontroli. Na przykład przycisk „Zamknij” nie spełnia swojej funkcji i zamiast tego generuje liczne błędy, powodując zawieszenie się systemu. Chociaż programista zgłasza, że ​​problem został przekazany do działu kontroli jakości, podstawowa funkcjonalność jest niedostępna. W rezultacie tracisz czas, uświadamiając sobie, że wszystkie twoje wysiłki poszły na marne.

Czasami zespoły, które wcześniej pracowały nad tym samym problemem, nie tworzą dokumentacji. W rezultacie masz do czynienia z funkcjonalnością, która działa całkowicie niezrozumiale. W takiej sytuacji trudno jest określić, co dokładnie jest błędem, a co ma być częścią funkcjonalności. Co więcej, brak dokumentacji jest irytujący, uniemożliwiając poproszenie o pomoc lub utrudniając znalezienie potrzebnych informacji.

Powolne i niereagujące platformy są irytujące, zwłaszcza gdy nie należą do Ciebie i nie masz możliwości ich naprawienia. A wymagania dotyczące środowiska testowego, które wysłałeś, nie są nawet czymś, co klienci i inne zespoły nawet nie czytają i nie mają zamiaru ich przeglądać.

To frustrujące, gdy trzeba przekonać programistę do wykonania jego pracy.

— To tutaj nie działa.

— To nie moje!

— Napisałeś Dev Result!

— No cóż...

Zdarzają się przypadki, gdy nowa kompilacja została właśnie przesłana do testów, a defekty pojawiają się od razu, a menedżer już zastanawia się, kiedy będzie można ją uruchomić na produkcji. To denerwujące: skąd mogę wiedzieć, ile czasu zajmie programiście naprawienie tych błędów? Moje kompetencje ograniczają się jedynie do problemów z testowaniem.

Denerwujące jest, gdy do tych już zaplanowanych dodawane są nowe zadania. Zwłaszcza jeśli dzieje się to bez udziału testera. Menedżer przekazał zadanie analitykowi, analityk wykonał analizę i przekazał informacje programiście, a potem nagle otrzymujesz wszystkie te zmiany. I nikt nie wyjaśnia, kto, co, jak i skąd wzięło się to zadanie.

W sytuacji, gdy w zespole brakuje jedności, pracownik jest świadomy problemu, ale nie dotyczy go on bezpośrednio. W rezultacie nie podejmują żadnych działań w celu zapewnienia pomocy lub wsparcia.

To denerwujące, gdy projekt nie ma systemu kontroli wersji – prowadzi to do sytuacji, w której nie jest jasne, którą kompilację aktualnie testujesz. W rezultacie nie można wskazać numeru kompilacji, w której wykryto błąd, w zgłoszeniu błędu.

Kiedy programista konfiguruje system rejestrowania tak, aby generowane rekordy przypominały kod maszynowy, który nadal wymaga interpretacji, może to stanowić prawdziwe wyzwanie, zwłaszcza przy ograniczonym czasie testowania.

To denerwujące, gdy klient nie może jasno zakomunikować swoich wymagań dotyczących produktu. Oto typowa sytuacja:

Klient: Wszystko w porządku, ale czy mógłby Pan wyjaśnić, dlaczego pola wyboru wskazują dokładnie te wartości: pierwsza, druga, trzecia?

Sam Pan zatwierdził to polecenie.

Klient. Cześć? Zmieńmy to na jeden, dwa, trzy...

Następnego dnia:

Klient. Wydaje mi się, że w polach wyboru były inne opcje, prawda?

Zespół. Tak, ale zatwierdziłeś obecne.

Klient. A, racja... Okej, w takim razie użyjmy pierwszy, drugi, trzeci...

— Coś tu nie działa.

— To nie moje!

— Napisałeś wynik deweloperski!

— O, okej...

Klient. Wszystko w porządku, ale chciałbym zrozumieć, dlaczego pola wyboru pokazują te nazwy: pierwszy, drugi, trzeci?

Zespół został przez Ciebie zatwierdzony.

Klient. Tak? Zmieńmy to na jeden, dwa, trzy...

Następnego dnia:

Klient: Chyba były inne opcje w polach wyboru, prawda?

Zespół: Zgadza się, ale zatwierdziłeś obecne.

Klient: Aha, jasne... Okej, w takim razie użyjmy pierwszej, drugiej, trzeciej...