Redakcja
Automatyczna kontrola jakości oprogramowania jest obecnie w topie pożądanych działań projektowych. Można uznać, że w większości to właśnie zespoły testerskie są odpowiedzialne za dobór właściwego narzędzia, wdrożenie i utrzymanie automatyzacji w organizacji. Aby lepiej zrozumieć automatyzację, trzeba przyjrzeć się obecnej sytuacji projektów automatyzacji i roli testerów w tym procesie. Bazując na dostępnych źródłach, obserwacjach, rozmowach z ekspertami oraz na wynikach ankiety, jaką przeprowadziliśmy na naszych stronach dochodzimy do dość nieoczywistych i może nawet nowatorskich wniosków.
Opieramy się na współczesnych publikacjach, jak np. na "Automatyzacji testów" Arnona Axelroda.
Przeprowadzona przez nas ankieta nie może być traktowana jako jedyna wyrocznia w analizie rynkowej ze względu na badaną próbkę (około 130 odpowiedzi), ale pokrywa się z wynikami obserwacji oraz rozmowami z ekspertami na rynku.
Zachęcamy do zapoznania się wynikami samej ankiety gdyż jest to ciekawy materiał wejściowy do naszej analizy.
Liczymy również, że ten artykuł wywoła dyskusję o kondycji automatyzacji testowania i potwierdzi lub podważy zawarte w nim wnioski.
W analizie i dla lepszego zrozumienia automatyzacji zdecydowaliśmy zbudować coś na kształt procesu z uwzględnieniem dwóch, naszym zdaniem, niezależnych ścieżek. Jedną z nich jest samo budowanie frameworku, który jest środowiskiem i silnikiem do budowanie testów. Drugim jest właściwe projektowanie, uruchomienie i utrzymanie testów.
Proces składa się z czynności, które są standardowymi zadaniami automatyka testów. Podjęliśmy próbę zbadania w jakim stopniu wykonywane są one przez osoby zaangażowane w projekt automatyzacji.
Wyniki mogą być częściowo zaskakujące ponieważ automatycy testów w małym stopniu są zaangażowani w samo pisanie testów, a bardziej zaangażowani są w czynności ich zaprojektowania. Szukając analogii można powiedzieć, że to tak jakby programista w modelu sekwencyjnym wykonywał pracę analityczną z klientem, próbując zdefiniować jego oczekiwania.
Uwzględniając, że koszty pracy testera automatyzującego mogą stanowić znaczące obciążenie dla projektu, warto zastanowić się nad wsparciem jego działań przez inne role. Można nawet powiedzieć role „odpowiedniejsze” do tych zadań.
Przykładowo zadania związane z wymyślaniem i projektowaniem testów oraz definiowaniem danych testowych może przejąć tester oprogramowania. Z kolei osoby bardziej techniczne, o kompetencjach pozwalających na modyfikowanie kodu źródłowego, mogłyby wziąć na siebie odpowiedzialność za uruchomienie testów i późniejszą analizę, w tym reprodukcję i raportowanie defektów. Ta wiedza może być konieczna, aby poprawiać same testy. Jednocześnie będąc w obszarze egzekucji mogą podejmować decyzje o usunięciu zbędnych testów z zestawu automatyzacji.
Wnioski
- Proces i projekt automatyzacji są skrajnie trudne, co potwierdza wysoki poziom niepowodzeń w projektach automatyzacji, jednakże w dużej mierze wynika to z problemów nieumiejętnego zarządzania projektami automatyzacji.
- Czynności, które przeprowadzane są w procesie automatyzacji, nie są tak trudne jak się większości osób wydaje, dlatego można je scedować na pracowników o kompetencjach testerskich bardziej niż programistycznych.
- Automatyzacja może być tańsza i może dostarczać większą wartość, jeśli umiejętnie rozdzielimy zadania między pracowników. Musimy też zmniejszyć deficyt w rolach związanych z automatyzacją.
