Redakcja
Choć powtarza się nam ciągle o tym, w jak innowacyjnym sektorze pracujemy i przy pomocy jak wyrafinowanych narzędzi działamy, to wcale nie jest to obraz mocno podkoloryzowany. Patrząc z perspektywy lat, które minęły od powstania IT, możemy spokojnie uznać, że pierwsze narzędzia i metody wytwórcze były dość prymitywne. Całe środowisko naszej pracy ciągle ewoluuje i zmienia się, więc zapewne za dziesięć lub kilkanaście lat, patrząc wstecz na 2024, powiemy, że namnożyliśmy metod i narzędzi, a wytwarzanie oprogramowania wcale nie stało się dużo bardziej sprofesjonalizowane. Nie musimy jednak patrzeć w głęboką przeszłość, aby zauważyć nieefektywności procesów wytwórczych. Wystarczy przyjrzeć się bliżej automatyzacji testów. Złożoność współczesnych całych procesów wytwarzania oprogramowania oraz mnogość kodu, jaki musi zostać napisany, aby rozpocząć tworzenie testów do weryfikacji produktu w projekcie IT, to jeden z głównych czynników porażki wdrożenia automatyzacji w projektach. Oczywiste jest to, że skuteczne wdrożenie automatów wymaga systemowego uproszczenia zarówno SDLC, jak i znaczącej redukcji liczby linijek kodowych, które musimy stworzyć pod testy. Tą zmianą może być użycie AI. Ale czy nie jest to jednak dalsze komplikowanie?
Spójrzmy na pewien uproszczony schemat automatyzacji w projekcie informatycznym, w którego centrum posadzimy testerkę automatyzującą:
Legenda:
Postać w centrum to testerka.
Osoby na skraju to programiści.
Narzędzie automatyzacji GUI to np. Selenium
JIRA jest środowiskiem prowadzenia projektu.
Skrypt jest kodem testów w Selenium.
Testowany obiekt - to, co poddajemy testom.
Powyższa wizualizacja pokazuje nam jak wiele zespołów programistycznych i narzędzi potrzebujemy, aby poprowadzić projekt automatyzacji. Musi zostać napisane bardzo dużo kodu (np. Jira czy Selenium), aby można było napisać kod skryptu, którym będzie można testować kod naszego produktu. W uproszczeniu możemy napisać, że piszemy kod, by zadbać o jakość kodu. To rozwiązanie wydaje się tak skomplikowane, że oczywistym jest konieczność jego uproszczenia. A to tylko uproszczony punkt widzenia, bo nie uwzględnia on repozytoriów, systemów operacyjnych, klientów poczty, narzędzi komunikacyjnych i dziesiątek innych aplikacji, które choć częściowo w proces tworzenia kodu testów zostają zaangażowane. Oczywiście, żeby test miał sens, to musimy stworzyć przede wszystkim testowany obiekt.
Z jednej strony mówi się, że testerzy dążący do automatyzacji i robotyzacji podcinają gałąź, na której siedzą. Z drugiej jednak widać, że jest to jedynie pogłębianie złożoności procesu wytwórczego, co powoduje, że pracy dla testerów mamy jeszcze więcej. Testerzy manualni nie zostali zastąpieni przez automatyzujących; oni się po prostu dodali do grupy już w testach pracujących. Cała populacja testerska to dziś i manuale, i automatycy. Automatyzacja nie niesie więc jednoznacznie negatywnych skutków dla testerów, ale też nie przynosi znaczących korzyści projektom. Jest ona pewną próbą usprawnień, ale nie jest optimum, dlatego też prace nad narzędziami, które przyniosą korzyści obu stronom, są pożądane przez wszystkich. Taką nadzieją na uproszczenia jest AI.
Jest pewna luka między pomysłem na test, a jego implementacją w postaci uruchamialnego skryptu. Tę lukę aktualnie wypełnia człowiek – mówi Radek Smilgin. To jest ten, czasami prześmiewczo określany, interfejs białkowy. Wszyscy z nadzieją patrzymy na AI, ale pamiętajmy, że obecnie AI nie testuje oprogramowania, a jedynie generuje testy dla testerów. Człowiek, jako interfejs białkowy, ciągle musi pośredniczyć między pomysłami na testy wygenerowanymi przez sztuczną inteligencję, a samym wykonaniem testów i analizą ich wyników.
Poniżej wizualizacja interfejsu białkowego między AI a testowanym obiektem:
Jednak i tu pojawia się problem złożoności. Kod rozwiązania AI, jak i wszystkie wspomniane wcześniej narzędzia, musi zostać napisany. Stąd wniosek, że do pokazanej na początku skomplikowanej infrastruktury dokładamy dodatkowy element komplikujący wszystko jeszcze bardziej. Oczywiście motywuje nas dalsza optymalizacja i naszą testerkę wyposażamy w kolejne narzędzia, które uczynią jej pracę jeszcze efektywniejszą. Całościowo środowisko pracy z kolejnym narzędziem staje się o wiele bardziej złożone.
Podsumowując, aktualnie procesy wytwarzania oprogramowania są skrajnie złożone i wymagają optymalizacji, aby móc w efektywny sposób wspomagać dostarczanie wysokiej jakości kodu końcowego produktu.
Wszelkiego rodzaju próby automatyzacji, robotyzacji i użycia AI są potrzebne, nawet jeśli dziś wydają się dość nieporadne i zamiast rozwiązywać problemy, to jeszcze je piętrzą. Dalszy rozwój tych koncepcji może pomóc nam oszczędzać czas i energię w przyszłości. Na ten moment jednak ciągle inwestujemy, aby osiągnąć korzyści. Pamiętajmy jednak, że jeśli automatyzacja i/lub AI staną się optymalne, to mogą doprowadzić do redukcji części miejsc pracy w projektach informatycznych.
Opracowane z prezentacją „TEST to nie PRZYPADEK” Radka Smilgina z WarszawQA 19.12.2023
