Zasoby ludzkie

Promowanie testerów manualnych lub niedoświadczonych programistów do roli deweloperów automatyzacji może początkowo przynosić efekty, jednak w dłuższej perspektywie zwykle prowadzi do problemów z utrzymaniem i stabilnością testów. Automatyzacja to specjalistyczna dziedzina wymagająca odpowiednich kompetencji, a co za tym idzie — nie powinna być traktowana jako dodatkowe zadanie wykonywane „przy okazji” ani powierzana niedoświadczonemu zespołowi korzystającemu z prostych narzędzi typu „nagraj i odtwórz”. Również przydzielanie zasobów do automatyzacji w trybie dorywczym nie jest dobrym rozwiązaniem, ponieważ pisanie testów automatycznych to jedynie część pracy — równie istotną częścią obowiązków testera automatyzującego jest analizowanie uzyskiwanych wyników i naprawa uszkodzonych testów, co także pochłania znaczną ilość czasu.

Modele pracy można podzielić według poziomu zależności i niezależności zespołów:

• Wysoka zależność organizacyjna: Dedykowany zespół automatyzacji testów pracuje oddzielnie od zespołów developerskich. Takie rozwiązanie jest wygodne organizacyjnie, umożliwia szybkie zbudowanie spójnej infrastruktury i wiedzy w jednym miejscu, ale powoduje problemy komunikacyjne — automatyzacja jest często „spóźniona” w stosunku do zmian w produkcie i wymaga dodatkowej koordynacji oraz wsparcia developerów przy integracji i debugowaniu.
• Średnia zależność organizacyjna: Model „dzielonej odpowiedzialności” — deweloperzy budują komponenty infrastrukturalne i kluczowe elementy frameworka, a testerzy (często bez zaawansowanych umiejętności kodowania) korzystają z nich do przygotowywania scenariuszy testowych w stylu KDT. To podejście angażuje cały zespół QA, ale generuje ryzyko wąskich gardeł: każda zmiana w komponentach wymaga czasu i kompetencji developerów, przez co zależność między testerami a developerami utrudnia płynność pracy.
• Wysoka niezależność organizacyjna (zwinne podejście): Automatyzacja jest całkowicie powierzona developerom aplikacji w zespołach funkcjonalnych. Każdy zespół odpowiada za testy swoich funkcji i utrzymanie „zielonych” testów jako element Definition of Done. To podejście minimalizuje zależności i opóźnienia, ale wymaga wysokich kompetencji testowych i praktyki TDD/ATDD wśród programistów. Nie sprawdzi się w organizacjach, które nie mają doświadczonych developerów lub w których nie zadbano o standaryzację i transfer wiedzy.

Dodatkowo każda organizacja musi świadomie zdefiniować:

• Kto ponosi odpowiedzialność za badanie niepowodzeń testów?
• Jak zapewnić spójność standardów kodowania i projektowania testów między zespołami?
• Jak eliminować problemy wynikające z niskiej jakości frameworka lub jego niewystarczającej modularności?