Umiejętności Claude Code do testów i QA: weryfikacja po 118 uruchomieniach

Każda umiejętność Claude Code obiecuje zwiększenie produktywności. W świecie testowania i zapewniania jakości (QA) ta obietnica często przekłada się na generowanie zestawów testów, audytowanie jakości czy automatyzację żmudnych sprawdzeń. Problem w tym, że większość katalogów z umiejętnościami to tylko listy nazw i obietnic. Nie mówią, czy dana umiejętność faktycznie działa.

My to robimy. W SkillProof niezależnie instalujemy i uruchamiamy każdą umiejętność w ramach realnego zadania, zanim trafi ona na listę. Następnie publikujemy werdykt i szczegółową ocenę. Nasz proces ma na celu znalezienie tego, co działa, co wymaga poprawek, a co jest fundamentalnie zepsute. Z 2172 umiejętności, które przetestowaliśmy we wszystkich kategoriach, tylko 1338 (62%) przeszło testy bezproblemowo. Kolejne 725 działa, ale wymaga ręcznej konfiguracji. A 109 umiejętności zawiodło całkowicie: albo nie dało się ich uruchomić zgodnie z dokumentacją, albo po uruchomieniu dawały gorsze wyniki niż czysty Claude bez zainstalowanej umiejętności. Publikujemy te porażki, ponieważ są równie ważne jak sukcesy.

Ten artykuł stosuje tę samą rygorystyczną, pozbawioną marketingu metodologię w odniesieniu do kategorii Testowanie i QA. Przyjrzymy się najlepszym umiejętnościom Claude Code do testowania, pokazując dokładnie, gdzie i jak przewyższają one model bazowy. Zbadamy również umiejętności, które są obiecujące, ale wadliwe, oraz kilka, które całkowicie oblały nasze testy. To nie jest teoretyczny ranking; to raport z praktyki.

Kategoria Testowanie i QA w liczbach

Kategoria Testowanie i QA na SkillProof zawiera obecnie 143 umiejętności. Z tego 25 wciąż czeka w naszej kolejce do testów. Ukończyliśmy testy dla 118 z nich. Oto podsumowanie werdyktów:

Werdykt	Liczba	Procent	Opis
Zaliczone	65	55%	Instaluje się i działa zgodnie z opisem, przewyższając model bazowy.
Działa po konfiguracji	46	39%	Dostarcza wartość, ale wymaga ręcznej pracy lub ma znane zastrzeżenia.
Niezaliczone	7	6%	Nie dało się uruchomić lub wynik był gorszy niż w modelu bazowym.

Kluczowe jest zrozumienie, jak dochodzimy do tych werdyktów i odpowiadających im ocen. Każda umiejętność jest oceniana według czterech kryteriów: bezproblemowa instalacja (/5), niezawodne wyzwalanie (/5), jakość wyniku w porównaniu z modelem bazowym (/10) oraz jakość dokumentacji (/5). Ten surowy wynik jest następnie normalizowany do ostatecznej oceny /10.

Werdykt jest osobną oceną, a nie progiem punktowym. Umiejętność otrzymuje status „Zaliczone”, jeśli od razu po instalacji daje lepsze rezultaty niż czysty Claude w odpowiednim zadaniu. Otrzymuje status „Działa po konfiguracji”, jeśli przynosi korzyści dopiero po konfiguracji, zastosowaniu umiejętności towarzyszącej lub podłączonej integracji. Jest „Niezaliczona”, jeśli jest bezużyteczna, zepsuta lub wręcz szkodliwa. Dlatego te dwie osie się rozchodzą: 371 umiejętności z werdyktem „Działa po konfiguracji” wciąż ma ocenę 8.0 lub wyższą, a najniżej oceniona zaliczona umiejętność w naszym katalogu ma 7.2. Niezaliczone umiejętności nie otrzymują oceny; bezproblemowa instalacja nie ratuje umiejętności, która awarię serwera raportuje jako sukces. Pełne szczegóły naszego procesu można przeczytać w naszej metodologii.

Najlepsi z najlepszych: umiejętności, które pokonują model bazowy

Te umiejętności uzyskały werdykt „Zaliczone”, dostarczając wymiernych ulepszeń w stosunku do modelu bazowego. Nie tylko generują kod; generują właściwy kod, wykazując zrozumienie kontekstu projektu, frameworków i dobrych praktyk. To, co odróżnia je od reszty, to zdolność do odczytywania istniejącej bazy kodu i tworzenia idiomatycznych, łatwych w utrzymaniu testów.

Umiejętności automatyzacji testów webowych i UI

W zadaniach związanych z automatyzacją przeglądarki najlepsze umiejętności zastępują kruche, sztywno zakodowane selektory i oczekiwania nowoczesnymi, odpornymi na zmiany alternatywami.

Playwright Automation Expert (9.6/10) Poproszony o napisanie testu logowania, model bazowy wygenerował skrypt z kruchymi selektorami #id i .class oraz stałymi wywołaniami waitForTimeout. Wersja z użyciem umiejętności była znacznym ulepszeniem. Użyła lokatorów opartych na rolach i asercji toHaveURL z automatycznym oczekiwaniem, które są znacznie bardziej odporne na zmiany w kodzie HTML. Obie te zmiany są jawnie wymienione jako nakazy i zakazy w treści samej umiejętności, więc postępowała ona zgodnie z własnymi zasadami, a nie miała szczęścia. Co więcej, dołączony skrypt inicjujący poprawnie utworzył obiecaną strukturę katalogów tests/, pages/ i fixtures/, od początku konfigurując nowy projekt z czystym układem Page Object Model.

Cypress Author (9.6/10) Uruchomiliśmy to samo polecenie napisania testu logowania z użyciem Cypress Author. Wynik modelu bazowego był ponownie wadliwy – zawierał sztywno zakodowany URL dla polecenia cy.visit() oraz cy.wait(2000) do obsługi operacji asynchronicznych. Po zainstalowaniu umiejętności wynik zmienił się diametralnie. Użyto względnej ścieżki wizyty w oparciu o skonfigurowany baseUrl i zastąpiono stałe oczekiwanie asercją opartą na timeout. Co kluczowe, preferowane były selektory data-cy, co świadczy o znajomości dobrych praktyk Cypress w tworzeniu stabilnych testów. Zastosowane reguły pochodziły z dołączonego przez autora pliku stylu, a nie z naszego polecenia.

Umiejętności do testów jednostkowych i integracyjnych

Stworzenie dobrej umiejętności Claude do testów jednostkowych wymaga czegoś więcej niż tylko generowania instrukcji assert. Wymaga zrozumienia frameworków, dublerów testowych i częstych pułapek.

Swift Testing (9.6/10) Poprosiliśmy o zestaw testów dla walidatora e-mail oraz dublera repozytorium. Model bazowy wygenerował działający, ale naiwny kod XCTest, w tym dublera, którego błędnie nazwał MockUserRepository. Umiejętność Swift Testing wygenerowała bardziej zaawansowany zestaw testów, używając @Suite i @Test z trzema do czterech sparametryzowanych wejść każdy, i umieściła dublera obok protokołu w bloku #if DEBUG, dokładnie tak, jak nakazuje umiejętność. Co bardziej imponujące, poprawnie zidentyfikowała rolę dublera testowego jako „spying stub” (szpiegująca zaślepka) zgodnie z taksonomią Martina Fowlera i odpowiednio zmieniła nazwę klasy, wykazując głębsze zrozumienie teorii testowania.

Flutter Tester (9.6/10) W projekcie Flutter używającym Riverpod do zarządzania stanem, test widżetu wygenerowany przez model bazowy zawierał dwa częste i poważne błędy: bezpośrednio mockował dostawcę Riverpod i nie wywoływał GetIt.reset() w metodzie tearDown. To dosłownie dwa pierwsze wiersze z tabeli „Częste błędy” w samej umiejętności Flutter Tester. Wersja z użyciem umiejętności naprawiła oba problemy bez żadnych dodatkowych wskazówek, co dowodzi wbudowanej wiedzy o pułapkach specyficznych dla tego frameworka.

Specjalistyczne umiejętności do QA i audytu

Ta grupa umiejętności Claude Code do QA wyróżnia się w celowanej, nieoczywistej analizie, którą człowiek lub mniej wyspecjalizowane narzędzie mogłoby pominąć.

Add LLM Evals (9.6/10) Gdy poproszono o dodanie potoku ewaluacyjnego do chatbota RAG, model bazowy zaproponował cztery ogólnikowe punkty dotyczące dokładności i trafności. W przeciwieństwie do tego, umiejętność Add LLM Evals dostarczyła kompletne, gotowe do uruchomienia rozwiązanie. Wymieniła specyficzne dla RAG metryki Ragas, wygenerowała gotową do uruchomienia konfigurację promptfoo do przeprowadzenia ewaluacji i dołączyła kod wyjścia dla CI, który przerywałby budowanie, gdyby metryki spadły poniżej progu. Dodała nawet kluczowy krok kalibracji oceniającego: zalecenie ręcznego oznaczenia około 30 przykładów w celu sprawdzenia zgodności przed skalowaniem ewaluacji.

Web Quality Audit (9.6/10) Skierowaliśmy tę umiejętność na stronę z kilkoma celowo umieszczonymi problemami. Zwykła analiza przez model bazowy pominęła większość z nich. Umiejętność natomiast wychwyciła subtelne problemy, takie jak brakująca deklaracja charset i ostrzeżenia o mieszanej zawartości (mixed-content). Dla każdego znaleziska podała tag file:line, co znacznie ułatwiło naprawę.

Screen Reader Testing (9.6/10) Testowanie dostępności jest notorycznie trudne do zautomatyzowania. Przetestowaliśmy tę umiejętność na oknie modalnym, które do zamykania używało przycisku z samą ikoną i nie miało roli dialog. Umiejętność nie tylko zasygnalizowała problem, ale wygenerowała dokładne atrybuty aria-label="Close" i role="dialog" potrzebne do jego naprawy. Stworzyła również konkretne skrypty testowe dla VoiceOver na macOS i NVDA na Windows, aby zweryfikować poprawkę.

Dobre, ale nie idealne: kategoria „Działa po konfiguracji”

Prawie 40% umiejętności, które testujemy w tej kategorii, wpada do tego worka. Są skuteczne, ale mają pewne zastrzeżenia. Mogą wymagać ręcznej konfiguracji, mieć znany błąd lub zawierać funkcję, która nie działa zgodnie z opisem. Mimo to umieszczamy je na liście, ponieważ ich podstawowa funkcjonalność jest wartościowa, ale dokumentujemy koszt konfiguracji.

Plugin Release Checker (9.2/10) Ta umiejętność jest przeznaczona do audytu repozytorium wtyczki przed wydaniem. W naszym teście pomyślnie wykryła wszystkie pięć defektów, które umieściliśmy w testowym repozytorium. Jednak jedno z sześciu reklamowanych sprawdzeń – walidator dla określonego pliku manifestu – po cichu degraduje się do prostego ostrzeżenia. Pełna logika walidacji znajduje się w osobnym, siostrzanym folderze umiejętności i nie jest dołączona, co odkryliśmy dopiero po przejrzeniu kodu źródłowego. Umiejętność jest nadal bardzo skuteczna, ale nie jest tak kompletnym pakietem, jak twierdzi.

Agent Verifier (Verification) (9.2/10) Użyliśmy tej umiejętności do audytu prostego pliku agent.py zawierającego dwa celowo umieszczone problemy: sztywno zakodowany klucz API do środowiska produkcyjnego i systemowy prompt, który obiecywał narzędzie, którego agent w rzeczywistości nie posiadał. Umiejętność poprawnie zidentyfikowała oba krytyczne problemy. Jednakże, oznaczyła również pętlę while True: jako potencjalną pętlę nieskończoną, wyłącznie dlatego, że brakowało w niej dosłownego słowa kluczowego break. Pętla zawierała instrukcję return, która zapewniała czyste wyjście, co czyniło to ostrzeżenie fałszywie pozytywnym. To przydatne narzędzie, które wymaga, aby człowiek interpretował jego bardziej pedantyczne znaleziska.

Porażki: umiejętności, których należy unikać

Siedem umiejętności w kategorii testowania otrzymało werdykt „Niezaliczone”. Taka ocena oznacza jedną z dwóch rzeczy: umiejętności nie dało się uruchomić zgodnie z dokumentacją, albo uruchomiła się i pogorszyła sytuację. Zgodnie z naszą polityką, nie publikujemy oceny dla tych umiejętności. Oto trzy przykłady, które ilustrują dlaczego.

API Auditor (Niezaliczona) Porażka tej umiejętności była spektakularna. Jej celem jest audytowanie punktów końcowych API pod kątem dostępności i poprawności. Skierowaliśmy jej dołączony dwunastoliniowy skrypt audytowy na usługę, która faktycznie nie działała (zwracając błąd 503 Service Unavailable) oraz na ścieżkę, która nie istniała (zwracając błąd 404 Not Found). W obu przypadkach skrypt wyświetlił Result: Success. Audytor dostępności, który błędy serwera raportuje jako sukces, jest gorszy niż brak audytora. Na domiar złego, jego własne instrukcje obiecują analizę opóźnień, której skrypt nawet nie próbuje mierzyć.

Reins (Niezaliczona) Ta porażka jest z tych bardziej frustrujących, ponieważ bazowy silnik jest naprawdę dobry. Problemem jest sposób spakowania. Zarówno plik SKILL.md, jak i dołączony skrypt instalacyjny, nakazują instalację globalnego pakietu npm pod nazwą, która nie istnieje w rejestrze, więc udokumentowana instalacja kończy się błędem E404. Dostarczony wrapper hooka szuka następnie pakietu w tej samej nieistniejącej ścieżce. Prawdziwa nazwa pakietu różni się o kilka znaków i można ją znaleźć tylko otwierając plik package.json z repozytorium. Umiejętność, której nie da się zainstalować, postępując zgodnie z jej własnymi instrukcjami, nie zdaje naszego testu, bez względu na to, jak dobry jest jej kod.

Common AppSec Patterns (Niezaliczona) Ta umiejętność to czysty orkiestrator. Jej jedyną funkcją jest wywoływanie pięciu różnych pod-agentów, które mają przeprowadzać testy bezpieczeństwa. Problem w tym, że ci pod-agenci nie są dostarczani razem z umiejętnością. Po samodzielnej instalacji jest ona całkowicie bezużyteczna. To pusta powłoka, która nic nie robi – ewidentna porażka w kwestii pakowania i dokumentacji.

Co odróżnia dobre umiejętności QA od złych?

Wzorzec jest jasny. Najlepsze umiejętności automatyzacji testów Claude Code to nie tylko sprytne łańcuchy promptów. Ich wartość pochodzi ze świadomości kontekstu. Odczytują zależności projektu, zauważają już używane frameworki, przyjmują istniejące konwencje, takie jak atrybuty data-cy i skonfigurowany baseUrl, oraz stosują ugruntowaną teorię testowania, taką jak taksonomia dublerów testowych. Pokonują model bazowy nie dlatego, że są inteligentniejsze, ale dlatego, że są lepiej oczytane.

Porażki, z drugiej strony, są zazwyczaj wynikiem błędów w pakowaniu i braku uczciwości, a nie inteligencji. Skrypt, który nieczynny serwer raportuje jako sukces, polecenie instalacji wskazujące na nieopublikowany pakiet, orkiestrator dostarczony bez agentów, którymi ma zarządzać: żadne z nich nie są subtelnymi błędami w rozumowaniu. To rzeczy, których nikt nie sprawdził, uruchamiając je. Dlatego wierzymy, że wykonanie w realnym środowisku to jedyny sposób na wydanie miarodajnego werdyktu, i jest to lekcja, która dotyczy wszystkich kategorii.

Powiązane artykuły: Dlaczego połowa umiejętności Claude nie działa analizuje powyższe tryby awarii w całym katalogu, a Jak testujemy umiejętności Claude dokumentuje dokładne porównanie z modelem bazowym, z którego pochodzi każdy werdykt na tej stronie.

Aby zobaczyć pełną, aktualną listę 143 umiejętności w tej kategorii, w tym te, które wciąż są w naszej kolejce, odwiedź katalog Testowanie i QA. Jeśli wolisz nie składać stosu samodzielnie, sprzedajemy również osiem tematycznych pakietów po dziesięć umiejętności w cenie 10 USD za każdy — Pakiet Bezpieczeństwo i Przegląd Kodu to ten zbudowany wokół przeglądu i testowania tego, co dostarczasz.