Testy alfa i testy beta: czym się różnią, kto je prowadzi i kiedy je stosować

Czas czytania: około 13 minut

Aplikacja przeszła wszystkie testy wewnętrzne, zespół jest pewny wydania, a pierwszego dnia w sklepie z aplikacjami dostaje ocenę 2,1, bo na telefonach z systemem sprzed trzech lat nie da się przejść przez ekran logowania. Nikt w firmie nie miał takiego telefonu. Testy beta istnieją dokładnie po to, żeby ten dzień zdarzył się u dwustu zaproszonych osób, a nie u dwustu tysięcy klientów, a testy alfa po to, żeby do tych dwustu osób nie trafiła wersja, która nie działa nawet w firmie.

W tym tekście wyjaśniamy, czym są testy alfa i testy beta według ISTQB, czym się różnią, gdzie mieszczą się w cyklu wydania, kto je prowadzi i kiedy je stosować, czym różni się zamknięta beta od otwartej, jak zorganizować program beta krok po kroku, jak przetwarzać opinie i jakie błędy popełniają zespoły. Piszemy dla właścicieli produktu, kierowników projektów i testerów, którzy planują wydanie produktu dla wielu użytkowników.

Czym są testy alfa?

Testy alfa to symulowane lub rzeczywiste testy operacyjne wykonywane przez potencjalnych użytkowników albo niezależny zespół w siedzibie dostawcy, ale poza zespołem wytwórczym; sprawdzają, czy produkt jest gotowy do pokazania komukolwiek z zewnątrz.

Tak definiuje je słownik ISTQB. Kluczowe są trzy elementy: testują ludzie spoza zespołu projektowego (sprzedaż, wsparcie, inny zespół, czasem zaproszeni klienci), dzieje się to u dostawcy, w środowisku, które kontroluje, i na wersji, która nie jest jeszcze dopracowana. Celem nie jest szukanie literówek, tylko sprawdzenie, czy produkt da się w ogóle użyć zgodnie z przeznaczeniem przez kogoś, kto nie budował go przez pół roku i nie zna obejść.

Testy alfa łapią to, na co zespół projektowy jest ślepy: niezrozumiały pierwszy ekran, brak przycisku „wstecz”, proces, który ma sens tylko dla osoby znającej architekturę. Zespół projektowy wie, że w polu kodu pocztowego trzeba wpisać myślnik, bo sam to napisał; tester alfa z działu sprzedaży wpisuje spację i zgłasza, że nie da się dokończyć zamówienia.

Czym są testy beta?

Testy beta to testy operacyjne wykonywane przez potencjalnych lub istniejących użytkowników w ich własnym środowisku, poza organizacją dostawcy; sprawdzają, jak produkt zachowuje się w warunkach, których nie da się odtworzyć w firmie: na cudzym sprzęcie, w cudzej sieci, przy cudzych nawykach.

Słownik ISTQB podkreśla to, co odróżnia betę od alfy: użytkownicy są prawdziwi i są u siebie. Nikt nie przygotował im środowiska, nie wgrał danych testowych, nie powiedział, jak obejść znany problem. Dlatego beta znajduje błędy konfiguracji sprzętu, sieci, wersji systemu, języka i strefy czasowej, a także problemy użyteczności, które w firmie nikt nie zgłosił, bo wszyscy przywykli.

Beta ma też drugi cel, którego alfa nie ma: informację zwrotną o wartości. Użytkownicy mówią nie tylko, co nie działa, ale czy funkcja jest w ogóle potrzebna, czy nazwa jest zrozumiała i czy zapłaciliby za to, co widzą. To ostatnia chwila, żeby coś zmienić, zanim zmiana będzie kosztować reputację. Beta, z której zespół bierze tylko zgłoszenia błędów, a wyrzuca opinie o produkcie, wykorzystuje połowę tego, za co zapłacił.

Czym różnią się testy alfa od testów beta?

Testy alfa różnią się od beta miejscem (u dostawcy kontra u użytkownika), ludźmi (pracownicy spoza zespołu kontra realni użytkownicy), środowiskiem (kontrolowane kontra naturalne), dojrzałością wersji (niedopracowana kontra bliska wydaniu), celem (czy da się użyć kontra jak działa w świecie) i skutkiem (poprawki funkcji kontra decyzja o wydaniu).

Oba są formami testów akceptacyjnych, obok testów akceptacyjnych użytkownika, produkcyjnych, zgodności z umową i z przepisami. Różnica wobec pozostałych form jest jedna: alfa i beta dotyczą produktów dla wielu klientów, gdzie nie ma jednego odbiorcy, który podpisze protokół. Pełny obraz form odbioru dajemy w tekście o testach akceptacyjnych.

Gdzie testy alfa i beta mieszczą się w cyklu wydania?

W cyklu wydania testy alfa i beta następują po testach systemowych, a przed kandydatem do wydania: kolejność to wersja rozwojowa, alfa, beta (zamknięta, potem często otwarta), kandydat do wydania i wydanie ogólne; w pracy iteracyjnej alfa i beta powtarzają się dla każdej większej wersji.

Nazewnictwo faz opisuje cykl życia wydania oprogramowania. W praktyce zespołów zwinnych alfa i beta nie są jednorazowymi wydarzeniami, tylko powtarzają się przy każdej większej wersji, a program beta bywa stały: grupa użytkowników dostaje każdą wersję tydzień lub dwa przed resztą. Tak działają kanały beta w sklepach z aplikacjami i w większości produktów dla wielu klientów.

Alfa i beta nie zastępują testów systemowych, tylko po nich następują, bo są formą testów akceptacyjnych. Beta, która znajduje dużo podstawowych błędów, to sygnał, że zawiodły wcześniejsze poziomy testów: testerzy zewnętrzni tracą wtedy czas na to, co powinien złapać zespół.

Kto przeprowadza testy alfa i beta?

Testy alfa prowadzą pracownicy spoza zespołu projektowego (sprzedaż, wsparcie, inny zespół produktowy) koordynowani przez testera, a testy beta wybrani użytkownicy zewnętrzni, rekrutowani z klientów, listy oczekujących albo społeczności, także koordynowani przez zespół QA, który projektuje program, zbiera zgłoszenia i decyduje, co z nimi zrobić.

Kiedy stosować testy alfa, a kiedy beta?

Testy alfa stosuje się zawsze przed pokazaniem produktu na zewnątrz, a testy beta wtedy, gdy produkt trafi do wielu użytkowników na różnym sprzęcie i w różnych warunkach: aplikacje mobilne, produkty z półki, gry, platformy dla klientów; w systemie na zamówienie dla jednego klienta betę zastępują testy akceptacyjne użytkownika.

Dla klienta z branży automotive i wynajmu samochodów pracowaliśmy nad aplikacją mobilną, w której efektem był wzrost satysfakcji użytkowników oraz system stabilny przy ruchu większym o 120 procent w sezonie wakacyjnym. Bez sprawdzenia aplikacji na sprzęcie i w warunkach realnych użytkowników, przed sezonem, druga z tych liczb byłaby zgadywaniem. Narzędzia do tego opisujemy w tekście o automatyzacji testów mobilnych, a testowanie aplikacji mobilnych na różnych urządzeniach w tekście Testowanie aplikacji mobilnych, część 1.

Zamknięta czy otwarta beta: co wybrać?

Zamknięta beta to zaproszona, ograniczona grupa użytkowników z kontrolą nad tym, kto testuje i co widzi; otwarta beta to dostęp dla każdego chętnego, z większą skalą, mniejszą kontrolą i publicznym ryzykiem; zwykle zaczyna się od zamkniętej, a otwartą uruchamia dopiero, gdy zamknięta przestaje znajdować nowe problemy.

Sklepy z aplikacjami mają to wbudowane: TestFlight pozwala zaprosić do 10 000 zewnętrznych testerów do programu beta aplikacji na iOS, a Google Play rozróżnia testy wewnętrzne, zamknięte i otwarte z osobnymi listami testerów. W produktach webowych tę samą rolę pełnią flagi funkcji: nowa funkcja włączona dla wybranych kont, potem dla procenta użytkowników, potem dla wszystkich.

Jak zorganizować testy beta krok po kroku?

Program beta organizuje się w sześciu krokach: cel i kryteria sukcesu, dobór i rekrutacja testerów, wersja i kanał dystrybucji, instrukcja i kanał zgłoszeń, czas trwania z punktami kontrolnymi oraz decyzja i podziękowanie; beta bez celu kończy się stertą opinii, z których nie wynika żadna decyzja.

Jak zbierać i przetwarzać opinie z testów beta?

Opinie z bety przetwarza się w trzech strumieniach: błędy trafiają do systemu zgłoszeń po weryfikacji i odsianiu duplikatów, opinie o użyteczności i wartości do właściciela produktu z oznaczeniem, ilu testerów je podziela, a dane ilościowe (awarie, ukończenia procesów, czas) do raportu wobec kryteriów sukcesu.

Zgłoszenie z programu beta, minimalny szablon

Tester:        B-042 (Android 12, telefon z 2021, sieć komórkowa)
Wersja:        2.4.0-beta3
Typ:           błąd | opinia | pomysł            -> błąd
Gdzie:         ekran logowania, po wpisaniu kodu SMS
Co się stało:  po wpisaniu kodu aplikacja wraca do ekranu numeru telefonu
Oczekiwane:    przejście do listy rezerwacji
Powtarzalność: 3 z 3 prób, tylko przy słabym zasięgu
Załącznik:     nagranie ekranu 14 s

Obróbka przez QA:
Zweryfikowane: tak, odtworzone na emulatorze z ograniczoną siecią
Duplikaty:     B-017, B-051 (razem 3 testerów, wszyscy na sieci komórkowej)
Waga:          krytyczna, blokuje logowanie
Zgłoszenie:    APP-1287, do wersji beta4

Najważniejsza w tym szablonie jest rubryka „Duplikaty”: trzech testerów z tym samym problemem na słabej sieci to nie trzy zgłoszenia, tylko jeden błąd z dowodem, że dotyczy warunków, których nikt w firmie nie ma. Jak pisać zgłoszenia, które developer odtworzy bez pytań, opisujemy w tekście Jak poprawnie zgłosić błąd. Opinie o wartości funkcji nie idą do systemu zgłoszeń, tylko do właściciela produktu, z liczbą testerów, którzy je podzielają, bo jedna głośna opinia nie jest trendem.

Jakie są zalety i wady testów alfa i beta?

Testy alfa są tanie, szybkie i kontrolowane, ale ślepe na realne warunki; testy beta pokazują prawdę o produkcie na cudzym sprzęcie i dają opinie o wartości, ale kosztują czas, wymagają organizacji i niosą ryzyko wizerunkowe; razem dają obraz, którego żadne z osobna nie daje.

Jakie są najczęstsze błędy w testach alfa i beta?

Najczęstsze błędy to alfa prowadzona przez zespół projektowy, beta bez celu i kryteriów sukcesu, testerzy dobrani przypadkowo, wersja beta bez oznaczenia i bez kanału zgłoszeń, brak poprawek w trakcie, ignorowanie opinii o wartości oraz otwarta beta zamiast zamkniętej dla produktu, który nie jest jeszcze stabilny.

1. Alfa robiona przez autorów. Zespół, który zbudował produkt, nie zobaczy, że pierwszy ekran jest niezrozumiały. Alfa wymaga ludzi spoza zespołu.
2. Beta bez celu. „Zobaczymy, co powiedzą” kończy się stertą opinii bez decyzji. Kryteria sukcesu ustala się przed rekrutacją testerów.
3. Przypadkowi testerzy. Dwustu pracowników firmy partnerskiej na tym samym sprzęcie to nie beta, tylko druga alfa.
4. Brak kanału zgłoszeń. Zgłoszenia mailem, na czacie i w komentarzach w sklepie. Połowa ginie, druga połowa nie ma urządzenia ani kroków.
5. Cisza w trakcie. Testerzy zgłaszają, nikt nie odpowiada, po dwóch tygodniach zostaje jedna piąta grupy. Poprawki w trakcie i informacja zwrotna utrzymują program.
6. Tylko błędy. Opinie o użyteczności i wartości wyrzucone, bo „to nie błąd”. To najdroższa część bety, której nie da się kupić inaczej.
7. Otwarta beta za wcześnie. Publiczna wersja z awariami dostaje recenzje jak wydanie. Otwartą betę uruchamia się, gdy zamknięta przestała znajdować nowe problemy.

Zorganizowanie alfy i bety jako części odbioru produktu, wraz z kryteriami, scenariuszami i obróbką zgłoszeń, prowadzimy w ramach testów akceptacyjnych i testów użyteczności. Kompetencje w testowaniu z użytkownikami budujemy na szkoleniu Testowanie manualne aplikacji mobilnych. Wiedzę dla liderów jakości publikujemy na portalu Strefa QA.

Powiązane na blogu Quality Island

• Testy akceptacyjne (UAT): co to jest, rodzaje, kryteria akceptacji i jak je przeprowadzić
• Testowanie aplikacji mobilnych część 1: podstawy, typy aplikacji i sposoby testowania
• Jak poprawnie zgłosić błąd: praktyczny przewodnik po raporcie, którego nikt nie odrzuci
• Poziomy testowania oprogramowania: od testów jednostkowych po akceptacyjne
• Testy wydajnościowe: co to jest, rodzaje, metryki, narzędzia i jak je przeprowadzić przed sezonem
• Typy testów oprogramowania

Pełna lista źródeł

• ISTQB Glossary, hasła alpha testing, beta testing i acceptance testing
• Wikipedia, Software release life cycle
• Apple, TestFlight, limit 10 000 zewnętrznych testerów; Google, testy wewnętrzne, zamknięte i otwarte w Google Play
• Dane własne Quality Island z projektu dla Autono (automotive i wynajem samochodów: wzrost satysfakcji użytkowników aplikacji mobilnej, stabilność przy ruchu większym o 120 procent), liczby potwierdzone przez klienta; ponad 152 zrealizowane projekty, ponad 100 firm