Dobry beta tester to prawdziwy skarb i wie o tym każda firma czy zespół, który po długich poszukiwaniach taką osobę znalazł. Niestety, zwykle ta pozycja jest nieobsadzona albo obsadzona niewłaściwymi ludźmi, którzy sieją zamęt. Dość powszechny jest pogląd, że betatesterzy to zbytek luksusu – ich pracę mogą wykonywać członkowie zespołu rozwojowego danej aplikacji.

Jaki więc powinien być dobry beta tester?

Powinien być członkiem zespołu deweloperskiego

Niekoniecznie. Właściwie, w większości przypadków, lepiej kiedy nie bierze udziału w rozwoju aplikacji. Choć wydaje się, że powinno być inaczej, to autorzy aplikacji są zwykle najgorszymi beta testerami. Oni po prostu znają ją na wskroś i przeglądając aplikację, poruszają się po ściśle określonych ścieżkach – generują nadzwyczaj mało przypadkowych kliknięć. Jako autorzy, doskonale wiedzą gdzie należy kliknąć by osiągnąć właściwy wynik.

Powinien być techniczny

Niekoniecznie. Pogląd ten bierze się z tego, że osoba techniczna szybciej i jaśniej wytłumaczy problem niż nietechniczna. I owszem, często to prawda. Równie często osoba techniczna stosuje skróty myślowe bądź pomija błędy, które w jej ocenie są “oczywiste i na pewno koledzy już nad nimi pracują”. Użytkownicy Waszej aplikacji nie muszą (zwykle: nie są) techniczni.

Powinien być ciekawski

Oglądaliście Dexter’s Laboratory? Pamiętacie sceny z DeeDee, głupiutką siostrą Dextera, która niszczyła piękny sen Dextera tekstem “Oohh, what does this button do?”. Mniejsza o to, dlaczego przycisk autodestrukcji był zawsze niechroniony i ściagający wzrok – Wasze aplikacje są lepsze, ale również nie pozbawione takich przycisków. Wy wiecie czego nie klikać a wasz idealny betatester właśnie to kliknie. I o to tu chodzi.

Powinien mieć dużo czasu wolnego

Koniecznie. Nie macie czasu? Zapomnijcie o beta testowaniu czegokolwiek. Powszechny błąd to myślenie, że “mogę się przeklikać przez tą aplikację w 15 minut”. “Przeklikać się” przez aplikację może każdy z nas, z różnymi efektami – nie o to tu chodzi. “Przeklikanie” to dopiero początek – trzeba jeszcze przekazać tę informację do zespołu i zrobić to w zrozumiały sposób. Tu zwykle okazuje się, że ochoczy beta bester “z tłumu” nie ma na to czasu albo mu się nie chce: “przecież to widać”.

Powinien… dobrze pisać

To absolutna podstawa. 37signals w Getting Real; stwierdzają “Zatrudnij dobrze piszących (Hire good writers)” i mają rację.

Dobry beta tester pisze bardzo dużo i bardzo dobrze. Raport od dobrego betatestera jest zwięzły, rzeczowy i zawiera między innymi:

  • informacje o środowisku w jakim testował,
  • informacje o napotkanych problemach,
  • ścieżkę “krok po kroku” co zostało kliknięte, jakiego efektu się spodziewał, jaki efekt otrzymał

Pracując jeszcze przy grach komputerowych, spotkałem się z poglądem osoby, która rekrutowała betatesterów, że wybiera tylko tych, którzy potrafią się dobrze komunikować. Mogą nie mieć doświadczenia, mogą być kompletnymi laikami w sprawach którymi przyjdzie im się bawić ale nie mają najmniejszego problemu w przekazywaniu informacji. Pamiętaj, że błąd w aplikacji, nad którą zespół pracował wiele dni jest już wystarczająco stresującą sytuacją – oszczędź im kolejnych stresów związanych z próbą zrozumienia twojego zgłoszenia.

Może być twoim przełożonym

Lepiej nie. W zespołach w których nie chce się zatrudniać testerów, rolę tę przejmują przełożeni. I zwykle, jest to początek końca. Nikt nie lubi błędów a już w szczególności nie lubią ich ludzie, którzy muszą się ładnie uśmiechać do klientów/zarządu. Jeśli więc przytrafi się wam błąd, możecie być pewni, że jego znaczenie zostanie wyolbrzymione a wasze umiejętności podważone. Drugim słabym punktem jest brak czasu. Feedback przyjdzie skrótowy, enigmatyczny i z poślizgiem. Albo z informacją, że błędy są “widoczne na pierwszy rzut oka”.

Podsumowując

Błędy zdarzają się wszędzie – nie widziałem jeszcze aplikacji, która byłaby ich pozbawiona. Przyczyn tego stanu rzeczy są setki: brak czasu, brak narzędzi, brak doświadczenia, złe założenia, zmiany koncepcji w trakcie trwania prac nad kodem i tak dalej. Serio, błędy były, są i będą. Możesz jednak uniknąć części problemów, zatrudniając dobrych beta testerów. Jeśli nie stać cię na nich – możesz nimi uczynić swoich użytkowników. Z oczywistych względów, zadziała to tylko w przypadku określonego typu aplikacji.

A jeśli chcesz zostać beta testerem albo chcesz wiedzieć więcej, jak najlepiej zgłaszać błędy, poczytaj – stary już – tekst: jak efektywnie zgłaszać błędy.

Powiązane wpisy:

  1. [Opera] Beta 3
  2. Chcesz zostać webdeveloperem?
  3. Ścieżkami porażek: róbcie podobnie, my nie mamy czasu
  4. Opera 8 beta
  5. Opera Beta 2 dla MS Windows