Menu

Co to jest testowanie oprogramowania? Ponad 100 darmowych samouczków do testowania ręcznego

what is software testing

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Kompletny podręcznik testowania oprogramowania z ponad 100 samouczkami testowania ręcznego z definicją testów, typami, metodami i szczegółami procesu:

Co to jest testowanie oprogramowania?

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

Co to jest testowanie ręczne?

Testowanie ręczne to proces, w którym porównujesz zachowanie opracowanego fragmentu kodu (oprogramowania, modułu, API, funkcji itp.) Z oczekiwanym zachowaniem (Wymagania).

Czego się nauczysz:

Lista samouczków do ręcznego testowania oprogramowania

Jest to najbardziej dogłębna seria samouczków na temat testowania oprogramowania. Uważnie przejrzyj tematy wymienione w tej serii, aby poznać podstawowe i zaawansowane techniki testowania.

Ta seria samouczków wzbogaci Twoją wiedzę i z kolei poprawi Twoje umiejętności testowania.

Przećwicz pełne ręczne testowanie Bezpłatne szkolenie w projekcie na żywo:

Samouczek nr 1: Podstawy ręcznego testowania oprogramowania
Samouczek nr 2: Wprowadzenie do projektu na żywo
Samouczek nr 3: Pisanie scenariuszy testów
Samouczek nr 4: Napisz dokument planu testów od podstaw
Samouczek nr 5: Pisanie przypadków testowych z dokumentu SRS
Samouczek nr 6: Wykonanie testu
Samouczek nr 7: Śledzenie błędów i podpisywanie testów
Samouczek nr 8: Kurs testowania oprogramowania

Cykl życia testowania oprogramowania:

Samouczek nr 1: STLC

Testy internetowe:

Samouczek nr 1: Testowanie aplikacji internetowych
Samouczek nr 2: Testowanie w różnych przeglądarkach

Zarządzanie przypadkami testowymi:

chcę przetestować produkty dla firm

Samouczek nr 1: Przypadki testowe
Samouczek nr 2: Przykładowy szablon przypadku testowego
Samouczek nr 3: Macierz śledzenia wymagań (RTM)
Samouczek nr 4: Pokrycie testowe
Samouczek nr 5: Zarządzanie danymi testowymi

Zarządzanie testami:

Samouczek nr 1: Strategia testów
Samouczek nr 2: Szablon planu testów
Samouczek nr 3: Szacowanie testu
Samouczek nr 4: Narzędzia do zarządzania testami
Samouczek nr 5: Samouczek HP ALM
Samouczek nr 6: Jira
Samouczek nr 7: Samouczek TestLink

Testy techniczne:

Samouczek nr 1: Testowanie przypadków użycia
Samouczek nr 2: Testowanie przejść między stanami
Samouczek nr 3: Analiza wartości brzegowych
Samouczek nr 4: Partycjonowanie równoważności
Samouczek nr 5: Metodologie testowania oprogramowania
Samouczek nr 6: Agile Methodology

Zarządzanie defektami:

Samouczek nr 1: Cykl życia błędu
Samouczek nr 2: Zgłaszanie błędów
Samouczek nr 3: Priorytet defektów
Samouczek nr 4: Samouczek Bugzilli

Testy funkcjonalności

Samouczek nr 1: Testów jednostkowych
Samouczek nr 2: Testy poczytalności i dymu
Samouczek nr 3: Testowanie regresji
Samouczek nr 4: Testowanie systemu
Samouczek nr 5: Testy akceptacyjne
Samouczek nr 6: Testy integracyjne
Samouczek nr 7: Testy akceptacyjne użytkowników UAT

Testy niefunkcjonalne:

Samouczek nr 1: Testy niefunkcjonalne
Samouczek nr 2: Test wydajności
Samouczek nr 3: Testowanie bezpieczeństwa
Samouczek nr 4: Testowanie bezpieczeństwa aplikacji internetowych
Samouczek nr 5: Test użyteczności
Samouczek nr 6: Testowanie zgodności
Samouczek nr 7: Testowanie instalacji
Samouczek nr 8: Testowanie dokumentacji

Typy testowania oprogramowania:

Samouczek nr 1: Rodzaje testów
Samouczek nr 2 : Testowanie czarnoskrzynkowe
Samouczek nr 3: Testowanie baz danych
Samouczek nr 4: Testy od końca do końca
Samouczek nr 5: Testowanie eksploracyjne
Samouczek nr 6: Testowanie przyrostowe
Samouczek nr 7: Testowanie dostępności
Samouczek nr 8: Testy negatywne
Samouczek nr 9: Testowanie zaplecza
Samouczek nr 10: Testy alfa
Samouczek nr 11: Testowanie beta
Samouczek nr 12: Testy alfa vs beta
Samouczek nr 13: Testowanie gamma
Samouczek nr 14: Testowanie ERP
Samouczek nr 15: Testowanie statyczne i dynamiczne
Samouczek nr 16: Testowanie ad hoc
Samouczek nr 17: Testowanie lokalizacji i internacjonalizacji
Samouczek nr 18: Testowanie automatyczne
Samouczek nr 19: Testowanie białoskrzynkowe

Kariera w testowaniu oprogramowania:

Samouczek nr 1: Wybór kariery w testowaniu oprogramowania
Samouczek nr 2: Jak uzyskać zlecenie testowania jakości - kompletny przewodnik
Samouczek nr 3: Opcje kariery dla testerów
Samouczek nr 4: Przełącznik testowania oprogramowania spoza IT
Samouczek nr 5: Rozpocznij karierę testowania ręcznego
Samouczek nr 6: Wnioski wyciągnięte z 10 lat testowania
Samouczek nr 7: Przetrwaj i postępuj w terenie testowym

Przygotowanie do rozmowy kwalifikacyjnej:

Samouczek nr 1: Przygotowanie do wznowienia kontroli jakości
Samouczek nr 2: Testowanie ręczne Pytania do rozmowy kwalifikacyjnej
Samouczek nr 3: Pytania do wywiadu dotyczącego testów automatyzacji
Samouczek nr 4: Pytania do wywiadu QA
Samouczek nr 5: Przeprowadź rozmowę kwalifikacyjną
Samouczek nr 6: Zdobądź testową pracę jako świeższy

Testowanie aplikacji w innej domenie:

Samouczek nr 1 : Testowanie aplikacji bankowych
Samouczek nr 2: Testowanie aplikacji opieki zdrowotnej
Samouczek nr 3: Testowanie bramki płatności
Samouczek nr 4: Testuj system punktów sprzedaży (POS)
Samouczek nr 5: Testowanie witryn eCommerce

Testowanie certyfikatu QA:

Samouczek nr 1: Podręcznik certyfikacji testowania oprogramowania
Samouczek nr 2: Przewodnik certyfikacji CSTE
Samouczek nr 3: Przewodnik certyfikacji CSQA
Samouczek nr 4: Przewodnik ISTQB
Samouczek nr 5: ISTQB Advanced

Tematy dotyczące zaawansowanych testów ręcznych:

Samouczek nr 1: Złożoność cykliczna
Samouczek nr 2: Testowanie migracji
Samouczek nr 3: Testowanie w chmurze
Samouczek nr 4: Testowanie ETL
Samouczek nr 5: Metryki testowania oprogramowania
Samouczek nr 6: Usługi internetowe

Przygotuj się na pierwszy samouczek z tej serii testów ręcznych !!!

Wprowadzenie do ręcznego testowania oprogramowania

Testowanie ręczne to proces, w którym porównujesz zachowanie opracowanego fragmentu kodu (oprogramowania, modułu, API, funkcji itp.) Z oczekiwanym zachowaniem (Wymagania).

A skąd będziesz wiedzieć, jakie jest oczekiwane zachowanie?

Poznasz to, uważnie czytając lub słuchając wymagań i całkowicie je rozumiejąc. Pamiętaj, że pełne zrozumienie wymagań jest bardzo ważne.

jak dodać ciąg do tablicy ciągów

Pomyśl o sobie jako o użytkowniku końcowym tego, co zamierzasz przetestować. Po tym czasie nie jesteś już związany dokumentem wymagań oprogramowania lub zawartymi w nim słowami. Możesz wtedy zrozumieć podstawowe wymaganie i nie tylko porównać zachowanie systemu z tym, co jest napisane lub powiedziane, ale także z własnym zrozumieniem oraz z rzeczami, które nie są napisane lub opowiedziane.

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

Ponadto wymóg niekoniecznie musi być udokumentowany. Możesz bardzo dobrze znać funkcjonalność oprogramowania lub nawet zgadywać, a następnie testować krok po kroku. Zwykle nazywamy to testowaniem ad hoc lub testowaniem eksploracyjnym.

Przyjrzyjmy się dokładniej:

Najpierw zrozumiemy fakt - Niezależnie od tego, czy porównujesz testowanie aplikacji czy czegoś innego (powiedzmy, pojazdu), koncepcja pozostaje ta sama. Podejście, narzędzia i priorytety mogą się różnić, ale główny cel pozostaje TEN SAM i jest PROSTY, tj. Porównanie rzeczywistego zachowania z oczekiwanym zachowaniem.

Po drugie - Testowanie jest jak nastawienie lub sposób myślenia, które powinny pochodzić z wnętrza. Umiejętności można się nauczyć, ale odniesiesz sukces jako tester tylko wtedy, gdy domyślnie masz w sobie kilka cech. Kiedy mówię, że umiejętności testowania można się nauczyć, mam na myśli ukierunkowaną i formalną edukację dotyczącą procesu testowania oprogramowania.

Ale jakie są cechy dobrego testera? Możesz o nich przeczytać pod poniższym linkiem:

Przeczytaj to tutaj => Cechy wysoce skutecznych testerów

Gorąco polecam przejrzenie powyższego artykułu przed kontynuowaniem tego samouczka. Pomoże Ci to porównać Twoje cechy z tymi, których oczekuje się w roli testera oprogramowania.

Dla tych, którzy nie mają czasu na zapoznanie się z artykułem, oto streszczenie:

„Twoja ciekawość, uważność, dyscyplina, logiczne myślenie, pasja do pracy i umiejętność analizowania rzeczy są ważne, aby być destrukcyjnym i skutecznym testerem. U mnie zadziałało i mocno wierzę, że zadziała również u Ciebie. Jeśli już posiadasz te cechy, to rzeczywiście zadziałało to również dla ciebie ”.

Rozmawialiśmy o podstawowych wymaganiach wstępnych programu zostając testerem oprogramowania. Teraz zrozumiemy, dlaczego testowanie ręczne zawsze istniało niezależnie, z rozwojem testów automatycznych lub bez niego.

Dlaczego wymagane jest testowanie ręczne?

Czy wiesz, co jest najlepsze w byciu testerem, a także testerem ręcznym?

Faktem jest, że nie można tu polegać tylko na umiejętnościach. Musisz mieć / rozwijać i ulepszać swój proces myślowy. To jest coś, czego naprawdę nie można kupić za kilka dolców. Sam musisz nad tym popracować.

Będziesz musiał wyrobić w sobie nawyk zadawania pytań i będziesz musiał ich pytać co minutę, kiedy będziesz testować. W większości przypadków powinieneś zadawać te pytania sobie, a nie innym.

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

Zobaczmy ten prosty przepływ:

  • Robisz coś ( wykonywać czynności ), gdy obserwujesz to z pewnym zamiarem (porównując z oczekiwanymi). Teraz twój obserwacja umiejętności i dyscyplina do wykonywania zadań wchodzi tutaj obraz.
  • Voila! Co to było? Zauważyłeś coś. Zauważyłeś to, ponieważ dawałeś doskonały dbałość o szczegóły przed Tobą. Nie pozwolisz temu odejść, ponieważ jesteś ciekawy . Nie było w twoim planie, że wydarzy się coś nieoczekiwanego / dziwnego, zauważysz to i zbadasz to dalej. Ale teraz to robisz. Możesz odpuścić. Ale nie powinieneś odpuszczać.
  • Jesteś szczęśliwy, znalazłeś przyczynę, kroki i scenariusz. Teraz przekażesz to poprawnie i konstruktywnie zespołowi programistycznemu i innym interesariuszom w swoim zespole. Możesz to zrobić za pomocą jakiegoś narzędzia do śledzenia defektów lub ustnie, ale musisz się upewnić, że tak jest komunikowanie go w sposób konstruktywny .
  • Ups! A jeśli zrobię to w ten sposób? Co się stanie, jeśli jako dane wejściowe wpiszę odpowiednią liczbę całkowitą, ale z wiodącymi białymi spacjami? Co jeśli? … Co jeśli? … Co jeśli? Nie kończy się łatwo, nie powinno się łatwo kończyć. Będziesz wyobrażać sobie wiele sytuacji i scenariuszy i rzeczywiście będziesz kuszony, aby je wykonać.

Poniższy diagram przedstawia żywotność testera:

Życie testera

Przeczytaj jeszcze raz te cztery wypunktowane punkty. Czy zauważyłeś, że utrzymałem to bardzo krótko, ale nadal podkreślałem najbogatszą część bycia testerem ręcznym? Czy zauważyłeś odważne podkreślenie w kilku słowach? To są właśnie najważniejsze cechy, których potrzebuje tester manualny.

Czy naprawdę myślisz, że te akty można całkowicie zastąpić czymkolwiek innym? A dzisiejszy gorący trend - czy kiedykolwiek można go zastąpić automatyzacją?

W SDLC przy każdej metodologii rozwoju niewiele rzeczy pozostaje niezmiennych. Jako tester będziesz konsumować wymagania, konwertować je na scenariusze testowe / przypadki testowe. Następnie wykonasz te przypadki testowe lub bezpośrednio je zautomatyzujesz (wiem, że robi to kilka firm).

Kiedy ją zautomatyzujesz, Twoja uwaga jest stała, czyli automatyzacja napisanych kroków.

Wróćmy do części formalnej, czyli wykonywania przypadków testowych napisanych ręcznie.

Tutaj nie tylko koncentrujesz się na wykonywaniu pisemnych przypadków testowych, ale także wykonujesz wiele testów eksploracyjnych. Pamiętaj, jesteś ciekawy? I sobie wyobrazisz. I nie będziesz w stanie się oprzeć, rzeczywiście zrobisz to, co sobie wyobrażałeś.

Poniższy obraz przedstawia uproszczenie pisania przypadków testowych:

Uproszczone pisanie przypadków testowych

Wypełniam formularz i skończyłem wypełniać pierwsze pole. Jestem zbyt leniwy, aby przejść do następnego pola za pomocą myszy. Nacisnąłem klawisz „tab”. Skończyłem z wypełnianiem następnego i ostatniego pola, teraz muszę kliknąć przycisk Prześlij, fokus jest nadal na ostatnim polu.

Ups, przypadkowo wcisnąłem klawisz „Enter”. Sprawdzę, co się stało. LUB jest przycisk przesyłania, kliknę go dwukrotnie. Niezadowolony. Klikam go wiele razy, zbyt szybko.

Czy 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 obejmują w 100% testowaną aplikację. Musi się to odbyć w odkrywczy sposób.

Będziesz dodawać nowe przypadki testowe podczas testowania aplikacji. Będą to przypadki testowe dla napotkanych błędów, dla których wcześniej nie napisano żadnego przypadku testowego. Albo, gdy testujesz, coś wyzwoliło twój proces myślowy i masz kilka innych przypadków testowych, które zechcesz dodać do zestawu przypadków testowych i wykonać.

Nawet po tym wszystkim nie ma gwarancji, że nie ma ukryte błędy . Oprogramowanie bez błędów to mit. Możesz celować tylko tak, aby zbliżyć się do zera, ale to po prostu nie może się zdarzyć bez ludzkiego umysłu ciągłego celowania w to samo, podobnie jak, ale nie ograniczając się 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 się wydarzy, czyj umysł, myśli i oko będą naśladować? Twoje lub moje? My, ludzie, też nie mamy tego samego prawa. Wszyscy jesteśmy różni. Następnie?

Potrzeba ręcznego testowania, gdy zbliża się automatyzacja:

Testowanie automatyczne ma obecnie swój udział w sukcesie, a w nadchodzących latach będzie jeszcze większe, ale po prostu nie może zastąpić ręcznego testowania jakości (czytaj testowanie ludzkie / eksploracyjne).

Musiałeś już słyszeć… Nie automatyzujesz testowania, tylko automatyzujesz sprawdzanie ”. To zdanie dużo mówi o tym, gdzie stoją ręczne testy QA z testami automatycznymi. Wiele znanych nazwisk na całym świecie napisało i przemówiło na ten temat, więc nie będę się zbytnio nad tym podkreślał.

Automatyzacja nie może zastąpić Human Testing, ponieważ:

  • Wymaga oceny w czasie wykonywania wszystkiego, co dzieje się na twoich oczach (podczas testowania), a w kilku przypadkach także za kulisami.
  • Wymaga jasnej i ciągłej obserwacji.
  • To wymaga pytający.
  • To wymaga śledztwa.
  • Wymaga rozumowania.
  • Podczas testowania wymaga nieplanowanych działań.

Testowanie można zastąpić narzędziem / maszyną, która będzie w stanie wchłonąć szczegóły, przetwarzać je, wydawać polecenia i wykonywać je jak ludzki umysł i człowiek, a wszystko to w czasie wykonywania i we wszystkich możliwych kontekstach. To narzędzie znowu musi być jak wszyscy ludzie.

Krótko mówiąc, testów na ludziach nie da się zastąpić. Może jakiś hollywoodzki film science-fiction za kilka lat będzie wyglądał na bliski, ale w prawdziwym życiu nie widzę tego przez kilkaset lat, co mogę sobie wyobrazić. Nie odpiszę tego wiecznie, ponieważ wierzę w nieskończone możliwości.

Z osobna uwaga, nawet jeśli dzieje się to naprawdę po kilkuset latach, obraz, który mogę sobie wyobrazić, jest z pewnością przerażającym światem. Age of Transformers. :)

= >> Zalecana lektura - Najlepsze firmy świadczące usługi testowania ręcznego

Jak automatyzacja uzupełnia testy ręczne?

Powiedziałem wcześniej i powtarzam, że automatyzacji nie można już ignorować. W świecie, w którym 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 być bezczynne. Musimy znaleźć sposoby, jak to zrobić.

W większości przypadków rozmieszczanie coraz większej liczby pracowników nie pomaga na dłuższą metę w tym zadaniu. W związku z tym Tester (Kierownik Testów / Architekt / Menedżer) musi ostrożnie zdecydować, co zautomatyzować, a co nadal należy zrobić ręcznie.

Niezwykle ważne staje się napisanie bardzo dokładnych testów / kontroli, tak aby można je było zautomatyzować bez odchyleń od pierwotnych oczekiwań i aby można je było wykorzystać podczas regresji produktu w ramach „ciągłego testowania”.

Uwaga: Słowo ciągłe z terminu „Testowanie ciągłe” jest poddawane warunkowym i logicznym wywołaniom podobnym do innych terminów, których używaliśmy powyżej, z tym samym przedrostkiem. Ciągłe w tym kontekście oznacza coraz częściej, szybciej niż wczoraj. W sensie może oznaczać każdą sekundę lub nanosekundę.

Bez doskonałego dopasowania Human Testers i automatycznych kontroli (testy z precyzyjnymi krokami, oczekiwanym wynikiem i kryteriami zakończenia tego testu udokumentowane), osiągnięcie ciągłego testowania jest bardzo trudne, a to z kolei spowoduje ciągłą integrację, ciągłe dostarczanie i ciągłe wdrażanie trudniejsze.

Celowo użyłem terminu kryteria zakończenia testu powyżej. Nasze kombinezony do automatyzacji nie mogą już być podobne do tradycyjnych. Musimy się upewnić, że jeśli zawiodą, to szybko. Aby przyspieszyć niepowodzenie, należy również zautomatyzować kryteria wyjścia.

Przykład:

Powiedzmy, że występuje defekt blokera, w którym nie mogę zalogować się na Facebooku.

Funkcjonalność logowania musi być wtedy pierwszym automatycznym sprawdzeniem, a Twój pakiet automatyzacji nie powinien uruchamiać następnego sprawdzenia, w przypadku którego logowanie jest warunkiem wstępnym, na przykład opublikowania statusu. Dobrze wiesz, że to się nie powiedzie. Więc spraw, aby błąd działał szybciej, publikuj wyniki szybciej, aby można było szybciej usunąć usterkę.

Następna rzecz to znowu coś, co musieliście wcześniej usłyszeć - Nie możesz i nie powinieneś próbować automatyzować wszystkiego.

Wybierz przypadki testowe, które w przypadku zautomatyzowania przyniosą znaczne korzyści do Human Testers i ma dobry zwrot z inwestycji. W związku z tym 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, o priorytecie 2.

Automatyzacja nie jest łatwa do wdrożenia i jest czasochłonna, dlatego zaleca się unikanie automatyzacji spraw 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, gdy jest używana i utrzymywana w sposób ciągły.

Wniosek

Mam nadzieję, że do tej pory musieliście już zrozumieć, dlaczego i jak bardzo testy ręczne / na ludziach są wymagane do dostarczania produktów wysokiej jakości i jak automatyzacja je uzupełnia.

Zaakceptowanie wagi ręcznych testów zapewniania jakości i wiedza, dlaczego są one wyjątkowe, jest pierwszym krokiem do bycia doskonałym testerem ręcznym.

W naszych nadchodzących samouczkach dotyczących testowania ręcznego omówimy ogólne podejście do testowania ręcznego, jego współistnienie z automatyzacją oraz wiele innych ważnych aspektów.

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

maven pytania do wywiadu i odpowiedzi dla doświadczonych

Bardzo chcielibyśmy usłyszeć od Ciebie. Zapraszam do wyrażenia swoich przemyśleń / sugestii w sekcji komentarzy poniżej.

rekomendowane lektury

^