Pisanie przypadków testowych przyjęcia

Integrujemy proces testowania z naszym procesem SCRUM. Moją nową rolą jest pisanie testów akceptacyjnych naszych aplikacji internetowych, aby zautomatyzować je później. Dużo czytałem o tym, jak należy pisać przypadki testowe, ale żaden nie dał mi praktycznych porad, jak napisać przypadki testowe dla złożonych aplikacji internetowych, a zamiast tego rzucił sprzeczne zasady, które trudno mi zastosować:

• Przypadki testowe powinny być krótkie: weź przykład CMS. Krótkie przypadki testowe są łatwe w utrzymaniu i pozwalają zidentyfikować dane wejściowe i wyjściowe. Ale co jeśli chcę przetestować długą serię operacji (np. Dodawanie dokumentu, wysyłanie powiadomienia do innego użytkownika, inny użytkownik odpowiada, dokument zmienia stan, użytkownik otrzymuje powiadomienie). Wydaje mi się raczej, że przypadki testowe powinny reprezentować kompletne scenariusze. Ale widzę, jak to da jawnie złożone dokumenty testowe.

• Testy powinny identyfikować dane wejściowe i wyjściowe:: Co jeśli mam długą formę z wieloma interaktywnymi polami i różnymi zachowaniami. Czy piszę jeden test na wszystko, czy jeden na każdy?

• Przypadki testowe powinny być niezależne: Ale jak mogę to zastosować, jeśli testowanie operacji przesyłania wymaga pomyślnego połączenia? A jak to się ma do pisania przypadków testowych? Czy powinienem napisać test dla każdej operacji, ale każdy test deklaruje swoje zależności, czy powinienem przepisać cały scenariusz dla każdego testu?

• Przypadki testowe powinny być lekko udokumentowane: zasady te są specyficzne dla projektów Agile. Czy masz jakieś porady, jak wdrożyć tę zasadę?

Chociaż myślałem, że pisanie przypadków testów akceptacyjnych będzie proste, czułem się przytłoczony każdą decyzją, którą musiałem podjąć (FYI: Jestem programistą, a nie profesjonalnym testerem). Więc moje główne pytanie brzmi: jakie kroki lub porady masz, aby napisać możliwe do utrzymania przypadki testów akceptacji złożonych aplikacji. Dziękuję Ci.

Edycja : Aby wyjaśnić moje pytanie: Zdaję sobie sprawę, że testy akceptacyjne powinny zaczynać się od wymagania i traktować całą aplikację jako czarną skrzynkę. Moje pytanie dotyczy praktycznych kroków do napisania dokumentu testowego, zidentyfikowania przypadków testowych, radzenia sobie z zależnościami między testami ... dla złożonych aplikacji internetowych

W moich pakietach akceptacyjnych unikałem używania specyficznych dla technologii kontrolek, tj. W aplikacjach internetowych nie używaj css nie używaj elementów HTML, jeśli musisz wypełnić formularz, wykonaj czynności opisane w krokach, aby skonfigurować SUT, a nie rzeczywiste testy akceptacyjne

Używam ogórka dla mojej akceptacji i mam następujące

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

ten przykład powrócił przez aplikację internetową, ale nadal mogę użyć testu do przetestowania aplikacji komputerowej, ponieważ kroki służą do skonfigurowania SUT, a nie testów akceptacyjnych

test ten kończy się na koniec zakupu, który idzie

Generuj -> Potwierdź -> Płatność -> Wydrukuj pokwitowanie

powyższy test dotyczy kroku płatności, pozostałe kroki są konfigurowane w innych testach, ponieważ aplikacja jest w stanie ustawić się w tych stanach za pomocą działań danych lub http. W tym przypadku płatność ma dane, które wykonują kroki potwierdzenia, a potwierdzenie robi generuj kroki, aby były nieco kruche w jednej chwili

Najpierw musisz zdefiniować testy akceptacyjne .

To, co wydaje się opisywać, to integracja lub testowanie systemu .

Chociaż nie zgadzam się w 100% z definicjami na Wikipedii, nadal są one w dużej mierze aktualne.

Zasadniczo celem testów akceptacyjnych jest sprawdzenie, czy procesy „biznesowe”, które korzystają z oprogramowania, które zbudowałeś, faktycznie działają zgodnie z przeznaczeniem i są odpowiednie do określonego celu - z rzeczywistymi danymi. W związku z tym nie budujesz przypadków testowych, takich jak testy jednostkowe lub inne. To nie powinno być zaprojektowane w ten sam sposób.

Pytanie, które należy zadać, brzmi „w jaki sposób używany jest system?”. Przetestujmy więc, jak ma być używany. Oczywiście teraz ponownie zakładasz kapelusz inżynieryjny i religijnie przechodzisz przez wymagania biznesowe, aby uzyskać swoje przypadki testowe. Zakłada się, że masz dobrze napisane wymagania biznesowe.

Jeśli tego nie zrobisz, nie jest za późno, musisz usiąść z użytkownikiem (użytkownikami) lub ich przedstawicielami (oraz analitykiem biznesowym i osobą odpowiedzialną za projektowanie techniczne) i zapisać, czego oczekują od oprogramowania w zakresie warunków biznesowych ( z oczywistym zastrzeżeniem, że jest to za mało za późno, ale lepiej zacząć od późna niż nigdy - i oczywiście nie wprowadzać nowych funkcji). Takie będą twoje przypadki testowe.

Innym sposobem obejścia tego problemu (ponownie, jeśli masz taki dokument), jest przejrzenie instrukcji obsługi. Chociaż jest to jeden krok usunięty z rzeczywistych wymagań biznesowych, więc można go użyć tylko wtedy, gdy wszystko inne zawiedzie.

Kiedy kupujesz samochód, zazwyczaj nie wchodzisz bardzo głęboko pod maskę (chyba że jesteś mechanikiem samochodowym). Po prostu siedzisz za kierownicą i sprawdzasz komfort, użyteczność, wygląd, dźwięki ... tj. Ogólne rzeczy. Ogólnie ufasz, że jeśli samochód musiał być w pierwszej kolejności (przynajmniej w przypadku nowego samochodu), jest ogólnie bezpieczny i dobrze zbudowany (istnieje gwarancja, wykonałeś prace domowe i sprawdziłeś specyfikację ...) Sprawdź teraz, czy to samochód, którym będziesz chciał jeździć przez kilka następnych lat.

To samo z oprogramowaniem.

Sprzeczne informacje mogą być frustrujące i trudne do uogólnienia i zastosowania w konkretnej sytuacji. Ergo, być może będziesz musiał zrobić to, co działa najlepiej w twoim kontekście.

Nie jestem wielkim fanem długich dokumentów testowych i dość skutecznie korzystałem z wizualizacji w kilku mniejszych projektach. Spróbuj tego? Jak schemat blokowy (lub jakikolwiek inny diagram UML, taki jak diagram stanu itp.) Zamiast używania samego tekstu? Wskaż dane wejściowe, wyjściowe, warunki, pętle, linie, stany, interakcje z innymi komponentami itp., A następnie wskaż, czy są one udane, nieudane, przeniesione, inne (?) W oparciu o twoje kryteria.

Na początku może być trochę pracy, ale na dłuższą metę może pomóc ci zachować rozsądek. Niezależnie od wybranej metody, im więcej z nią będziesz pracować, tym lepiej ją uzyskasz.

HTH i powodzenia!

KM

Myślę, że już ustaliłeś kilka dobrych kryteriów. Drugi punkt to dobry sposób na zdefiniowanie zakresów testów. Sugeruję także testowanie pod kątem błędów i bufix (zalecam, aby każda poprawka zawierała co najmniej jeden nowy test jednostkowy). To może wydawać się teraz przytłaczające, ale po prostu zanurz się, a po zdobyciu odrobiny doświadczenia rozpoznanie, co czyni dobre testy, stanie się łatwiejsze.