Różnica między testem akceptacyjnym a testem funkcjonalnym?

Jaka jest prawdziwa różnica między testami akceptacyjnymi a testami funkcjonalnymi?

Jakie są najważniejsze lub cele każdego z nich? Wszędzie, gdzie czytam, są do siebie niejednoznacznie podobne.

W moim świecie używamy następujących terminów:

testowanie funkcjonalne : jest to czynność weryfikacyjna ; czy stworzyliśmy poprawnie działający produkt? Czy oprogramowanie spełnia wymagania biznesowe?

W przypadku tego typu testów mamy przypadki testowe, które obejmują wszystkie możliwe scenariusze, jakie przychodzą nam do głowy, nawet jeśli jest mało prawdopodobne, aby taki scenariusz istniał „w prawdziwym świecie”. Podczas przeprowadzania tego typu testów dążymy do maksymalnego pokrycia kodu. Używamy dowolnego środowiska testowego, jakie możemy w danej chwili pobrać, nie musi to być kaliber „produkcyjny”, o ile jest użyteczny.

testy akceptacyjne : jest to czynność walidacyjna ; czy stworzyliśmy właściwą rzecz? Czy tego naprawdę potrzebuje klient?

Odbywa się to zwykle we współpracy z klientem lub przez wewnętrznego pełnomocnika klienta (właściciela produktu). Do tego typu testów używamy przypadków testowych, które obejmują typowe scenariusze, w których spodziewamy się użycia oprogramowania. Ten test należy przeprowadzić w środowisku „produkcyjnym”, na sprzęcie, który jest taki sam lub zbliżony do tego, z jakiego będzie korzystał klient. To wtedy testujemy nasze „chore”:

• Niezawodność, dostępność : potwierdzona testem warunków skrajnych.

• Skalowalność : sprawdzona za pomocą testu obciążenia.

• Użyteczność : potwierdzona przez inspekcję i demonstrację dla klienta. Czy interfejs użytkownika jest skonfigurowany zgodnie z ich upodobaniami? Czy umieściliśmy branding klienta we właściwych miejscach? Czy mamy wszystkie pola / ekrany, o które prosili?

• Bezpieczeństwo (inaczej zabezpieczalność, tylko po to, by się dopasować) : sprawdzone przez demonstrację. Czasami klient zatrudnia firmę zewnętrzną do przeprowadzenia audytu bezpieczeństwa i / lub testów włamań.

• Łatwość utrzymania : sprawdzone poprzez demonstrację, w jaki sposób będziemy dostarczać aktualizacje / poprawki oprogramowania.

• Konfigurowalność : Sprawdzona poprzez demonstrację, w jaki sposób klient może modyfikować system, aby odpowiadał jego potrzebom.

W żadnym wypadku nie jest to standardowe i nie sądzę, aby istniała „standardowa” definicja, jak pokazują sprzeczne odpowiedzi. Najważniejsze dla Twojej organizacji jest precyzyjne zdefiniowanie tych terminów i trzymanie się ich.

Podoba mi się odpowiedź Patricka Cuffa. Chciałbym dodać różnicę między poziomem testu a typem testu, który był dla mnie otwieraczem oczu.

poziomy testów

Poziom testu można łatwo wyjaśnić za pomocą modelu V , przykład: Każdy poziom testu ma odpowiadający mu poziom rozwoju . Charakteryzuje się typową charakterystyką czasową, są one wykonywane w określonej fazie cyklu rozwojowego.

1. testowanie komponentów / jednostek => weryfikacja szczegółowego projektu
2. testowanie integracji komponentów / jednostek => weryfikacja projektu globalnego
3. testowanie systemu => weryfikacja wymagań systemowych
4. testowanie integracji systemów => weryfikacja wymagań systemowych
5. testy akceptacyjne => weryfikacja wymagań użytkownika

typy testów

Rodzaj testu jest to cechy, skupia się na specyficzny cel testu. Typy testów podkreślają Twoje aspekty jakościowe, znane również jako aspekty techniczne lub niefunkcjonalne. Typy testów można wykonywać na dowolnym poziomie testów . Lubię używać jako typów testów charakterystyk jakości wymienionych w ISO / IEC 25010: 2011.

1. testy funkcjonalności
2. testy niezawodności
3. test wydajności
4. testowanie funkcjonalności
5. testy bezpieczeństwa
6. testy zgodności
7. testy konserwacyjne
8. testowanie przenoszenia

Aby to zakończyć. Jest też coś, co nazywa się testowaniem regresji . To dodatkowa klasyfikacja obok poziomu i typu testu . Testy regresji jest test, który chcesz powtarzać, ponieważ dotyka czegoś krytycznego w swoim produkcie. W rzeczywistości jest to podzbiór testów, które zdefiniowałeś dla każdego poziomu testu . Jeśli w Twoim produkcie występuje drobna poprawka błędu, nie zawsze masz czas na powtórzenie wszystkich testów. Odpowiedzią na to są testy regresyjne .

Różnica polega na przetestowaniu problemu i jego rozwiązaniu. Oprogramowanie jest rozwiązaniem problemu, oba można przetestować.

Test funkcjonalny potwierdza, że ​​oprogramowanie wykonuje funkcję w granicach tego, jak rozwiązałeś problem. Jest to integralna część tworzenia oprogramowania, porównywalna z testowaniem przeprowadzanym na masowo produkowanym produkcie, zanim opuści on fabrykę. Test funkcjonalny sprawdza, czy produkt faktycznie działa tak, jak myślisz (programista).

Testy akceptacyjne potwierdzają, że produkt faktycznie rozwiązuje problem, który miał rozwiązać. Najlepiej może to zrobić użytkownik (klient), na przykład wykonując swoje zadania, w których pomaga oprogramowanie. Jeśli oprogramowanie przejdzie ten test w świecie rzeczywistym, zostanie zaakceptowane jako zastąpienie poprzedniego rozwiązania. Ten test akceptacji można czasami przeprowadzić poprawnie tylko na produkcji, zwłaszcza jeśli masz anonimowych klientów (np. Strona internetowa). W związku z tym nowa funkcja zostanie zaakceptowana dopiero po kilku dniach lub tygodniach użytkowania.

Testy funkcjonalne - przetestuj produkt, sprawdzając, czy ma cechy, które zaprojektowałeś lub zbudowałeś (funkcje, szybkość, błędy, spójność itp.)

Testy akceptacyjne - przetestuj produkt w jego kontekście, wymaga to (symulacji) interakcji człowieka, sprawdź, czy ma on pożądany wpływ na pierwotny problem (y).

Odpowiedź brzmi: opinia. Pracowałem przy wielu projektach, będąc testmanager i issueemanager, a różne role i opisy w różnych książkach różnią się, więc oto moja odmiana:

testowanie funkcjonalne: weź wymagania biznesowe i przetestuj wszystko dobrze i dokładnie z funkcjonalnego punktu widzenia.

testy akceptacyjne: „płacący” klient przeprowadza testy, które lubi, aby mógł zaakceptować dostarczony produkt. Zależy to od klienta, ale zwykle testy nie są tak dokładne, jak testy funkcjonalne, zwłaszcza jeśli jest to projekt wewnętrzny, ponieważ interesariusze przeglądają i ufają wynikom testów wykonanych we wcześniejszych fazach testów.

Jak powiedziałem, to jest mój punkt widzenia i doświadczenie. Testowanie funkcjonalne jest systematyczne, a testowanie akceptacyjne jest raczej działem biznesowym testującym przedmiot.

1. Publiczność. Testowanie funkcjonalne ma na celu zapewnienie członków zespołu wytwarzającego oprogramowanie, że robi to, czego oczekują. Testy akceptacyjne mają na celu zapewnienie konsumentowi, że spełnia jego potrzeby.

2. Zakres. Testy funkcjonalne sprawdzają funkcjonalność tylko jednego komponentu naraz. Testy akceptacyjne obejmują każdy aspekt produktu, który ma znaczenie dla konsumenta na tyle, aby przetestować go przed zaakceptowaniem oprogramowania (tj. Wszystko, co warte jest czasu lub pieniędzy, jakie zajmie przetestowanie go w celu określenia jego akceptowalności).

Oprogramowanie może przejść testy funkcjonalne, testy integracyjne i testy systemowe; tylko po to, aby oblać testy akceptacyjne, gdy klient odkryje, że funkcje po prostu nie spełniają jego potrzeb. Zwykle oznaczałoby to, że ktoś schrzanił specyfikację. Oprogramowanie może również nie przejść niektórych testów funkcjonalnych, ale przejdzie testy akceptacyjne, ponieważ klient jest skłonny poradzić sobie z niektórymi funkcjonalnymi błędami, o ile oprogramowanie wykonuje podstawowe rzeczy, których potrzebuje, w akceptowalny sposób (oprogramowanie beta często jest akceptowane przez podzbiór użytkowników wcześniej jest w pełni funkcjonalny).

Testowanie funkcjonalne: zastosowanie danych testowych pochodzących z określonych wymagań funkcjonalnych bez względu na ostateczną strukturę programu. Znany również jako testowanie czarnoskrzynkowe.

Testowanie akceptacyjne: Formalne testowanie przeprowadzane w celu ustalenia, czy system spełnia kryteria akceptacji - umożliwia użytkownikowi końcowemu określenie, czy akceptuje system, czy nie.

Moim zdaniem główna różnica polega na tym, kto mówi, czy testy zakończą się sukcesem, czy niepowodzeniem.

Test funkcjonalny sprawdza, czy system spełnia predefiniowane wymagania. Jest przeprowadzany i sprawdzany przez osoby odpowiedzialne za rozwój systemu.

Test akceptacyjny jest podpisywany przez użytkowników. Idealnie byłoby, gdyby użytkownicy powiedzieli, co chcą przetestować, ale w praktyce prawdopodobnie będzie to koniec testu funkcjonalnego, ponieważ użytkownicy nie inwestują wystarczająco dużo czasu. Zwróć uwagę, że ten widok pochodzi od użytkowników biznesowych, z którymi mam do czynienia z innymi grupami użytkowników, np. Lotnictwo i inne krytyczne dla bezpieczeństwa kwestie mogą nie mieć tej różnicy,

Testy akceptacyjne :

... to test czarnoskrzynkowy wykonywany w systemie (np. oprogramowanie, wiele wyprodukowanych części mechanicznych lub partie produktów chemicznych) przed jego dostawą.

Chociaż to mówi dalej:

Znane są również jako testy funkcjonalne, testy czarnoskrzynkowe, akceptacja wersji, testy jakości, testy aplikacji, testy zaufania, testy końcowe, testy walidacyjne lub testy akceptacji fabrycznej

ze znakiem „potrzebne źródło”.

Testowanie funkcjonalne (które w rzeczywistości przekierowuje do Testowania systemu):

prowadzone na kompletnym, zintegrowanym systemie w celu oceny zgodności systemu z określonymi wymaganiami. Testowanie systemowe wchodzi w zakres testowania czarnoskrzynkowego i jako takie nie powinno wymagać znajomości wewnętrznego projektu kodu lub logiki.

Więc z tej definicji są prawie tym samym.

Z mojego doświadczenia wynika, że ​​testy akceptacyjne są zwykle podzbiorem testów funkcjonalnych i są używane w formalnym procesie zatwierdzania przez klienta, podczas gdy testy funkcjonalne / systemowe będą przeprowadzane przez dział programisty / QA.

Związek między tymi dwoma: Test akceptacyjny zwykle obejmuje testy funkcjonalne, ale może obejmować testy dodatkowe. Na przykład sprawdzenie wymagań dotyczących etykietowania / dokumentacji.

Testowanie funkcjonalne ma miejsce, gdy testowany produkt jest umieszczany w środowisku testowym, które może wywoływać różnorodną stymulację (w zakresie testu), jaką zwykle wytwarza środowisko docelowe lub nawet poza nią, podczas badania odpowiedzi testowanego urządzenia.

W przypadku produktu fizycznego (nie oprogramowania) istnieją dwa główne rodzaje testów akceptacyjnych : testy projektowe i testy produkcyjne. Testy projektowe zazwyczaj obejmują dużą liczbę próbek produktów, które przeszły pomyślnie test produkcyjny. Różni konsumenci mogą testować projekt na różne sposoby.

Testy akceptacyjne są określane jako weryfikacja, gdy projekt jest testowany pod kątem specyfikacji produktu, a testy akceptacyjne są określane jako walidacja, gdy produkt jest umieszczony w rzeczywistym środowisku konsumenta.

Testy akceptacyjne to tylko testy przeprowadzane przez klienta i obejmują inne rodzaje testów:

• Testy funkcjonalne: „ten przycisk nie działa”
• Testy niefunkcjonalne: „ta strona działa, ale jest zbyt wolna”

W przypadku testów funkcjonalnych i niefunkcjonalnych (ich podtypy) - zobacz moją odpowiedź na to pytanie SO .

To są te same rzeczy.

Testy akceptacyjne są przeprowadzane na gotowym systemie w sposób możliwie najbardziej identyczny z rzeczywistym środowiskiem produkcyjnym / wdrożeniowym, zanim system zostanie wdrożony lub dostarczony.

Możesz przeprowadzić testy akceptacyjne w sposób zautomatyzowany lub ręcznie.