Czy weryfikacja i walidacja są częścią procesu testowania?

Opierając się na wielu źródłach, nie wierzę, że prosta definicja, że ​​celem testowania jest znalezienie jak największej liczby błędów - testujemy, aby upewnić się, że działa lub nie działa. Przykładem są następujące cele testowania z ISTQB:

1. Sprawdź, czy (oprogramowanie) spełnia określone wymagania (myślę, że jest to weryfikacja)

2. Wykazać, że (produkty programowe) są odpowiednie do celu (myślę, że to jest sprawdzanie poprawności)

3. Wykryj wady

   Zgadzam się, że testowanie to weryfikacja, walidacja i wykrywanie wad. Czy to jest poprawne?

Myślę, że dokładnie to rozumiesz.

1. Weryfikacja i walidacja to różne rzeczy i są w rzeczywistości dość dobrze zdefiniowane. Chociaż nie podoba mi się ten dokument, ISO 9000ff jest bardzo istotny dla kontroli jakości i definiuje Weryfikację jako porównywanie produktu z jego wymaganiami i Walidację jako sprawdzanie, czy rzeczywiście odpowiada potrzebom klienta / użytkownika i wszyscy wiemy, że to może się różnić .

2. Oba można zrobić poprzez testowanie. Weryfikacja doprowadziłaby do wygenerowania testów w postaci wymagań. Walidacja prowadzi do testu wykonanego przez Testy bez bezpośredniego odniesienia do wymagań. Myślę, że często nazywa się to testowaniem eksploracyjnym. Oczywiście muszą to zrobić ludzie z prawdziwym zrozumieniem rzeczywistych potrzeb użytkowników, więc testy alfa i beta przez prawdziwych użytkowników są oczywistymi opcjami.

3. Teoretycznie wydaje mi się, że można argumentować, że cokolwiek objęte pierwszymi dwoma nie jest błędem, dlatego znalezienie błędów jako oddzielnego celu nie ma sensu. Ale myślę, że są rzeczy, których tak naprawdę nie można zweryfikować ani potwierdzić. Na przykład bezpieczeństwo: w jaki sposób weryfikujesz lub weryfikujesz, czy system oprogramowania jest bezpieczny przed atakami? Zamiast tego próbujesz znaleźć luki w zabezpieczeniach. To wyszukiwanie nie weryfikuje ani nie weryfikuje niczego, jeśli nie znajdzie problemów, ale znajdzie błędy, jeśli się powiedzie.

Z Wikipedii: „... Innymi słowy, sprawdzanie poprawności gwarantuje, że produkt rzeczywiście spełnia potrzeby użytkownika , a specyfikacje były przede wszystkim prawidłowe , a weryfikacja zapewnia, że ​​produkt został zbudowany zgodnie z wymaganiami i specyfikacjami projektowymi Walidacja gwarantuje, że „zbudowałeś właściwą rzecz”. Weryfikacja gwarantuje, że „zbudowałeś ją poprawnie”. Walidacja potwierdza, że ​​produkt, jak przewidziano, spełni swoje przeznaczenie. ”

Nie można przetestować potrzeb użytkownika i sprawdzić, czy specyfikacje są prawidłowe za pomocą kodu. Tak więc sprawdzanie poprawności nie odbywa się.

Weryfikacja zakłada, że ​​twoje wymagania i projekt są poprawne, więc możesz to przetestować, pisząc kod (testowanie).

W prawdziwym świecie testowanie to weryfikacja i walidacja oprogramowania, które spełnia jego wymagania (biznesowe / funkcjonalne / niefunkcjonalne). Ich celem jest ustalenie, czy oprogramowanie jest odpowiednie do określonego celu. Każde zachowanie, które nie spełnia wymagań aplikacji, jest wadą, której ważność będzie wymagać wyważenia przed ustaleniem, czy oprogramowanie jest odpowiednie do określonego celu.

Wady o niskiej istotności prawdopodobnie nie są przeszkodą w przekazywaniu oprogramowania do zastosowania typu produkcyjnego. Wysoka istotność może wymagać naprawy. W prawdziwym świecie całe oprogramowanie ma wady, niektóre mają problemy z kodowaniem, a inne wynikają z brakujących wymagań - których nie można przetestować, ponieważ nie można przetestować nieznanych wymagań.

Istnieje wiele definicji weryfikacji i walidacji. Wiele osób używa nawet tagu V&V do grupowania obu w jednym działaniu. Celem jest upewnienie się, że oprogramowanie robi właściwe rzeczy i czyni je właściwie. To, czy chodzi o sprawdzenie zgodności z wymaganiami, czy o znalezienie błędów, nie jest niezbędne na tym poziomie.

Testowanie jest jedną z wielu technik weryfikacji i walidacji, a nie drugą drogą. Przegląd kodu to kolejny, a formalna weryfikacja, z matematycznymi dowodami jeszcze jeden.

Niemniej jednak testy powinny być przeprowadzane w celu znalezienia błędów, a nie w celu sprawdzenia zgodności z wymogami.

Główna różnica leży w umyśle testera. O wiele łatwiej jest zbudować przypadek testowy pokazujący, że oprogramowanie działa zgodnie z przeznaczeniem (sprawdzanie zgodności), niż zbudować przypadek testowy pokazujący, że oprogramowanie nie działa (znajdowanie błędów).

Wielki tester jest pasjonatem łamania oprogramowania, a nie korzystania z niego w bezpieczny sposób.

Zobaczmy to z praktycznego punktu widzenia. Do testowania musisz zdefiniować przypadki testowe. Zazwyczaj przypadki testowe definiuje się zgodnie z określonymi wymaganiami i powinny one obejmować przypadki „szczęśliwego dnia” oraz „przypadki skrajne” - szczególnie te ostatnie są często definiowane z zamiarem złamania oprogramowania. Gdy niektóre z twoich testów zakończą się niepowodzeniem, pokazują błędy / wady. Kiedy masz rozsądną liczbę przypadków testowych dla każdego wymagania i wszystkie testy są udane, możesz nie w pełni udowodnić, że wszystkie wymagania są spełnione, ale zwiększyłeś prawdopodobieństwo tego, a zatem dokonałeś pewnej weryfikacji.

Tak więc w tej części pytania znalezienie błędów i weryfikacja mogą być tylko dwiema stronami tego samego procesu:

• testy zakończone niepowodzeniem: wykryte wady

• testy zaliczone: weryfikacja wykonana (przynajmniej do pewnego stopnia, jeśli dostarczysz wystarczającą liczbę i odpowiednie testy)

W odniesieniu do walidacji: jak wskazał @Mert, walidacji można dokonać poprzez testy akceptacyjne, ale nie przez inne formy testowania. Tak więc testowanie zasadniczo nie powoduje żadnej walidacji, tylko gdy jest wykonywane jako test akceptacyjny, przez niektórych potencjalnych użytkowników.

Wszystko zależy od twojej definicji „weryfikacji”. Na przykład formalna weryfikacja zwykle nie jest przeprowadzana przez zespół ds. Kontroli jakości, ale jest obowiązkiem programistów. Prawie nikt nie dokonuje formalnej weryfikacji ze względu na związane z tym wysokie koszty (luka w wiedzy i potrzebne zasoby).

Testowanie oprogramowania to nie to samo co kontrola jakości. Dobrze rozumiesz. Ogólnie testy oprogramowania obejmują wiele etapów (dym, jednostka, regresja, integracja, akceptacja użytkownika itp.).

Tak więc zapewnienie, że oprogramowanie działa zgodnie z wymaganiami, jest głównym celem QA (specjalista ds. Zapewnienia jakości - inaczej lata temu nazywano go po prostu testerami). To jednak nie tylko testowanie . Kontrola jakości zapewnia, że ​​wdrożony jest odpowiedni zestaw procesów do przeprowadzania kontroli jakości danego produktu lub przynajmniej jest on wprowadzany w fazę projektową projektu.

Dlatego idealnie byłoby oczekiwać, że twoja kontrola jakości zweryfikuje aplikację pod kątem zestawu wymagań, a nie tylko spróbujesz przetestować ją przez uszkodzenie oprogramowania i znajdowanie wad.