Praktyka automatyzacji. Ile jest kodowania w automatyzacji?

Zachęcamy się do zapoznania z innymi naszymi publikacjami dotyczącymi automatyzacji, które wprowadzają w poruszany tutaj temat.

• "Zrozumieć automatyzację" – wyniki ankiety,
• Praktyka automatyzacji. Analiza.

W tej publikacji nie poruszamy aspektów narzędzi automatyzacji no code / low code, a środowiska automatyzacji testów polegające na pisaniu kodu źródłowego. Wcześniej patrzyliśmy na automatyzację z perspektywy procesu i kierownictwa, teraz chcielibyśmy na przykładzie pokazać, że kodowanie stanowi mały fragment obowiązków testerów tworzących automatyzację. 

Aby to udowodnić, przyjrzyjmy się bardzo prostemu testowi. 

 
*) test ten oczywiście nie spełnia standardów projektowania dobrych skryptów, a jest jedynie pewnym uproszczeniem; przykładowo nie wprowadzamy tutaj oddzielania warstw danych od samego skryptu.

Analizując jego treść możemy łatwo wyróżnić elementy, które są rzeczywistym skryptem testowym i te, które stanowią jego część "niekodową". Należą do niej min. opis testu, definiowanie dane czy komentarze będące elementami samego testu.

Patrząc na przykład można zdefiniować sobie zbiór czynności, które zostały wykonane, aby powstał:

• pomysł na testy, który zawiera się w jego nagłówku - przykład: Search by text
• projektowanie testu, które pokazuje pewną strukturę skryptu  – przykład: //type searched text...
• projektowanie danych, czyli wartość z jaką skrypt ma zostać uruchomiony  – przykład: Simply the best
• pisanie testów – przykład: .contains(searchResultTitle).

Dodatkowo samo pisanie testów jest później podstawą do czynności debugowania / poprawiania testów – przykładowo: #L2AGlb – jest to css selector, czyli wskazanie na element, na którym należy wykonać operację; przy jego zmianie w testowanym systemie należy go w teście zaktualizować.

Uruchomienie testu. Przykład. W GIF.

 
Warto też przyjrzeć się aspektowi późniejszego uruchamiania testów. Podczas niego część testów zakończy się niepowodzeniem, choć przy wykonaniu ręcznym wszystko wydaje się działać w najlepszych porządku. Jedną z wielu przyczyn może być zmiana nazwy elementu, na którym ma być wykonana operacja. Zadaniem testera, który debuguje taki test, będzie podmiana starej nazwy obiektu na nową. Innym obowiązkiem testera może być usuwanie z zestawu testów automatycznych tych, które pokrywają usunięte lub znacząco przebudowane funkcje. 

Mapując kod na działania podczas automatyzacji okazuje się, że pisanie testu jest ułamkiem działań w odniesieniu np. do jego projektowania.

Oczywiście kod źródłowy jest ciągle tutaj kluczowy i bez niego test nie mógłby zostać uruchomiony. Jeśli jednak dobrze się przyjrzymy, to ponad 70% części testu to elementy, których definiowanie / redefiniowanie realnie nie wymagają posiadania umiejętności kodowania. 

W zależności od perspektywy jaką przyjmiemy w tej analizie możemy dojść do różnych wniosków.
Perspektywa kontra wnioski:

• tester automatyzujący może założyć, że gdyby ktoś wspomógł go w definiowaniu testów, to mógłby stworzyć więcej skryptów lub lepsze skrypty,
• tester "manualny" może dojść do wniosku, że automatyzacja nie jest wcale taka trudna i z podstawowymi wiadomościami o składni kodu można poprawiać lub utrzymywać testy,
• kierownik testów mógłby wyciągnąć wniosek, że jeśli połączy role testera i programisty testów, mógłby mieć więcej lepszej automatyzacji w niższej cenie.