wprowadzenie

żywotność testera QA zostanie uznana za niekompletną, jeśli terminy „testowanie dymu”, „testowanie rozsądku” i „testowanie regresji” nie są w nim zawarte. Chociaż są to niektóre regularnie używane terminy, istnieje kilka typowych nieporozumień wokół nich zbyt.

zanim przejdziemy do szczegółów testów dymu, zdrowego rozsądku i regresji oraz ich znaczenia, przejdźmy przez kilka powszechnych nieporozumień i mitów wokół nich:

1. testowanie dymu i testowanie zdrowego rozsądku są takie same i mogą być stosowane zamiennie : to nie jest prawda i nigdy nie powinno się tego robić, dlaczego? omówimy to w tym artykule.
2. testowanie zdrowego rozsądku jest równoważne testom akceptacyjnym: testowanie akceptacyjne odbywa się w celu zapewnienia, że konstrukcja spełnia wszystkie wymagania określone przez klienta przed wydaniem, podczas gdy testowanie zdrowego rozsądku odbywa się w celu zapewnienia, że produkt jest zdrowy rozsądek, racjonalny dla bardziej szczegółowych testów. Nie są i nie powinny być stosowane zamiennie.
3. jeśli robię Test dymu, mogę pominąć test zdrowego rozsądku: Testowanie dymu jest testowaniem na bardzo wysokim poziomie, ponieważ testowanie to odbywa się w celu zapewnienia, że ta kompilacja jest odpowiednia do rozpoczęcia każdego innego rodzaju testów. Na przykład, może to być tylko test, aby upewnić się, że kompilacja instaluje się, a następnie można rozpocząć testowanie rozsądku. Chociaż czasami przypadki testowania dymu są uruchamiane razem z przypadkami testowania zdrowego rozsądku, nie należy ich mylić z jedną i tą samą rzeczą.
4. testowanie regresji nie jest związane z testowaniem dymu lub testowaniem poczytalności: w teorii testowanie poczytalności jest podzbiorem testów regresji. Niektóre przypadki testowania regresji o wysokim priorytecie stanowią zwykle przypadek testowania poczytalności.
5. Jeśli mam zamiar uruchomić pełny zestaw testów regresji – nie muszę uruchamiać żadnego testu smoke ’ a ani testu sanity: chociaż może to być prawdą w niektórych przypadkach, ponieważ testowanie Sanity jest podzbiorem testów regresji, nadal wskazane jest najpierw wykonać przypadki testowania sanity, a następnie wykonać je z resztą przypadków testowania regresji.

w tym artykule postaramy się raz na zawsze usunąć powyższe nieporozumienia.

Jeśli chcesz przeczytać więcej o testowaniu ręcznym, zajrzyj do linku tutaj.

Uwaga: ponieważ będziemy używać terminu 'Software Build’ wiele razy w artykule, zdefiniujmy go tutaj. „Software Build” to proces konwersji kodu źródłowego, w aplikację użytkownika, po wielu wersjach i zmianach kodu, a tworzenie oprogramowania obejmuje wiele procesów, takich jak”kontrola wersji, jakość kodu & Kompilacja”, a tworzenie oprogramowania jest również wynikiem tego procesu budowania. W tym artykule kompilacja będzie określana jako testowalna wersja oprogramowania.

testowanie dymu

testowanie dymu jest podejściem, które jest zwykle przeprowadzane na początkowych etapach rozwoju cyklu życia oprogramowania(SDLC), aby upewnić się, że podstawowe funkcje programu działają dobrze bez żadnych problemów. Jest on wykonywany przed wykonaniem jakichkolwiek szczegółowych testów funkcjonalnych oprogramowania.

głównym celem testowania dymu nie jest przeprowadzenie głębokich testów, ale sprawdzenie, czy podstawowe lub główne funkcje programu lub oprogramowania działają dobrze. Testowanie dymu ma na celu odrzucenie źle zepsutej kompilacji na początkowym etapie, aby zespół testujący nie tracił czasu na instalowanie & testowanie aplikacji.

testowanie dymu jest również nazywane testem weryfikacji kompilacji.

zobaczmy prosty przykład, w którym otrzymujesz aplikację e-mailową do przetestowania. Ważnymi funkcjami byłoby logowanie się do aplikacji e-mail, komponowanie wiadomości e-mail i wysyłanie jej, prawda? A jeśli e-mail nie zostanie wysłany, czy ma sens testowanie innych funkcji, takich jak wersje robocze, usunięte wiadomości, archiwa itp.? Oznacza to, że będziesz musiał zrezygnować z kompilacji bez dalszej walidacji. To się nazywa testowanie dymu.

głównym celem testowania dymu jest testowanie obszarów krytycznych, a nie kompletnej aplikacji.

kiedy przeprowadzić testowanie dymu

• kiedy Programiści dostarczą nowy build do zespołu QA. Nowy build oznacza tutaj, gdy build ma nowe zmiany wprowadzone przez deweloperów.
• gdy nowy moduł zostanie dodany do istniejącej funkcjonalności.

Automatyka & testowanie dymu:

zwykle jest to rodzaj testów, które są wykonywane przed uruchomieniem rzeczywistych przypadków testów automatyki. W przypadku organizacji, które mają wbudowane ciągłe testy, testowanie dymu jest równoznaczne z pomyślnym zainstalowaniem kompilacji w celu uruchomienia przypadków testowych lub wykonania pierwszego przypadku testowego. Tak więc nie jest to rodzaj testów, które są celowo zautomatyzowane, ale jeśli automatyzacja testów zostanie wprowadzona, automatyzacja testów może działać pomyślnie tylko wtedy, gdy oprogramowanie przejdzie testy dymu. Lub inaczej, pierwszy przypadek testowy, który wykonuje może się nie udać.

testowanie poczytalności

testowanie poczytalności to rodzaj testów wykonywanych w celu sprawdzenia, czy oprogramowanie działa poprawnie, gdy nowy moduł lub funkcjonalność zostanie zaimplementowana do istniejącego produktu. Sanity testing to technika testowania oprogramowania, która dokonuje szybkiej oceny jakości wydania oprogramowania w celu ustalenia, czy kwalifikuje się do dalszych rund testowania, czy nie.

testowanie rozsądku jest zwykle wykonywane po otrzymaniu dość stabilnej kompilacji oprogramowania lub czasami, gdy kompilacja oprogramowania mogła ulec niewielkim zmianom w kodzie lub funkcjonalności. Decyduje on, czy należy przeprowadzić dalsze testy oprogramowania od końca do końca.

testowanie Sanity jest również testowaniem na poziomie powierzchniowym, które pomaga w podjęciu decyzji, czy budowa oprogramowania jest wystarczająco dobra, aby przejść do następnego poziomu testowania.

po co przeprowadzać testy Sanity

• , aby zweryfikować i zweryfikować zgodność nowo dodanych funkcji i funkcji w istniejącym kodzie.
• aby wprowadzone zmiany nie miały wpływu na inne istniejące funkcjonalności produktu.
• aby zdecydować o dalszym testowaniu można przejść dalej lub nie.

kiedy należy przeprowadzić testowanie poprawności

• Build jest odbierany po wielu regresjach lub jeśli w kodzie jest niewielka zmiana.
• kompilacja jest odbierana po poprawieniu błędu.
• tuż przed wdrożeniem na produkcję.

Automatyzacja& testowanie poczytalności:

biorąc pod uwagę, testowanie poczytalności jest uważane za podzbiór testów regresji, są to przypadki testowe, które można zautomatyzować. Zalecane jest wykonanie tych przypadków testowych przed uruchomieniem pełnego zestawu testów regresji. Zaletą jest to, że jeśli są jakieś błędy w przypadkach testu zdrowego rozsądku, błędy można zgłaszać raczej wcześniej niż później.

testowanie regresji

testowanie regresji to weryfikacja „poprawek błędów lub jakichkolwiek zmian w wymaganiu” i upewnienie się, że nie wpływają one na inne funkcjonalności aplikacji. Testowanie regresji jest skuteczne w automatyzacji i zwykle wykonywane po wprowadzeniu pewnych modyfikacji w kompilacji oprogramowania po zmianach wymagań lub poprawkach błędów.

Po zakończeniu testowania poprawności zmienionej funkcjonalności wszystkie dotknięte funkcje aplikacji wymagają pełnego testowania. To się nazywa testowanie regresji.

ilekroć poprawki błędów są dokonywane w istniejącym oprogramowaniu, niektóre scenariusze testowe muszą zostać wykonane, aby zweryfikować poprawki. Oprócz tego zespół ds. kontroli jakości musi również sprawdzić dotknięte obszary na podstawie zmian w kodzie. W testach regresyjnych wszystkie te scenariusze testowe będą musiały zostać wykonane, aby zadbać o powiązane funkcjonalności.

kiedy wykonać test regresji

• po modyfikacji kodu zgodnie z wymaganymi zmianami
• Po dodaniu nowych funkcji do aplikacji
• Po dodaniu pewnych poprawek błędów do kompilacji

Automatyzacja& testowanie regresji:

przypadki testów regresji są w rzeczywistości idealnymi przypadkami testowymi dla automatu. Zazwyczaj, gdy organizacja rozpoczyna automatyzację, są to przypadki testowe, które są zautomatyzowane jako pierwsze. Jeśli testowanie regresyjne jest działaniem, które zajmuje dużo czasu dla testerów i te same przypadki testowe są powtarzane wiele razy, to jest czas, aby zacząć myśleć o automatyzacji zbyt.

Jeśli szukasz narzędzia, które pomoże Ci rozpocząć automatyzację, musisz również upewnić się, że wybierzesz odpowiednie narzędzie. Narzędzie, które może również zapewnić zwrot z inwestycji. Mamy przewodnik, który może Ci pomóc:

10 Points to Help You Choose the Right Test Automation Tool

Differences Between Smoke vs Sanity vs Regression Testing

kluczowe punkty

• testowanie dymu i rozsądku pomaga zespołowi ds. kontroli jakości zaoszczędzić czas, szybko testując, czy aplikacja działa prawidłowo, czy nie. Ponadto zapewnia, że produkt kwalifikuje się do dalszych testów. Podczas gdy testowanie regresji pomaga zwiększyć pewność co do jakości oprogramowania po konkretnej zmianie. Zwłaszcza, że zmiany w kodzie nie mają wpływu na powiązane obszary.

• testowanie dymu jest wykonywane zarówno przez zespół programistów, jak i przez zespół QA i może być traktowane jako podzbiór rygorystycznych testów. Podczas gdy oba testy regresji Sanity & są wykonywane tylko przez zespół QA. Ponadto testowanie poczytalności można uznać za podzbiór testów akceptacyjnych.

• testowanie dymu jest wykonywane na początkowym etapie SDLC, aby sprawdzić podstawowe funkcjonalności aplikacji. Podczas gdy Sanity & testy regresji są wykonywane na końcowym etapie SDLC, aby sprawdzić główne funkcjonalności aplikacji.

• zgodnie z wymogiem testowania& dostępność czasu, zespół ds. W takich przypadkach najpierw przeprowadza się testy dymu, a następnie testuje zdrowie psychiczne &, a następnie w oparciu o dostępność czasową planuje się test regresji.

w praktyce wszystkie zespoły QA muszą wykonywać testy dymu, rozsądku i regresji. Wszystkie te typy testów mają predefiniowaną liczbę przypadków testowych, które są wykonywane wielokrotnie. To powtarzalne wykonanie czyni je również idealnym kandydatem do automatyzacji testów. Szukając automatyzacji, zaleca się użycie narzędzia, które zapewnia zwrot z inwestycji w automatyzację od początkowych etapów. Testsigma jest jednym z takich narzędzi.