Testy akceptacyjne to etap, którego nie da się pominąć w procesie wytwarzania oprogramowania. Dzieje się tak, ponieważ dotyczą one odbioru aplikacji, a ta zawsze jest dla kogoś wytwarzana i ten ktoś odebrać ją musi. Odbiorcą może być klient, który zamówił oprogramowanie, Product Owner w naszej firmie, gdy projekt dotyczy stworzenia wewnętrznej aplikacji.
O ile zdarza się pominąć w specjalnych warunkach pewne poziomy testów, co nie jest idealnym rozwiązaniem i niesie za sobą konsekwencje tych działań, o tyle tego etapu nie da się przeskoczyć.
Kiedy wykonywane są testy akceptacyjne?
Moment wykonywania testów akceptacyjnych zależy od modelu wytwarzania oprogramowania. Zapisów w kontrakcie. Wymogów prawnych związanych z branżą, dla której tworzymy aplikację.
W Scrum testy akceptacyjne wykonywane są bardzo często, przeważnie na zakończenie Sprintu. Testy akceptacyjne zazębiają się wówczas z rozpoczęciem prac nad nowym Sprintem. Wygląda to w następujący sposób:
Zespół developerski pracuje nad Sprintem 2.
Klienci testują aplikacje dostarczoną w Sprint 1.
Oczywiście jak zespół zakończy prace w ramach Sprintu 2, to zaczyna zajmować się materiałem ze Sprintu 3, a klient testuje materiał ze Sprintu 2.
W przypadku modelu Kaskadowego testy akceptacyjne zaplanowane są w harmonogramie. Odpowiedzią na, to kiedy wykonywane są testy akceptacyjne, jest zapis w kontrakcie informujący o tym, kiedy mamy oddać do testów naszemu klientowi aplikację.
Co do tego wszystkiego mają wymogi prawne?
Niektóre branże, w których tworzymy aplikacje, wymagają szczególnej uwagi, ponieważ mają większą odpowiedzialność niż inne. Przykładem może być aplikacja z branży medycznej kontra sklep internetowy z ubraniami.
Pewnie sami się domyślacie, że w wypadku aplikacji z branży medycznej możemy być zmuszeni do zwiększonej czujności oraz prawo może wymuszać na nas pewne działania. Jakie? Nie wiem, nie pracowałem przy wytwarzaniu aplikacji z tej branży, ale domyślam się, że są. 🙂
Co jest celem podczas wykonywania testów akceptacyjnych?
Skoro już wiemy, kiedy to teraz warto zadać sobie pytanie, po co nam te testy?
Testy akceptacyjne nie mają znaleźć nam błędów w aplikacji, przynajmniej nie jest to ich celem. Chociaż oczywiście podczas takich testów możemy natknąć się na takie błędy. Znalezienie dużej ilości błędów podczas testów akceptacyjnych może świadczyć, że coś jest nie tak z naszą aplikacją i może wiązać się z ryzykiem dotyczącym oddania takiej aplikacji użytkownikom. W końcu pierwsze dobre wrażenie możemy zrobić tylko raz.
Głównymi celami testów akceptacyjnych jest potwierdzenie, że nasza aplikacja na pewno jest zgodna z dokumentacją. Czy nie brakuje jakichś funkcjonalności? Czy procesy biznesowe przechodzą w prawidłowy sposób? Dzięki tym testom budujemy zaufanie wśród odbiorców.
Kto wykonuje testy akceptacyjne?
Często spotykałem się z tym że wykonawcami testów akceptacyjnych był właśnie biznes po stronie klienta. Teraz zapewne część z was się zastanawia dlaczego? Przecież to tester jest od testowania! W tym przypadku nie do końca, ponieważ testerowi może czasami brakować pewnej wiedzy branżowej/biznesowej, którą zwyczajnie osoby na co dzień pracujące z finalnym klientem mogą znać.
To były testy akceptacyjne wykonywane przez użytkownika.
Kolejnym elementem sprawdzenia naszej aplikacji jest weryfikacja wykonywana przez administratorów naszej aplikacji. Weryfikują oni wszelkiego rodzaju problemy/zdarzenia środowiskowe.
- Czy możemy je w prosty sposób naprawić?
- Czy możemy zarządzać/zaktualizować wersję oprogramowania?
- Sprawdzamy możliwość tworzenia wersji zapasowych oraz przywracania ich.
- Sprawdzenie trybu maintenance.
- Weryfikacja zarządzania użytkownikami np. dodawanie nowych.
- Wykonanie testów zabezpieczeń oraz testów wydajności.
Nazywamy to Produkcyjnymi testami akceptacyjnymi.
Kolejnym aspektem, który bierzemy pod uwagę przy testach akceptacyjnych, jest prawo, które wymusza działanie naszej aplikacji w konkretny sposób. Pod tym względem często zleca się takie testy poza organizację do zewnętrznego audytu, który ma dam nać informację, że nasza aplikacja spełnia wymagania prawne zawarte w różnego rodzaju ustawach, rozporządzeniach prawnych itp.
Kiedy wykonuje się takie testy?
Staramy się, żeby wersja aplikacji możliwie była finalna. Nie chcemy w niej błędów, które będą wymuszały na nas poprawki. Dodatkowo nasze środowisko testowe, na którym będą wykonywane te testy, powinno być możliwie jak najbardziej podobne do warunków finalnych, które będą występowały na co dzień u końcowego użytkownika.
Testy alfa i beta
Ostatnim elementem dotyczącym testów akceptacyjnych, o którym warto wspomnieć, są testy alfa oraz beta.
Trochę definicji:
testowanie alfa: Symulowane lub rzeczywiste testy produkcyjne przeprowadzane przez potencjalnych użytkowników lub niezależny zespól testowy, przeprowadzane u producenta, ale bez udziału wytwórców oprogramowania. Testowanie alfa jest często wykorzystywane jako forma wewnętrznych testów akceptacyjnych dla oprogramowania z półki.
[Słownik wyrażeń związanych z testowaniem, wersja 2.0]
testowanie beta: Produkcyjne testowanie przez potencjalnego i / lub istniejącego użytkownika / klienta w zewnętrznym miejscu niezwiązanym z programistami/twórcami – poza organizacją wytwórczą, w celu podjęcia decyzji, czy moduł albo system zaspokaja potrzeby użytkownika / klienta i współgra z procesami biznesowymi. Testowanie beta często jest traktowane jako forma zewnętrznych testów akceptacyjnych oprogramowania “z półki”, w celu uzyskania informacji zwrotnej z rynku.
[Słownik wyrażeń związanych z testowaniem, wersja 2.0]
Co dają nam testy alfa i beta? Najprościej jest powiedzieć, że te testy w sposób prosty dają nam potwierdzenie, że nasza aplikacja działa poprawnie i zachęca finalnych użytkowników do korzystania z niej. W ten sposób budujemy zaufanie względem stworzonej aplikacji. Kolejną korzyścią jest weryfikacja na realnych urządzeniach, które będą w finalnej wersji aplikacji używane na co dzień w miejscu pracy. Sprawdzamy, czy nie występują na nich jakieś błędy związane z tymi konkretnymi urządzeniami. Testy alfa i beta pozwalają nam na zdobycie feedbacku z pierwszej „linii frontu” na temat naszej aplikacji. Wszystko to po to by aplikacja spełniała wymagania użytkownika, co za tym idzie, była przez niego używana i być może polecana.
