2013-04-11 18 views
6

Jestem nieco zdezorientowany rzeczywistą różnicą między testowaniem systemu a testami akceptacyjnymi. Kiedy przeszukuję ten temat, odpowiedzi są różne i nie widzę, jak te testy mogą się znacznie różnić.Testowanie systemu a testy akceptacyjne - Różnice w przypadkach testowych

Fakty odkryłem:

Testowanie systemu prowadzony jest na całego systemu i jest wykonywana przez dostawcę. Testowanie systemu polega na testowaniu od końca do końca, w którym testowane są pełne przepływy w systemie (od logowania do wylogowania) w oparciu o specyfikację wymagań (zarówno funkcjonalną, jak i niefunkcjonalną).

Testy odbiorcze wykonywane są przez klienta w celu sprawdzenia, czy spełnia on wymagania klienta. Jest to również pełny przepływ i jest oparty na specyfikacji wymagań. JEDNAKŻE zbudowany system został zaprojektowany w oparciu o specyfikację wymagań, a wygląd/użyteczność jest zwykle akceptowana na wcześniejszych etapach cyklu rozwoju. Jeśli system obejmuje specyfikację wymagań, klient nie powinien być w stanie powiedzieć: "to nie jest to, co chcieliśmy, powtórzyć to i tamto", chyba że umowa na to pozwala, a klient płaci za godzinę.

Moje pytanie brzmi: jak wyglądałyby przypadki testowe dla tych dwóch faz testowych? Oba są testami typu end-to-end i koncentrują się na tym, że jest to system funkcjonalny i spełnia specyfikację, która w zakresie jest również potrzebą biznesową (skoro już zamówiła). Wydaje się, że przypadki testowe z testowania systemu mogą być ponownie wykorzystane w testach akceptacyjnych, ponieważ obie zapewniają pełne przepływy?

Odpowiedz

3

Testy akceptacyjne przez klienta nie powinny mieć formalnych przypadków testowych. Wszystko zależy od tego, czy klient korzysta z systemu tak, jak planował i widzi, gdzie ich zrozumienie tego, jak to działa, pasuje do tego, co faktycznie robi. Przypadki testowe ograniczają testy akceptacyjne, ponieważ zazwyczaj rzeczy z nich wywoływane są takie, jak "X jest świetny, ale możesz również dodać Y" i "Powiedzieliśmy, że pole Z powinno być liczbą całkowitą, ale w rzeczywistości możemy również potrzebować umieścić tam tekst".

+5

Nie zgadzam się. Testy akceptacyjne powinny zdecydowanie mieć formalny przypadek testowy, w przeciwnym razie dasz klientowi kartę "Wyjdź z pisania głupie wymagania". –

+0

Myślę, że podstawą każdej umowy między klientem a dostawcą jest specyfikacja wymagań. Jeśli klient jest testem akceptacyjnym ad-hoc i nie testuje systemu, wykorzystując tę ​​specyfikację jako bazę i akceptuje system, to nie ma prawnego żądania, aby po nim przyjść i powiedzieć: hej, tęskniłeś za tym. Zarówno klient, jak i dostawca powinni sprawdzić, czy te wymagania są spełnione? –

+0

To prawda, nie zaszkodzi poprosić klienta o sprawdzenie specyfikacji. Brzmi trochę jak "uważamy, że to jest to czego chcesz, proszę potwierdzić, że je zaimplementowaliśmy" zamiast bardziej otwartego "czy system robi to, co chcesz?" –

7

Krótka odpowiedź brzmi:

Testowanie systemu Wykonywane przez deweloperów i/lub kontroli jakości, aby zapewnić, że system robi to, co zostało zaprojektowane do zrobienia. Można to zrobić automatycznie za pomocą, na przykład, czegoś takiego jak Selenium (dla aplikacji internetowej). Celem tego jest zapewnienie jakości, a wiele organizacji nie przejmuje się tym.

Testowanie akceptacji Wykonane przez klientów i/lub kierowników w celu zapewnienia, że ​​system wykonuje to, co powinien. Powszechnie uważa się, że koniec prawnego zobowiązania dewelopera do naprawy oprogramowania.

Różnica polega na tym, że test systemowy zwykle testuje rzeczy, których klient tak naprawdę nie obchodzi, Takie rzeczy jak: "Czy połączenia bazy danych zostały popełnione we właściwej kolejności". Testy akceptacyjne zwykle koncentrują się na takich rzeczach jak "Jak subiektywne doświadczenie użytkownika".

2

Oba rodzaje testów są wykonywane w odniesieniu do całego systemu/aplikacji. Jest bardzo możliwe, że wiele testów będzie się nakładać.

Test systemu jest często wykonywany przez niezależny zespół ds. Kontroli jakości w środowisku produkcyjnym. Może to być pierwszy raz, gdy wszystkie komponenty są testowane razem.

Testowanie akceptacji często odbywa się w tym samym środowisku lub podobnym (również produkcyjnym) środowisku, ale skład zespołu często składa się z podzbioru rzeczywistych użytkowników systemu. Jedno przekonanie jest takie, że użytkownicy będą identyfikować scenariusze, defekty i obserwować zachowania, które zwykły tester przeoczyłby. Może to również zapewnić komfort użytkownikom, zanim zostaną wdrożeni do produkcji.

Jeśli pracujesz z modelem V, test systemu jest zgodny z projektem na poziomie systemu, a testy akceptacyjne są zgodne z wymaganiami biznesowymi.