Co to jest testowanie oprogramowania? 100+ Free Manual Testing Tutorials

A Complete Software Testing Guide with 100+ Manual Testing Tutorials with Testing Definition, Types, Methods, and Process Details:

What is Software Testing?

Testowanie oprogramowania jest procesem weryfikacji i walidacji funkcjonalności aplikacji w celu stwierdzenia, czy spełnia ona określone wymagania. Jest to proces znajdowania defektów w aplikacji i sprawdzania, gdzie aplikacja funkcjonuje zgodnie z wymaganiami użytkownika końcowego.

Co to jest testowanie ręczne?

Testowanie ręczne jest procesem, w którym porównuje się zachowanie opracowanego fragmentu kodu (oprogramowania, modułu, API, funkcji, itp.) z oczekiwanym zachowaniem (Wymaganiami).

Lista samouczków ręcznego testowania oprogramowania

To jest najbardziej dogłębna seria samouczków na temat testowania oprogramowania. Przejdź przez tematy wymienione w tej serii uważnie, aby nauczyć się podstawowych i zaawansowanych technik testowania.

Ta seria samouczków wzbogaci twoją wiedzę i, z kolei, zwiększy twoje umiejętności testowania.

Praktyka End-to-End Manualnego Testowania Darmowe Szkolenie na Żywym Projekcie:

Samouczek #1: Podstawy Manualnego Testowania Oprogramowania
Samouczek #2: Wprowadzenie do Żywego Projektu
Samouczek #3: Pisanie Scenariusza Testowego
Samouczek #4: Pisanie Dokumentu Planu Testowego od podstaw
Samouczek #5: Pisanie Przypadków Testowych z Dokumentu SRS
Samouczek #6: Wykonanie testu
Tutorial #7: Śledzenie błędów i podpisywanie testów
Tutorial #8: Kurs testowania oprogramowania

Cykl życia testowania oprogramowania:

Tutorial #1: STLC

Testowanie stron internetowych:

Tutorial #1: Web Application Testing
Tutorial #2: Cross Browser Testing

Test Case Management:

Tutorial #1: Test Cases
Tutorial #2: Sample Test Case Template
Tutorial #3: Requirements Traceability Matrix (RTM)
Tutorial #4: Test Coverage
Tutorial #5: Test Data Management

Zarządzanie przypadkami testowymi:

Tutorial #1: Test Strategy
Tutorial #2: Test Plan Template
Tutorial #3: Test Estimation
Tutorial #4: Test Management Tools
Tutorial #5: HP ALM Tutorial
Tutorial #6: Jira
Tutorial #7: TestLink Tutorial

Techniki testowe:

Tutorial #1: Testowanie przypadków użycia
Tutorial #2: Testowanie przejść stanów
Tutorial #3: Analiza wartości granicznych
Tutorial #4: Partycjonowanie równoważności
Tutorial #5: Metodyki testowania oprogramowania
Tutorial #6: Metodyka Agile

Zarządzanie defektami:

Tutorial #1: Bug Life Cycle
Tutorial #2: Bug Reporting
Tutorial #3: Defect Priority
Tutorial #4: Bugzilla Tutorial

Testowanie funkcjonalne

Tutorial #1: Testy Jednostkowe
Samouczek #2: Testy Sanity i Smoke
Samouczek #3: Testy Regresyjne
Samouczek #4: Testy Systemowe
Samouczek #5: Acceptance Testing
Tutorial #6: Integration Testing
Tutorial #7: User Acceptance Testing UAT

Testy niefunkcjonalne:

Tutorial #1: Non-Functional Testing
Tutorial #2: Performance Testing
Tutorial #3: Security Testing
Tutorial #4: Web Application Security Testing
Tutorial #5: Usability Testing
Tutorial #6: Testowanie Kompatybilności
Tutorial #7: Testowanie Instalacji
Tutorial #8: Testowanie Dokumentacji

Typy Testowania Oprogramowania:

Tutorial #1: Rodzaje Testowania
Tutorial #2: Testowanie czarnej skrzynki
Tutorial #3: Testowanie baz danych
Tutorial #4: Testowanie end to end
Tutorial #5: Testowanie eksploracyjne
Tutorial #6: Testowanie przyrostowe
Tutorial #7: Accessibility Testing
Tutorial #8: Negative Testing
Tutorial #9: Backend Testing
Tutorial #10: Alpha Testing
Tutorial #11: Beta Testing
Tutorial #12: Testowanie Alpha vs Beta
Samouczek #13: Testowanie Gamma
Samouczek #14: Testowanie ERP
Samouczek #15: Testowanie Statyczne i Dynamiczne
Samouczek #16: Testowanie Adhoc
Samouczek #17: Testowanie Lokalizacji i Internacjonalizacji
Tutorial #18: Testowanie Automatyzacji
Tutorial #19: Testowanie białej skrzynki

Kariera testera oprogramowania:

Samouczek #1: Wybór kariery testera oprogramowania
Samouczek #2: Jak zdobyć pracę w testowaniu QA – kompletny przewodnik
Samouczek #3: Opcje kariery dla testerów
Samouczek #4: Non-IT to Software Testing Switch
Tutorial #5: Kick Start Your Manual Testing Career
Tutorial #6: Lessons Learned from 10 Years in Testing
Tutorial #7: Survive and Progress in Testing Field

Przygotowanie do rozmowy kwalifikacyjnej:

Tutorial #1: QA Resume Preparation
Tutorial #2: Manual Testing Interview Questions
Tutorial #3: Automation Testing Interview Questions
Tutorial #4: QA Interview Questions
Tutorial #5: Handle Any Job Interview
Tutorial #6: Get Testing Job as a Fresher

Testing Different Domain Application:

Poradnik #1: Testowanie Aplikacji Bankowych
Poradnik #2: Testowanie Aplikacji Opieki Zdrowotnej
Poradnik #3: Testowanie Bramek Płatniczych
Poradnik #4: Testowanie Systemu Point of Sale (POS)
Poradnik #5: Testowanie Witryn eCommerce

Testowanie Certyfikacji QA:

Poradnik #1: Przewodnik Certyfikacji Testowania Oprogramowania
Poradnik #2: Przewodnik Certyfikacji CSTE
Poradnik #3: Przewodnik Certyfikacji CSQA
Poradnik #4: Przewodnik ISTQB
Poradnik #5: ISTQB Advanced

Zaawansowane Tematy Testowania Manualnego:

Poradnik #1: Złożoność Cyklomatyczna
Samouczek #2: Testowanie Migracji
Samouczek #3: Testowanie Chmury
Samouczek #4: Testowanie ETL
Samouczek #5: Metryki Testowania Oprogramowania
Samouczek #6: Usługi Sieciowe

Przygotuj się do obejrzenia pierwszego samouczka z tej serii Testów Manualnych !!!!

Wprowadzenie do Manualnego Testowania Oprogramowania

Testowanie Manualne jest procesem, w którym porównujesz zachowanie stworzonego kawałka kodu (oprogramowania, modułu, API, funkcji, itd.) z oczekiwanym zachowaniem (Wymaganiami).

A skąd będziesz wiedział jakie jest oczekiwane zachowanie?

Dowiesz się tego czytając lub słuchając wymagań uważnie i rozumiejąc je całkowicie. Pamiętaj, całkowite zrozumienie wymagań jest bardzo ważne.

Pomyśl o sobie jako o użytkowniku końcowym tego, co zamierzasz testować. Po tym, nie jesteś już związany z dokumentem wymagań oprogramowania lub słowami w nim zawartymi. Możesz wtedy zrozumieć podstawowe wymaganie i nie tylko sprawdzić zachowanie systemu względem tego, co jest napisane lub powiedziane, ale także względem własnego zrozumienia i względem rzeczy, które nie są napisane lub powiedziane.

Czasami, może to być pominięte wymaganie (niepełne wymaganie) lub ukryte wymaganie (coś, co nie wymaga oddzielnej wzmianki, ale powinno być spełnione), i musisz przetestować to również.

Ponadto, wymaganie nie musi być koniecznie udokumentowane. Możesz bardzo dobrze znać funkcjonalność oprogramowania lub możesz nawet zgadywać, a następnie testować jeden krok na raz. Ogólnie nazywamy to testowaniem ad-hoc lub testowaniem eksploracyjnym.

Poznajmy to dokładnie:

Po pierwsze, zrozummy fakt – Niezależnie od tego, czy porównujemy testowanie aplikacji oprogramowania, czy czegoś innego (powiedzmy pojazdu), koncepcja pozostaje taka sama. Podejście, narzędzia i priorytety mogą się różnić, ale główny cel pozostaje TAKI SAM i jest on PROSTY, tj. porównanie rzeczywistego zachowania z oczekiwanym zachowaniem.

Po drugie – Testowanie jest jak postawa lub sposób myślenia, który powinien pochodzić z wewnątrz. Umiejętności można się nauczyć, ale staniesz się skutecznym testerem tylko wtedy, gdy domyślnie będziesz miał kilka cech w sobie. Kiedy mówię, że umiejętności testowania można się nauczyć, mam na myśli skupioną i formalną edukację wokół procesu testowania oprogramowania.

Ale jakie są cechy skutecznego testera? Możesz o nich przeczytać w poniższym linku:

Przeczytaj tutaj =>Qualities of Highly Effective Testers

Bardzo polecam przejrzenie powyższego artykułu przed kontynuowaniem tego tutoriala. Pomoże ci on porównać twoje cechy z tymi, które są oczekiwane w roli Testera Oprogramowania.

Dla tych, którzy nie mają czasu, aby przejść przez artykuł, oto streszczenie:

„Twoja ciekawość, uważność, dyscyplina, logiczne myślenie, pasja do pracy i zdolność do rozbioru rzeczy ma duże znaczenie, aby być Destrukcyjnym i Skutecznym Testerem. To zadziałało dla mnie i mocno wierzę, że zadziała również dla Ciebie. Jeśli masz już te cechy, to rzeczywiście musi to zadziałać również dla Ciebie.”

Mówiliśmy o podstawowych warunkach wstępnych zostania testerem oprogramowania. Teraz zrozumiemy dlaczego Testowanie Manualne ma i zawsze będzie miało swoje niezależne istnienie z lub bez wzrostu Testowania Automatyzacji.

Dlaczego Testowanie Manualne jest Wymagane?

Czy wiesz co jest najlepszą rzeczą w byciu Testerem, że zbyt Testerem Manualnym?

Jest to fakt, że nie można polegać tylko na skillset tutaj. Musisz mieć/rozwijać i ulepszać swój proces myślowy. To jest coś, czego nie można kupić za kilka dolarów. Sam musisz nad tym pracować.

Będziesz musiał rozwinąć nawyk zadawania pytań i będziesz musiał je zadawać w każdej minucie, kiedy będziesz testował. W większości przypadków powinieneś zadawać te pytania sobie, a nie innym.

Mam nadzieję, że przeszedłeś przez artykuł, który poleciłem w poprzedniej sekcji (tj. cechy wysoce skutecznych testerów). Jeśli tak, to wiesz, że testowanie jest uważane za proces myślowy i to jak skuteczny będziesz jako tester całkowicie zależy od cech, które posiadasz jako osoba.

Zobaczmy ten prosty przepływ:

• Robisz coś (wykonujesz działania) podczas gdy obserwujesz to z pewnym zamiarem (porównując z oczekiwanym). Teraz twoje umiejętności obserwacji i dyscyplina do wykonywania rzeczy wchodzi tu w grę.
• Voila! Co to było? Zauważyłeś coś. Zauważyłeś to, ponieważ zwracałeś doskonałą uwagę na szczegóły przed tobą. Nie pozwoliłaś temu odejść, ponieważ jesteś ciekawa. To nie było w waszym planie, że coś nieoczekiwanego/dziwnego się wydarzy, zauważycie to i będziecie to dalej badać. Ale teraz to robisz. Możesz pozwolić temu odejść. Ale nie powinieneś tego puszczać.
• Jesteś szczęśliwy, znalazłeś przyczynę, kroki i scenariusz. Teraz musisz to odpowiednio i konstruktywnie zakomunikować zespołowi programistów i innym interesariuszom w twoim zespole. Możesz to zrobić za pomocą jakiegoś narzędzia do śledzenia defektów lub ustnie, ale musisz się upewnić, że komunikujesz to konstruktywnie.
• Oops! A co jeśli zrobię to w ten sposób? Co jeśli wprowadzę właściwą liczbę całkowitą jako dane wejściowe, ale z wiodącymi białymi spacjami? Co jeśli? … Co jeśli? … Co jeśli? To się nie kończy łatwo, to się nie powinno kończyć łatwo. Wyobrażasz sobie wiele sytuacji & scenariuszy i rzeczywiście będziesz kuszony, aby je również wykonać.

Schemat podany poniżej przedstawia Życie Testera:

Przeczytaj te cztery punkty wypunktowane powyżej jeszcze raz. Czy zauważyłeś, że trzymałem je bardzo krótko, ale wciąż podkreślałem najbogatszą część bycia testerem manualnym? A czy zwróciłeś uwagę na pogrubienie kilku słów? To są właśnie najważniejsze cechy, których potrzebuje tester manualny.

Teraz, czy naprawdę myślisz, że te czynności mogą być całkowicie zastąpione przez cokolwiek innego? A gorący trend dzisiaj – czy można je kiedykolwiek zastąpić automatyzacją?

W SDLC z jakąkolwiek metodologią rozwoju, kilka rzeczy zawsze pozostaje niezmiennych. Jako tester, będziesz konsumował wymagania, przekształcał je w Scenariusze Testowe / Przypadki Testowe. Następnie wykonasz te przypadki testowe lub bezpośrednio je zautomatyzujesz (wiem, że kilka firm tak robi).

Gdy je automatyzujesz, twoja uwaga jest skupiona na automatyzacji napisanych kroków.

Powróćmy do części formalnej, tj. wykonania przypadków testowych napisanych ręcznie.

Tutaj nie tylko skupiasz się na wykonaniu napisanych przypadków testowych, ale również wykonujesz wiele testów eksploracyjnych podczas ich wykonywania. Pamiętasz, że jesteś ciekawski? I będziesz sobie wyobrażał. I nie będziesz mógł się oprzeć, rzeczywiście zrobisz to, co sobie wyobraziłeś.

Obraz podany poniżej przedstawia jak pisanie przypadków testowych jest uproszczone:

Wypełniam formularz, i skończyłem wypełniać pierwsze pole. Jestem zbyt leniwy, aby sięgnąć po mysz, aby przenieść fokus na następne pole. Naciskam klawisz 'tab’. Skończyłem wypełniać następne i ostatnie pole również, teraz muszę kliknąć na przycisk Prześlij, fokus jest nadal na ostatnim polu.

Oops, I przypadkowo uderzył klawisz 'Enter’. Pozwól mi sprawdzić, co się stało. LUB tam jest przycisk przesyłania, będę klikać go dwukrotnie. Nie jestem zadowolony. Klikam go wiele razy, zbyt szybko.

Zauważyłeś? Jest tak wiele możliwych działań użytkownika, zarówno zamierzonych, jak i niezamierzonych.

Nie uda Ci się napisać wszystkich przypadków testowych, które w 100% pokrywają Twoją testowaną aplikację. To musi się wydarzyć w sposób eksploracyjny.

Będziesz dodawał nowe przypadki testowe w miarę testowania aplikacji. Będą to przypadki testowe dla błędów, które napotkałeś, dla których wcześniej nie było napisanego przypadku testowego. Albo, podczas testowania, coś uruchomiło twój proces myślowy i masz jeszcze kilka przypadków testowych, które chcesz dodać do swojego zestawu przypadków testowych i wykonać.

Nawet po tym wszystkim, nie ma gwarancji, że nie ma żadnych ukrytych błędów. Oprogramowanie z zerową liczbą błędów jest mitem. Możesz jedynie dążyć do tego, aby zbliżyć się do zera, ale to po prostu nie może się zdarzyć bez ludzkiego umysłu stale dążącego do tego samego, podobnego, ale nie ograniczonego do przykładowego procesu, który widzieliśmy powyżej.

Przynajmniej na dzień dzisiejszy, nie ma oprogramowania, które będzie myśleć jak ludzki umysł, obserwować jak ludzkie oko, zadawać pytania i odpowiadać jak człowiek, a następnie wykonywać zamierzone i niezamierzone działania. Nawet jeśli coś takiego powstanie, czyj umysł, myśli i oko będzie naśladować? Twój czy mój? My, ludzie, również nie mamy takiego samego prawa. Każdy z nas jest inny. Wtedy?

Potrzeba Testowania Manualnego kiedy Automatyzacja jest dookoła:

Automatyzacja Testowania ma swój własny udział w chwale w tych dniach i będzie miała jeszcze więcej w nadchodzących latach, ale, to po prostu nie może zastąpić ręcznego testowania QA (czytaj testowania ludzkiego/eksploracyjnego).

Musisz słyszeć wcześniej- 'Nie automatyzujesz testowania, automatyzujesz sprawdzanie’. To zdanie mówi wiele o tym, gdzie ręczne testowanie QA stoi z testami automatycznymi wokół. Wiele wielkich nazwisk z całego świata pisało i mówiło na ten temat, więc nie będę się zbytnio nad tym rozwodził.

Automatyzacja nie może zastąpić testowania przez człowieka, ponieważ:

• Żąda osądów runtime o wszystkim, co dzieje się na twoich oczach (podczas testowania) i w kilku przypadkach również za kulisami.
• Żąda jasnej i stałej obserwacji.
• Żąda zadawania pytań.
• Żąda śledztwa.
• Żąda rozumowania.
• Żąda nieplanowanych działań, które są wymagane podczas testowania.

Testowanie może być zastąpione przez narzędzie/maszynę, która będzie w stanie wchłonąć szczegóły, przetworzyć je, nakazać działania i wykonać je jak ludzki umysł i człowiek, a wszystko to w czasie działania i we wszystkich możliwych kontekstach. To narzędzie znowu musi być takie jak każdy możliwy człowiek.

W skrócie, ludzkie testy nie mogą być zastąpione. Może jakiś hollywoodzki flick sci-fi w ciągu kilku lat będzie wyglądał blisko tego, ale w prawdziwym życiu nie widzę tego nadchodzącego przez kilkaset lat, które mogę sobie wyobrazić. Nie będę jednak spisywał tego na straty, bo wierzę w nieskończone możliwości.

Na osobną uwagę, nawet jeśli to naprawdę nastąpi po kilkuset latach, to obraz jaki mogę sobie wyobrazić, to na pewno przerażający świat. Wiek Transformerów 🙂

=>>Zalecana lektura – Najlepsze firmy świadczące usługi testowania manualnego

Jak automatyzacja uzupełnia testowanie manualne?

Powiedziałem wcześniej i powtarzam to ponownie, że automatyzacja nie może być już ignorowana. W świecie, gdzie ciągła integracja, ciągłe dostarczanie i ciągłe wdrażanie stają się obowiązkowe, ciągłe testowanie nie może siedzieć bezczynnie. Musimy znaleźć sposoby, jak to zrobić.

Większość czasu, wdrażając więcej i więcej siły roboczej nie pomaga w dłuższej perspektywie dla tego zadania. Dlatego też, Tester (Lider Testów/Architekt/Menedżer) musi ostrożnie decydować o tym, co zautomatyzować, a co nadal powinno być wykonywane ręcznie.

Staje się niezwykle ważne, aby mieć bardzo precyzyjnie napisane testy/sprawdzenia, które mogą być zautomatyzowane bez żadnych odchyleń od oryginalnych oczekiwań i mogą być używane podczas regresji produktu jako część 'Testowania Ciągłego’.

Uwaga: Słowo ciągły z terminu 'Testowanie Ciągłe’ jest poddane warunkowym i logicznym wywołaniom podobnym do innych terminów, które użyliśmy powyżej z tym samym przedrostkiem. Ciągły w tym kontekście oznacza więcej i częściej, szybciej niż wczoraj. Podczas gdy w znaczeniu, to może bardzo dobrze oznaczać co sekundę lub Nano-sekundę.

Bez posiadania idealnego dopasowania Ludzkich Testerów i zautomatyzowanych kontroli (testy z precyzyjnie określonymi krokami, oczekiwanym wynikiem i udokumentowanymi kryteriami wyjścia z danego testu), osiągnięcie Ciągłego Testowania jest bardzo trudne, a to z kolei utrudni ciągłą integrację, ciągłe dostarczanie i ciągłe wdrażanie.

Celowo użyłem terminu kryteria wyjścia z testu powyżej. Nasze garnitury automatyzacji nie mogą już być podobne do tych tradycyjnych. Musimy się upewnić, że jeśli zawiodą, to powinny zawodzić szybko. A żeby szybko się nie udały, kryteria wyjścia również powinny być zautomatyzowane.

Przykład:

Powiedzmy, że jest wada blokera, gdzie, nie jestem w stanie zalogować się do Facebooka.

Funkcjonalność logowania wtedy musi być pierwszym automatycznym sprawdzeniem i twój zestaw automatyzacji nie powinien uruchamiać następnego sprawdzenia, gdzie logowanie jest warunkiem wstępnym, jak pisanie statusu. Bardzo dobrze wiesz, że jest to związane z niepowodzeniem. Więc zrób to szybciej, opublikuj wyniki szybciej, aby defekt mógł być rozwiązany szybciej.

Następną rzeczą jest znowu coś, co pewnie słyszałeś wcześniej – Nie możesz i nie powinieneś próbować zautomatyzować wszystkiego.

Wybierz przypadki testowe, które, jeśli zostaną zautomatyzowane, przyniosą znaczne korzyści ludzkim testerom i mają dobry zwrot z inwestycji. W tej kwestii, istnieje ogólna zasada, która mówi, że powinieneś spróbować zautomatyzować wszystkie przypadki testowe o priorytecie 1, a jeśli to możliwe, to również o priorytecie 2. Automatyzacja nie jest łatwa do wdrożenia i jest czasochłonna, więc zaleca się unikanie automatyzacji przypadków o niskim priorytecie, przynajmniej do czasu, gdy skończysz z tymi o wysokim priorytecie. Wybór tego, co zautomatyzować i skupienie się na tym poprawia jakość aplikacji, kiedy jest używane i utrzymywane w sposób ciągły.

Wniosek

Mam nadzieję, że do tej pory zrozumiałeś, dlaczego i jak bardzo ręczne/ludzkie testowanie jest wymagane do dostarczania Produktów Wysokiej Jakości i jak automatyzacja je uzupełnia.

Przyjęcie znaczenia ręcznego testowania QA i wiedza, dlaczego jest ono wyjątkowe, jest pierwszym krokiem do bycia doskonałym testerem ręcznym.

W naszych nadchodzących samouczkach dotyczących testowania manualnego, zajmiemy się ogólnym podejściem do testowania manualnego, jak będzie ono współistnieć z automatyzacją i wieloma innymi ważnymi aspektami.

Jestem pewien, że zdobędziesz ogromną wiedzę na temat testowania oprogramowania, gdy przejdziesz przez całą listę samouczków z tej serii.

.