Menu

7-etapowa praktyczna implementacja testowania ręcznego przed wydaniem do produkcji

7 step practical implementation manual testing before production release

Wypróbuj Nasz Instrument Do Eliminowania Problemów

W poprzednim poście z tej serii, poświęconym testom ręcznym, starałem się rzucić jak najwięcej światła na podstawy testowania ręcznego.

Jeśli to przegapiłeś, możesz to przeczytać tutaj .

Mam nadzieję, że udało się zbliżyć Cię do odpowiedzi, których szukałeś.

W takim razie, czy nie chciałbyś dowiedzieć się więcej o praktycznej implementacji testów ręcznych, jak lepiej się z nimi zapoznać i jak rozpocząć karierę?

Ten artykuł rzuci światło na wszystkie te aspekty.

Wdrażanie testów ręcznych

Zaczynajmy.

Czego się nauczysz:

Cykl testowania ręcznego

Rozumieć Cykl testowania ręcznego lub cyklu życia testów oprogramowania (STLC), przede wszystkim musimy zrozumieć cykl życia oprogramowania (SDLC), który, jestem pewien, już rozumiesz.

Ludzie odnoszą się do nich osobno, ale nie są pewni, czy naprawdę mogą współistnieć. Są tak ściśle ze sobą zintegrowani. Cóż, nawet te cykle mają tak wiele ich wersji utworzonych i unoszących się w przestrzeni internetowej, że różnią się one znacznie od wybranego modelu rozwoju.

Jak większość świat staje się zwinny w dzisiejszych czasach będę upraszczał swoje rzeczy dzięki Agile.

7 praktycznych kroków testowania ręcznego przed wprowadzeniem do produkcji

Teraz ja.

Pamiętaj, że mówię zarówno o SDLC, jak i STLC.

1) Zbieranie wymagań

Faza zbierania wymagań

Analityk biznesowy (osoba / zespół odpowiedzialny za gromadzenie wymagań) dokumentuje wymagania. Dokumentują wymagania, to jest najważniejsze, możesz skupić się tylko na tym. To, gdzie jest to udokumentowane, ma mniejsze znaczenie.

Ludzie używają wszystkiego do udokumentowania tych, które im odpowiadają, ale nie ograniczają się do tradycyjnych platform, takich jak MS Word doc, nowoczesne platformy, takie jak Jira / Rally i narzędzia New Age, takie jak Trello.

# 2) Dyskusja / udostępnianie wymagań

Faza dyskusji na temat wymagań

Analityk biznesowy ma następnie udostępniać udokumentowane wymagania zespołowi programistycznemu, zespołowi testującemu i zespołowi UX (w razie potrzeby). Zwykle odbywa się to podczas formalnego spotkania, na którym SPOC (pojedynczy punkt kontaktowy lub cały zespół, to zależy) ze wszystkich trzech funkcji spełniają i rozumieją cały wymóg.

W kulturze zdrowej pracy wymagania są omawiane pod każdym kątem, a każdy uczestnik spotkania może zadawać pytania i wątpliwości. Po uzyskaniu odpowiedzi na wszystkie pytania i dokonaniu niezbędnych zmian w wymaganiu, tę fazę można uznać za wykonaną. Znowu to, co nazywa się tym konkretnym spotkaniem / krokiem, i jego dokumentacja różni się od firmy.

Dalsza lektura=> Jak przejrzeć dokument SRS

Po uzyskaniu odpowiedzi na wszystkie pytania i wprowadzeniu niezbędnych modyfikacji w wymaganiu można uznać tę fazę za Gotowy .

Znowu to, co nazywa się tym konkretnym spotkaniem / krokiem, i jego dokumentacja różni się od firmy.

Na przykład, dokumentacja jest nazywana lub rozkładana jako SRS (specyfikacja wymagań systemowych), dokument wymagań, epicka, historia użytkownika, punkt fabularny (możliwie najmniejsza jednostka wymagań) itp. Podobnie, to spełnienie, w którym wymagania jest wspólne, nazywa Wymagania Spotkanie dyskusyjne, pielęgnacja, spotkanie z dziurkowaniem itp., Mam nadzieję, że rozumiesz, o co mi chodzi?

Naciskanie na te terminologie, abyś zawsze pamiętał główny pomysł, niezależnie od różnych nazw.

Po tym spotkaniu uruchomione zostaną dwa kroki w tym samym czasie, w dowolnej kolejności, przejdź do kolejnych dwóch kroków.

# 3) Projektowanie

Zespół programistów rozpoczyna projektowanie techniczne, gdy tylko zostaną omówione wymagania i gdy nie ma żadnych ważnych oczekujących punktów. To, co się robi na tym etapie, znowu różni firmę od firmy.

Ta faza może obejmować między innymi następujące zadania:

  • Decydowanie o podejściu do rozwoju
  • Przygotowanie dokumentu projektowego
  • Projektowanie schematów blokowych
  • Szacowanie wysiłków
  • Określenie wpływu tego nowego wymagania na istniejące funkcje
  • Konieczność poprawienia istniejących danych itp.

Zespół UX może również zaangażować się w tę fazę, gdy nastąpi zmiana interfejsu użytkownika lub zostanie opracowany nowy ekran. Zespół UX pomaga zespołowi programistycznemu i zespołowi testującemu w tworzeniu prototypu interfejsu użytkownika pod kątem funkcjonalności / funkcji w dyskusji. Może to być dokument Photoshopa, prosty obraz, prezentacja PowerPoint lub cokolwiek innego, co pozwoli zespołowi programistów zrozumieć, w jaki sposób należy projektować ekrany.

Uwaga: Idealnie byłoby, gdyby te ekrany lub przynajmniej ich wersje robocze były wyświetlane w sesji dyskusji dotyczącej wymagań tylko po to, aby pomóc zespołowi w lepszym zrozumieniu. Zostaje oznaczony zgodnie z pierwotnym wymaganiem, aby można było się do niego odwołać w dowolnym momencie.

# 4) Projektowanie scenariuszy testowych / przypadków testowych

Scenariusz testowy Faza projektowania

Równolegle z fazą projektowania, zespół testujący rozpoczyna tworzenie scenariuszy testowych i / lub przypadków testowych w oparciu o omówione wymagania. To, czy scenariusze testowe są zawsze najpierw zapisywane, a następnie rozbijane na przypadki testowe, znowu nie jest stałe.

Moim zdaniem, niezależnie od tego, czy dokumentujesz scenariusze testowe, czy nie, są one zawsze przed przypadkami testowymi. Scenariusz testowy to punktor, który możesz powiedzieć, poprowadzi Cię do dalszej analizy. Po zakończeniu pisania przypadków testowych można podzielić się nimi z zespołem deweloperskim, aby dać im wyobrażenie o zakresie testowania, a także upewnić się, że rozwój, który się wydarzył lub ma miejsce, spełnia pisemne przypadki testowe.

Po zakończeniu pisania przypadków testowych można podzielić się nimi z zespołem deweloperskim, aby dać im wyobrażenie o zakresie testowania, a także upewnić się, że rozwój, który się wydarzył lub ma miejsce, spełnia pisemne przypadki testowe.

Przypadki testowe po napisaniu idealnie sprawdzają się przez kierownika testów lub współpracowników pod wieloma względami, na przykład:

  • Pokrycie wymagań
  • Gramatyka ortograficzna
  • Standardy pisania przypadków testowych (nic poza szablonem, za którym podąża zespół / firma)
  • Kompatybilność wsteczna
  • Zgodność z platformą
  • Odniesienia do danych testowych
  • Rodzaje docelowych testów itp.

Dalsza lektura=> Pisanie przypadków testowych z dokumentu SRS

W idealnym przypadku, dopiero po przeglądzie i potrzebnej modyfikacji, są one przekazywane do zespołu deweloperskiego.

Kiedy powiedziałem „po zakończeniu pisania przypadków testowych”, miałem na myśli „wszystkie przypadki testowe zostały napisane na podstawie pełnej znajomości danego wymagania i możliwych scenariuszy testowych odkrytych do tego konkretnego czasu”. Niemal niemożliwe jest pokrycie przypadków testowych w 100% za pierwszym razem.

Będą defekty, które znajdziesz w przypadkowych (ale zamierzonych) działaniach, w czysto losowych działaniach (testowanie małp) oraz w niektórych rzadkich scenariuszach. Są szanse, że przegapisz kilka z nich. W pewnym momencie możesz przegapić nawet bardzo podstawowe, w końcu jesteś człowiekiem. Ale tutaj przynajmniej dobry przegląd przypadków testowych i uporządkowany sposób pisania przypadków testowych mogą cię uratować.

Najczęściej tester lub zespół testujący dodaje coraz więcej przypadków testowych do istniejącego fragmentu, gdy odkrywają prawdę lub myślą więcej o wymaganiach.

Cóż, do tej pory niektórzy z was pewnie wątpią w moją wiedzę na temat testowania oprogramowania, ponieważ pewnego słowa (które stało się normą w testowaniu oprogramowania) jeszcze nie używam. Plan testów, prawda?

Powiem coś na ten temat. Mocno wierzę w potrzebę większości informacji, o których mowa w planie testów, ale dokumentowanie ich wszystkich w tym samym miejscu i uczynienie ich absolutnie obowiązkowymi jest czymś, co jest dyskusyjne.

W każdym razie to osobny temat do omówienia. Udostępnienie informacji „pasuje do wszystkich” na ten temat jest trudne, ale pozwól mi spróbować.

Ty, Ty wraz ze swoim przewodnikiem lub kierownikiem testów przygotowujesz plan testu lub dokumentujesz wymagane informacje w różnych miejscach.

Dalsze czytanie=> Jak napisać dokument planu testów

Informacje, które na tym etapie należy bezwzględnie zamrozić:

  • Zakres badań: Wymagania, kompatybilność wsteczna, platformy, urządzenia itp.
  • Osoba / zespół, który będzie testował
  • Szacowanie wysiłku testowego
  • Ograniczenia: Wszelkie przyjęte założenia lub ograniczenia zaakceptowane z góry.
  • Ludzie dodatkowo dokumentują kryteria wejścia, kryteria zakończenia, ryzyko itp., Które moim zdaniem nie wymagają osobnej wzmianki, ponieważ powinno to być raczej normalne zrozumienie.
    • Kryteria wejścia (Kiedy rozpocząć testowanie): Niewiele osób zaczyna się, gdy dostępna jest testowalna część funkcji do testowania. Niewielu czeka, aż cała funkcjonalność będzie możliwa do przetestowania. Gdy okaże się, że podstawowy przepływ działa, rozpoczyna się testowanie.
    • Kryteria wyjścia (Kiedy zatrzymać): Gdy nie ma elementu blokującego, krytyczne i główne (narażone na wpływ) defekty w testowaniu w fazie otwartej mogą zostać zatrzymane. Lub w połowie drogi, gdy jest zbyt wiele defektów, przed którymi stoi testowanie, może zostać zatrzymane przez odpowiednich interesariuszy.
    • Ryzyko : Ryzyko biznesowe lub funkcjonalne, jeśli testowanie nie odbywa się zgodnie z udokumentowanym planem.

# 5) Faza rozwoju

Faza rozwoju oprogramowania

Zespół programistów po fazie projektowania zaczyna od właściwego rozwoju i testowania jednostkowego, tak jak i kiedy są one gotowe, wraz z opracowywaniem testowalnych fragmentów wymagań. Mogą przekazywać funkcje do testowania w fragmentach, gdy są wdrażane, lub mogą przekazywać całą funkcjonalność naraz.

W idealnym scenariuszu formalny przegląd kodu i testowanie typu white box mają miejsce przed przekazaniem opracowanej funkcjonalności do testowania. w idealnej sytuacji zespół deweloperski powinien również odnosić się do przypadków testowych dostarczonych przez zespół testujący oprócz wymagań i dokumentów projektowych.

# 6) Faza testowania

Jak wspomniano wcześniej, początek tej fazy różni się od firmy do firmy, od zespołu do zespołu.

Zespół testujący rozpoczyna testowanie, gdy zostanie opracowana testowalna (coś, co można niezależnie przetestować) część całego wymagania lub gdy zostanie opracowane całe wymaganie.

jaka jest różnica między przekierowaniem portów a wyzwalaniem portów

Pozwól, że przejdę dalej w tej fazie i porozmawiam o ważnych zadaniach:

  • Tester / zespół testujący rozpoczyna rundę testową (testowanie eksploracyjne i wykonanie pisemnych przypadków testowych) i rejestrowanie defektów
  • Zespół programistów rozwiązuje je zgodnie z priorytetem.
  • Nowa kompilacja (kod) jest pobierana w środowisku, w którym przeprowadzane są testy
  • Naprawione usterki są następnie weryfikowane przez Testera / Zespół Testujący i oznaczane jako Naprawione
  • Cykl ten trwa do momentu osiągnięcia kryterium wyjścia.
  • Należy pamiętać, że w razie potrzeby wady są również oznaczane jako nieprawidłowe, zduplikowane i można je również sklasyfikować jako ulepszenia.

Kolejną rzeczą, która różni firmę od firmy, jest to, ile rund testowych należy wykonać. Podobnie jak w niektórych przypadkach, pierwsza runda testowania odbywa się na małych elementach funkcji, gdy są one gotowe, a po opracowaniu wszystkich wymagań następuje kompleksowa runda testowania w innym środowisku. Ale znowu, słyszałem również o ludziach wykonujących trzy właściwe pełne rundy testowe i czwartą jako rundę poczytalności / dymu.

Pierwszym celem związanym z przeprowadzaniem wielu rund testowych jest testowanie funkcjonalności w różnych środowiskach, a drugim przeprowadzanie testów od końca do końca po opracowaniu wszystkich punktów historii. Normalna runda zwykle szybko zyskuje pewność siebie, gdy wszystkie historie w wydaniu zostaną opracowane i przetestowane niezależnie.

Przeczytaj szczegółowe instrukcje=> Faza wykonania testu

# 7) Recenzja analityka biznesowego (BA)

Analityk biznesowy analizuje żądaną funkcjonalność, odwołując się do wyniku testu lub do wyniku testu i bawiąc się aplikacją, aby uzyskać rzeczywisty wygląd. Ten krok ponownie podlega różnym działaniom w różnych firmach.

BA może przejrzeć zakres całego wydania za jednym razem lub w fragmentach. W zależności od tego, ten krok może nastąpić przed ostatecznym testem poczytalności lub po ostatniej rundzie testów poczytalności przeprowadzonej przez zespół testujący.

Powyższe 7 kroków dotyczy wszystkich historyjek użytkownika / wymagań, które mają być spełnione w danym wydaniu (przesyłce). Po wykonaniu wszystkich tych kroków dla wszystkich wymagań, wydanie jest gotowe do wysyłki.

# 8) Wysyłka / wydanie

Wersja jest oznaczona jako Gotowe do wysyłki po pomyślnym przejrzeniu przez analityka biznesowego.

Zalecana lektura=> Proces wydania testowego

Rodzaje testów manualnych (czytaj na ludziach)

Cóż, jeśli musimy porozmawiać o ogólnych typach testów w liczbach, to gdzieś znalazłem 100 rodzajów testów o różnych nazwach . Szczerze mówiąc, nie jestem wystarczająco bystry, aby zrozumieć różnicę między tymi wszystkimi typami (gra słów zamierzona).

To jest proste i proste: Testowanie funkcjonalności aplikacji pod kątem danego wymagania przy pomocy ludzkich wysiłków i inteligencji. Jest dalej podzielony na kilka typów w zależności od zakresu i planu testowania. Rodzaje wymienione w następnym ust.

Jest dalej podzielony na kilka typów w zależności od zakresu i planu testowania. Rodzaje wymienione w następnym ust.

Jeśli mi wolno, pozwolę sobie na kilka linijek z testów na ludziach (które zachęcam każdego testera do zrobienia tylko ręcznych testów funkcjonalnych). Nie dajcie się zmylić, moim zdaniem ręczne testy funkcjonalne są podzbiorem testów na ludziach. Ponieważ jest tak wiele rzeczy, które może zrobić tylko ludzki umysł.

Poniżej znajduje się lista niektórych popularnych i ważnych typów testów, które można podzielić na testy na ludziach:

  • Ręczne testy funkcjonalne : Testowanie funkcjonalności aplikacji pod kątem danego wymagania przy pomocy ludzkich wysiłków i inteligencji. Dalej dzieli się na kilka typów w zależności od zakresu i planu testów, takich jak testy systemowe, testy jednostkowe, testy dymne, testy poczytalności, testy integracyjne, testy regresji, testy interfejsu użytkownika itp.
  • Test wydajności : To zostaje zaklasyfikowane do testów niefunkcjonalnych, prawda? Ale znowu to człowiek go wdraża, chociaż wykonanie jest wykonywane przez człowieka lub narzędzie. Tester powinien przynajmniej przeprowadzić te testy pod kątem czasu odpowiedzi (aby sprawdzić, czy jest to akceptowalne), jeśli nie powinien używać żadnego narzędzia do testowania obciążenia i tak dalej.
  • Przeglądarka / Testowanie zgodności platform: Testowana aplikacja powinna wyglądać i działać zgodnie z oczekiwaniami (oczywiście może występować niewielka różnica w zależności od silnika przeglądarki) na różnych przeglądarkach i platformach (lub urządzeniach, jeśli jest to aplikacja mobilna).
  • Test użyteczności : Przede wszystkim zgodzę się, że jest to obszerny temat sam w sobie i zwykle prowadzony przez specjalistów od testów użyteczności. Nadal uważam, że jako tester powinniśmy przynajmniej zgłosić lub podkreślić, jeśli znajdziemy coś jako mniej użytecznego, lub powinniśmy podzielić się naszym poglądem.
  • Testowanie bezpieczeństwa : Znowu bardzo duży rodzaj testów i wymaga oczywiście dużej wiedzy praktycznej. Tester powinien spróbować nauczyć się i wykonać przynajmniej podstawowe testy, takie jak manipulowanie adresem URL, skrypty między witrynami, wstrzykiwanie SQL, przechwytywanie sesji itp. W zależności od dostępnej wiedzy i wszędzie tam, gdzie ma to zastosowanie.
  • Testowanie wielu dzierżawców: Jeśli Twoja aplikacja jest wielodostępna, tj. Pojedyncza instancja przechowująca dane wielu klientów, to testowanie jest koniecznością. Należy to zrobić niezależnie od wyraźnej wzmianki w wymaganiach. Pokazanie danych jednego klienta drugiemu to rodzaj rozwoju i testowania przestępstw.

Uwaga: Powyższe poglądy to moje osobiste poglądy. Zalecam również zapoznanie się z obszerną listą typów testów dla Twojej wiedzy i śledzenie ich / korzystanie z nich, jeśli uznasz to za konieczne. Przez lata zrozumiałem, że niezależnie od tego, czy używasz czegoś, czy nie wierzysz w coś, czy nie, nadal powinieneś mieć pewną wiedzę na temat szeroko stosowanych pojęć w swojej dziedzinie.

To wszystko w tej części. Dziękuję za przeczytanie. Podziel się swoimi opiniami / opiniami w komentarzach.

W następnej i ostatniej części tego seria samouczków testowania ręcznego , Postaram się wszystkim pomóc jakie przygotowania powinieneś zrobić, jeśli chcesz wejść na pole testowe i jakie są możliwe sposoby, aby się tam dostać.

rekomendowane lektury

^