Menu

Testowanie sterowane kontekstem: 7 podstawowych zasad na przykładzie

context driven testing

Wypróbuj Nasz Instrument Do Eliminowania Problemów

7 Podstawowych zasad testowania sterowanego kontekstem na przykładzie:

implementacja stosu w C ++ przy użyciu tablicy

Jadąc na lotnisko, zazwyczaj jeżdżę autostradą, która dojedzie mnie tam w jak najkrótszym czasie i pozwoli uniknąć opłat. Ale tego dnia wybrałem dłuższą lokalną trasę drogową z opłatą. Ponieważ chciałem kilka dodatkowych minut z przyjacielem w podróży, który przebył bardzo długi dystans, aby spędzić weekend z naszą rodziną. Normalny najgorszy wybór w tym przypadku okazał się najlepszy.

Ale zastanów się nad tym.

A co, gdybym miał mało paliwa?

A co, gdybym miał mało gotówki?

Wybrałbym inną opcję. Dlaczego? Kontekst.

Co to jest testowanie kontekstowe

(wizerunek kredyt )

Kiedy podejmujesz decyzje w oparciu o następujące kwestie, jest to decyzja kontekstowa:

  • Osoby zaangażowane
  • Okoliczności
  • Cele
  • Dostępne opcje
  • Emocje itp.

Więc czym jest testowanie kontekstowe?

Context Driven Testing to zmiana sposobu myślenia (lub szkoła testowania) opracowana przez Cema Kanera, Jamesa Bacha i Breta Pettichorda. Szczegóły na ten temat można znaleźć w ich słynnej książce: Lekcje z testowania oprogramowania .

Jest w tym 7 podstawowych zasad. Następujące osoby są bezpośrednio wybierane ze swojej książki:

# 1) Wartość każdej praktyki zależy od jej kontekstu.

#dwa) Istnieją dobre praktyki w kontekście, ale nie ma najlepszych praktyk.

# 3) Ludzie pracujący razem są najważniejszą częścią kontekstu każdego projektu.

# 4) Projekty rozwijają się w czasie w sposób, który często nie jest przewidywalny.

# 5) Produkt jest rozwiązaniem. Jeśli problem nie zostanie rozwiązany, produkt nie będzie działać.

# 6) Dobre testowanie oprogramowania to wymagający proces intelektualny.

# 7) Tylko dzięki rozsądkowi i umiejętnościom, ćwiczonym wspólnie przez cały projekt, jesteśmy w stanie zrobić właściwe rzeczy we właściwym czasie, aby skutecznie przetestować nasze produkty.

Nie będę wyjaśniać każdego z nich, ponieważ robi to dla nas samych ekspertów .

Zamierzam po prostu wyjaśnić na podstawie scenariusza moje podejście do testowania sterowanego kontekstem.

Przykład testowania sterowanego kontekstem:

Powiedzmy, że zaczynam projekt testowy - Projekt A, który obejmuje kompleksowe testowanie aplikacji internetowej.

Jaka byłaby moja strategia?

Zgodnie ze standardowymi procesami będzie to kolejność zdarzeń:

  • Zbierz wymagania i zapoznaj się z aplikacją
  • Utwórz plan testów
  • Utwórz dokumentację testową - scenariusze testowe, przypadki testowe, macierz identyfikowalności itp.
  • Sprawdź i zatwierdź całą dokumentację
  • Skonfiguruj środowisko kontroli jakości i dane testowe
  • Wykonaj wykonanie testu
  • Twórz raporty o błędach
  • Generuj i udostępniaj raporty o stanie wykonania testów itp.

Jeśli zadam sobie pytanie: „Jak zdecydowałem, że to jest to, co muszę robić?” Moja odpowiedź brzmiałaby: najlepsze praktyki, standardy kontroli jakości, wytyczne branżowe, podstawowe doświadczenia z przeszłości itp., Prawda?

Powtarzam to, czego mnie nauczono lub co robili inni.

Czy jest w tym coś nie tak? Ani trochę. To też może zadziałać, ponieważ w tym podejściu istnieje pewne poczucie powtarzalności i sprawdzonej w czasie. Czy jednak utoruje drogę do optymalnych rezultatów?

Wątpliwy. Dlaczego?

Ponieważ przy każdym projekcie będziesz mieć do czynienia z różnymi okolicznościami:

  • Wymagania udokumentowane a nieudokumentowane
  • Ściśle pracujące a rozproszone geograficznie zespoły
  • Zespoły programistyczne i testowe należące do tej samej firmy a konkurencja
  • Wystarczający czas vs. Napięte harmonogramy
  • Skład Twojego zespołu - Nowoprzybyli kontra doświadczeni. Wyszkoleni kontra nieprzeszkoleni.
  • Dostępność narzędzi - użycie narzędzia do zarządzania ręcznego i testowego
  • Rodzaj projektu - wymaga ścisłego przestrzegania zasad (FDA lub bankowość) vs. eksperymentalne (np. Media społecznościowe)
  • Technologia projektu.Na przykład:nie przetestowałbyś sieci i aplikacji Windows w ten sam sposób
  • Wymagania klientów (niektórzy chcą codziennych szczegółowych raportów, niektórzy chcą tylko najważniejszych informacji)
  • Przebieg procesu (testy zwinne vs. tradycyjne, skryptowe vs. eksploracyjne)

Ta lista nie jest wyczerpująca i wiesz równie dobrze jak ja, że ​​każdy projekt ma wiele zmiennych.

Testowanie kontekstowe polega na tym, że pozwalasz tym okolicznościom decydować o swoich praktykach testowych, technikach, a nawet definicjach, zamiast standardowych, postrzeganych przez branżę „ najlepsze praktyki' .

A teraz powiedzmy, że pracuję nad szczegółami projektu A:

  • Pracuję z zespołem 5-4 nowicjuszy i 1 doświadczonym testerem.
  • Nie mam udokumentowanych wymagań.
  • Mój zespół znajduje się w Indiach, a zespół programistów w Stanach Zjednoczonych, więc pracujemy w różnych strefach czasowych.
  • Klient chce codziennego szczegółowego raportu o stanie
  • Używamy internetowego narzędzia do śledzenia błędów, takiego jak Mantis lub Bugzilla i to wszystko, co mamy.
  • Muszę zrobić 2 rundy testów w 10 dni i 3 dni na dokumentację testów

Oto przybliżony plan gry:

1) Ponieważ w zespole jest wielu nowoprzybyłych, potrzebujemy wielu wzajemnych recenzji.

dwa) Potrzebujemy również co najmniej 2 spotkań w celu omówienia wymagań z zespołem BA i Dev. To musi być formalne, ponieważ zespoły są zlokalizowane gdzie indziej i nie mam zbyt wiele możliwości, aby podejść do nich z pytaniami.

3) Jest to agresywny harmonogram testów dokumentacji. Im więcej piszemy dokumentacji, tym więcej potrzebujemy recenzji, co oznacza więcej czasu. Będziemy więc musieli zachować minimalną dokumentację. Zamierzamy udokumentować tylko główne Kompleksowi Najlepsi Współtwórcy a reszta będzie testowane eksploracyjnie .

4) Codzienne raporty o stanie podczas wykonywania testów będą tworzone i wysyłane codziennie na żądanie.

5) Większość testów ma charakter eksploracyjny, więc zasugeruj czas na zrobienie krótkiego opisu każdego wykonanego testu. W ten sposób wiemy, co jest testowane, a co nie.

6) Defekty będą zgłaszane w czasie rzeczywistym do Mantis. Ponieważ zespół pracuje w innej strefie czasowej, być może będą musieli czekać cały dzień, zanim otrzymają wiadomość od zespołu ds. Kontroli jakości, na wypadek gdyby potrzebowali wyjaśnienia. Dlatego umów się na codzienną rozmowę telefoniczną z wygodnym zespołem, w którym zespół QA zademonstruje odtwarzanie błędów. W ten sposób nie będzie potrzeby czekania ani dalszych działań.

I tak dalej.

Kiedy masz już ogólną strategię, napisz podstawowy plan testów, wyjaśniający te punkty. Teraz jesteście gotowi przystąpić do projektu testowego po dokładnym rozważeniu i niestandardowej strategii sukcesu.

W podsumowaniu:

To jest Testowanie oparte na kontekście; uczynienie z okoliczności (a nie standardów) głównych danych wejściowych i czynników mających wpływ na strategię testowania. Zachęca nas do rozejrzenia się i wzięcia pod uwagę wszystkiego wokół.

kopiuj filmy DVD na dysk twardy za darmo

Osobiście jestem zakochany w tej koncepcji, ponieważ zbyt często praktyki testowe są postrzegane jako sztywne i oparte na imitacji. Ktoś to zrobił i odniósł sukces, więc ja też to zrobię. To jest rodzaj obrazu, który odstrasza ludzi przed próbami pozostania w karierze testera.

Ale istnieje wiele możliwości kreatywnego myślenia, umiejętności analitycznych i podejmowania decyzji. Aby dowiedzieć się więcej, poczytaj o temacie, korzystając z linków podanych powyżej.

Miłego testowania kontekstowego

rekomendowane lektury

^