Redakcja
Ludziom z branży często zdarza się definiować rolę między testerem manualnym na pozycji mida, nazywanego pokrótce "tester+" (tester plus), a testerem automatyzującym z podstawami automatyzacji interfejsów graficznych, nazywanego "automatykiem-" (automatyk minus). Problem polega na tym, że próba zestawienia tych dwóch ról jest błędna. Pomiędzy nimi nie ma nic więcej, poza wolą do zmiany kierunku rozwoju. Poniżej powody takiej sytuacji.
Powód 1
Różne umiejętności
Oba te zawody zupełnie różnią się od siebie. Przejście z testera do automatyka jest realnie przebranżowieniem się z dobrym punktem startowym znajomości zagadnienia weryfikacji jakości oprogramowania.
Umiejętności testera+ to cały proces pracy w testowaniu oprogramowania, często błędnie określany jako manualne testowanie:
- zrozumienie wymagań
- zrozumienie domeny biznesowej
- zaprojektowanie testów
- wykonanie testów
- raportowanie incydentów
- raportowanie swojej pracy.
Umiejętności automatyka- to de facto umiejętności pisania kodu skryptów testowych i należą do nich:
- transformacja testu w skrypt
- posługiwanie się frameworkiem automatyzacji oraz wzorcami projektowymi
- analiza logów wykonania
- debugowanie kodu
- raportowanie incydentów.
Umiejętności te są częściowo zbliżone, ale podobieństwo między testerem i automatykiem jest takie jak między analitykiem a programistą.
Powód 2
Źle definiowany kierunek rozwoju
Ukuło się przekonanie, że dla testera naturalną ścieżką rozwoju jest zostanie automatykiem. Niestety jest to mocno wspierane przez rynek, a główna motywacja testerów do automatyzacji to finanse oraz prymitywny model weryfikacji w organizacji.
Motywacja finansowa to oczywiście kwestia możliwości podwojenia swoich zarobków. Tam, gdzie pojawia się sufit w testach „manualnych”, zaczyna się odliczanie dla automatyków.
Motywacja wynikająca z modelu weryfikacji to przede wszystkim zmuszanie testerów do wykonywania powtarzalnych czynności, które powinny być albo wykluczone z testów po analizie zakresu zmian w oprogramowaniu, albo zautomatyzowane. Często mówi się, że testerzy chcą automatyzować. Jest to prawda, ale jedynie w środowisku, gdzie testowanie nie jest traktowane jako pełnoprawna profesja i gdzie jest to jedyna możliwość podniesienia swojego prestiżu oraz warunków finansowych.
Naturalnym kierunkiem rozwoju testera jest przejście od juniora do seniora z poszerzeniem świadomości domeny biznesowej, w jakiej działa oprogramowanie. Oczywiście dalej znajdują się pozycje managerskie (lider testów) i eksperckie (konsultanci i trenerzy).
Naturalnym kierunkiem rozwoju automatyka jest specjalizacja w narzędziu / platformie / języku lub przejście do obszaru programowania. Tu również znajdują się pozycje managerskie (development manager) i eksperckie (konsultanci i trenerzy).
Oczywiście z każdej z tych ścieżek można zejść w dowolnym momencie, idąc na analityka biznesowego czy też sprzedawać planszówki w sklepie.
Powód 3
Źle zdefiniowany i zaadresowany problem jakości
Czy zdarzyło się Wam coś z poniższych?
a. Niska jakość oprogramowania oznacza, że tester źle przetestował, więc należy zacząć automatyzację.
b. Tester nie wyrabia się z kontrolowaniem jakości, co oznacza, że należy zacząć automatyzować.
c. Tester aktualnie ma przerwę w testach, co znaczy, że powinien zacząć automatyzować.
W środowiskach takich, jak to mamy do czynienia z niską świadomością tego, do czego realnie służy automatyzacja. Dla przypomnienia – automatyzacja nie szuka nowych defektów, a jedynie potwierdza, że działające oprogramowanie nie ma regresu. Podczas projektowania automatów wszystkie dotychczas niewykryte defekty powinny zostać ujawnione. Ponowne uruchomienie automatów jest potwierdzeniem, że wszystko ciągle działa. Dlatego „a” i „b” jest kompletnie pozbawione sensu. Przypadek „c” wskazuje na powszechne postrzeganie automatyzacji jako remedium na złą jakość. Jest to również wskazanie na „naturalną” ścieżkę rozwoju testera, a jak opisano w powodzie 2, jest to bzdura.
Spróbujcie zrobić pewien test. Zapytajcie swój zespół wytwórczy co by wybrali, gdyby musieli zdecydować, czy wolą pracować z testerem+, czy testerem automatyzującym?
Podajcie definicję:
- testera+ jako osoby z lepszym rozumieniem domeny i z większymi kompetencjami w projektowaniu realistycznych scenariuszy testowych, skrajnych przypadków użycia czy wywoływania obsługi nieobsługiwanych zdarzeń
- automatyka testów z kompetencjami pokrycia podstawowych ścieżek użycia oprogramowania przez skrypty automatyczne.
W tym teście większość programistów, analityków i managerów wybierze odpowiedź "tester+". Niestety, ci ostatni nie uznają tych kompetencji za wystarczające do zrównania zarobków takiej roli z poziomem zarobków automatyków-.
