Co to jest Testowanie Automatyzacyjne (Ultimate Guide to Start Test Automation)

Kompletny przewodnik do rozpoczęcia Testowania Automatyzacyjnego w Twoim projekcie:

Co to jest testowanie automatyczne?

Testowanie automatyczne jest techniką testowania oprogramowania mającą na celu przetestowanie i porównanie rzeczywistego wyniku z oczekiwanym. Można to osiągnąć poprzez pisanie skryptów testowych lub użycie dowolnego narzędzia do automatyzacji testów. Automatyzacja testów jest używana do automatyzacji powtarzających się zadań i innych zadań testowych, które są trudne do wykonania ręcznie.

Czy chcesz rozpocząć testy automatyzacji w swoim projekcie, ale zmagasz się z najbardziej podstawowymi krokami wymienionymi poniżej:

• Jak wprowadzić automatyzację do swojego projektu?
• Jak wybrać najlepsze i właściwe narzędzie do automatyzacji?
• Jak efektywnie rozwijać skrypty?
• Jak wykonywać i utrzymywać skrypty testowe?
• I w końcu jakie są najlepsze praktyki, których należy przestrzegać, aby odnieść sukces w testowaniu automatyzacji?

Dzisiaj, zaplanowaliśmy wzbogacić Twoją wiedzę o serię tutoriali na temat „Rozpoczęcia Testowania Automatyzacji”. Ta seria samouczków automatyzacji odpowie na wszystkie powyższe pytania w sposób krok po kroku z prostymi przykładami.

Przyjrzyjrzyjmy się serii samouczków na temat rozpoczęcia automatyzacji w twoim projekcie!!!

Automatyzacja End-to-end Process:

Samouczek #1: Najlepszy przewodnik do rozpoczęcia automatyzacji w twoim projekcie
Samouczek #2: Rodzaje testów automatycznych i kilka błędnych koncepcji
Samouczek #3: 10 kroków do wprowadzenia automatyzacji w twoim projekcie
Samouczek #4: Przewodnik od A do Z na temat wyboru najlepszego narzędzia do automatyzacji
Samouczek #5: Tworzenie skryptów i frameworków automatyzacji
Samouczek #6: Egzekucja i raportowanie automatyzacji
Tutorial #7: Najlepsze praktyki i strategie automatyzacji testów

Wskazówki dotyczące automatyzacji:

Tutorial #8: 10 wskazówek, które powinieneś przeczytać przed automatyzacją testów
Tutorial #9: Jak różni się planowanie testów dla projektów manualnych i automatycznych
Tutorial #10: Kiedy zdecydować się na automatyzację?
Tutorial #11: Wyzwania związane z testami automatycznymi
Tutorial #12: Przewodnik jak wdrożyć Proof of Concept (POC) w automatyce
Tutorial #13: Jak wybrać prawidłowe przypadki testowe do automatyzacji
Tutorial #14: Jak przetłumaczyć manualne przypadki testowe na skrypty automatyzacji

Automatyzacja kariery:

Tutorial #15: Tips to Become a Better Automation Tester
Tutorial #16: Test Automation – Is it a Specialized Career? Can Normal Testers Do Automation Also?

Popularne narzędzia do automatyzacji:

Tutorial #17: Selenium Tutorials 31+ Best Free Selenium Training Tutorials
Tutorial #18: QTP Tutorials
Tutorial #19: SoapUI Web Services Testing Tool
Tutorial #20: HP LoadRunner for Performance Testing

Automation Frameworks:

Tutorial #21: Why Do We Need Framework for Automation

Tutorial #22: Most Popular Automation Frameworks

Automation in Agile:

Tutorial #23: How to Implement Efficient Automation in the Agile World

Other Automation Tools:

Tutorial #24: Best Automation Test Tools
Tutorial #25: Sikuli GUI Automation Tool
Tutorial #26: PowerShell: Desktop Application UI Automation With PowerShell
Tutorial #27: Katalon Automation Recorder (Selenium IDE Alternative)
Tutorial #28: Geb Tool: Automatyzacja przeglądarki przy użyciu Geb Tool
Tutorial #29: AutoIt: How to Handle Windows Pop-up Using AutoIt
Tutorial #30: Cucumber: Automation Using Cucumber Tool and Selenium
Tutorial #31: Protractor Testing Tool for End-to-end Testing of AngularJS Applications

Mobile Automation Testing:

Tutorial #32: Appium Studio Hands-on Tutorial
Tutorial #33: Appium Tutorial for Beginners
Tutorial #34: Selendroid Tutorial: Android Mobile Automation Framework
Tutorial #35: Ranorex Tutorial: A Powerful Desktop, Web, and Mobile Testing Tool

Przykłady automatyzacji dla konkretnych dziedzin:

Tutorial #36: Automatyzacja aplikacji JAVA/J2EE

Przygotowanie do rozmowy kwalifikacyjnej na stanowiska związane z automatyzacją:

Tutorial #37: Pytania kwalifikacyjne dotyczące testowania automatyzacyjnego
Tutorial #38: Pytania kwalifikacyjne dotyczące Selenium

Poznajmy pierwszy samouczek z serii „The Ultimate Guide to Automation Testing”!

Czym są testy automatyzacji?

Jeśli oprogramowanie może zrobić wszystko, to dlaczego oprogramowanie nie może testować oprogramowania?

Czy to stwierdzenie brzmi dla ciebie logicznie?

Jeśli tak, to gratulacje, myślisz teraz o Automatyzacji Testów, która jest centralnym punktem, który zamierzamy omówić w tej serii pouczających poradników.

Wyobraź sobie siebie pierwszego dnia w pracy jako SQA. Jesteś przedstawiony z aplikacją do przetestowania. Jest to aplikacja ERP zawierająca 100s formularzy i tysiące raportów. Zaczynasz swoje testy eksploracyjne, otwierając formularz, który zawiera około 50 różnych pól.

Próbujesz wprowadzić losowe dane w tym formularzu, który zajął około 20 minut. Następnie naciskasz submit. Wolla!!! Pojawia się komunikat o błędzie, który wygląda jak nieobsługiwany wyjątek. Stajesz się bardzo szczęśliwy. Z dumą notujesz kroki i zgłaszasz błąd w swoim systemie zarządzania błędami. Wielki wysiłek, czujesz się naprawdę pewny siebie i pełen energii. Kontynuujesz testowanie do końca dnia i znajdujesz jeszcze kilka błędów. „Niesamowity pierwszy dzień”, pomyślałeś.

Nadchodzi kolejny dzień, deweloper naprawił problem i wypuszcza nową wersję builda. Testujesz ten sam formularz z tymi samymi krokami i okazuje się, że błąd został naprawiony. Oznaczasz go jako naprawiony. Wielki wysiłek. Przyczyniłeś się do poprawy jakości produktu poprzez zidentyfikowanie tego błędu, a ponieważ został on naprawiony, jakość produktu uległa poprawie.

Teraz nadchodzi trzeci dzień, deweloper ponownie wydał nowszą wersję. Teraz znów musisz przetestować ten formularz, aby upewnić się, że nie ma problemu z regresją. Te same 20 minut. Teraz czujesz się trochę znudzony.

Wyobraź sobie, że 1 miesiąc od teraz, ciągle wypuszczane są nowsze wersje i na każdym wydaniu, musisz przetestować ten długi formularz plus 100 innych podobnych, tylko po to, aby upewnić się, że nie ma regresji.

Teraz czujesz się zły. Czujesz się zmęczony. Zaczynasz pomijać kroki. Wypełniasz tylko około 50% wszystkich pól. Twoja dokładność nie jest taka sama, Twoja energia nie jest taka sama i na pewno Twoje kroki nie są takie same.

I pewnego dnia klient zgłasza ten sam błąd w tym samym formularzu. Czujesz się żałośnie. Czujesz się teraz niepewnie. Myślisz, że nie jesteś wystarczająco kompetentny. Menedżerowie kwestionują Twoje umiejętności.

Mam dla Ciebie wiadomość; to jest historia 90% testerów manualnych. Ty nie jesteś inny.

Problemy związane z regresją są najbardziej bolesne. Jesteśmy ludźmi. I nie możemy robić tych samych rzeczy z taką samą energią, szybkością i dokładnością każdego dnia. To jest to, co robią maszyny. Do tego właśnie potrzebna jest automatyzacja, aby powtarzać te same czynności z taką samą szybkością, dokładnością i energią, jak za pierwszym razem.

Mam nadzieję, że rozumiesz o co mi chodzi!!!

Gdy tylko pojawi się taka sytuacja, powinieneś zautomatyzować swój przypadek testowy. Automatyzacja testów jest Twoim przyjacielem. Pomoże Ci ona skupić się na nowej funkcjonalności, jednocześnie dbając o regresje. Dzięki automatyzacji, możesz wypełnić ten formularz w mniej niż 3 minuty.

Skrypt wypełni wszystkie pola i poinformuje Cię o wyniku wraz ze zrzutami ekranu. W przypadku niepowodzenia, może wskazać miejsce, w którym test się nie powiódł, co pomoże Ci odtworzyć go z łatwością.

Automatyzacja – Efektywna kosztowo metoda testowania regresji

Koszty automatyzacji są początkowo naprawdę wyższe. Obejmuje on koszt narzędzia, następnie koszt zasobu testującego automatyzację i jego szkolenia.

Ale kiedy skrypty są gotowe, mogą być wykonywane setki razy wielokrotnie z tą samą dokładnością i dość szybko. Pozwoli to na zaoszczędzenie wielu godzin testów manualnych. Tak więc koszt stopniowo spada i ostatecznie staje się to opłacalną metodą testowania regresji.

Scenariusze, które wymagają automatyzacji

Powyższy scenariusz nie jest jedynym przypadkiem, kiedy będziesz potrzebował automatyzacji testów. Istnieje kilka sytuacji, których nie da się przetestować ręcznie.

Na przykład,

1. Porównanie dwóch obrazów piksel po pikselu.
2. Porównanie dwóch arkuszy kalkulacyjnych zawierających tysiące wierszy i kolumn.
3. Testowanie aplikacji pod obciążeniem 100 000 użytkowników.
4. Performance Benchmarks.
5. Testowanie aplikacji na różnych przeglądarkach i na różnych systemach operacyjnych równolegle.

Te sytuacje wymagają i powinny być, testowane przez narzędzia.

Więc, kiedy automatyzować?

Jest to era zwinnej metodyki SDLC, gdzie rozwój i testowanie będą przebiegać prawie równolegle i bardzo trudno jest zdecydować, kiedy automatyzować.

Przed przystąpieniem do automatyzacji należy rozważyć następujące sytuacje

• Produkt może być w fazie prymitywnej, kiedy produkt nie ma nawet UI, na tych etapach musimy mieć jasną myśl, co chcemy zautomatyzować. Należy pamiętać o następujących kwestiach.
  • Testy nie powinny być przestarzałe.
  • W miarę jak produkt będzie ewoluował, powinno być łatwo wybrać skrypty i dodać do nich kolejne.
  • Bardzo ważne jest, aby nie dać się ponieść i upewnić się, że skrypty są łatwe do debugowania.
• Nie próbuj automatyzacji UI na początkowych etapach, ponieważ UI podlega częstym zmianom, co doprowadzi do niepowodzenia skryptów. W miarę możliwości zdecyduj się na automatyzację na poziomie API/nie UI, dopóki produkt się nie ustabilizuje. Automatyzacja API jest łatwa do naprawienia i debugowania.

Jak zdecydować o najlepszych przypadkach automatyzacji:

Automatyzacja jest integralną częścią cyklu testowego i bardzo ważne jest, aby zdecydować, co chcemy osiągnąć dzięki automatyzacji, zanim zdecydujemy się na automatyzację.

Korzyści, które automatyzacja wydaje się zapewniać są bardzo atrakcyjne, ale w tym samym czasie, źle zorganizowany zestaw automatyzacji może zepsuć całą grę. Testerzy mogą skończyć na debugowaniu i poprawianiu skryptów przez większość czasu, co skutkuje stratą czasu na testowanie.

Ta seria wyjaśni Ci, w jaki sposób pakiet automatyzacji może być wystarczająco efektywny, aby wyłapać właściwe przypadki testowe i przynieść właściwe rezultaty przy użyciu skryptów automatyzacji, które posiadamy.

Oto również odpowiedzi na takie pytania jak: Kiedy automatyzować, Co automatyzować, Czego nie automatyzować i Jak strategicznie automatyzować.

Właściwe testy do automatyzacji

Najlepszym sposobem na rozwiązanie tego problemu jest szybkie wymyślenie „Strategii Automatyzacji”, która pasuje do naszego produktu.

Pomysł polega na pogrupowaniu przypadków testowych tak, aby każda grupa dała nam inny rodzaj rezultatu. Ilustracja poniżej pokazuje, jak moglibyśmy pogrupować nasze podobne przypadki testowe, w zależności od produktu/rozwiązania, które testujemy.

Zanurzmy się teraz głęboko i zrozummy, co każda grupa może nam pomóc osiągnąć:

#1) Zrób zestaw testów wszystkich podstawowych funkcjonalności Pozytywne testy. Ten zestaw powinien być zautomatyzowany, a kiedy jest uruchamiany w dowolnym kompilatorze, wyniki są pokazywane natychmiast. Każdy skrypt, który zawiedzie w tym zestawie prowadzi do defektu S1 lub S2, a ten konkretny build może zostać zdyskwalifikowany. W ten sposób zaoszczędziliśmy sporo czasu.

Jako dodatkowy krok, możemy dodać ten zautomatyzowany zestaw testów jako część BVT (Build verification tests) i sprawdzić skrypty automatyzacji QA w procesie budowania produktu. Tak więc, gdy build jest gotowy testerzy mogą sprawdzić wyniki testów automatyzacji i zdecydować czy build jest odpowiedni czy nie do instalacji i dalszego procesu testowania.

To wyraźnie osiąga cele automatyzacji, którymi są:

• Zmniejszenie wysiłku testowania.
• Znalezienie błędów na wcześniejszych etapach.

#2) Następnie mamy grupę testów End to End.

W przypadku dużych rozwiązań, testowanie funkcjonalności end to end jest kluczowe, szczególnie w krytycznych fazach projektu. Powinniśmy mieć kilka skryptów automatyzacji, które dotykają również testów end to end rozwiązania. Kiedy ten zestaw jest uruchamiany, wynik powinien wskazywać, czy produkt jako całość działa tak, jak się tego oczekuje, czy nie.

Pakiet testów automatycznych powinien być wskazany, jeśli którykolwiek z elementów integracji jest uszkodzony. Pakiet ten nie musi obejmować każdej małej cechy/funkcjonalności rozwiązania, ale powinien obejmować działanie produktu jako całości. Ilekroć mamy alfa lub beta lub inne pośrednie wydania, wtedy takie skrypty są przydatne i dają pewien poziom zaufania do klienta.

Aby lepiej zrozumieć, załóżmy, że testujemy portal zakupów online, jako część testów end to end powinniśmy pokryć tylko kluczowe kroki zaangażowane.

As Given Below:

• Logowanie użytkownika.
• Przeglądanie i wybieranie przedmiotów.
• Opcja płatności – to obejmuje testy front-end.
• Backend zarządzania zamówieniami (obejmuje komunikację z wieloma zintegrowanymi partnerami, sprawdzanie zapasów, wysyłanie wiadomości e-mail do użytkownika itp.) – pomoże to w testowaniu integracji poszczególnych elementów, a także sedna produktu.

Więc kiedy jeden taki skrypt jest uruchomiony, daje pewność, że rozwiązanie jako całość działa dobrze.Na przykład, możemy mieć funkcjonalność przeglądania i wybierania pliku, więc kiedy to zautomatyzujemy, możemy zautomatyzować przypadki, aby włączyć wybór różnych typów plików, rozmiarów plików itp. Kiedy pojawią się jakiekolwiek zmiany/dodatki do tej funkcjonalności, ten zestaw może służyć jako zestaw do testowania regresji.

#4) Następne na liście byłyby testy oparte na UI. Możemy mieć inny zestaw, który będzie testował funkcjonalności oparte wyłącznie na UI, takie jak paginacja, ograniczenie znaków w polu tekstowym, przycisk kalendarza, rozwijane listy, wykresy, obrazy i wiele innych funkcji skupionych wyłącznie na UI. Niepowodzenie tych skryptów nie jest zazwyczaj bardzo krytyczne, chyba że UI jest całkowicie uszkodzone lub niektóre strony nie pojawiają się zgodnie z oczekiwaniami!

#5) Możemy mieć jeszcze jeden zestaw testów, które są proste, ale bardzo pracochłonne do wykonania ręcznie. Nudne, ale proste testy są idealnymi kandydatami do automatyzacji, na przykład wprowadzenie danych 1000 klientów do bazy danych ma prostą funkcjonalność, ale jest niezwykle żmudne do wykonania ręcznie, takie testy powinny być zautomatyzowane. Jeśli nie, to najczęściej kończą się one ignorowaniem i nie są testowane.

Czego NIE automatyzować?

Podajemy poniżej kilka testów, które nie powinny być automatyzowane.

#1) Testy negatywne/testy failover

Nie powinniśmy próbować automatyzować testów negatywnych lub failover, ponieważ w przypadku tych testów testerzy muszą myśleć analitycznie, a testy negatywne nie są tak naprawdę proste, aby dać wynik pozytywny lub negatywny, który może nam pomóc.

Testy negatywne będą wymagały dużo ręcznej interwencji, aby zasymulować rzeczywisty scenariusz disaster recovery. Dla przykładu, testujemy takie cechy jak niezawodność usług sieciowych – uogólniając, głównym celem takich testów byłoby wywołanie celowych awarii i sprawdzenie jak dobrze produkt radzi sobie z niezawodnością.

Symulacja powyższych awarii nie jest prosta, może wymagać wstrzyknięcia kilku stubów lub użycia kilku narzędzi pomiędzy nimi, a automatyzacja nie jest tutaj najlepszym rozwiązaniem.

#2) Testy ad hoc

Testy te mogą nie być tak naprawdę istotne dla produktu przez cały czas i może to być nawet coś, o czym tester mógłby pomyśleć na tym etapie inicjacji projektu, a także wysiłek włożony w automatyzację testu ad hoc musi być zweryfikowany pod kątem krytyczności cechy, której testy dotyczą.

Na przykład, tester, który testuje funkcję, która zajmuje się kompresją/szyfrowaniem danych, mógł wykonać intensywne testy ad-hoc z różnymi danymi, typami plików, rozmiarami plików, uszkodzonymi danymi, kombinacją danych, używając różnych algorytmów, na kilku platformach itd.

Gdy planujemy automatyzację, możemy chcieć ustalić priorytety i nie robić wyczerpującej automatyzacji wszystkich testów ad hoc dla tej cechy, a skończyć z odrobiną czasu na automatyzację innych kluczowych cech.

#3) Testy z masywną konfiguracją wstępną

Są testy, które wymagają ogromnych wymagań wstępnych.

Na przykład, możemy mieć produkt, który integruje się z oprogramowaniem innej firmy dla niektórych funkcji, ponieważ produkt integruje się z dowolnym systemem kolejek komunikacyjnych, który wymaga instalacji w systemie, ustawienia kolejek, utworzenia kolejek itp.

Programem strony trzeciej może być cokolwiek, a konfiguracja może być złożona i jeśli takie skrypty są zautomatyzowane to na zawsze będą zależne od funkcji/konfiguracji tego oprogramowania strony trzeciej.

Wymagania wstępne obejmują:

W chwili obecnej sprawy mogą wyglądać prosto i czysto, ponieważ obie strony są skonfigurowane i wszystko jest w porządku. Widzieliśmy wiele razy, że kiedy projekt wchodzi w fazę konserwacji, jest przenoszony do innego zespołu, a oni kończą debugowanie takich skryptów, gdzie rzeczywisty test jest bardzo prosty, ale skrypt zawodzi z powodu problemu z oprogramowaniem strony trzeciej.

Powyższe jest tylko przykładem, ogólnie rzecz biorąc, miej oko na testy, które mają pracochłonne wstępne ustawienia dla prostego testu, który następuje.

Proste przykłady automatyzacji testów

Gdy testujesz oprogramowanie (w sieci lub na pulpicie), zwykle używasz myszki i klawiatury, aby wykonać swoje kroki. Narzędzie automatyzacji naśladuje te same kroki używając skryptów lub języka programowania.

Na przykład, jeśli testujesz kalkulator i przypadek testowy jest taki, że musisz dodać dwie liczby i zobaczyć wynik. The script will perform the same steps by making use of your mouse and keyboard.

The example is shown below.

Manual Test Case Steps:

1. Launch Calculator
2. Press 2
3. Press +
4. Press 3
5. Press =
6. The screen should display 5.
7. Close Calculator.

Automation Script:

//the example is written in MS Coded UI using c# language.public void TestCalculator(){//launch the applicationvar app = ApplicationUnderTest.Launch("C:\\Windows\\System32\\calc.exe");//do all the operationsMouse.Click(button2);Mouse.Click(buttonAdd);Mouse.Click(button3);Mouse.Click(buttonEqual);//evaluate the resultsAssert.AreEqual("5", txtResult.DisplayText,”Calculator is not showing 5);//close the applicationapp.Close();}

The above script is just a duplication of your manual steps. The script is easy to create and easy to understand as well.

What are Assertions?

The second last line of the script needs some more explanation.

Assert.AreEqual(„5”, txtResult.DisplayText,”Calculator is not showing 5);

In every test case, we have some expected or predicted result at the end. In the above script, we have an expectation that „5” should be shown on the screen. The actual outcome is the result that is displayed on the screen. W każdym przypadku testowym, porównujemy oczekiwany wynik z rzeczywistym wynikiem.

To samo dotyczy również testów automatycznych. Jedyna różnica polega na tym, że kiedy robimy to porównanie w automatyce testowej, to w każdym narzędziu nazywa się to inaczej.

Niektóre narzędzia nazywają to „asercją”, inne „punktem kontrolnym”, a jeszcze inne „walidacją”. Ale w zasadzie jest to tylko porównanie. Jeśli to porównanie nie powiedzie się, np. ekran pokazuje 15 zamiast 5, wtedy ta asercja/punkt kontrolny/walidacja nie powiedzie się i twój przypadek testowy zostanie oznaczony jako nieudany.

Gdy przypadek testowy nie powiedzie się z powodu asercji, oznacza to, że wykryłeś błąd poprzez automatyzację testów. Musisz zgłosić go do systemu zarządzania błędami, tak jak robisz to normalnie w testach manualnych.

W powyższym skrypcie, wykonaliśmy asercję w drugiej ostatniej linii. 5 jest oczekiwanym wynikiem, txtResult. DisplayText jest rzeczywistym wynikiem i jeśli nie są one równe, zostanie nam wyświetlony komunikat, że „Kalkulator nie pokazuje 5”.

Wniosek

Często testerzy napotykają terminy projektów i mandaty do automatyzacji wszystkich przypadków, aby poprawić szacunki testowania.

Istnieją pewne powszechne „błędne” wyobrażenia na temat automatyzacji. Są to:

• Możemy zautomatyzować każdy przypadek testowy.
• Automatyzacja testów ogromnie zredukuje czas testowania.
• Żadne błędy nie zostaną wprowadzone, jeśli skrypty automatyzacji będą działać płynnie.

Powinniśmy mieć jasność, że automatyzacja może zredukować czas testowania tylko dla pewnych typów testów. Zautomatyzowanie wszystkich testów bez żadnego planu lub sekwencji doprowadzi do powstania masywnych skryptów, które są ciężkie w utrzymaniu, często zawodzą i wymagają dużo ręcznej interwencji. Ponadto, w ciągle ewoluujących produktach, skrypty automatyzacji mogą stać się przestarzałe i wymagać ciągłych kontroli.

Zgrupowanie i zautomatyzowanie odpowiednich kandydatów zaoszczędzi mnóstwo czasu i da wszystkie korzyści automatyzacji.

Ten doskonały samouczek można podsumować w zaledwie 7 punktach.

Testowanie automatyczne:

• Jest to testowanie, które jest wykonywane programowo.
• Używa narzędzia do kontroli wykonania testów.
• Porównuje oczekiwane wyniki z rzeczywistymi (Assertions).
• Może zautomatyzować niektóre powtarzalne, ale konieczne zadania (np. Twoje przypadki testów regresji).
• Może zautomatyzować niektóre zadania, które są trudne do wykonania ręcznie (np.scenariusze testów obciążeniowych).
• Skrypty mogą być uruchamiane szybko i wielokrotnie.
• Jest efektywna kosztowo na dłuższą metę.

Tutaj, Automatyzacja jest wyjaśniona w prosty sposób, ale to nie znaczy, że zawsze jest prosta do wykonania. Istnieją wyzwania, ryzyko i wiele innych przeszkód z tym związanych. Istnieje wiele sposobów, przez które automatyzacja testów może pójść źle, ale jeśli wszystko pójdzie dobrze, to korzyści z automatyzacji testów są naprawdę ogromne.

Następne w tej serii:

W naszych nadchodzących tutorialach, omówimy kilka aspektów związanych z automatyzacją.

Należą do nich:

1. Typy testów automatycznych i kilka błędnych koncepcji.
2. Jak wprowadzić automatyzację w swojej organizacji i uniknąć typowych pułapek podczas automatyzacji testów.
3. Proces wyboru narzędzia i porównanie różnych narzędzi do automatyzacji.
4. Rozwój skryptów i frameworków automatyzacji z przykładami.
5. Wykonywanie i raportowanie automatyzacji testów.
6. Najlepsze praktyki i strategie automatyzacji testów.

.