Menu

6 podstawowych umiejętności, które powinien posiadać każdy tester (głównie świeższy)

6 basic skills that every tester should have

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Testowanie oprogramowania lub kontrola jakości to najlepsza platforma dla nowoprzybyłych do wejścia w branżę IT pomimo błędnego przekonania, że ​​jest to mniej lub mniej płatna praca.

Najważniejszą umiejętnością potrzebną testerowi jest umiejętność znajdowania błędów . A jeśli jesteś osobą, która uwielbia znajdować błędy, to będziesz kochać i rozwijać się w tej dziedzinie.

Mimo to istnieje kilka innych umiejętności, które mogą pomóc w znajdowaniu błędów i lepszej pracy z procesami kontroli jakości.

Jest to artykuł, który pokaże proces zapewniania jakości taki, jaki stosuje się w większości firm, i dostarczy nowym testerom wyjaśnień na temat testowania.

W szczegółach zapoznasz się z procesem dokumentacji i standardami, wstępną pracą testera, testowaniem opartym na ograniczeniach, testowaniem podczas częściowego rozwoju i wreszcie procesem podpisywania.

podstawowe umiejętności testowania

Zaczynajmy.

Czego się nauczysz:

# 1. Dokumentacja

Dokumentacja jest niezbędna do testowania. Większość firm powierza to zadanie nowo przybyłym. Aby odnieść sukces, powinieneś dobre słownictwo ponieważ pozostałe rzeczy, takie jak standardy dokumentacji itp., nie są pod Twoją kontrolą i zależą od procesów zespołu i firmy.

Upewnij się również, że widzisz wartość procesu tworzenia dokumentacji. Zalet jest wiele - pomagają śledzić zmiany wymagań, śledzić etapy testów, rejestrować pracę itp.

otwórz tablicę skrótów adresowania c ++

Zalecana lektura=> Dlaczego dokumentacja jest ważna w testowaniu oprogramowania

# 2. Przygotowanie do testu

Ze wszystkich dostępnych dokumentów nie można pominąć następujących. Są one również nazywane dokumentami dostarczanymi i łączą wiedzę klientów, programistów i testerów.

a) Plan testów: przedstawia przebieg testowania od początku do końca .

Plan testów przedstawia zakres i czynności w fazie testowania. Zespół utworzony przez kierownika ds. Kontroli jakości musi wnosić wkład i być na bieżąco ze wszystkim, co jest zapisane w planie testów.

Niektóre zespoły mają wiele poziomów planów testów: plan główny i plany dotyczące fazy.

Plan testów musi zawierać:

  • Nazwa i wersja projektu
  • Identyfikatory planu testów - twórca, nr wersji roboczej, data utworzenia itp.
  • Wprowadzenie - Omówienie projektu, celu i ograniczeń
  • Referencje - lista odniesień używanych jako dane wejściowe. (Upewnij się, że korzystasz z dokładnych i najnowszych wersji)
  • Elementy testowe - moduły, wersja, zakres, poza zakresem itp.
  • Ogólne podejście do testowania / strategia testowania - narzędzia do użycia, proces śledzenia defektów, poziomy testów do wykonania itp.
  • Kryteria dotyczące przedmiotu pozytywnego / negatywnego - wytyczne dotyczące wykonywania testów
  • Kryteria zawieszenia i wznowienia
  • Wyniki testów - przypadek testowy, raporty z testów, raport o błędach, metryki testów itp.
  • Szczegóły środowiska testowego
  • Skład zespołu z danymi punktu kontaktowego. dla każdego modułu lub typu testów
  • Szacunki testowe - czas i wysiłek. Szczegóły budżetu są poufne i nie znajdziesz ich tutaj
  • Ryzyka i plany łagodzenia
  • Aprobaty
  • Inne wytyczne

Przeczytaj także=>

jak przeprowadzić test penetracyjny

b) Scenariusze testowe:

Jeden wiersz zawiera informacje o tym, „co należy przetestować” w oparciu o każde wymaganie, zwykle dokumentowane i śledzone w arkuszach kalkulacyjnych.

Większość z nich zawiera:

  • Nazwa modułu / komponentu / funkcji (login, administrator, rejestracja itp.)
  • Identyfikator scenariusza służy jako odniesienie (np .: TS_Login_001)
  • Opis scenariusza - „Co przetestować” Np .: Sprawdź, czy logowanie pozwala użytkownikom z ważnymi poświadczeniami zalogować się pomyślnie
  • Znaczenie scenariusza - ustalanie priorytetów w przypadku braku czasu - wysokie / średnie / niskie
  • Identyfikator wymagania - do śledzenia

Dalsza lektura=>

c) Przypadki testowe:

Dokładne przypadki testowe dają dokładne wyniki testów. Arkusze kalkulacyjne są nadal popularnym medium do pisania przypadków testowych, zwłaszcza dla początkujących, mimo że niektóre firmy dostosowują narzędzia do zarządzania testami. Podstawą do pisania przypadków testowych jest dokument SRS / FRD / Req. Ale często nie jest to wystarczające, więc będziesz musiał wykorzystać wiele założeń i dyskusji z zespołami BA / Dev.

Pisanie skutecznych przypadków testowych to najważniejsza kwalifikacja jaką musi posiadać tester. Zwykle wszystkie przypadki testowe są klasyfikowane jako pozytywne / negatywne. Pozytywny przypadek testowy dostarcza ważnych danych wejściowych i uzyskuje pozytywne wyniki. Negatywny przypadek testowy podaje nieprawidłowe dane wejściowe i otrzymuje dokładny komunikat o błędzie.

Aby uzyskać więcej informacji na ten temat, sprawdź:

Niektóre z typowych atrybutów wszystkich przypadków testowych to:

  • Identyfikator scenariusza - wzięty z dokumentu scenariusza testowego
  • Identyfikator przypadku testowego - do unikalnej identyfikacji i śledzenia. Np .: TC_login_001
  • Opis testu - krótkie wyjaśnienie testowanych warunków testu
  • Kroki do wykonania - szczegółowe instrukcje krok po kroku dotyczące testowania
  • Dane testowe - dane dostarczane do etapów testu
  • Oczekiwany wynik - wynik zgodny z oczekiwaniami
  • Rzeczywisty wynik - reakcja AUT po uruchomieniu testu
  • Status - Zaliczony / Niepowodzenie / Brak wykonania / Niekompletne / Zablokowane - opisuje wynik testu
  • Komentarze - dodatkowe szczegóły
  • Wykonane przez - nazwisko testera
  • Data wykonania - data uruchomienia testu
  • Identyfikator defektu - defekt zarejestrowany dla przypadku testowego w przypadku niepowodzenia testu
  • Szczegóły konfiguracji - system operacyjny, przeglądarka, platforma, informacje o urządzeniu (opcjonalnie)

Zalecana lektura=>

# 3. Proces testowy - jakie testy wykonać?

Istnieje ogromna liczba typów testów, ale nie wszystkie z nich można przeprowadzić na tym AUT. Czas, budżet, charakter działalności, charakter aplikacji i interes klienta to kluczowe czynniki decydujące o wyborze testów aplikacji.

Na przykład: Jeśli jest to portal handlu elektronicznego, testy warunków skrajnych i testy obciążenia są obowiązkowe. Jednak niektóre typy testów, których nie można pominąć, to:

# 4. Testowanie na częściowym etapie rozwoju

Ogólnie rzecz biorąc, w przypadku firm średniego szczebla i firm rozpoczynających działalność, czas i zasoby są ograniczone. Testerzy mogą tutaj rozpocząć proces testowania przed integracją modułów, co oznacza, że ​​możemy wykonywać jednostkowe i pośrednie testy integracyjne.

Ważne jest, aby pamiętać, że wyników z tych etapów nie można zaliczyć do dokładnych, więc może być konieczne zaplanowanie ogólnego testu czarnej skrzynki, gdy wszystko będzie gotowe do pracy. Przeoczenie tej części może okazać się kosztowne, a testowanie nieskuteczne.

jak obsługiwać wyskakujące okienko w selenium webdriver

# 5. Dokument zgłoszenia błędu

To najbardziej krytyczny dokument dotyczący kontroli jakości, jaki kiedykolwiek stworzysz.

Oto pola, które musi zawierać dobry raport o błędzie:

  • Identyfikator wady - zwykle numer seryjny
  • Opis wady - jednowierszowe wyjaśnienie problemu
  • Lokalizacja - moduł / obszar AUT, w którym znaleziono problem
  • Numer kompilacji - Wersja i kod kompilacji nr
  • Kroki do odtworzenia - lista czynności, które prowadzą do problemu
  • Istotność - ustaw poziom opisujący powagę problemu - niski, średni, wysoki, blokujący itp.
  • Priorytet - ustawiany przez programistów w celu określenia kolejności, w jakiej usterka zostanie naprawiona (P1, P2, P3 itd. P1 - najwyższa)
  • Przypisany do - właściciela wady w tym momencie
  • Zgłoszone przez - nazwisko testera
  • Status - inny status reprezentujący etap cyklu życia błędu
    • Nowość - błąd został znaleziony i został właśnie zgłoszony
    • Otwarta - zatwierdzona przez kierownika ds. Kontroli jakości
    • Przypisane - wysłane do głównego dewelopera w celu przypisania do odpowiedniego dewelopera
    • W toku / W toku - Dev zaczął nad tym pracować
    • Naprawiono / rozwiązano - programista skończył nad tym pracować
    • Zweryfikowano / zamknięto - zespół kontroli jakości ponownie przetestował i stwierdził, że błąd został naprawiony
    • Ponowny test - zespół ds. Kontroli jakości nie zgadza się z rozwiązaniem podanym przez deweloperów i dalej postępuje z błędem w celu przeprojektowania
    • Duplikat - podobny błąd już istnieje
    • Odroczony - ważny błąd, ale zostanie naprawiony w późniejszych wersjach
    • Nieprawidłowe - to nie jest błąd, nie można go odtworzyć lub nie ma wystarczających informacji

Dalsza lektura=>

# 6. Proces podpisywania

Wycofać się a przesłanie ostatecznej dokumentacji jest zadaniem kierownika / menedżera ds. kontroli jakości. Jednak zespół musi przedłożyć powyższe dokumenty (scenariusz testowy, przypadek testowy i dokument dziennika defektów) do ostatecznego przeglądu i audytu.

Upewnij się, że wszystkie je sprawdzisz i wyślesz ostateczne wersje.

Przeczytaj także=>

Wniosek

Jest to proces, którego byłem świadkiem i doświadczyłem na własnej skórze, kiedy byłem testerem, i mam nadzieję, że dostarczył Ci on przydatnych wskazówek.

Wreszcie kariera w testowaniu była dla mnie absolutną radością i mam nadzieję, że dla Ciebie.

Wszystkiego najlepszego w Twojej karierze!

rekomendowane lektury

^