softify.pro Flow — testowane przez COCO

Control. Clarity. Flow.

Każdy poważny produkt softwarowy w końcu rozwija drugi produkt za produktem.

Klienci mogą nigdy go nie zobaczyć. Odwiedzający mogą nigdy nie wiedzieć, że istnieje. Ale administratorzy, operatorzy, i deweloperzy polegają na nim każdego dnia.

Dla softify.pro Flow, tą aplikacją jest Administration — konsola operacyjna odpowiedzialna za zarządzanie użytkownikami, rolami, poziomami dostępu, stanami uwierzytelniania, środowiskami baz danych, i inną konfiguracją, która utrzymuje wdrożenie Flow pod kontrolą.

Jej ekran logowania niesie trzy słowa:
Control. Clarity. Flow.

Zostały pierwotnie wybrane, aby opisać doświadczenie, które chcieliśmy, aby mieli administratorzy podczas obsługi systemu.

Ale opisują też zaskakująco dobrze to, jak naszym zdaniem oprogramowanie powinno być testowane.

To uczyniło softify.pro Flow — Administration oczywistym kandydatem do rzeczywistego testu COCO.

Nie demonstracji laboratoryjnej.
Nie kolekcji izolowanych przycisków przygotowanych specjalnie do demo AI.
Prawdziwej wieloplatformowej aplikacji desktopowej z prawdziwą logiką aplikacji, wieloma oknami, wieloma zapleczami baz danych, uwierzytelnianiem, uprawnieniami, lokalizacją, i wystarczającym stanem, aby pozornie małe regresje były trudne do wykrycia ręcznie.

Dla publicznej demonstracji pokazanej tutaj, COCO pracowało wyłącznie z wygenerowanymi danymi demonstracyjnymi. Aplikacja była licencjonowana dla fikcyjnej firmy Presentation GmbH, i żadne produkcyjne informacje klientów, dane uwierzytelniające, ani dane osobowe nie zostały użyte.

Cel był prosty:
Pozwolić COCO podejść do aplikacji tak, jak zrobiłby to tester, i ustalić, czy kompletny przepływ pracy administracyjnej nadal zachowuje się tak, jak twierdzi oprogramowanie.

Wyzwanie

Na pierwszy rzut oka, testowanie aplikacji administracyjnej wydaje się proste.

Otwórz ją.
Zaloguj się.
Kliknij przez kilka okien.
Sprawdź, czy wszystko wygląda poprawnie.

To założenie szybko się zmienia, gdy aplikacja rośnie.

softify.pro Flow — Administration nie jest jednym statycznym formularzem. To kolekcja wzajemnie połączonych widoków operacyjnych wewnątrz jednej powłoki aplikacji.

Między innymi, administrator może pracować z:

• kontami użytkowników
• rolami i poziomami dostępu
• informacjami uwierzytelniania
• statusem uwierzytelniania dwuskładnikowego
• informacjami o systemie operacyjnym
• informacjami o sieci i IP
• konfiguracją bazy danych
• opcjami sortowania i prezentacji
• wyborem języka na żywo
• informacjami o aplikacji i licencjonowaniu

Interfejs obecnie obsługuje jedenaście języków. Aplikacja działa też z zapleczami baz danych MySQL i PostgreSQL. Indywidualnie, żadna z tych funkcji nie reprezentuje nietypowego problemu testowego.

Trudność pochodzi z ich kombinacji.
Tabela użytkowników może działać poprawnie po angielsku, ale wyświetlać przestarzałą nazwę kolumny po chorwacku.
Sortowanie może działać poprawnie połączone z MySQL, ale zachowywać się inaczej po przełączeniu na PostgreSQL.

Zmiana języka może zaktualizować większość elementów interfejsu, pozostawiając jeden komunikat statusu nieprzetłumaczony. Aplikacja może pomyślnie przełączyć bazy danych, ale zachować nieaktualne informacje z poprzedniego połączenia. Nowe wydanie może wprowadzić funkcję, podczas gdy dialog About wciąż opisuje poprzednią. Program nie musi się zawiesić, aby którakolwiek z tych sytuacji była regresją. Faktycznie, niektóre z najbardziej niewygodnych defektów oprogramowania to dokładnie te, gdzie wszystko wydaje się działać.

Aplikacja się uruchamia.
Okno się otwiera.
Przycisk odpowiada.
Ale coś pod spodem nie jest już do końca w porządku.
Dlatego powtarzalne testowanie regresyjne ma znaczenie.

I jest to też dokładnie ten rodzaj pracy, w którym ludzie stają się coraz gorsi po powtórzeniu tej samej sekwencji dziesiątki razy.

Dlaczego testowanie ręczne staje się kosztowne

Przetestowanie czegoś raz jest łatwe.
Testowanie tego niezawodnie po każdym istotnym wydaniu jest inne.

Weźmy pod uwagę tylko trzy wymiary: 11 języków interfejsu × 2 zaplecza baz danych × wiele przepływów pracy aplikacji.

Liczba kombinacji szybko rośnie.
Dodaj różne role użytkowników, stany uwierzytelniania, zachowanie sortowania, zmiany konfiguracji, i środowiska operacyjne, a macierz testowa staje się zbyt duża, aby traktować ją jako okazjonalną ręczną listę kontrolną.

Tutaj testowanie regresyjne często zaczyna się rozpadać.
Nie celowo.
Termin wydania zbliża się.
Ktoś pamięta, że aplikacja była testowana w zeszłym tygodniu.
Deweloper szybko sprawdza najważniejszy ekran.

Niemiecki działa.
Angielski działa.
MySQL działa.
Założenie staje się:
„Reszta prawdopodobnie jest w porządku."

Zwykle tak jest. Aż do wydania, w którym nie jest.
COCO istnieje częściowo, aby usunąć to założenie z procesu.

Co COCO faktycznie zrobiło

COCO uruchomiło softify.pro Flow — Administration ze stanu zimnej aplikacji, bez polegania na wcześniej przygotowanym ekranie lub ręcznie ustawionym przepływie pracy.

Pierwsza interakcja była tą samą, którą prezentuje się ludzkiemu administratorowi: oknem logowania.

COCO zidentyfikowało interfejs uwierzytelniania zawierający:

• nazwę użytkownika
• hasło
• kod uwierzytelniania dwuskładnikowego

i linię bezpośrednio pod tożsamością softify.pro Flow:
Control. Clarity. Flow.

Stamtąd, COCO kontynuowało przez zdefiniowaną sesję regresyjną. Celem nie było po prostu ustalenie, czy aplikacja może zostać otwarta.

Celem było zweryfikowanie, czy stan aplikacji pozostał wewnętrznie spójny, podczas gdy COCO wchodziło z nią w interakcję.

Uwierzytelnianie to dopiero początek

Testowanie logowania jest jednym z najbardziej oczywistych kandydatów do automatyzacji, ale samo udane uwierzytelnianie mówi nam bardzo mało o reszcie aplikacji administracyjnej.

Po wejściu, COCO przeszło do faktycznego środowiska operacyjnego. Sprawdziło interfejs administracji użytkownikami i zweryfikowało, że oczekiwane informacje były obecne.

To obejmowało dane takie jak:

• nazwy użytkowników
• zamaskowane hasła
• wskaźniki 2FA
• przypisane role
• informacje o systemie operacyjnym
• adresy IP

COCO następnie wchodziło w interakcję z tabelą, zamiast tylko ją obserwować.
Lista użytkowników została posortowana według nazwy użytkownika.
Wynikowa kolejność została sprawdzona.
Ważna część nie polegała na tym, czy kliknięcie nagłówka kolumny spowodowało jakąś widoczną zmianę.

COCO zweryfikowało, że wynikowy stan tabeli odpowiadał żądanej operacji.

Ta różnica ma znaczenie.
Test funkcjonalny pyta:
„Czy przycisk zareagował?"

Użyteczny test regresyjny pyta:
„Czy aplikacja znalazła się w poprawnym stanie?"

Testowanie granicy bazy danych

softify.pro Flow obsługuje więcej niż jedno zaplecze bazy danych.

To czyni przełączanie baz danych szczególnie ważną granicą regresyjną.
COCO zmieniło aktywne zaplecze z MySQL na PostgreSQL.

Po przełączeniu, ponownie sprawdziło informacje o użytkownikach.
Test szukał czegoś więcej niż udanego połączenia.
Sprawdził, czy aplikacja nadal prezentowała oczekiwane rekordy i czy informacje pokazane przez interfejs pozostały spójne.

COCO następnie przełączyło się z powrotem.


Ten rodzaj przejścia jest łatwy do niedocenienia.
Interfejs użytkownika może pozostać wizualnie identyczny, podczas gdy warstwa przechowywania pod nim zmienia się całkowicie.
Z perspektywy administratora, to przejście powinno wydawać się niemal nudne.
Ci sami użytkownicy powinni wciąż być zrozumiali.
Te same role powinny wciąż mieć sens.

To samo zachowanie interfejsu powinno nadal obowiązywać.

Ta pozornie bezzdarzeniowa ciągłość jest dokładnie tym, co musi zostać udowodnione.

Jedenaście języków, jeden stan aplikacji

Lokalizacja to kolejny obszar, gdzie powierzchowne testowanie jest szczególnie niebezpieczne.

Stosunkowo łatwo jest zweryfikować, że aplikacja może uruchomić się w innym języku.
Znacznie bardziej wartościowe jest zweryfikowanie, co dzieje się, gdy język zmienia się, podczas gdy aplikacja już działa i utrzymuje stan.

COCO przełączyło język interfejsu na żywo.

Sesja obejmowała przejścia między językami, takie jak:
Niemiecki → Angielski → Chorwacki
podczas gdy widok administracji pozostał aktywny.

COCO obserwowało, czy elementy interfejsu zmieniały się poprawnie na miejscu:

• nagłówki tabel
• kontrolki
• przyciski
• etykiety
• komunikaty statusu

Leżąca u podstaw tabela i stan aplikacji również musiały przetrwać to przejście.
To ma znaczenie, ponieważ wielojęzyczne oprogramowanie składa się z więcej niż przetłumaczonych ciągów znaków.
Zmiany języka mogą ujawnić:

• zapomniane zasoby
• nieaktualne etykiety
• problemy z układem
• nieprzetłumaczone komunikaty statusu
• problemy z kodowaniem
• resety stanu
• problemy z odtwarzaniem kontrolek

Okno, które wygląda poprawnie, gdy uruchomione bezpośrednio po chorwacku, może wciąż zachowywać się niepoprawnie, gdy użytkownik przełącza się z niemieckiego na chorwacki podczas aktywnej sesji.

To jest różnica między sprawdzaniem zrzutu ekranu a testowaniem przepływu pracy.

Przywracanie stanu aplikacji

COCO następnie przywróciło domyślną konfigurację sortowania aplikacji.

Ponownie, test nie zakończył się na samym kliknięciu.

Wynikowa kolejność i potwierdzenie przedstawione przez obszar statusu aplikacji zostały ocenione. Ten typ weryfikacji może wydawać się nieznaczący w porównaniu z testowaniem uwierzytelniania czy dostępu do bazy danych.

Nie jest.

Aplikacje korporacyjne gromadzą setki takich małych przejść stanu.
Użytkownicy polegają na nich, nie myśląc o nich świadomie.
Oprogramowanie wydaje się niezawodne właśnie dlatego, że te interakcje pozostają przewidywalne.
Testowanie regresyjne istnieje, aby chronić tę przewidywalność.

Testowanie informacji wokół oprogramowania

COCO otworzyło też dialog About aplikacji.

Dlaczego testować okno About?

Ponieważ dokumentacja oprogramowania zaczyna się wewnątrz samego oprogramowania.
Numer wersji, opis funkcji, i informacje licencyjne przedstawione operatorowi powinny odpowiadać aplikacji, która faktycznie działa.

Aplikacja może funkcjonować doskonale, wciąż prezentując nieaktualne informacje o wersji lub opisując możliwości, które już nie odpowiadają wydaniu.

To nie zawiesza bazy danych.
Robi coś subtelniejszego:
zmniejsza zaufanie.

Dla oprogramowania korporacyjnego, dokładność operacyjna obejmuje te pozornie małe szczegóły. COCO więc sprawdziło też je.

Control.

Pierwsze słowo w sloganie softify.pro Flow jest też pierwszą zasadą środowiska testowego.

Control oznacza wiedzę o tym, co jest testowane, przeciwko jakiemu stanowi, i z jakimi danymi.

Publiczna demonstracja COCO nie używa produkcyjnych rekordów klienta.

Działa z celowo przygotowanymi danymi demonstracyjnymi, których oczekiwany stan jest znany.

To czyni wyniki odtwarzalnymi.

Oznacza to też, że różnice między przebiegami testów mogą być badane, zamiast być wyjaśniane jako losowe zmiany w danych produkcyjnych.

Co ważniejsze, COCO jest zaprojektowane jako samodzielnie hostowany system testowania AI.

Dowody testowe, zrzuty ekranu aplikacji, i informacje o wewnętrznym przepływie pracy mogą pozostać wewnątrz infrastruktury pod własną kontrolą klienta lub operatora, zamiast być domyślnie wysyłane do niepowiązanej usługi chmurowej strony trzeciej.

Dla wewnętrznych aplikacji biznesowych, to nie jest jedynie preferencja infrastrukturalna. Może być częścią samego wymagania testowego.

Clarity.

Automatyzacja nie jest szczególnie użyteczna, jeśli jej ostatecznym wynikiem jest: FAILED
za którym następują setki linii technicznego wyniku, które ktoś musi ręcznie zrekonstruować, zanim zrozumie, co się stało.

COCO jest zaprojektowane, aby zachować zrozumiały ślad dowodowy.

Raport opisuje:

• co było testowane
• która interakcja miała miejsce
• w jakiej kolejności to się wydarzyło
• co COCO zaobserwowało
• jaki stan był oczekiwany
• gdzie zachowanie różniło się, gdy coś zawiodło

Zrzuty ekranu i dowody wykonania mogą towarzyszyć tej sekwencji.
Celem nie jest ukrywanie szczegółów technicznych.

Jest nim uczynienie wyniku zrozumiałym, zanim ktoś będzie musiał otworzyć debugger.

Inżynier powinien być w stanie odpowiedzieć:
Co się stało? zanim zapyta:
Gdzie w kodzie to się stało?

Ta różnica dramatycznie skraca dochodzenie, gdy pojawia się regresja.

Flow.

Tradycyjna automatyzacja UI często myśli w elementach.

Znajdź selektor.
Kliknij selektor.
Znajdź kolejny selektor.
Sprawdź wartość.

To podejście pozostaje użyteczne, ale aplikacje nie są doświadczane jako kolekcje selektorów.

Ludzie doświadczają przepływów.

Zaloguj się.
Otwórz administrację.
Znajdź użytkownika.
Zmień ustawienie.
Przełącz bazę danych.
Zmień język.
Zweryfikuj wynik.

Kontynuuj pracę.

COCO więc traktuje sekwencję jako proces, a nie losową kolekcję kontrolek.

Podąża za tym, co użytkownik próbuje osiągnąć, i ocenia aplikację w kontekście.

To staje się szczególnie wartościowe podczas testowania prawdziwego oprogramowania biznesowego, ponieważ awarie często występują między ekranami lub między stanami, nie wewnątrz pojedynczego przycisku.

Przepływ pracy logistycznej może zawierać zamówienie, rezerwację zapasu, operację kompletacji, dokument dostawy, i potwierdzenie wysyłki.
Każdy pojedynczy ekran może wydawać się poprawny, podczas gdy kompletny proces jest błędny.
Ta sama zasada obowiązuje tutaj w mniejszej skali.
Okno administracji nie jest produktem.

Przepływ pracy przez nie jest.

Dowód zamiast założenia

Jedną z najważniejszych prac COCO nie jest klikanie. Jest nią zapamiętywanie tego, co się stało.
Ludzkie testowanie regresyjne często kończy się stwierdzeniem takim jak:
„Przetestowałem to i wszystko wyglądało dobrze."

To może być całkowicie dokładne.
Ale kilka tygodni później, gdy pojawia się problem, użyteczne pytania są inne:

• Które wydanie było testowane?
• Która baza danych?
• Który język?
• Jaki stan użytkownika?
• Co wydarzyło się przed problemem?
• Co dokładnie było widoczne?

W jakiej kolejności wykonano akcje?
Przebiegi testowe COCO są zaprojektowane, aby pozostawić po sobie dowody.

To przekształca wynik testu z opinii w coś, co można zbadać. Udany przebieg staje się więc też użyteczny.
Ustanawia znany stan referencyjny, z którym można porównać późniejsze zachowanie.

COCO nie jest decydentem

Istnieje ważna granica w sposobie, w jaki używamy AI do testowania oprogramowania.
COCO nie ma na celu zastąpienia odpowiedzialności inżynierskiej.

Nie decyduje, jaka powinna być reguła biznesowa.

Testuje zachowanie względem scenariuszy, wymagań, i oczekiwań zdefiniowanych dla aplikacji. Dla wrażliwych decyzji dotyczących uprawnień, cen, zapasu, transakcji finansowych, lub innych krytycznych stanów biznesowych, definicja poprawnego zachowania pozostaje ludzką odpowiedzialnością.

Ta różnica ma znaczenie.
AI jest doskonałe w powtarzaniu szczegółowego testu bez utraty koncentracji. Jest doskonałe w zbieraniu dowodów.
Może sprawdzać ekrany, porównywać oczekiwane i zaobserwowane zachowanie, i wyjaśniać rozbieżności. Ale biznes wciąż definiuje, co oznacza poprawne.

COCO czyni tę definicję możliwą do przetestowania.

Test, którego nikt nie chce powtarzać

Istnieje prosty powód, dla którego automatyzacja dodaje tu wartość.
Ludzki tester może absolutnie wykonać tę sesję regresyjną.
Pierwszy język otrzymuje pełną uwagę.
Prawdopodobnie drugi też.
Potem kolejny.
Potem kolejny.
MySQL zostało już sprawdzone.
PostgreSQL wciąż wymaga sprawdzenia.
Test sortowania był już wykonywany kilka razy.
Dialog About nie zmienił się od miesięcy.

Jest piątek popołudnie.

A ludzka uwaga robi to, co ludzka uwaga naturalnie robi. Zaczyna optymalizować.
COCO tego nie robi. W duchu samego COCO:

• Nie nudzi mnie klikanie tego samego przycisku w jedenastu językach. Nie pomijam przebiegu PostgreSQL, ponieważ jest piątek popołudnie. Nie zakładam, że kolejność sortowania się utrzymała, ponieważ działała w poprzednim wydaniu.

Dla COCO, każda sesja regresyjna może być traktowana tak, jakby była pierwszą. To nie jest inteligencja zastępująca ludzkiego testera.
To automatyzacja chroniąca ludzkiego testera przed częścią testowania, gdzie ludzka uwaga jest najmniej wartościowa.

Od powtarzalnego testowania do dowodu inżynierskiego

Większym celem COCO nie jest maksymalizacja liczby zautomatyzowanych akcji.
Tysiąc zautomatyzowanych kliknięć jest bez znaczenia, jeśli nikt nie rozumie, co one dowodzą. Użytecznym rezultatem jest zaufanie wsparte dowodami.

Dla softify.pro Flow, oznacza to możliwość powiedzenia, że wydanie zostało przetestowane w obszarach operacyjnych, które mają znaczenie:

• uwierzytelnianie
• administracja użytkownikami
• role i informacje o dostępie
• stan uwierzytelniania dwuskładnikowego
• zachowanie sortowania
• działanie MySQL
• działanie PostgreSQL
• lokalizacja na żywo
• informacja zwrotna o statusie
• informacje o aplikacji
• informacje licencyjne

i że wynik jest zachowany w formie, która może być przejrzana później. Ta sama zasada skaluje się daleko poza tę aplikację.
Proces logowania może być testowany w ten sposób.
Przepływ pracy rezerwacji może być testowany w ten sposób.
Proces logistyczny może być testowany w ten sposób.
Wieloplatformowa aplikacja desktopowa może być testowana w ten sposób.
Ekrany się zmieniają.
Reguły biznesowe się zmieniają.
Zasada nie:
zdefiniuj oczekiwany przepływ pracy, wykonuj go konsekwentnie, zbieraj dowody, i uczyń wynik zrozumiałym.

Dlaczego testujemy nasze własne oprogramowanie za pomocą COCO

Istnieje inny powód, dla którego softify.pro Flow ma znaczenie jako studium przypadku COCO.

To nasze własne oprogramowanie.
To usuwa wygodny dystans, który czasem istnieje między demonstracją technologiczną a ludźmi ją demonstrującymi.

Jeśli COCO ma na celu testowanie oprogramowania korporacyjnego, musi być wystarczająco użyteczne, abyśmy mogli mu zaufać z oprogramowaniem, które faktycznie sami rozwijamy i wydajemy.

Flow działa więc zarówno jako produkt, jak i poligon doświadczalny.
Nowe możliwości testowe mogą być sprawdzane wobec prawdziwej aplikacji.
Nieoczekiwane zachowanie może ujawnić słabości w aplikacji, planie testowym, lub samym COCO.

Każda strona ulepsza drugą.
Ta pętla informacji zwrotnej jest znacznie bardziej wartościowa niż budowanie sztucznych demonstracji zaprojektowanych tylko po to, aby się udać. System testowy nie powinien wyglądać przekonująco, ponieważ demonstracja była łatwa.
Powinien stać się przekonujący, ponieważ nadal znajduje małe rzeczy, których ludzie w końcu przestaliby sprawdzać.

Wynik

softify.pro Flow — Administration ma teraz udokumentowany i powtarzalny proces regresyjny, który COCO może wykonać przed istotnymi wydaniami.

Test obejmuje oba obsługiwane środowiska baz danych i jedenastojęzyczny interfejs aplikacji, podążając za aplikacją tak, jak używałby jej administrator, zamiast traktować każdy ekran jako izolowany cel testowy.

COCO tworzy ślad dowodowy pokazujący, co było testowane, co zostało zaobserwowane, i w jakiej kolejności miała miejsce sesja.

Ten dowód może pozostać lokalnie kontrolowany.
Deweloperzy zyskują odtwarzalny punkt startowy, gdy coś się zmienia.
Ludzcy testerzy spędzają mniej czasu na powtarzaniu przewidywalnych interakcji, a więcej czasu na badaniu sytuacji, które naprawdę wymagają osądu.

A softify.pro Flow otrzymuje coś bardziej wartościowego niż zielony wskaźnik PASS.

Otrzymuje dowód, że doświadczenie obiecane na jego ekranie logowania nadal istnieje po tym, jak kod pod spodem się zmienia.

Control. Wiedz, co jest testowane, i utrzymuj środowisko pod kontrolą.

Clarity. Rozumiej, co się stało, bez rekonstruowania nieprzejrzystego dziennika automatyzacji.

Flow. Testuj aplikację jako proces, którego ludzie faktycznie używają.

Control. Clarity. Flow.

Zostało napisane dla oprogramowania.
Okazało się, że opisuje też równie dobrze filozofię testowania stojącą za nim.