Rozmowy o automatyzacji. Podsumowanie

Nie jest to tylko podsumowanie prowadzonego przeze mnie panelu „Porozmawiajmy o automatyzacji”, ale podsumowanie serii rozmów, jakie odbyłem w ostatnim roku po publikacji swoich tez dotyczących automatyzacji. Nasłuchałem się wiele o jej wartości, podebatowałem o konkretach i przede wszystkim potwierdziłem, że warto rozmawiać. 
 
Oto 5 tematów, o których rozmawiałem i które pozwoliły mi spojrzeć na automatyzację z zupełnie nowej perspektywy. 

1. Automatyczne testy eksploracyjne

Zawsze negowałem mówienie o eksploracji w kategoriach automatyzacji. Określenie „automatyczne testy eksploracyjne” było dla mnie nieakceptowalnym uproszczeniem. Uznawałem, że eksploracja jako odkrywanie nowego jest zarezerwowana dla ludzkiego postrzegania, a dopiero naśladowanie przez maszynę podjętych przez człowieka działań można uznać za automatyzację. 

Co prawda jednym z moich pierwszych kroków na początku sesji eksploracyjnej zawsze było uruchamianie narzędzi, ale nie postrzegałem tego jako automatyzacji testów. Zaczynałem od narzędzi do rejestrowania sesji - nagrywania, logowania działań lub screencastów. Kolejne były instrumenty wspierające raportowanie (note taking) z narzędziami analizy statycznej (jak audyty w  DevTools). Dla mnie było to jedynie proste użycie narzędzia niczym młotka w testach odporności telefonów komórkowych. 

Dziś sesji eksploracyjnych nie wyobrażam sobie bez użycia LLM-ów. Ja robię swoje, a równolegle do moich działań AI przygotowuje swoje analizy. Czasami jakiś agent wykona polecenie wystarczająco dobrze, abym mógł uznać go za pomocnika w wykonaniu powtarzalnych zadań eksploracji. Moim zadaniem na końcu jest interpretacja uzyskanych przez niego wyników. 

Zaczynam otwierać się na koncept, że rzeczywiście część prac w eksploracji może zostać zautomatyzowana, a nasza współpraca z maszyną znacząco podniesie efektywność. Jeśli tylko dobrze skonstruuję prompt i wybiorę właściwy model, moja praca zostaje w pewnym stopniu zautomatyzowana. 

Dziś więc stwierdzenie „automatyczne testy eksploracyjne” przestało mnie razić.

2. Badacze automatyzacji wpływają na to, jak wygląda automatyzacja

Badanie skuteczności narzędzi jest trudne, bo pracujemy w tak zmiennym środowisku, że po zakończeniu analizy danego narzędzia pojawia się już jego nowa, ulepszona wersja, która eliminuje wady poprzednika (choć bywa, że wprowadza nowe). Z naukowej perspektywy badanie należałoby powtórzyć, ale czy w takim razie nie wchodzimy naturalnie w cykl wytwórczy? Jako badacze próbujemy zewnętrznie obserwować obiekt, ale ten obiekt reaguje na naszą obserwację i jej wyniki. Badanie staje się testem, a wynik analizy raportem defektów do poprawy. Obiekt zostanie poprawiony i będzie zachowywał się już inaczej.

Gonimy własny ogon, więc… może badanie automatyzacji trzeba sprowadzić do procesu testowania w konkretnym środowisku (o tym w punkcie 4)?

3. Automatyzacja się skaluje

Choć zawsze uważałem łatwość przeskalowania automatyzacji za jej podstawowy benefit, to coraz częściej myślę, że nie doceniałem jej wystarczająco mocno. Z jednej strony to skalowalność na wiele danych (jeden skrypt, wiele danych testowych), wiele platform (jeden skrypt i wiele środowisk), czy skalowalność wydajnościowa (jeden skrypt do wielu testów performance, jak standardowe obciążenie, maksymalne obciążenie i przeciążenie). 

Skalowalność automatyzacji ma też olbrzymią wartość na osi czasu (o ile nie opiera się na interfejsie graficznym). Jeden skrypt może być używany do sprawdzania starych wersji aplikacji, które jeszcze utrzymujemy; obecnych, które aktualnie mamy na preprodukcji lub produkcji i przyszłych, aż zdecydujemy się na przepisanie systemu. 

4. Automatyzacja zależy od kontekstu

Z jednej strony chciałbym rozmawiać o automatyzacji w kategoriach naukowych, ale coraz częściej dociera do mnie, że automatyzacja nie ma swojego uniwersalnego, ponadprojektowego wymiaru. Gdybyśmy zadali sobie pytanie, ile projektów automatyzacji zakończyło się powodzeniem, to bez względu na odpowiedź nic nam to nie powie o wdrożeniu automatyzacji w naszym projekcie. Jest zbyt wiele czynników, które mogą przyczynić się do sukcesu oraz drugie tyle, które mogą sprzyjać porażce. 

Nadal uważam, że przedstawianie automatyzacji w projektach jako remedium na występujące problemy jakościowe to scam, ale nie mogę (i nie chcę) powiedzieć, że automatyzacja zazwyczaj się nie sprawdza. 

Jakie jest więc rozwiązanie? Eksperymentowanie w swojej organizacji. Każda firma planująca wdrożenie automatyzacji powinna przeprowadzić projekt we własnym zakresie. Im lepiej zostanie on poukładany, tym większa będzie świadomość (nie)skuteczności automatyzacji. Do niektórych wniosków można dojść jedynie na produkcji, a nie w ramach wcześniejszych badań. 

5. Automatyzacja szybko się zmienia

Nie ma sensu analizowanie skuteczności narzędzia, które na rynku było 5 lat, 3 lata, a nawet rok temu, bo dziś, w swojej najnowszej wersji, to zupełnie inne narzędzie. Badania i analizy sprzed 10 lat nie będą adekwatne do aktualnej sytuacji. Chyba że przez 10 ostatnich lat nasza organizacja nie wychodziła z piwnicy. Automatyzacja dziś to nie ta sama automatyzacja co wczoraj. 

Czy więc (i jak da się) rozmawiać o czymś tak zmiennym? Oczywiście, że tak, ale rozmowa zamiast koncentrować się na przeszłości, musi skupiać się na teraźniejszości i na tym, co możliwe do przewidzenia w przyszłości. Przeszłe badania nie dostarczają wystarczających argumentów do rozmowy o automatyzacji dziś. A czym odleglejsze badania, tym ich mniejsza wartość. Analiza statystyczna z predykcją trendów oraz monitoring powiedzą nam dużo więcej o dzisiejszej sytuacji i potencjalnym jutrze rynku. Pojawia się tutaj również wiele ryzyk, np. czy nie wpadniemy w pułapkę hype'u na daną technologię lub metodę? Jednak tani i szybki pilot z PoC (proof of concept) będzie dużo lepszym rozwiązaniem niż poprzedzony wielomiesięczną analizą projekt wdrożenia narzędzia. To pilot da nam dane wystarczające do podjęcia decyzji o poziomie skuteczności metody automatyzacji. Projekt wdrożenia da nam tylko decyzję – niekoniecznie słuszną.
 
Aby takie rzeczy zobaczyć i doświadczyć, trzeba wyjść ze swojej bańki technologicznej, projektowej czy organizacyjnej i nie tylko dzielić się zdobytym doświadczeniem, ale i otworzyć się na doświadczenia innych.