Zyski:
- Możliwość rozróżnienia, gdzie sztuczna inteligencja oszczędza czas rzeczywisty w procesie kontroli jakości, a gdzie decyzje dotyczące jakości, takie jak „gotowe do publikacji”, pozostawia się ludziom, w zależności od poziomu ryzyka zadania
- Umiejętność rozpoznawania ryzyka fałszywych przejść i wdrożenia dyscypliny weryfikacyjnej, która testuje każdy test AI poprzez celowe łamanie kodu
- Umiejętność ochrony danych testowych, danych osobowych i kluczy oraz nabycie nawyku przeprowadzania testów bezpieczeństwa wyłącznie w ramach autoryzacji i w celach obronnych.
Rozważ wieczór premierowy. Przeprowadzono setki testów, wszystkie dostały zielone światło, zespół odetchnął z ulgą i oprogramowanie zostało uruchomione. Następnego ranka klient zgłosił, że ekran płatności uległ awarii. Testy były zielone, ale nie zauważył błędu. To najbardziej podstępny koszmar zawodu zapewnienia jakości (QA), czyli dyscypliny, która systematycznie dba o to, aby oprogramowanie było odpowiedniej jakości: test, który świeci na zielono, ale tak naprawdę niczego nie potwierdza. Kiedy sztuczna inteligencja (AI — oprogramowanie wydobywające wzorce z danych historycznych oraz generujące tekst i kod) wkracza do tego zawodu, następuje zarówno ogromne przyspieszenie, jak i powiększenie dokładnie tego koszmaru. Początkowe założenia tego modułu są jasne: sztuczna inteligencja to asystent testowania, generator planów i mnożnik pomysłów; Jesteś testerem, który podpisuje decyzję „czy to oprogramowanie jest gotowe do wydania”.
W tej pierwszej części skupimy się na dyscyplinie, a nie na narzędziu. Dowiesz się, gdzie sztuczna inteligencja oszczędza czas rzeczywisty w procesie kontroli jakości, gdzie jest to niebezpieczne, dlaczego zwodnicze zielone tzw. „fałszywe przejście” stanowi największe ryzyko, jak zweryfikować każdy wynik i jakie dane możesz przekazać do jakiego narzędzia. Bez położenia tego fundamentu kolejne jednostki pozostaną w powietrzu.
Gdzie AI przydaje się w procesie testowania?
Podzielmy zadania testowe na dwa duże klastry. Grupa pierwsza: powtarzalne, możliwe do wyprodukowania prace w wersji roboczej. Tworzenie przypadku testowego na podstawie wymagania, wyświetlanie listy punktów przerwania, pisanie szkieletu kodu automatyzacji dla ekranu, tłumaczenie złożonego przypadku błędu na schludny raport o błędach, podsumowanie setek linii plików dziennika, wyodrębnianie schematu z odpowiedzi API. W tych zadaniach AI skraca minuty do sekund i nie męczy się.
Skupienie drugie: decyzje, których efektem jest jakość, zaufanie i odpowiedzialność. Decyzje takie jak „czy ta wersja może zostać uruchomiona”, „czy ten błąd jest krytyczny, czy można go przełożyć”, „czy zakres testów jest wystarczający”, „czy ten scenariusz uwzględnia rzeczywiste ryzyko użytkownika” itp. wymagają kontekstu, wiedzy o produkcie i odpowiedzialności. Tutaj sztuczna inteligencja generuje opcje, wersje robocze – ale ty decydujesz „pozytywny/nieudany” i „go/nie”.
Wyjaśnijmy to rozróżnienie w jednym zdaniu: sztuczna inteligencja jest silna w „jakich sytuacjach można przetestować i jak napisać kod, który to testuje”; Decyzja należy do Ciebie, jeśli chodzi o pytanie: „Czy to oprogramowanie naprawdę działa i kto za to gwarantuje?”
Wskazówka: zanim przekażesz zadanie sztucznej inteligencji, zapytaj: „Co się stanie, jeśli wynik będzie nieprawidłowy, a ja tego nie zauważę?” Jeśli odpowiedź brzmi: „Stracę kilka minut”, deleguj zadania z łatwością. Jeśli odpowiedź brzmi „wadliwe oprogramowanie zostanie udostępnione”, pozwól sztucznej inteligencji sporządzić wersję roboczą, a Ty podejmiesz decyzję i weryfikację.
Fałszywe podanie: ryzyko numer jeden związane ze sztuczną inteligencją w kontroli jakości
Kiedy test świeci na zielono, może to oznaczać dwie rzeczy: albo oprogramowanie rzeczywiście działa poprawnie, albo nie widzi błędu, ponieważ test został napisany niepoprawnie. Drugie podejście nazywa się fałszywym wynikiem — test mówi „pozytywny”, ale w rzeczywistości niczego nie potwierdza. Ryzyko to znacznie wzrasta w testach tworzonych przy użyciu sztucznej inteligencji, ponieważ sztuczna inteligencja bardzo skutecznie pisze płynne, gładko wyglądające, ale puste testy.
Trzy najczęstsze formy pseudo-passu to: (1) Testowanie bez asercji — kod działa, nie zawiera żadnych asercji, zawsze kończy się sukcesem. (2) Test samoweryfikujący się – wartość oczekiwana testu jest obliczana na podstawie wyniku testowanego kodu; Oznacza to, że niezależnie od tego, jaki kod wygeneruje, test uzna go za „poprawny”. (3) Test weryfikujący niewłaściwą rzecz — asercja istnieje, ale sprawdza coś trywialnego (np. „odpowiedź nie jest pusta”), a nie faktyczną regułę biznesową.
Uwaga: Zielony panel testowy nie jest dowodem jakości; W najlepszym razie jest napisane „kontrole, które napisaliśmy, nie są teraz zepsute”. Nie pocieszaj się, gdy zobaczysz „pozytywny” wynik testu przeprowadzanego przez sztuczną inteligencję — prawdziwe pytanie brzmi: czy ten test zmieni kolor na czerwony, jeśli celowo złamię kod? Jeśli się nie obraca, test ten jest ozdobą.
Złota zasada powtarzająca się w całym tym module: testuj każdy test sztucznej inteligencji, celowo łamiąc kod. Jeśli test jest nadal zielony, oznacza to, że test nie działa. (Pogłębimy ten pomysł podczas testowania mutacji w części 10.)
Dyscyplina weryfikacji: trzy kroki
AI przemawia z pewnością; To nie znaczy, że to prawda. Opracuj trzyetapowy odruch, który można zastosować do każdego wyniku:
- Powiąż to z wymaganiem. Każdy przypadek testowy i twierdzenie, które generuje sztuczna inteligencja, musi opierać się na rzeczywistym wymaganiu lub kryteriach akceptacji (warunkach, które musi spełnić zadanie, aby można było uznać je za „ukończone”). „Jaką zasadę potwierdza ten scenariusz?” zapytać.
- Wpadać we wściekłość. Uruchom wygenerowany test raz, łamiąc kod. Jeśli nie zmieni koloru na czerwony, test jest nieważny. Jest to niepodlegający negocjacjom krok w testowaniu sztucznej inteligencji.
- Przepuść go przez filtr kontekstowy. Czy wyniki odpowiadają znanemu zachowaniu produktu, architekturze i rzeczywistemu przepływowi użytkowników? Znajomość Twojej domeny jest ostatnim filtrem.
Prywatność i bezpieczeństwo danych: co i gdzie?
Dane, z którymi pracujesz w środowisku testowym, są często wrażliwe: prawdziwe dane klientów, kopie produkcyjnej bazy danych, klucze API, wewnętrzne adresy systemu, funkcje, które nie zostaną jeszcze ogłoszone. Dokonaj prostej klasyfikacji: Otwarte dane (udokumentowane, publicznie dostępne) mogą dostać się do każdego pojazdu. Dane wewnętrzne (fragmenty kodu źródłowego, dokumentacja wewnętrzna) tylko do narzędzi zatwierdzonych przez agencję. Dane poufne (prawdziwe dane klienta, informacje o tożsamości, szczegóły podatności, klucze) trafiają jedynie do zakontraktowanych narzędzi instytucji, których dane nie trafiają do szkoleń modelowych, najlepiej zamaskowanych.
Istnieje dodatkowe ograniczenie w kontekście testowania bezpieczeństwa: wszystko, czego nauczysz się w tym module, służy celom obronnym — autorytatywnemu testowaniu bezpieczeństwa własnego produktu. Używanie sztucznej inteligencji do infiltrowania cudzego systemu bez pozwolenia, wykorzystywania prawdziwych luk w zabezpieczeniach lub testowania systemu, do którego nie masz uprawnień, jest zarówno nieetyczne, jak i przestępcze. Żadne obraźliwe testy nie będą przeprowadzane bez autoryzacji (zakresu i pozwolenia).
Wskazówka: używaj syntetycznych (sztucznie wytworzonych) danych testowych zamiast prawdziwych danych klientów. Zwrócenie się do sztucznej inteligencji o „wygenerowanie realistycznych, ale całkowicie fikcyjnych danych testowych” zarówno chroni prywatność, jak i różnicuje przypadki Edge.
trzy mini etui
Przypadek 1 — Oszczędność czasu we właściwym miejscu. Tester zespołu Ekomerce spędził 6 godzin ręcznie tworząc scenariusz testowy na podstawie 30-stronicowego dokumentu wymagań dla każdego wydania. Przekazał dokument (część niezawierającą tajemnicy handlowej) YZ i poprosił o ustrukturyzowany projekt scenariusza; Czas skrócono do 90 minut. Zaoszczędzony czas poświęcił na samodzielną weryfikację, dodając przypadki brzegowe reguł biznesowych, które przeoczyła sztuczna inteligencja. Sztuczna inteligencja wyeliminowała powtarzalną pracę, pozostawiając ocenę człowiekowi.
Przypadek 2 — Przyłapano na fałszywym podaniu. Deweloper zlecił sztucznej inteligencji napisanie 12 testów jednostkowych dla funkcji obliczeniowej; wszystkie były zielone. Tester zaimplementował krok „zobacz czerwony”: celowo zmienił znak dodawania wewnątrz funkcji na mnożenie. Tylko 3 z 12 testów dało wynik czerwony. Pozostałe 9 testów nie dostarczyło prawdziwego potwierdzenia; Po prostu powiedział „nie zgłosił błędu”. Usunięto 9 testów dekoracyjnych, a zamiast nich napisano 5 testów rzeczywistych.
Przypadek 3 – Powrót po naruszeniu prywatności. Stażysta wkleił dziennik błędów zawierający e-maile prawdziwych klientów i cztery ostatnie cyfry karty z produkcyjnej bazy danych do narzędzia publicznego i powiedział „wyjaśnij ten błąd”. Lider ds. kontroli jakości interweniował: dane osobowe wymknęły się spod kontroli i stanowiły naruszenie KVKK (ustawy o ochronie danych osobowych). Tę samą pracę wykonano w pojeździe zatwierdzonym przez instytucję, maskując obszary osobiste i pozostawiając jedynie ślad stosu.
Cztery szablony do kopiowania
1) Ocena przydatności do pracy:
Twoja rola: starszy lider ds. kontroli jakości. Opiszę ci zadanie testowe. Powiedz mi (1) czy ta praca jest pracą kreślarską/analizą, którą można bezpiecznie przekazać sztucznej inteligencji, czy też decyzją dotyczącą jakości, którą musi podjąć człowiek, (2) potencjalny koszt nieprawidłowego wyniku, (3) weryfikację, którą powinienem przeprowadzić przed delegowaniem. Stanowisko: [tu wstaw pracę]
2) Kontrola pseudoprzepustowa:
Sprawdź poniższy test. Powiedz mi: - Jakie zachowanie potwierdza ten test? (jedno zdanie) - Jak mogę złamać testowany kod, aby test zmienił kolor na CZERWONY? - Czy istnieje słabość, która może spowodować, że ten test zawsze zakończy się pomyślnie (brak potwierdzenia, samosprawdzenia, trywialne sprawdzenie)? Test: [wklej test tutaj]
3) Kontrola maskowania danych testowych:
Log/dane, które Ci przekażę, mogą zawierać pola osobiste lub poufne (e-mail, imię i nazwisko, karta, klucz, adres wewnętrzny). Najpierw wypisz pola, które należy zamaskować; Zamaskuję to i wyślę ponownie. Nie analizuj tego takim, jakie jest.
4) Syntetyczne generowanie danych testowych:
Wygeneruj 20 wierszy całkowicie fikcyjnych, realistycznych danych testowych dla [następującej struktury pól]. Nie używaj danych prawdziwych osób/organizacji. Uwzględnij także przypadki Edge: pusta przestrzeń, zbyt długi tekst, wartości graniczne, nieprawidłowy format.
Słaba zachęta/silna zachęta
Słabe: „Napisz testy na tym kodzie”.
Mocne: „Oblicz to. Zapisz testy jednostkowe dla funkcji rabatu. Kryteria akceptacji dla funkcji: 10% rabatu powyżej 1000 TL, 20% rabatu powyżej 5000 TL; kwota ujemna powinna spowodować błąd. W wierszu komentarza określ, którą regułę sprawdzasz dla każdego testu. Przetestuj wartości graniczne (999, 1000, 1001, 5000, 0, -1) osobno. Użyj prawdziwych asercji, które zmienią kolor na czerwony jeśli złamię kod; pusty lub nie napiszę trywialnego potwierdzenia. ”
Potężny monit; Zawiera kryteria akceptacji, wartości graniczne, oczekiwania dotyczące walidacji i wyraźne instrukcje dotyczące zapobiegania fałszowaniu. Słaby monit zachęca sztuczną inteligencję do napisania testu dekoracyjnego.
Typowe błędy
- Ufając zieleni. Myślenie, że zdanie testu jest dowodem. Prawdziwe pytanie brzmi: czy zmienia kolor na czerwony, gdy złamiesz kod?
- Prośba o wykonanie testu bez podania przyczyny. Sztuczna inteligencja tworzy ogólne, często bezużyteczne testy, nie wiedząc, co należy zweryfikować.
- Pomijanie weryfikacji. Mówiąc: „AI to napisała, to prawdopodobnie prawda”. Odpowiedzialność spoczywa na osobie korzystającej z wyników.
- Wklejanie prawdziwych/wrażliwych danych do narzędzia. Praca z danymi produkcyjnymi, kluczami lub danymi osobowymi.
- Nieautoryzowane testy bezpieczeństwa. Próba ofensywnego testowania bez zakresu i pozwolenia.
- Wykorzystanie sztucznej inteligencji do delegowania decyzji. Zadawanie pytania „Czy ta wersja może zostać wydana?” do AI i umieszczenie odpowiedzi w podpisie.
Podsumowując
AI to potężny asystent w procesie kontroli jakości, który przyspiesza powtarzalną i produktywną pracę; Ale odpowiedzialność za decyzję dotyczącą jakości spoczywa na człowieku. Największym ryzykiem związanym ze sztuczną inteligencją w tym zawodzie jest pseudo-zaliczenie: zielone testy, które wyglądają schludnie, ale niczego nie potwierdzają. Przetestuj każdy test AI, celowo łamiąc kod; Jeśli nie zmieni koloru na czerwony, test ten jest ozdobą. Powiąż to z wymaganiem, zobacz kolor czerwony, przepuść go przez filtr kontekstowy. Maskuj poufne dane, przeprowadzaj testy bezpieczeństwa tylko w celach autoryzowanych i obronnych.
Zadanie aplikacji
Wykonaj 5 testów jednostkowych wygenerowanych przez sztuczną inteligencję (lub wygenerowanych przez sztuczną inteligencję) z własnego projektu. Dla każdego: (1) zapisz w jednym zdaniu, które zachowanie sprawdza, (2) celowo złam i uruchom testowany kod i zanotuj, ile zmienia kolor na czerwony, (3) oznacz te, które nie zmieniają koloru na czerwony, jako „testy wystroju” i przepisz je, używając prawdziwego potwierdzenia. Umieść wynik w tabeli: nazwa testu / reguła, którą zweryfikowano / czy została zepsuta po złamaniu / działanie.
lista kontrolna
- [ ] Przed oddaniem pracy zadałem pytanie „co stracę, jeśli coś pójdzie nie tak?”
- [ ] Przetestowałem każdy test AI, łamiąc kod; Zastąpiłem ten, który nie zmienił koloru na czerwony, prawdziwym testem.
- [ ] Powiązałem przypadki testowe z rzeczywistymi kryteriami wymagań/akceptacji.
- [ ] Zamaskowałem wrażliwe/prawdziwe dane bez podawania ich narzędziu; Jeśli to możliwe, użyłem danych syntetycznych.
- [ ] Rozważałem testowanie bezpieczeństwa tylko w ramach władzy i w celach obronnych.
- [ ] Decyzję „czy wersja zostanie wydana” pozostawiłem sobie, a nie sztucznej inteligencji.