Smoke testing to proces, który jest używany do testowania oprogramowania w celu określenia, czy wdrożony build oprogramowania jest stabilny.
Kiedy testujesz oprogramowanie, wykonujesz serię testów zaprojektowanych w celu oceny każdej z podstawowych funkcjonalności oprogramowania.
Narzędzia Smoke testing sprawdzają, czy najważniejsze cechy oprogramowania działają. Istnieje wiele różnych podejść do testów dymnych, a współczesna technologia sprawia, że zautomatyzowane testy dymne są możliwe do wykonania w większości programów.
W tym artykule zamierzamy głęboko zanurkować w testowanie dymu, aby przejrzeć typy, procesy i podejścia do testowania dymu, których używają testerzy oprogramowania. Przyjrzymy się również nowoczesnym narzędziom do testowania dymu, w tym automatyzacji testów dymu.
W skrócie, dowiesz się wszystkiego, co kiedykolwiek będziesz musiał wiedzieć o testach dymu.
Czym jest smoke testing w inżynierii oprogramowania?
Smoke testing to proces testowania oprogramowania w celu zapewnienia, że spełnia ono podstawowe wymagania dotyczące funkcjonalności i stabilności. Jest to w zasadzie rodzaj miniaturowych, szybkich testów regresyjnych, które polegają na testowaniu najważniejszych funkcji oprogramowania, aby upewnić się, że działają one na podstawowym poziomie.
Smoke testing jest ważnym wczesnym krokiem w procesie QA, ponieważ wskazuje, czy zespół powinien kontynuować dalsze testy, czy też od razu odesłać produkt do deweloperów.
Jeśli produkt nie przejdzie swojego testu dymu, wskazuje to, że początkowy build ma znaczące wady, które muszą zostać usunięte przed dalszymi testami.
Kiedy należy wykonać badania dymu?
Testujemy oprogramowanie za każdym razem, gdy nowe funkcjonalności są rozwijane i integrowane z istniejącym buildem oraz przed wdrożeniem nowego builda do QA. Przeprowadzenie testów dymnych na tym etapie zapobiega marnowaniu pieniędzy i innych zasobów na testy QA dla oprogramowania z poważnymi problemami.
Aby przeprowadzić test dymu QA, zespół programistów wdraża nowy build oprogramowania w QA, a podzbiór przypadków testowych jest pobierany i uruchamiany na tym buildzie. Zespół QA testuje aplikację pod kątem jej najważniejszych funkcjonalności. Jeśli test dymu przejdzie, zespół QA będzie kontynuował testy funkcjonalne, a jeśli się nie powiedzie, build jest przekazywany z powrotem do zespołu programistów w celu dalszego rozwoju.
Takie testy dymne mają miejsce za każdym razem, gdy nowe funkcje są dodawane do kompilacji oprogramowania.
Mogą być inne czasy, że zespoły QA będą dymić oprogramowanie testowe, takie jak:
● Przed wysłaniem nowego kodu do repozytorium
● Przed dużą serią testów, w tym testów regresyjnych i akceptacyjnych
● Po wdrożeniu nowej wersji oprogramowania
Jeśli nie wykonasz smoke test w tych punktach, możesz skończyć na znalezieniu poważnych defektów w późniejszych etapach testowania funkcjonalności, co może wpłynąć na datę wydania nowego kompilatora lub spowodować poważniejsze zakłócenia w harmonogramie.
Kiedy nie trzeba wykonywać badania dymu
Ważne jest, aby przeprowadzać testy dymu w testowaniu oprogramowania, kiedy dokonujesz jakichkolwiek zmian w kodzie oprogramowania lub dodajesz nowe funkcje do kompilacji.
Jest to również istotny krok przygotowawczy do testów funkcjonalności, ponieważ zapobiega marnowaniu czasu przez zespoły QA na testowanie oprogramowania, które nie jest gotowe.
Jeśli Twoje oprogramowanie nie spełnia tych kryteriów, być może nie musisz przeprowadzać smoke testów w tym momencie… chociaż zautomatyzowane narzędzia do smoke testów sprawiają, że przeprowadzanie regularnych smoke testów w celu zapewnienia, że oprogramowanie zawsze działa prawidłowo, jest łatwe i opłacalne.
Kto bierze udział w badaniu dymu
Smoke testing jest przeprowadzany przez inżynierów QA lub kierownika QA; jest to pierwszy etap testowania QA i jest przeprowadzany w środowisku QA.
Zespół QA jest odpowiedzialny za testowanie budowy oprogramowania i ocenę jego działania w różnych warunkach i przy różnych obciążeniach. Podczas testów dymnych inżynierowie QA będą szukać „showstoppers”, czyli błędów, które wstrzymują rozwój i muszą być naprawione przed kontynuacją testów.
Porównując smoke testing vs sanity testing vs regression testing, ważne jest, aby wziąć pod uwagę nie tylko to, co jest testowane, ale także kto przeprowadza testy.
Smoke testing w testowaniu oprogramowania jest zawsze wykonywany przez specjalistów QA. To odróżnia smoke testing od sanity testing, które jest testowaniem wykonywanym w środowisku deweloperskim i zazwyczaj nie angażuje zespołu QA.
Cykl życia badania dymu
Cykl życia testu dymu ilustruje, gdzie występuje test dymu podczas rozwoju produktu i testowania QA. Zrozumienie każdego etapu tego cyklu pomoże ci zrozumieć więcej o tym, jak testowanie dymu pasuje do podróży testowej i różnic między testowaniem dymu vs sanity testing vs regression testing.
1. Kod
Pierwszym etapem budowy każdego oprogramowania jest zawsze pisanie i tworzenie kodu. Kod służy jako budulec każdego oprogramowania, a zespół programistów musi napisać kod, zanim będzie można go przetestować pod kątem stabilności i funkcjonalności.
2. Testy jednostkowe
Testy jednostkowe są zwykle przeprowadzane przez programistów, chociaż czasami inżynierowie QA mogą również wykonywać niektóre testy jednostkowe. Testy jednostkowe zapewniają, że różne jednostki lub elementy kodu działają zgodnie z oczekiwaniami, zanim poszczególne jednostki zostaną zintegrowane razem w jeden build oprogramowania.
Testowanie jednostkowe zwykle odbywa się równolegle z rozwojem, ponieważ uwydatnia błędy i usterki w kodzie, które można szybko naprawić.
3. Testy integracyjne
Testy integracyjne to proces testowania, jak poszczególne jednostki działają razem, gdy są zintegrowane w jeden kawałek oprogramowania.
Nawet jeśli każda oddzielna jednostka funkcjonuje dobrze, problemy mogą często pojawić się, gdy te jednostki są ze sobą zintegrowane. Testy integracyjne są zazwyczaj przeprowadzane przez programistów, chociaż różne podejścia do tego typu testów oznaczają, że mogą być one przeprowadzane na różnych etapach procesu tworzenia oprogramowania.
4. Testy poprawności
Testy sanity są rodzajem testów regresyjnych i zwykle są ostatnim rodzajem testów regresyjnych, które mają miejsce. Występuje on w fazie rozwoju kompilacji, po naprawieniu wszelkich błędów wskazanych przez testy regresji.
Sanity testing jest zwykle bardzo szybki i po prostu istnieje, aby zapewnić, że oprogramowanie działa płynnie i że wszelkie znalezione błędy zostały odpowiednio naprawione.
Smoke i sanity testing są czasami mylone, ale kluczowe jest, aby pamiętać, że sanity testing występuje w środowisku deweloperskim, podczas gdy smoke testy występują w środowisku QA.
5. Badanie dymu
Smoke testing jest pierwszym etapem testowania QA i pierwszym rodzajem testu, który jest przeprowadzany w środowisku QA.
Smoke testing zwykle występuje przed sanity testing i regression testing, mimo że jest zwykle przeprowadzany przez zespoły QA. Jest to szybki i prosty proces testowania – a w dzisiejszych czasach większość zespołów QA używa automatycznych testów dymnych w testowaniu oprogramowania – który określa, czy build jest stabilny i czy należy przeprowadzić dalsze testy.
Ponieważ smoke testing jest najszybszym i najprostszym testem, porównując smoke testing vs sanity testing vs regression testing, rozsądnie jest przeprowadzić go najpierw, zanim przejdziemy do innych, bardziej złożonych testów.
6. Testy funkcjonalne
Testowanie funkcjonalne jest kolejnym etapem cyklu życia testowania oprogramowania i jest przeprowadzane w środowisku QA.
Testowanie funkcjonalne testuje każdą funkcję aplikacji z jej wymaganiami i skupia się na funkcjach, użyteczności, dostępności i warunkach błędów.
Testy funkcjonalne można rozpocząć po przejściu testu dymu.
Aplikacje do badania dymu na różnych poziomach
Badanie dymu ma zastosowanie na trzech różnych poziomach badań: badanie dymu na poziomie akceptacji, badanie dymu na poziomie systemu oraz badanie dymu na poziomie integracji.
1. Poziom badania akceptacyjnego
Smoke testing na poziomie akceptacji jest zwykle przeprowadzany, gdy kompilacja oprogramowania jest przekazywana do QA. Ten typ testu dymu QA weryfikuje po prostu podstawową funkcjonalność kompilacji i czy jest ona zgodna z oczekiwaną funkcjonalnością.
2. Poziom badania systemu
Smoke testing na poziomie systemu polega na testowaniu najważniejszych przepływów pracy systemu. Przeprowadza się je po przetestowaniu samego systemu, a przed przeprowadzeniem pełnego testu regresji systemu.
Na poziomie systemu najbardziej rozpowszechnioną formą są zautomatyzowane testy dymne.
3. Poziom testów integracyjnych
Na poziomie testów integracyjnych, testy dymne zapewniają, że wszystkie funkcjonalności end-to-end oprogramowania działają zgodnie z oczekiwaniami, a podstawowa integracja jest funkcjonalna.
Ten rodzaj testów dymu zwykle występuje, gdy poszczególne moduły są wdrażane lub gdy wiele modułów jest zintegrowanych w jednym kompilatorze oprogramowania.
Ręczne i automatyczne testy dymu
Kiedy zespoły programistyczne po raz pierwszy zaczynają wykonywać smoke testy, muszą podjąć decyzję, czy będą przeprowadzać manualne smoke testy, czy automatyczne smoke testy.
Podczas gdy zautomatyzowane testy dymu zwykle oferują szybsze i bardziej opłacalne wyniki, mogą również zająć czas na stworzenie i wdrożenie. Wiele zespołów zaczyna od tworzenia ręcznych testów dymnych, zanim rozważy automatyzację w dalszej części linii.
1. Ręczne badanie dymu
Manualne testy dymu są dość łatwe do zaprojektowania i mogą być zazwyczaj wykonywane przez nietechnicznych profesjonalistów spoza zespołów QA lub deweloperskich. Oznacza to, że ręczne testy dymne są często preferowane w mniejszych firmach, które mogą nie mieć jeszcze dedykowanego lidera QA.
Podczas przeprowadzania ręcznych testów dymnych, ważne jest, aby przetestować pewną liczbę przypadków użycia, które obejmują wystarczająco dużo podstawowych funkcji oprogramowania, bez obejmowania tak wielu, że test dymny trwa zbyt długo. Zazwyczaj uważa się, że idealna liczba przypadków użycia wynosi od 20 do 50.
Korzyści wynikające z ręcznego wykonywania badań dymu
Istnieje wiele korzyści z przeprowadzania ręcznych testów dymnych w QA w porównaniu do automatycznych testów dymnych. Manualne testy dymne często oferują bardziej szczegółowy wgląd w wydajność i funkcjonalność oprogramowania w porównaniu do testów automatycznych.
Osoby nie będące inżynierami mogą wykonywać testy manualne
Podczas gdy zautomatyzowane testy dymne zwykle wymagają wiedzy specjalistycznej inżynierów oprogramowania i programistów, aby je skonfigurować, ręczne testy dymne mogą być przeprowadzane przez członków zespołu z mniej specjalistyczną wiedzą.
Jest to zazwyczaj korzystne w mniejszych zespołach, gdzie zasoby mogą być już mocno naciągnięte, a czas specjalistów jest niezwykle cenny.
Można utworzyć niestandardowy test dymu dla każdego zadania
Jeśli chcesz mieć pewność, że twój test dymu dokładnie pokrywa najważniejsze funkcje dowolnej aplikacji i skupia się na tych funkcjach, które są ważniejsze dla każdego kompilacji, tworzenie ręcznego testu dymu pozwala testerom dostosować test do każdego projektu.
Manualne testy dymu, takie jak ten, mogą zaoferować bardziej użyteczne wyniki w porównaniu do niektórych testów automatycznych, ale oznacza to, że są one niezwykle czasochłonne w konfiguracji i uruchomieniu.
Testy manualne ujawniają dane jakościowe
Kiedy uruchamiasz zautomatyzowany test dymu, wszystko, czego możesz oczekiwać, to dane ilościowe o tym, które aspekty testu przeszły, a które nie.
Kiedy członkowie zespołu przeprowadzają ręczne testy dymne, mogą wykorzystać swoją wiedzę, intuicję i osąd, aby ocenić nie tylko to, czy kompilacja przechodzi lub nie, ale jak i/lub dlaczego.
Wyzwania związane z ręcznym testowaniem dymu
Istnieje również wiele wyzwań związanych z ręcznym wykonywaniem testów dymu i dlatego wiele firm decyduje się na stosowanie automatycznych testów dymu tam, gdzie jest to możliwe.
Ręczne testy dymu są dokładne, ale są też bardzo czasochłonne.
Ręczne testy dymu pochłaniają czas
Ręczne testy dymu trwają znacznie dłużej niż testy automatyczne i wymagają znacznie więcej uwagi Twojego zespołu.
Podczas gdy testy automatyczne mogą po prostu działać w tle, Twój zespół będzie musiał wygospodarować czas na przeprowadzenie manualnych testów dymnych.
Testy manualne nie mogą być uruchamiane zbyt często
Ze względu na samą ilość czasu i zasobów, których wymagają manualne smoke testy, nie mogą być one przeprowadzane tak regularnie jak automatyczne smoke testy.
Wykonując manualny smoke test, testerzy oprogramowania muszą wygospodarować godziny, nawet pół dnia, w zależności od złożoności testu.
Usuwa to możliwość codziennego badania dymu, co jest powszechnie uważane za najlepszą praktykę w branży.
Zawsze jest miejsce na błędy
Ponieważ ludzie przeprowadzają testy ręczne, zawsze istnieje możliwość popełnienia błędów podczas ręcznych testów dymu.
Z tego powodu, ręczne testy dymne zazwyczaj nie są tak wszechstronne jak testy automatyczne, zwłaszcza jeśli chodzi o wychwytywanie subtelnych błędów, które łatwiej przeoczyć lub gdy przeprowadza się bardzo powtarzalne testy, które mogą spowodować, że testerzy stracą koncentrację podczas testów.
Kiedy należy stosować ręczne testy dymu
Ręczne testy dymu są najczęściej stosowane w mniejszych zespołach, które mogą nie mieć zasobów, aby oszczędzić inżynierów do zautomatyzowanych testów dymu, lub w przypadkach, gdy dodatkowy ludzki wgląd i osąd są pożądane lub potrzebne.
Z tego powodu w testach dymnych często wdrażane są ręczne testy na poziomie integracyjnym.
2. Zautomatyzowane badanie dymu
Zautomatyzowane testy dymne mogą być wdrożone przez inżynierów oprogramowania posiadających umiejętności kodowania niezbędne do stworzenia i uruchomienia serii odpowiednich przypadków użycia dla każdego kompilowanego oprogramowania.
Zautomatyzowane testy dymu są znacznie szybsze niż testy ręczne, zwykle zajmują nie więcej niż 30-60 minut, i mogą być przeprowadzane w tle, podczas gdy wszyscy członkowie zespołu rozwoju i QA kontynuują swoje codzienne zadania.
Z tego powodu, zautomatyzowane testy dymu stały się powszechne w branży oprogramowania, ponieważ coraz więcej firm stara się poprawić wydajność miejsca pracy.
Korzyści z automatyzacji testów dymnych
Automatyzacja testów smoke oferuje wiele korzyści dla tych firm, które mają czas i środki na jej wdrożenie. Jest szybki i skuteczny, a dzięki temu, że testy automatyczne nie obciążają zespołów i zasobów, mogą być przeprowadzane regularnie nawet w małych firmach.
Automatyczne testowanie jest szybkie
Zautomatyzowane testy dymu są znacznie szybsze niż testy manualne, przy czym większość zautomatyzowanych testów nie zajmuje więcej niż 30-60 minut.
Dla porównania testy manualne mogą trwać godzinami.
Zautomatyzowane testy dymne wymagają minimalnych zasobów i po ich wdrożeniu są bardzo łatwe do przeprowadzenia.
Dzięki automatyzacji możliwe są codzienne testy dymu
Obecne najlepsze praktyki branżowe nakazują, że codzienne testy dymu są idealnym rozwiązaniem, zwłaszcza gdy pracujemy nad oprogramowaniem, które jest stale w stanie zmian.
Manualne testy dymu są zbyt czasochłonne, aby uruchamiać je codziennie, ale automatyczne testy dymu są łatwe do przeprowadzenia na początku każdego dnia roboczego.
Automatyzacja eliminuje błędy ludzkie
Testy automatyczne uruchamiane są na podstawie przygotowanych wcześniej skryptów, tworzonych według ściśle określonych standardów. Oznacza to, że szansa na to, że test automatyczny przegapi poważny błąd lub ważne zagadnienie jest bardzo niska.
Automatyzacja może imitować testy obciążeniowe i wydajnościowe
Testy obciążeniowe i wydajnościowe oceniają, jak dobrze działa aplikacja, gdy korzysta z niej wielu użytkowników jednocześnie. Zautomatyzowane testy dymne mogą naśladować dodatkowe obciążenie wielu użytkowników w sposób, w jaki nie mogą tego robić testy ręczne, i dostarczać dodatkową warstwę danych na temat wydajności oprogramowania w określonych warunkach.
Wyzwania związane z automatyzacją testów dymnych
Automatyzacja testów smoke nie jest pozbawiona wyzwań. Wdrożenie zautomatyzowanych testów dymnych może być bardziej czasochłonne i wymagające zasobów, zwłaszcza w mniejszych zespołach, które mają do dyspozycji mniejszą liczbę inżynierów.
Wymagania techniczne
Zautomatyzowane testy dymu wymagają większej wiedzy technicznej i umiejętności kodowania niż manualne testy dymu. Inżynierowie oprogramowania muszą mieć czas i wiedzę, aby wiedzieć, jak tworzyć automatyczne testy, zanim zostaną one wdrożone, a nie wszystkie zespoły będą koniecznie miały dostępne zasoby, aby to zrobić.
Brak wglądu w człowieka
Testy automatyzacji oferują ogólny pogląd na funkcjonalność aplikacji, a podczas przeprowadzania automatycznego testu dymu, testerzy oprogramowania uzyskują wgląd w podstawowe funkcje oprogramowania, co jest ostatecznym celem testu dymu.
Jednak testy automatyczne nie oferują żadnego wglądu w bardziej subiektywne aspekty wydajności oprogramowania, takie jak użyteczność i dostępność.
Kiedy wdrożyć automatyzację testów dymnych
Automatyzacja jest często stosowana w smoke testing, ponieważ celem smoke testing jest po prostu sprawdzenie podstawowej funkcjonalności, co jest czymś, w czym testy automatyczne są stosunkowo dobre.
Zespoły posiadające wystarczające umiejętności techniczne do wdrożenia automatycznego badania dymu najprawdopodobniej mają czas i zasoby, aby zainwestować w ten proces, a większe, bardziej ugruntowane firmy prawdopodobnie będą odczuwać większą presję, aby spełnić standardy najlepszych praktyk w zakresie codziennego badania dymu.
Automatyzacja testów dymu a ręczne testy dymu
Nie ma dobrego lub złego sposobu na przeprowadzenie badania dymu, a to, co działa dobrze dla jednego zespołu, może nie działać dobrze dla innego.
Przed przeprowadzeniem testu dymu, zespoły programistów powinny rozważyć swoje cele, zasoby i długoterminowe plany projektu. Proces ręcznego testowania oprogramowania może być edukacyjny dla młodych profesjonalistów początkujących w QA, ale dla bardziej ustabilizowanych zespołów rzadko jest korzyść z wyboru testowania ręcznego nad automatycznym.
Badania dymu hybrydowego
Trzecią opcją dla zespołów, które nie mogą zdecydować się pomiędzy ręcznymi i automatycznymi testami dymu i sanity testing, jest wybór testowania hybrydowego.
Testowanie hybrydowe łączy aspekty zarówno ręcznych, jak i automatycznych testów dymnych, aby zwiększyć ogólną wydajność i efektywność testów. W przypadku stosowania hybrydowej metody badania dymu większość badania może być zautomatyzowana, ale niektóre aspekty mogą być wykonywane ręcznie. Pozwala to zespołom na skupienie większej uwagi na tych aspektach budowy, które tego wymagają, przy jednoczesnym zachowaniu niskiego czasu trwania testu dymnego.
Rodzaje badań dymu
Testy dymu można zasadniczo podzielić na dwie kategorie, formalne i nieformalne testy dymu. To, czy testy dymu są formalne czy nieformalne, zależy od tego, czy są one inicjowane przez kierownika działu QA formalnie, czy po prostu są przeprowadzane w ramach rozwoju.
1. Formalne badania dymu
W formalnym teście dymnym, programiści przekazują kompilację oprogramowania do inżyniera lub kierownika działu QA w celu przeprowadzenia formalnych testów. QA lead przydziela testerów do zadania smoke testing i prosi o wykonanie smoke test albo za pomocą narzędzi smoke testing takich jak automatyzacja lub ręcznie.
Podczas przeprowadzania formalnych testów dymnych, testerzy QA kompilują wyniki testu w formalny raport, który może być analizowany przez lidera QA.
Formalne testy dymu są przeprowadzane w ważnych punktach procesu budowy oprogramowania, na przykład przed wykonaniem testów funkcjonalnych nowych funkcji.
2. Nieformalne badania dymu
Nieformalne testy dymne to testy dymne wykonywane na kompilacji oprogramowania podczas procesu rozwoju lub procesu QA, które nie są formalnie raportowane lub wymagane przez kierownika QA.
Codzienne testy dymu, które wiele zespołów programistycznych przeprowadza w ramach protokołu, są przykładem nieformalnych testów dymu.
Nieformalne testy mogą być przeprowadzane ad hoc, gdy tylko inżynierowie QA uznają, że mogą być przydatne.
Czego potrzebujesz, aby rozpocząć testy dymu
Zanim zaczniesz testowanie dymu w testowaniu oprogramowania, ważne jest, aby zebrać wszystkie rzeczy, które będą potrzebne, w tym pliki danych i umiejętności w organizacji.
To, czego będziesz potrzebował do przeprowadzenia smoke test, będzie zależało od tego, czy planujesz przeprowadzić zautomatyzowane czy ręczne smoke testy, oraz od tego, jakich narzędzi testowych używasz, aby ułatwić ten proces.
1. Lista przypadków testowych
Zanim rozpoczniesz test dymu, będziesz potrzebował obszernej listy wszystkich przypadków testowych, które chcesz, aby twój test dymu ocenił.
Przypadki testowe to indywidualne zestawy działań, które chcesz przetestować, aby ocenić, czy wynik podjęcia tych działań jest zgodny z wynikami, których oczekujesz.
Na przykład bardzo prosty przypadek testowy może polegać na tym, że oprogramowanie ładuje główny pulpit nawigacyjny po otwarciu aplikacji.
2. Pliki testowe
Zanim uruchomisz swój test dymu, musisz zebrać wszystkie pliki testowe, na których zamierzasz uruchomić swój test dymu. Możesz być w stanie użyć wiersza poleceń oprogramowania do badania dymu, którego używasz, aby zebrać wszystkie pliki w jednym miejscu.
To, jak gromadzisz pliki i gdzie je przechowujesz, będzie zależało od tego, jak działa Twoja organizacja.
3. Narzędzia do badania dymu
Możesz wykonać podstawowy test dymu bez użycia konkretnych narzędzi, ale użycie narzędzi do testowania dymu może pomóc w poprawieniu dokładności wyników i przyspieszeniu procesu testowania dymu.
Badaj najpierw narzędzia do testowania dymu online i wybierz oprogramowanie, które automatyzuje lub optymalizuje twój test dymu w odniesieniu do twoich konkretnych potrzeb i budżetu.
Proces badania dymu
Najlepszy sposób przeprowadzania testów dymnych różni się w zależności od organizacji, a jeśli jesteś nowy w testowaniu dymnym, możesz chcieć eksperymentować z różnymi podejściami, aby zobaczyć, co działa najlepiej dla twojego zespołu.
Poniżej znajduje się przykład, jak przeprowadzić podstawowy test dymu, aby ocenić podstawowe funkcje twojego oprogramowania.
Krok 1: Wybierz swoje przypadki testowe
Pierwszym krokiem do przeprowadzenia testu dymu jest wybór przypadków testowych, na których zamierzasz przeprowadzić swój test dymu.
Podczas projektowania testu dymnego inżynierowie oprogramowania i inżynierowie QA powinni rozważyć, które funkcje oprogramowania są najbardziej krytyczne dla oprogramowania i jak najlepiej przetestować te funkcje. Nie trać czasu na testowanie funkcji, które nie są ważne dla działania oprogramowania.
Krok 2: Zbudowanie testów dymnych
Po zidentyfikowaniu przypadków testowych, które zamierzasz wykorzystać, możesz napisać skrypty testowe, aby je przetestować. Użyj pojedynczego skryptu dla testów dymu, aby zwiększyć elastyczność podczas uruchamiania testu.
Jeśli zdecydujesz się na automatyzację testów dymnych, nie będziesz musiał zawsze pisać ręcznych skryptów testowych za każdym razem, gdy chcesz uruchomić test dymny. Możesz użyć pakietów automatyzacji testów oprogramowania, aby zautomatyzować skrypty takie jak ten.
Krok 3: Przeprowadzenie testów dymnych
Po stworzeniu skryptów testów dymnych, możesz je uruchomić na swoim kompilatorze, aby poszukać błędów i innych poważnych błędów. Nie powinno to zająć więcej niż 30-60 minut, a po zakończeniu testów możesz ocenić wyniki, aby określić swoje kolejne kroki.
Krok 4: Napraw wszystkie błędy
Celem testów dymnych w rozwoju oprogramowania jest zidentyfikowanie wszelkich głównych błędów lub showstopperów, zanim rozpocznie się pełne testowanie QA.
Jeśli testy dymne ujawnią jakiekolwiek znaczące problemy, które zakłócają podstawowe funkcje budowanego oprogramowania, ważne jest, aby wysłać oprogramowanie i analizę z powrotem do zespołu programistów w celu naprawienia błędów przed kontynuowaniem QA.
Najlepsze praktyki w zakresie badania dymu
Smoke testing jest zaufanym sposobem na zidentyfikowanie głównych błędów w kompilacjach oprogramowania na wszystkich etapach rozwoju. Przestrzeganie najlepszych praktyk branżowych to najlepszy sposób na zapewnienie, że badania dymu są skuteczne, dokładne i wydajne.
1. Często przeprowadzaj testy dymu
Nie zawsze jest możliwe uruchamianie testów dymnych każdego dnia, zwłaszcza jeśli prowadzisz testy ręczne, a nie automatyczne testy dymne.
Uruchom testy dymu tak często, jak to możliwe, i za każdym razem, gdy wprowadzasz zmiany w swoim oprogramowaniu. Kiedy już jesteś w stanie, przeprowadzanie codziennych testów dymu jest uważane za najlepszą praktykę.
2. Nigdy nie pomijaj etapów testowania
Jeśli się spieszysz, może być kuszące, aby pominąć niektóre etapy testowania w celu szybszego postępu w procesie rozwoju, ale zarówno testy dymne, jak i regresyjne są niezbędne do utrzymania rozwoju na właściwym torze.
Zawsze testuj swoje kompilacje z dymem i sanity testing przed przejściem do następnego etapu.
3. Przetestuj każdą zmianę
Nie ma jednego zastosowania dla badań dymu. Możesz i powinieneś używać smoke testów do testowania każdej zmiany, którą wprowadzasz do kompilacji oprogramowania oraz do testowania oprogramowania pomiędzy różnymi etapami rozwoju.
Smoke testy powinny być prekursorem testów integracyjnych, wydajnościowych i funkcjonalnych.
4. Śledź wyniki swoich badań
Standardową praktyką jest testowanie wyników formalnego testu dymu, ale nawet podczas przeprowadzania nieformalnych testów dymu inżynierowie powinni zachować jakiś zapis wyników.
Ułatwia to przekazanie wyników z powrotem do deweloperów i śledzenie, które funkcje zawodzą w testach.
5. Przeprowadź dwukrotnie test dymu.
Dwukrotne uruchomienie testu dymnego może wydawać się przesadą, ale jeśli naprawdę chcesz wyłapać każdy błąd podczas testu, najlepiej jest uruchomić go dwukrotnie.
To gwarantuje, że twój test dymu ma każdą szansę na złapanie głównych błędów i problemów, które mogą spowodować dalsze problemy, jeśli nie zostaną natychmiast naprawione.
6. Wybierz właściwy rodzaj testu dymu
To, czy powinieneś używać ręcznych czy automatycznych testów dymu, zależy od wielkości i potrzeb twojego zespołu. Upewnij się, że wybierasz najlepszy typ testów dla swojego projektu, aby zoptymalizować wydajność bez utraty dokładności wyników.
Rodzaje danych wyjściowych z badania dymu
Kiedy przeprowadzasz test dymu, możesz oczekiwać, że twój test dymu spowoduje jeden z dwóch odrębnych wyników dla każdego przypadku testowego, który oceniasz: przejście lub niepowodzenie.
1. Podaj
Jednym z możliwych wyników dla każdego przypadku testowego, który uruchamiasz, jest to, że test dymu przechodzi. Oznacza to, że rzeczywisty wynik badania pokrywa się z oczekiwanym wynikiem badania.
Na przykład, jeśli uruchomisz test na to, co się stanie, gdy załadujesz aplikację i załaduje się ona do ekranu, który ma się otworzyć po załadowaniu, twój skrypt powinien wyświetlić to jako przepustkę.
2. Fail
Jeśli twój test dymny zakończy się niepowodzeniem dla konkretnego przypadku testowego, oznacza to zazwyczaj, że rzeczywisty wynik testu nie był zgodny z oczekiwanym wynikiem testu.
Na przykład, jeśli testujesz aplikację do robienia zakupów i jeden z przypadków testowych, które uruchamiasz, testuje funkcjonalność dodawania przedmiotów do koszyka, test jest nieudany, jeśli przedmioty, które dodajesz do koszyka, nie pojawiają się w nim tak, jak oczekujesz.
Przykłady przypadków testowych dla testów dymnych
Kiedy próbujesz wymyślić, które przypadki testowe włączyć do swojego testu dymu, napisz listę podstawowych funkcjonalności swojego oprogramowania i zastanów się, które z nich są niezbędne do uruchomienia i korzystania z oprogramowania.
Niektóre przykłady przypadków testowych dla testów dymu mogą pomóc w określeniu, które przypadki testowe należy wykorzystać we własnym teście dymu.
1. Zatwierdzanie poświadczeń logowania
Jeśli Twoja aplikacja wymaga od użytkowników logowania, możesz chcieć stworzyć przypadek testowy, który sprawdzi, czy proces walidacji poświadczeń logowania działa tak, jak powinien.
Aby to zrobić, utwórz skrypt, który zautomatyzuje ruchy logowania, uruchamiania testu i sprawdzania wyników. Jeśli oprogramowanie loguje się zgodnie z oczekiwaniami, ten przypadek testu dymu przechodzi.
2. Tworzenie nowego dokumentu
Możesz stworzyć przypadek testowy, aby ocenić, czy twoje oprogramowanie pozwala użytkownikom prawidłowo utworzyć nowy dokument. Utwórz skrypt, który zautomatyzuje tworzenie, nazywanie i zapisywanie dokumentów w Twoim programie i uruchom go.
Wszelkie istotne problemy, które pojawią się i uniemożliwią ten proces, oznaczałyby, że ten test dymu kończy się niepowodzeniem.
3. Wylogowanie się
Jeśli Twoja aplikacja ma funkcjonalność logowania, powinna mieć również funkcjonalność wylogowania. Uruchom skrypt, aby przetestować, co się stanie, gdy użytkownicy klikną „wyloguj się”.
Jeśli użytkownik nie może pomyślnie wylogować się po kliknięciu tego przycisku, test dymu kończy się niepowodzeniem.
Rodzaje błędów i usterek wykrywanych za pomocą smoke testów
Smoke testy mogą pomóc w identyfikacji błędów i bugów, które zakłócają podstawową funkcjonalność oprogramowania. W zależności od tego, kiedy przeprowadzasz swój smoke test i co chcesz sprawdzić, możesz znaleźć różne rodzaje błędów i bugów poprzez smoke testing.
1. Błędy funkcjonalne
Błędy funkcjonalne to błędy, które powstają, gdy Twoje oprogramowanie nie zachowuje się tak, jak byś tego oczekiwał, lub gdy nie działa prawidłowo.
Większość przypadków testowych, do których sprawdzenia użyjesz smoke testów, to testy funkcjonalne, a więc błędy funkcjonalne najprawdopodobniej zostaną zidentyfikowane przez smoke testy takie jak ten.
2. Błędy logiczne
Błędy logiczne reprezentują wady w logice kodu i mogą również powodować nieprawidłowe zachowanie oprogramowania. Błędy logiczne mogą powodować, że działania dają nieprawidłowe wyniki lub nawet powodują awarie oprogramowania.
Częstym błędem logicznym jest nieskończona pętla, która powoduje, że oprogramowanie powtarza te same czynności raz za razem, aż do awarii.
3. Błędy integracyjne
Jeśli prowadzisz test dymu na poziomie integracji, możesz znaleźć błędy integracyjne podczas testu. Występują one, gdy dwa oddzielne zestawy kodu nie integrują się ze sobą bezbłędnie. Mogą one być spowodowane szerokim zakresem problemów ze zgodnością w kodzie i mogą wymagać złożonych rozwiązań do naprawy.
Wspólne metryki badań dymu
Podczas przeprowadzania testu dymu zespoły QA mogą używać metryk do oceny wyników testu dymu i ocenić, czy test przeszedł lub nie.
Oprócz rozważenia, czy oprogramowanie jest w stanie prawidłowo wykonywać swoje podstawowe funkcje, metryka testu dymu może oceniać między innymi szybkość i czas ładowania oprogramowania.
1. Szybkość oprogramowania
Smoke testy mogą być użyte do sprawdzenia, czy szybkość i czas ładowania oprogramowania spełniają pewne kryteria określone w poszczególnych przypadkach testowych.
Na przykład, jeśli testujesz, jak zachowuje się oprogramowanie po załadowaniu aplikacji i aplikacja ładuje się zgodnie z oczekiwaniami, ale trwa dwie minuty, aby uruchomić się, możesz oznaczyć to jako Fail, ponieważ nie spełnia oczekiwanego czasu ładowania.
2. Niezawodność
Dwukrotne uruchomienie testu dymu może również pomóc w przetestowaniu niezawodności oprogramowania. Jeśli pewne przypadki testowe przechodzą raz, ale raz zawodzą, wskazuje to, że jakiś błąd w kodzie powoduje błędy, które mogą nie występować za każdym razem, gdy oprogramowanie jest używane, ale nadal mogą powodować poważne problemy dla użytkowników.
Najlepsze darmowe narzędzia do testowania dymu
Narzędzia do testowania dymu mogą pomóc w bardziej efektywnym i szybkim przeprowadzaniu testów dymu, aby pomóc Ci uzyskać jak najwięcej z Twoich testów dymu.
Poniżej przedstawiamy kilka najlepszych narzędzi do badania dymu, dostępnych dziś bez żadnych kosztów.
5 najlepszych darmowych narzędzi do badania dymu
1. ZAPTEST edycja FREE
ZAPTEST to darmowe narzędzie, które pozwala użytkownikom zautomatyzować testowanie oprogramowania i RPA bez płacenia ani centa.
Możesz użyć edycji ZAPTEST FREE do przeprowadzenia prostych testów dymnych na wielu platformach, w tym mobilnych, webowych, API i platform LOAD.
Jeśli chcesz wypróbować zautomatyzowane testy dymu, ZAPTEST darmowa edycja może pomóc Ci zobaczyć korzyści z automatyzacji z pierwszej ręki. Jest również łatwy w użyciu, nawet jeśli nie jesteś z wykształcenia technikiem, ponieważ posiada niekodowany interfejs i wykorzystuje najnowocześniejszą technologię Computer Vision.
Co najważniejsze, ZAPTEST FREE jest dobrze…. wolny na zawsze! W przeciwieństwie do tego, wiele narzędzi do testowania dymu i ogólnej automatyzacji oprogramowania ma początkowy okres testowy, po którym jesteś wciągany w płacenie opłat abonamentowych.
2. Selen
Selenium jest darmowym, open-source’owym narzędziem, które możesz wykorzystać do przeprowadzania różnych rodzajów testów na swoim oprogramowaniu, w tym testów dymnych i regresyjnych. Działa z wieloma różnymi językami programowania i jest szczególnie dobry do testowania aplikacji internetowych.
3. Appium
Jeśli chcesz wykonać testy dymu i sanity na aplikacjach mobilnych, Appium jest lepszym wyborem niż Selenium. Appium jest łatwy w instalacji i użyciu i może być używany do wykonywania prostych testów dymu na aplikacjach opracowanych zarówno dla systemu iOS, jak i Android.
4. Testlink
Testlink jest darmowym, internetowym narzędziem do zarządzania, które umożliwia użytkownikom tworzenie planów testów i przypadków testowych w ramach jednej struktury. Testlink może pomóc Ci zaplanować testy dymne, jak również nakreślić Twoje oczekiwania i metryki przed rozpoczęciem testów dymnych.
5. QA Wilk
QA Wolf to darmowe, kompleksowe narzędzie do testowania, które pozwala użytkownikom tworzyć zautomatyzowane testy dymu QA obok innych testów funkcjonalnych. QA Wolf może być używany nawet przez osoby bez umiejętności technicznych lub kodowania, co oznacza, że jest to świetne wprowadzenie do automatyzacji testów dla większości zespołów QA.
Najlepsze narzędzia do przeprowadzania testów dymnych w przedsiębiorstwach
Jeśli jesteś gotowy zainwestować trochę pieniędzy w narzędzia do testowania dymu, możesz kupić narzędzia korporacyjne, które mają bardziej rozbudowane możliwości testowania dymu i bardziej dokładne wyniki.
Poniżej znajduje się lista pięciu najlepszych na rynku narzędzi do automatyzacji testów dymu przedsiębiorstwa.
5 najlepszych narzędzi automatyzacji testów dymu w przedsiębiorstwach
1. ZAPTEST ENTERPRISE edycja
ZAPTEST ENTERPRISE edition to pakiet do testowania oprogramowania i RPA, który może w pełni zautomatyzować każdy rodzaj testu, w tym smoke testing.
Wersja darmowa jest odpowiednia dla mniejszych firm, które chcą wiedzieć, co ZAPTEST potrafi, ale jeśli szukasz płatnego rozwiązania, które jest łatwe w użyciu i nadaje się do testowania dowolnego oprogramowania lub aplikacji, na dowolnej platformie, przeglądarce lub urządzeniu, ORAZ z implementacją 1SCRIPT na wszystkich tych urządzeniach, to ZAPTEST ENTERPRISE jest świetnym miejscem, aby zacząć.
2. SoapUI
SoapUI to narzędzie do testowania w przedsiębiorstwie, które ułatwia zarządzanie i wykonywanie testów QA end-to-end na oprogramowaniu. Jest to stosunkowo proste narzędzie do zainstalowania, ale ma swoje ograniczenia, co znajduje odzwierciedlenie w ich punkcie cenowym.
3. Testim
Testim to płatne narzędzie do testowania dymu, które wykorzystuje AI do tworzenia bezkodowych testów, które oceniają funkcjonalność twojego oprogramowania. API Javascript Testima może być używane do refaktoryzacji, dostosowywania i debugowania testów.
4. T-Plan Robot
T-Plan Robot jest narzędziem testowym dla przedsiębiorstw, które inżynierowie QA mogą wykorzystać do automatyzacji skryptowych działań użytkowników i Robotic Process Automation (RPA) w systemach Windows, Mac, Linux i Mobile. Możesz użyć T-Plan Robot do zautomatyzowania testów dymnych na wielu aplikacjach i stworzyć automatyczne skrypty, które mogą być uruchamiane w kluczowych punktach podczas rozwoju.
5. Las deszczowy QA
Rainforest QA to narzędzie do testowania dymu QA, które pozwala użytkownikom zarządzać i wdrażać zarówno ręczne, jak i automatyczne testy dymu z jednego pulpitu nawigacyjnego. Dzięki temu jest to idealne rozwiązanie dla organizacji zainteresowanych wypróbowaniem podejścia hybrydowego i nadaje się do ogromnej liczby platform, w tym aplikacji opartych na chmurze, systemu Windows i Mac.
Kiedy powinieneś używać narzędzi do testowania dymu w wersji enterprise vs free?
Narzędzia do testowania dymu korporacyjnego i darmowego mogą spełniać podobne potrzeby w nieco inny sposób. Zazwyczaj, darmowe narzędzia służą jako doskonała brama dla organizacji, które są wygodne z ręcznymi testami dymu, ale chcą zbadać zautomatyzowane testy dymu bardziej szczegółowo.
Mogą też być bardziej odpowiednie dla bardzo małych start-upów, gdzie pieniędzy na płatne narzędzia po prostu jeszcze nie ma.
Narzędzia do testów korporacyjnych zwykle stają się bardziej realną opcją w miarę rozwoju firm. Oferują one szereg korzyści w stosunku do darmowych narzędzi, zwykle oferując większą elastyczność, lepsze wsparcie i bardziej przyjazne interfejsy, które ułatwiają nawet nietechnicznym profesjonalistom przeprowadzanie zautomatyzowanych testów dymu.
Lista kontrolna testów dymu
Przed rozpoczęciem testu dymu, zespół QA oprogramowania może użyć tej listy kontrolnej, aby upewnić się, że obejmują one każdy krok procesu testowania dymu.
● Zidentyfikuj narzędzia smoke testing, których będziesz używał
● Wybierz, czy zamierzasz stworzyć test ręczny czy automatyczny
● Wybierz przypadki testowe, które chcesz przetestować
● Tworzenie skryptów testowych dla każdego przypadku
● Określenie wymagań „pass” dla każdego przypadku testowego
Uruchomić testy dymu
● Przeanalizuj wyniki
Informacje zwrotne dla działu rozwoju i QA
Wniosek
Smoke testing jest niezbędnym krokiem w rozwoju oprogramowania i QA. Zapewnia, że produkt jest funkcjonalny przed dalszymi testami, co zapobiega ryzyku, że zespoły QA będą tracić czas i zasoby na przeprowadzanie intensywnych testów funkcjonalnych na buildach, które nie są jeszcze stabilne.
Smoke testing to stosunkowo szybki i prosty proces, który powinien być przeprowadzany przez zespoły programistów jak najczęściej.
W miarę jak przedsiębiorstwa dążą do osiągnięcia optymalnej wydajności poprzez wykorzystanie zaawansowanych narzędzi wspierających hiperautomatyzację, RPA i inne powiązane technologie, zautomatyzowane testy dymne stają się coraz bardziej powszechne w organizacjach każdej wielkości.
Zarówno ręczne jak i automatyczne testy dymu nadal mają swoje miejsce we współczesnych środowiskach QA, ale w miarę jak automatyczne testy stają się coraz bardziej powszechne, nie ma wątpliwości, że staną się one normą.
FAQ i zasoby
Jakie są najlepsze kursy dotyczące automatyzacji testów dymu?
Jeśli chcesz dowiedzieć się więcej o automatyzacji testów dymu, niektóre przykłady kursów online, które możesz wziąć to:
● Kursy Coursera z zakresu badania dymu tytoniowego
● Kursy Udemy z zakresu badania dymu tytoniowego
● Kursy Skillshare z zakresu badania dymu tytoniowego
Jednym z najlepszych kursów dla początkujących jest Certified Tester ISTQB Foundation Level (CTFL), dostępny na Udemy.
Każdy z tych zasobów online oferuje kursy testowania dymu dla uczniów o różnych umiejętnościach, i może być możliwe, aby wziąć zarówno darmowe i płatne kursy na tych stronach.
Jeśli chcesz uzyskać certyfikat, szukaj kursów, które są akredytowane przez CAST.
Jakie są najlepsze książki o testach dymu?
Jeśli chcesz dowiedzieć się więcej o testowaniu dymu, możesz przeczytać książki o testowaniu oprogramowania i testowaniu dymu, aby rozwinąć swoje zrozumienie podejść i korzyści z testowania dymu. Jedne z najlepszych książek na temat badania dymu to:
● Sztuka testowania oprogramowania, autorstwa Glenforda J Myersa, Toma Badgetta i Coreya Sandlera
● Testowanie oprogramowania, autorstwa Rona Pattona
● Software Test Automation, autorstwa Marka Fewstera i Dorothy Graham
Jednak istnieje wiele fantastycznych książek o testowaniu oprogramowania, które mogą pomóc ci zrozumieć więcej o tym, jak, co i jak testować.
Wybierz książkę, która do Ciebie przemawia i bardziej szczegółowo zgłębia tematy, które najbardziej Cię interesują.
Jakie jest 5 najlepszych pytań na rozmowie kwalifikacyjnej dotyczących testów dymnych?
Jeśli zastanawiasz się nad rozmową kwalifikacyjną na stanowisko, które może wiązać się z testami dymu, przygotuj się do rozmowy przygotowując swoje odpowiedzi na typowe pytania z rozmowy kwalifikacyjnej, takie jak:
● Kiedy jest właściwy czas na przeprowadzenie badania dymu?
● W jaki sposób zdecydowałbyś, które przypadki testowe wykorzystać w teście dymu?
● Czym różni się smoke testing od innych rodzajów testów, jak np. sanity testing?
● Jak duża wiedza z zakresu kodowania jest potrzebna do przeprowadzenia smoke testów?
● Co byś zrobił, gdyby test dymu zakończył się niepowodzeniem?
Jakie są najlepsze tutoriale na YouTube dotyczące testowania dymu?
Jeśli jesteś wzrokowcem, możesz użyć tych filmów z YouTube, aby dowiedzieć się więcej o testach dymu:
Edureka smoke testing tutorial
● Co to jest badanie dymu?
Smoke testing vs sanity testing
Jak utrzymać testy dymu?
Konserwacja testów dymnych polega na zapewnieniu, że testy dymne, które tworzysz, pozostaną zdrowe i istotne w miarę trwania projektu budowy oprogramowania.
Wykonuj codziennie testy dymne i twórz nowe przypadki testowe, gdy są potrzebne.
Możesz również zmaksymalizować korzyści ze swoich testów dymnych poprzez ścisłą współpracę z tymi programistami, których wkład nie poprawia jakości ich kodu.
Czym jest smoke testing w inżynierii oprogramowania?
Smoke testing w inżynierii oprogramowania jest również nazywany testem weryfikacji budowy i jest to prosty i szybki test zapewniający, że kompilacja oprogramowania jest stabilna.
Smoke testing jest używany do testowania podstawowych funkcjonalności kompilacji i służy jako wstępny test przed dalszymi testami QA.
Smoke testing vs sanity testing
Smoke i sanity testing to oba rodzaje testów, które obejmują szybkie testowanie podstawowych funkcjonalności oprogramowania lub produktu.
Jednakże, podczas gdy smoke testing testuje czy podstawowe funkcjonalności oprogramowania zachowywały się zgodnie z oczekiwaniami, sanity testing jest zwykle używany do sprawdzenia czy naprawy błędów naprawiły zidentyfikowane problemy.
Smoke testing jest bardziej formalnym i udokumentowanym procesem, który jest zwykle wykonywany przed zweryfikowaniem kompilacji jako stabilnej, podczas gdy sanity testing jest nieformalnym rodzajem testu, który może być przeprowadzony jako część testów regresyjnych na stosunkowo stabilnych kompilacjach.
Testy smoke a testy regresyjne
Testy dymne i regresyjne to oba rodzaje testów, które sprawdzają, czy oprogramowanie po wprowadzeniu nowych zmian nadal działa poprawnie.
Jednak testowanie dymu jest stosunkowo szybkim i mało dogłębnym rodzajem testowania, które po prostu sprawdza podstawowe funkcje i zapewnia, że oprogramowanie jest stabilne.
Testy regresyjne to testy na głębszym poziomie, które trwają znacznie dłużej i oceniają kompilację w sposób bardziej szczegółowy.
Smoke testing vs sanity testing vs regression testing
Kiedy porównujesz testy dymu i sanity z testami regresji, ważne jest, aby zrozumieć, że wszystkie trzy te rodzaje testów są niezbędne do dobrego rozwoju oprogramowania i QA.
Smoke testing i sanity testing oferują szybki sposób na sprawdzenie, czy oprogramowanie działa normalnie, podczas gdy testy regresyjne oferują głębszy wgląd w działanie produktu.
Zespoły QA najpierw testują oprogramowanie pod kątem dymu, a następnie, jeśli oprogramowanie przejdzie tę kontrolę, można przeprowadzić testy sanitarne, a później testy regresji.
Zautomatyzowane testowanie za pomocą narzędzi smoke testing staje się coraz bardziej powszechne, ale niektóre rodzaje testów, takie jak testy regresyjne, nie są jeszcze możliwe do pełnego zautomatyzowania ze względu na złożoną naturę testu.
Wreszcie, jeśli szukasz narzędzi do przeprowadzania testów na platformach Windows, iOS , Android, testów UI, Linux i wielu innych, to śmiało pobierz ZAPTEST FREE!
