QA Studio jest rozwiązaniem referencyjnym zbudowanym z użyciem Amazon Nova Act. Część pierwsza wprowadziła definiowanie testów w języku naturalnym oraz wizualną nawigację wspomaganą przez sztuczną inteligencję. Część druga dodała zestawy testów i interfejs wiersza poleceń do wsadowego wykonywania testów regresyjnych w potokach CI/CD. Część trzecia koncentruje się na warstwie organizacyjnej i operacyjnej: grupowaniu testów, obserwowaniu wyników oraz ustalaniu, kto może oglądać i modyfikować poszczególne zasoby.

Aplikacja wyznacza granicę testowanego systemu

W QA Studio aplikacja reprezentuje system poddawany testom. Jest również kontenerem i granicą własności dla należących do niego przypadków użycia oraz zestawów testów. Powiązane testy otrzymują w ten sposób wspólny kontekst, a ich organizacja, raportowanie i reguły dostępu zostają przypisane do jednoznacznego właściciela.

Utworzenie aplikacji wymaga podania nazwy i bazowego adresu URL. Opcjonalnie można zdefiniować zestaw środowisk, takich jak środowisko deweloperskie, stagingowe i produkcyjne. Wyniki wykonań mogą dzięki temu pozostać częścią jednej aplikacji, a jednocześnie być rozróżniane według miejsca uruchomienia.

Wyniki wykonań tworzą obraz kondycji aplikacji

QA Studio zapisuje rezultat każdego wykonania jako niestandardową metrykę Amazon CloudWatch. Metryki są wymiarowane według aplikacji i środowiska, a rozwiązanie wykorzystuje je do budowania widoku kondycji aplikacji. Pojedynczy rezultat staje się zatem elementem szerszego obrazu przypisanego do konkretnego systemu i środowiska.

Strona aplikacji pokazuje współczynnik zaliczeń dla wybranego przedziału czasu, całkowitą liczbę wykonań oraz bieżącą liczbę niepowodzeń. Prezentuje także wynik kondycji w skali od 0 do 100. Jest on obliczany na podstawie współczynnika zaliczeń i uwzględnia karę za niestabilne testy. Podsumowanie odzwierciedla więc zarówno ogólną skuteczność, jak i zmienność rezultatów.

Karta metryk oferuje dwa zakresy czasu o różnej szczegółowości. Widok siedmiodniowy ma rozdzielczość godzinową, natomiast widok trzydziestodniowy – dzienną. Wykresy obejmują wykonania, sukcesy, niepowodzenia oraz średni czas trwania. Filtr środowiska pozwala analizować te miary w wybranym kontekście aplikacji.

Niestabilne testy i niedawne niepowodzenia

Osobny widok niestabilnych testów porządkuje przypadki użycia według przejść między wynikiem pozytywnym i negatywnym w ciągu poprzednich siedmiu dni. Kieruje to uwagę na testy, których rezultaty się zmieniają. Widok niedawnych niepowodzeń zawiera natomiast wpisy prowadzące do dzienników trajektorii Amazon Nova Act oraz nagrań sesji, łącząc podsumowanie z materiałami dotyczącymi konkretnego nieudanego wykonania.

Zespoły określają własność i widoczność

Dostęp w QA Studio jest zorganizowany wokół zespołów. Każda aplikacja należy dokładnie do jednego zespołu, a jego członkowie pracują z nią zgodnie ze swoimi rolami. Pozostali użytkownicy nie widzą aplikacji, chyba że właściciel udostępni im dostęp. Własność jest więc zarówno domyślną granicą widoczności, jak i podstawą zarządzania pracą.

QA Studio definiuje pięć kumulatywnych ról. Admin ma dostęp do całego studia. Team Lead zarządza członkami zespołu i tworzy aplikacje zespołowe. Editor tworzy i edytuje przypadki użycia oraz zestawy testów. Executor może je uruchamiać, ale nie może ich modyfikować. Viewer ma dostęp tylko do odczytu. Kumulatywność oznacza, że każda wyższa rola obejmuje zakres ról znajdujących się niżej.

Zespół będący właścicielem może udostępnić aplikację innemu zespołowi na jednym z trzech poziomów: podglądu, wykonywania lub pełnego dostępu. Efektywne uprawnienie jest niższym z dwóch poziomów: własnej roli odbiorcy i dostępu przyznanego w udostępnieniu. Odbiorca nie może więc dzięki udostępnieniu przekroczyć możliwości swojej roli, a szeroka rola nie omija ograniczenia wybranego przez właściciela aplikacji.

Model rozdziela dwa zagadnienia. Udostępnienie określa zakres oferowany przez zespół właścicielski, natomiast rola określa dozwolone działania konkretnego odbiorcy. Zasada wyboru niższego poziomu zachowuje obie granice.

Egzekwowanie dostępu i granice danych

Implementacja mapuje każdy zespół na grupy Amazon Cognito odpowiadające jego rolom. Amazon DynamoDB przechowuje zespoły, członkostwa, własność aplikacji i przyznane udostępnienia. AWS Lambda oraz Amazon API Gateway egzekwują zakres roli i kontrole dostępu do zasobów. Widoczny model zespołów i ról jest zatem powiązany ze sprawdzaniem zarówno uprawnień użytkownika, jak i żądanego zasobu.

Aplikacje, metryki i zespołowa kontrola dostępu są częścią rozwiązania referencyjnego QA Studio. Jest ono wdrażane za pomocą AWS CDK na koncie AWS użytkownika. Dane testowe, wyniki i metryki pozostają w granicach tego konta, co określa operacyjne ramy wdrożenia.

Część trzecia rozszerza więc QA Studio poza definiowanie testów i wsadowe uruchamianie regresji. Aplikacje zapewniają granicę organizacji i własności, metryki CloudWatch przekształcają wykonania w trendy i ocenę kondycji, a zespoły, role oraz reguły udostępniania określają widoczność i dozwolone działania. Elementy te uzupełniają funkcje przedstawione wcześniej: testy w języku naturalnym, wizualną nawigację, zestawy testów i interfejs CLI przeznaczony do procesów CI/CD.