Redakcja
Na początek warto wyjaśnić, czym właściwie jest tytułowy Devin. Otóż Devin to narzędzie oparte na sztucznej inteligencji, które ma na celu najpierw wspomaganie programistów, a następnie ich zastąpienie (przynajmniej części tych odtwórczych). Stworzony przez firmę Cognition, swój debiut zaliczył w połowie marca 2024. Według jego twórców Devin potrafi:
- projektować i pisać kod; może on także generować kod na podstawie prostych opisów funkcjonalności, a także planować architekturę oprogramowania i pisać testy jednostkowe
- uczyć się nowych technologii i języków programowania, a także uczyć się na podstawie błędów i stale poprawiać zdobyte umiejętności
- współpracować z programistami w czasie rzeczywistym, dostarczając im sugestii i rozwiązań problemów
- automatyzować powtarzalne zadania, takie jak pisanie dokumentacji czy testowanie kodu.
Od czasu swojego debiutu Devin zdążył już wywołać niemałe poruszenie. Uważany za pierwszego „inżyniera oprogramowania AI”, może pochwalić się imponującym i dość unikalnym jak na ten moment zestawem funkcji, które mogą znacznie zmienić również proces wytwarzania oprogramowania. Wiemy, że od momentu coraz większego rozpowszechnienia się AI, stale zmienia się też szeroko pojęty krajobraz rozwoju oprogramowania. Dotyczy to także kontroli jakości. Narzędzia takie jak Devin już dawno przestały mieścić się wyłącznie w wizjach dotyczących odległej przyszłości, a zdecydowanie wyciągnięto je z szuflady podpisanej jako ‘science fiction’.
Czy (i jakie) są ograniczenia kontroli jakości za pomocą AI?
Devin „wprowadził się” na tereny rozwoju oprogramowania, wnosząc ze sobą interesujący zestaw narzędzi. Nie będzie mu jednak łatwo pozbyć się pewnych uwarunkowań, które już na starcie mogą postawić go na przegranej pozycji. Devin jest bowiem „uzależniony” od wpojonych w niego instrukcji, a to znacznie uszczupla zakres jego doświadczenia z rzeczywistym światem, przez co trudno mu uchwycić niuanse należące do sfery doświadczeń użytkownika. W jaki sposób Devin może poradzić (a raczej nie poradzić) sobie z zadaniami wymagającymi zrozumienia potrzeb użytkowników i oceny intuicyjnego projektu?
Testowanie oprogramowania, które uwzględnia doświadczenia użytkownika, znacznie wykracza poza samą, prostą identyfikację tego, czy dana funkcja działa, czy też nie. Wymaga ono też zrozumienia, w jaki sposób użytkownik będzie wchodzić w interakcję z oprogramowaniem oraz tego, czy będzie ono dla niego intuicyjne i przyjazne. Devin takich umiejętności nie ma, nie potrafi więc uchwycić emocjonalnych aspektów doświadczenia osoby korzystającej z aplikacji i nie może dokonać oceny, czy dany projekt wydaje się mu się mylący albo frustrujący.
Dla skutecznego testowania UX ważne jest też zrozumienie potrzeb użytkowników. Tester manualny może obserwować ich zachowania, zbierać opinie i identyfikować pojawiające się trudności. Devin jest ograniczony jedynie do tych danych, na których został przeszkolony, co sprawia, że w trakcie swojej pracy może pominąć istotne potrzeby użytkowników, które nie zostały wyraźnie zaprogramowane albo przewidziane przez programistów.
Żeby ocenić intuicyjność projektu, trzeba zrozumieć, w jaki sposób użytkownicy naturalnie poruszają się po interfejsie i wchodzą z nim w interakcje. Devin będzie mógł co prawda przeanalizować wcześniej zdefiniowane zakresy użyteczności, ale nie jest w stanie odtworzyć ludzkiej zdolności oceny ogólnego przepływu interfejsu. Dlatego w trakcie testów mogą umknąć mu np. nielogiczne rozmieszczenia przycisków albo mylące układy, jeśli nie zostaną wcześniej wyraźnie oznaczone jako problematyczne. Załóżmy, że Devin zaprojektuje nam aplikację fitness. Dzięki swoim testom może zapewnić sprawne i poprawne działanie wszystkich timerów i trackerów ćwiczeń, ale nie stwierdzi, czy układ aplikacji nie jest zbyt chaotyczny i przytłaczający dla użytkownika albo czy wiadomości motywacyjne nie wydają się za bardzo bezosobowe i nie zniechęcają do ćwiczeń. Tester takie problemy zidentyfikuje dzięki testom z udziałem rzeczywistych użytkowników i przekaże programistom cenną informację projektantom, którzy będą mogli poprawić ogólne doświadczenia użytkowników.
Devin nie poradzi sobie też z użytecznością
Chociaż Devin bardzo dobrze odnajduje się w automatyzacji zadań i identyfikowaniu błędów technicznych, testerzy manualni mają taki zestaw umiejętności, który szczególnie sprawdza się w odkrywaniu problemów z użytecznością. Na początek, wyobraźmy sobie stronę internetową dowolnego sklepu. Działania Devina ukierunkowane są na to, aby zapewnić prawidłowe ładowanie stron produktów i dokładne wyświetlanie informacji, ale tylko tester jest w stanie zauważyć, że przycisk „Dodaj do koszyka” zlewa się z tłem, przez co jest trudny do odnalezienia przez użytkownika. Taka z pozoru drobna wada projektowa, pominięta przez narzędzia AI, może znacząco wpłynąć na doświadczenie użytkownika końcowego.
Tester porusza się po interfejsie oprogramowania i ocenia, czy jego przepływ jest intuicyjny. Może na przykład odkryć ukrytą opcję menu, która jest ważna dla konkretnego zadania albo zauważyć sekwencję kroków, która jest niepotrzebnie skomplikowana. Narzędzie AI takie problemy z nawigacją, które korzystanie z oprogramowania utrudniają, może pominąć.
Czasami użytkownicy korzystają z oprogramowania w dość nieprzewidywalny dla projektanta, a nawet niekonwencjonalny sposób. „Praca” Devina, która oparta jest przecież na zaprogramowanych przypadkach testowych, takie „kreatywne” interakcje użytkowników pomija, co prowadzi w efekcie do pominięcia wady użyteczności systemu. Dzieje się tak dlatego, że AI nie potrafi przewidzieć sposobu myślenia ani celów użytkownika końcowego. Aby to wyjaśnić, przyjrzyjmy się przykładowej aplikacji do edycji zdjęć. AI będzie mogło doskonale przetestować wszystkie dostępne w niej filtry, ale nie przewidzi, że użytkownik połączy je w zupełnie nieoczekiwany sposób, chcąc w ten sposób uzyskać wyjątkowy dla niego, unikalny efekt artystyczny. Użytkownik wykazał się więc swoją kreatywnością, potencjalnie ujawniając błąd lub ograniczenie, a „sztywne” podejście AI do testowania może takie rozwiązanie pominąć.
Nieprzewidziane działania użytkowników też mogą wynikać z błędów oprogramowania, ich pomyłek w trakcie użytkowania lub po prostu mogą być efektem kreatywnego rozwiązywania problemów. Devin nie będzie potrafił uwzględnić wszystkich możliwych scenariuszy podczas tworzenia przypadków testowych. Użytkownik, który napotyka błąd ładowania, może na przykład zacząć szybko klikać losowe przyciski w efekcie swojej frustracji. Czy Devin byłby w stanie przewidzieć takie zachowanie, które potencjalnie może ujawnić poważniejszy problem? Wątpliwe.
Zdarza się, że korzystając z oprogramowania, użytkownicy często opracowują swoje własne obejścia słabo zaprojektowanych funkcji. Ograniczeniem AI jest podążanie z góry narzuconą ścieżką testowania, dlatego może ono te obejścia całkowicie pominąć. Może się zdarzyć, że aplikacja do streamingu muzyki zostanie wyposażona w całkowicie nieintuicyjną funkcję losowego odtwarzania. Żeby to obejść, użytkownicy mogliby wpaść na pomysł utworzenia playlisty wypełnionej losowymi utworami, aby przez to uzyskać efekt losowego odtwarzania. Wiemy, że Devin nie byłby w stanie zidentyfikować tego obejścia jako symptomu wadliwego elementu projektu.
Do efektywnego testowania oprogramowania potrzebne jest uzyskanie informacji zwrotnej. Testerzy manualni mogą obserwować zachowania użytkowników podczas testów i odpowiednio dostosowywać do nich swoją strategię testowania. Devin nie uczy się z zachowań użytkowników w czasie rzeczywistym, bo opiera się na wstępnie zaprogramowanych danych i jeśli napotka na nieoczekiwane interakcje użytkowników, nie będzie w stanie dostosować swojego podejścia testowego, opierając się o uzyskane informacje zwrotne.
Testerzy manualni mają możliwość oceny, w jaki sposób oprogramowanie wpływa na emocje użytkownika. Mogą na przykład zauważyć, że strona logowania wydaje się dla nich zbyt skomplikowana, a przez to jest odstraszająca albo pasek postępu powoduje u użytkownika niepotrzebną frustrację. Devin emocjonalnych odpowiedzi nie będzie potrafił zrozumieć i pominie problemy z doświadczeniem użytkownika, które przecież łatwo można rozwiązać za pomocą drobnych poprawek w projekcie. Co więcej, Devin może mieć trudności ze zrozumieniem pojawiających się ewentualnych niuansów kulturowych w projekcie. Tester, który zna kontekst kulturowy docelowej grupy odbiorców, może zidentyfikować elementy, które są dyskryminujące lub obraźliwe dla użytkownika, mimo że technicznie działają zgodnie z założeniem.
W gruncie rzeczy widzimy, że Devin ma trudności z samym ludzkim aspektem interakcji z oprogramowaniem - elementem zaskoczenia. Chociaż może doskonale nadawać się do testowania przewidywalnych funkcji, nie może odtworzyć ludzkiej zdolności do nieszablonowego myślenia, przewidywania zaskakujących działań użytkowników i odpowiedniego dostosowywania do nich strategii testowania. I tu wkraczają testerzy manualni (cali na biało), razem ze swoją kreatywnością i zdolnością adaptacji, stając się dzięki temu ważnym elementem zapewnienia, że oprogramowanie wytrzyma nawet najbardziej chaotyczne sposoby wykorzystania go przez jego użytkowników. Aby to zrobić, mogą wykorzystać do tego między innymi przypadki brzegowe. Dlaczego?
Tester myśli jak użytkownik zaawansowany. Może więc wykonywać szybkie działania, testować ekstremalne dane wejściowe lub próbować złamać oprogramowanie za pomocą najróżniejszych, niekonwencjonalnych metod. Takie podejście pomoże odkryć przypadki brzegowe, które mogą zostać pominięte przez wstępnie zdefiniowane testy Devina. Wyobraźmy sobie aplikację do obsługi mediów społecznościowych. Devin przetestuje podstawową funkcjonalność tworzenia konta i publikowania postów. Tester manualny, który myśli jak użytkownik zaawansowany, może zechcieć spróbować utworzyć konto z wyjątkowo długą nazwą użytkownika albo spróbować przesłać plik obrazu o ogromnym rozmiarze. Te przypadki brzegowe ujawnią ograniczenia znaków lub pliku, które nie są widoczne w typowej sytuacji, wskazując na naprawdę poważne błędy.
Wiemy też, że tester może wykorzystać swoją kreatywność do wymyślenia i przetestowania różnych nieprzewidzianych scenariuszy. Niech przykładem będzie aplikacja pogodowa, w której Devin testuje wyświetlanie danych pogodowych dla popularnych lokalizacji, a tester w tym samym czasie rozważa przypadki brzegowe, takie jak wyświetlanie danych w odległych lokalizacjach o ograniczonej łączności internetowej albo testuje działania aplikacji podczas ekstremalnych zjawisk pogodowych, odkrywając w ten sposób potencjalne problemy z pobieraniem danych lub nieprawidłowe wyświetlanie.
Tester uwzględnia opinie rzeczywistych użytkowników oprogramowania w swojej strategii testowania. Przykład: aplikacja do nauki języków, w której narzędzie AI testuje podstawowe funkcje nauki, zaś tester, analizując opinie użytkowników, może odkryć przypadek brzegowy, w którym użytkownicy z określoną niepełnosprawnością uczenia się mają trudności z konkretnym formatem lekcji. Takie skoncentrowane na użytkownikach podejście przyczynia się do ujawniania przypadków brzegowych, które mogą nie być widoczne w czysto technicznym środowisku testowym.
Testerzy łączą więc świat, w którym oczekiwany rozwój oprogramowania ściera się z nieprzewidywalnym światem rzeczywistych użytkowników.
Ograniczona kreatywność AI
Devin potrafi wykonywać precyzyjne polecenia i jest w tym całkiem dobry. Doskonale radzi sobie z zadaniami powtarzalnymi, identyfikowaniem błędów na podstawie wstępnie zdefiniowanych parametrów, a nawet pisaniem kodu w oparciu o ustaloną logikę. Jednak w rzeczywistym świecie rozwoju oprogramowania nie brakuje trudnych do przewidzenia przeszkód. W sytuacjach, które wymagają kreatywnego podejścia do rozwiązywania problemów i adaptacji do nieprzewidzianych okoliczności, Devin spotyka się ze znacznymi ograniczeniami.
Można więc powiedzieć, że siła narzędzia AI jest jednocześnie jego słabością. Uzależnienie od wstępnie zaprogramowanej i wpojonej logiki bardzo utrudnia mu kreatywne myślenie i spojrzenie na pojawiające się problemy z innego punktu widzenia. Wyobraźmy sobie raport o błędzie, który opisuje nieoczekiwane działanie, ale jego przyczyna nie jest od razu widoczna w kodzie. Można podejrzewać, że Devin będzie mieć trudności z analizą takiej sytuacji, zidentyfikowaniem źródła problemu i opracowaniem rozwiązania. Tester, który z nieszablonowym myśleniem nie ma problemu, rozważy alternatywne wyjaśnienia i wypróbuje różne metody rozwiązywania problemów, aby ustalić ich przyczynę.
Debugowanie złożonych problemów z oprogramowaniem często wymaga zastosowania metody prób i błędów. Devin będzie mieć trudności z tym podejściem. Może utknąć w ustalonej ścieżce rozwiązywania problemów, pomijając przyczynę, jeśli tylko wykracza ona poza parametry jego początkowych instrukcji, podczas gdy tester sytuację przeanalizuje całościowo, poeksperymentuje z różnymi rozwiązaniami i wykorzysta swoją wiedzę na temat architektury oprogramowania, aby zidentyfikować główny problem.
Podsumowując, Devin w kontrolowanych środowiskach z jasnymi instrukcjami czuje się jak ryba w wodzie. Kiedy jednak w grę wchodzi konieczności zastosowania kreatywnego rozwiązywania problemów, zdolności adaptacji i nieszablonowego myślenia, poleganie przez Devina na zaprogramowanej logice staje się ogromną przeszkodą.
Odkrywanie przyczyny źródłowej
Mówiliśmy, że jedną z zalet Devina jest umiejętność skutecznego identyfikowania błędów i wskazywania wstępnych objawów nieprawidłowego działania. Jednak to testerzy mają zdolność do zagłębiania się w problem, identyfikowania źródła błędu i zapewnienia bardziej trwałego rozwiązania. Wróćmy do naszej aplikacji do streamowania muzyki. Devin w trakcie automatycznego testowania zidentyfikuje problem, który polega na tym, że playlisty czasami przestają grać w połowie. Oznaczy on błąd i wskaże miejsce w kodzie, w którym występuje awaria, może też zasugerować potencjalne poprawki związane z nim, jednak może mieć trudności z identyfikacją przyczyny nieprawidłowego odtwarzania playlisty.
A co może zrobić tester, po otrzymaniu raportu o błędzie od Devina?
- Dokonać analizy zgłoszeń użytkowników. Warto zacząć od przeglądu zgłoszeń użytkowników dotyczących problemu z odtwarzaniem. To może ujawnić dodatkowe szczegóły, takie jak typ urządzenia, na którym użytkownicy doświadczają danego problemu, konkretny format muzyczny, który jest nim objęty lub wszelkie inne czynności, które wydają się powodować zatrzymanie odtwarzania
- Odtworzyć i odizolować problem. Tester może spróbować odtworzyć problem, obserwując jednocześnie wydajność systemu. To obejmuje korzystanie z konkretnego modelu urządzenia, testowanie z różnymi formatami muzycznymi lub celowe wywoływanie działań zgłaszanych przez użytkowników.
- Zidentyfikować przyczynę pierwotną. Odtwarzanie i obserwacja sprawiają, że tester dociera do pierwotnej przyczyny, która wykracza poza wstępną awarię kodu zidentyfikowaną przez Devina. Co, jeśli za wszystkim stoi problem z wyciekiem pamięci na konkretnym urządzeniu, powodującym awarię aplikacji podczas odtwarzania?
- Odkryć prawdziwego "winowajcę". Dzięki połączeniu wstępnej detekcji Devina z badaniami testera manualnego zostaje w końcu zidentyfikowana przyczyna źródłowa - wyciek pamięci. To pozwala programistom wdrożyć trwalszą poprawkę, która rozwiązuje problem pierwotny, zapobiegając przyszłym przerwom w odtwarzaniu playlist na różnych urządzeniach i w formatach muzycznych.
Czego jeszcze nie zastąpi Devin?
Myślenie analityczne i rozwiązywanie problemów.
Testerzy doskonale radzą sobie z analizą raportów o błędach, opinii użytkowników i zachowania systemu w celu zrozumienia kontekstu problemu, a następnie wykorzystują umiejętność krytycznego myślenia, aby rozłożyć złożone problemy na mniejsze, łatwiejsze w zarządzaniu elementy. Dzięki temu identyfikuje się przyczynę źródłową - ukryty powód za objawem - a nie tylko rozwiązuje problem na poziomie powierzchownym.
Jeśli nasza aplikacja do fitnessu źle działa podczas śledzenia treningu, Devin może zidentyfikować błąd kodowania związany z obliczaniem dystansu, ale tylko tester manualny przeanalizuje sytuację dalej. Weźmie on pod uwagę czynniki, takie jak siła sygnału GPS, zmiany lokalizacji użytkownika lub rozbieżności między danymi aplikacji a danymi wprowadzonymi przez użytkownika. Taka analiza jest w stanie doprowadzić do ujawnienia wadliwej integracji GPS jako przyczyny źródłowej, prowadzącej do niedokładnego śledzenia dystansu.
Całościowe rozumienie architektury oprogramowania.
Efektywne rozwiązywanie problemów wymaga dogłębnego zrozumienia architektury oprogramowania i tego, w jaki sposób różne komponenty ze sobą współpracują. Testerzy mają taką perspektywę i mogą dzięki temu analizować, w jaki sposób błąd w jednej części kodu może wpływać na pozornie niezwiązane ze sobą funkcjonalności. To pozwala im zidentyfikować przyczynę źródłową, nawet jeśli objawia się ona w różnych obszarach oprogramowania.
Devin może zidentyfikować komunikat o błędzie związany z uwierzytelnieniem użytkownika. Tester manualny, dzięki zrozumieniu architektury oprogramowania, może rozpoznać, że błąd wynika z głębszego problemu z połączeniem z bazą danych użytkowników. I właśnie ta szersza perspektywa zapewnia wdrożenie bardziej wydajnego i ukierunkowanego rozwiązania.
Współpraca z programistami nad długoterminowymi poprawkami.
Testerzy nie tylko szukają błędów, ale także współpracują w procesie rozwoju oprogramowania z innymi członkami zespołu wytwórczego. Mogą skutecznie komunikować się z programistami, wyjaśniać przyczynę problemów i wspólnie pracować nad wdrożeniem długoterminowych rozwiązań. To podejście oparte na współpracy zapewnia, że poprawki nie są jedynie tymczasowymi łatami, ale rozwiązują przyczynę źródłową, zapobiegając ponownemu pojawianiu się podobnych problemów w przyszłości.
Rozumienie person użytkowników.
Testerzy zagłębiają się w persony użytkowników, czyli szczegółowe profile reprezentujące grupę docelową. Analizując dane demograficzne, zachowania i punkty zapalne związane z tymi personami, testerzy mogą podejść do testowania z perspektywy użytkownika. Ta empatia pozwala im przewidywać, w jaki sposób użytkownicy będą poruszać się po interfejsie, jakich informacji będą szukać i jakie funkcjonalności będą priorytetyzować. Testując aplikację do rezerwacji podróży, Devin może upewnić się, że wszystkie funkcje rezerwacji działają bez zarzutu. Jednak tester manualny, który rozumie personę użytkownika (niech będzie to zapracowany biznesmen planujący podróż), jest w stanie zidentyfikować potrzebę szybkiego i łatwego porównywania opcji lotów lub zasugerować integrację funkcji synchronizacji kalendarza w celu płynnego zarządzania trasą podróży.
Współpraca i burza mózgów.
Testerzy nie pracują w izolacji. Współpracują z programistami, projektantami i innymi testerami, aby wymyślić kreatywne scenariusze i podejścia testowe. To środowisko współpracy sprzyja innowacjom i pozwala testerom uczyć się nawzajem z doświadczeń.
Weźmy pod lupę zespół testujący nową grę VR. Podczas burz mózgów testerzy są w stanie opracować kreatywne przypadki testowe symulujące doświadczenie użytkownika w różnych wirtualnych środowiskach, przesuwając granice technologii VR i odkrywając w ten sposób potencjalne problemy z chorobą lokomocyjną, projektem interfejsu lub nieoczekiwanymi interakcjami użytkownika w świecie wirtualnym.
Devin to narzędzie, a nie zastępstwo
Pojawienie się Devina może oznaczać duży krok naprzód w świecie rozwoju oprogramowania. Może być ono też początkiem usprawnień wielu elementów pracy programistów i testerów, jak na przykład bardziej wydajne przeprowadzanie testów czy skuteczniejsze wykrywanie błędów. Pozostawienie AI wykonywania powtarzalnych przypadków testowych może pozwolić testerom skupić się na projektowaniu kreatywnych scenariuszy testowych czy badaniu przypadków brzegowych i przeprowadzaniu testów użyteczności, a w czasie, gdy AI przeanalizuje kod i zidentyfikuje potencjalne wzorce powodujące błędy, poprawiając w ten sposób ogólny wskaźnik ich wykrywania, testerzy manualni będą mogli zagłębić się w bardziej złożone błędy, które wymagają ludzkiej oceny i umiejętności analitycznych, aby ustalić ich przyczynę źródłową.
Naszym zdaniem Devin nie został stworzony, aby zastąpić testerów manualnych; powinniśmy go raczej traktować jak potężne narzędzie, które pomoże udoskonalić proces kontroli. AI może na przykład automatyzować powtarzalne zadania, podczas gdy testerzy manualni skupią się na strategiach testowania na wyższym poziomie, doświadczeń użytkownika i kreatywnym rozwiązywaniu problemów. To połączone podejście będzie skutkować niezawodnym i przyjaznym dla użytkownika oprogramowaniem.
Jakie prognozy dotyczące przyszłości testowania oprogramowania można wysnuć na podstawie powyższego? Możemy przypuszczać, że będzie ona opierać się na współpracy. Devin (oraz podobne narzędzia) i testerzy manualni będą pracować razem, tworząc w ten sposób bardziej wydajny produkt. Technologia sztucznej inteligencji wciąż się rozwija, a my możemy się spodziewać jeszcze większego rozszerzenia możliwości narzędzi. Nie wiemy jednak, czy nauczy się on analizować dane dotyczące zachowań użytkowników, identyfikować potencjalne problemy z użytecznością, albo czy w pewnym stopniu będą pomagać w testach UX.
Oparty na sztucznej inteligencji Devin oferuje nam ogromny zestaw funkcji, ale nie będzie w stanie odtworzyć pewnych cech testów manualnych. Na ten moment empatia człowieka i zdolność rozumienia intencji użytkownika wciąż pozostaną niezastąpione. Efektem współpracy sztucznej inteligencji i testerów może być jednak stworzenie przyszłości testowania, które będzie nie tylko wydajne i zautomatyzowane, ale także jeszcze bardziej skoncentrowane na użytkowniku, elastyczne i ostatecznie prowadzące do tworzenia wyjątkowych produktów.
