Menu

Praktyczny przebieg procesu testowania oprogramowania QA (wymagania do wydania)

practical software testing qa process flow

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Pełny przegląd kompleksowego przebiegu procesu testowania oprogramowania do kontroli jakości:

Uwaga - ponownie publikujemy ten przydatny post ze zaktualizowaną zawartością.

Praca specjalisty od testowania oprogramowania nie jest łatwa. Jest pełen wyzwań, ale i równie wymagających. Testerzy powinni być czujni i entuzjastyczni na każdym etapie cyklu życia aplikacji.

Chociaż istnieją wyzwania, istnieje również kilka ogromnych możliwości poznania i zbadania różnych aspektów metodologii testowania, procesów i oczywiście szczegółowego oprogramowania.

Rola inżyniera testów zaczyna się bardzo wcześnie. Od samego początku konceptualizacji projektu testerzy uczestniczą w dyskusjach z właścicielem produktu, kierownikiem projektu i różnymi interesariuszami.

Wymagania dotyczące wydania

Ten samouczek dotyczący „Przepływu procesu testowania oprogramowania” zawiera pełny przegląd różnych faz w STLC wraz z towarzyszącymi wyzwaniami i najlepszymi praktykami, aby sprostać tym wyzwaniom w łatwy do zrozumienia sposób.

Czego się nauczysz:

Wymóg wydania - pełny przegląd

Cykl życia testowania oprogramowania

Od wymagania do wydania każda faza jest jasno wyjaśniona. Przyjrzyjmy się im szczegółowo.

1) Wymaganie

Projekt nie może ruszyć bez wyraźnych wymagań. Jest to najważniejsza faza, w której pomysły muszą zostać zapisane w dobrze zrozumiałym i sformatowanym dokumencie. Jeśli jesteś częścią projektu, w którym uczestniczysz w fazie zbierania wymagań, to pomyśl, że masz szczęście.

jak otworzyć plik jnlp w systemie Windows 10

Zastanawiać się dlaczego? To dlatego, że jesteś świadkiem tworzenia projektu od zera. Chociaż jest dumny z tego, że istnieje od samego początku, wiąże się również z pewnymi obowiązkami i wyzwaniami.

Wyzwania

Nie można sobie wyobrazić wszystkich wymagań, aby zebrać się na jednym posiedzeniu. Bądź wystarczająco cierpliwy.

Będzie miało miejsce wiele dyskusji, z których niektóre mogą być po prostu nieistotne dla twojego projektu, ale nawet wtedy mogą zawierać istotne informacje dla twojego projektu. Czasami szybkość dyskusji może przekraczać twoje możliwości chwytania lub po prostu nie zwracasz uwagi na właściciela produktu.

Poniższy rysunek przedstawia kluczowe kroki związane z gromadzeniem wymagań:

Cykl życia wymagań

Każda brakująca informacja ma ogromny wpływ na ogólne zrozumienie i testowanie projektu. Aby temu zaradzić, oto kilka najlepszych praktyk, których należy przestrzegać na tym etapie.

Najlepsze praktyki

  • Miej otwarty umysł i zwracaj uwagę na każde słowo właściciela produktu.
  • Nie tylko słuchaj, rozwiąż swoje wątpliwości, jakkolwiek małe się one wydają.
  • Zawsze używaj notatników do szybkiego sporządzania notatek. Powinieneś używać laptopa, tylko jeśli naprawdę możesz pisać z odpowiednią prędkością.
  • Powtórz zdania i poproś o ich wyjaśnienie z PO, co Twoim zdaniem jest tym, co zrozumiałeś.
  • Rysuj diagramy blokowe, tekst linków itp., Aby w późniejszym czasie wymagania były bardziej zrozumiałe.
  • Jeśli zespoły są w różnych lokalizacjach, postaraj się, aby było to nagranie WebEx lub podobne. Zawsze pomoże, gdy będziesz mieć wątpliwości po zakończeniu dyskusji.

Chociaż nie ma oddzielnej ściany jako takiej dla każdej fazy, wymagania zmieniają się nawet bardzo późno. Tak więc chodzi o to, aby pobrać większość wymagań i odpowiednio je udokumentować.

Po udokumentowaniu wszystkich niezbędnych punktów, rozpowszechnij i omów wszystkich interesariuszy, tak aby wszelkie sugestie lub zmiany zostały wychwycone wcześnie, a przed przejściem wszyscy są na tej samej stronie.

# 2) Strategia testów

Testerzy mają opracować strategię testowania, która nie tylko wystarczy do lepszego przetestowania oprogramowania, ale także powinna wzbudzić zaufanie każdego interesariusza co do jakości produktu.

Strategia testów

Wyzwania

Najważniejszym aspektem tej fazy jest stworzenie strategii, nad którą pracując, powinno powstać oprogramowanie, które jest wolne od błędów, trwałe i akceptowane przez użytkowników końcowych.

Strategie testowe to coś, czego nie będziesz zmieniać co drugi dzień. W niektórych przypadkach musisz również omówić swoje strategie testowe z klientami. Dlatego tę część należy potraktować bardzo poważnie.

Najlepsze praktyki

  • Oto niektóre z najlepszych praktyk, których przestrzeganie może przynieść wielką ulgę i zaowocować płynnym testowaniem.
  • Jeszcze raz przejrzyj dokument wymagań. Wyróżnij punkty importu w odniesieniu do środowiska oprogramowania docelowego.
  • Sporządź listę środowisk, w których oprogramowanie zostanie faktycznie wdrożone.
  • Środowiska można rozumieć jako rodzaj systemów operacyjnych lub urządzeń mobilnych.
  • Jeśli systemem operacyjnym jest Windows, wypisz wszystkie wersje okna, w którym będziesz testować oprogramowanie. Jeśli wersje, a mianowicie. Systemy Windows 7, Windows 10 lub Windows Server nadal nie są zdefiniowane w dokumencie wymagań, więc nadszedł najwyższy czas, aby je omówić.
  • Podobnie, pobierz docelowe przeglądarki z omówionymi i udokumentowanymi wersjami, jeśli AUT jest systemem internetowym.
  • Zrób listę wszystkich programów innych firm, których będzie potrzebować aplikacja (jeśli jest to wymagane / obsługiwane). Mogą to być Adobe Acrobat, Microsoft Office, wszelkie dodatki itp.

W tym przypadku chodzi o to, aby zachować przed nami każdą niezbędną i wymaganą platformę, urządzenia i oprogramowanie, których nasza aplikacja będzie potrzebować do działania, aby można było sformułować kompleksową strategię.

Poniższy rysunek pomoże ci zrozumieć zarys strategii testowej, jeśli pracujesz nad zwinnym projektem:

Strategia testowania

# 3) Planowanie testów

Po uzbrojeniu testerów we wszystkie informacje dotyczące AUT, strategia jest wdrażana w fazie planowania.

Podobnie jak strategia testów, planowanie testów jest również kluczową fazą.

Plan testów

Wyzwania

Ponieważ sukces (lub porażka) AUT zależy w dużej mierze od tego, jak testy zostały przeprowadzone, faza ta staje się ważnym aspektem całego cyklu życia testów. Czemu? Ponieważ część testów jest definiowana w tej fazie.

Aby sprostać niektórym wyzwaniom, te najlepsze praktyki mogą być naprawdę pomocne.

Najlepsze praktyki

  • Zawsze pamiętaj, aby nie pozostawiać kamienia na kamieniu, jeśli chodzi o testowanie aplikacji.
  • Czas sformułować strategię testową.
  • Utwórz macierz środowiska, aby oprogramowanie było testowane na wszystkich platformach.
  • Na przykład Windows 10 + Internet Explorer 11+ Windows Office 2010+.
  • Podobnie jak przeglądarka Chrome na Androida 4.2.2+.
  • Jeśli Twoja aplikacja działa z wieloma bazami danych (jeśli jest udokumentowana), przechowuj bazy danych (MySQL, Oracle, SQLServer) w macierzy testów w taki sposób, aby były zbyt zintegrowane z niektórymi testami.
  • Skonfiguruj odpowiednio maszyny testowe i nazwij je jako SetUp1, SetUp2 itd.
  • SetUp1 będzie miał Windows 7+ IE 10+ Office 2007+.
  • SetUp2 może mieć system Windows 10+ IE Edge + Office 2013+.
  • SetUp3 może mieć telefon z systemem Android z zainstalowanym plikiem .apk.
  • Gratulacje! Twoja konfiguracja testowa jest gotowa, a także uwzględniono wszystkie możliwe kombinacje platform, na których będzie działać Twoja aplikacja.

# 4) Testowanie

Znajdowanie błędów

Wreszcie, Twoja kompilacja aplikacji została zakończona i jesteś gotowy do znajdowania błędów! Nadszedł czas, aby popracować nad planowaniem testów i znaleźć jak najwięcej błędów. Jeśli pracujesz w zwinnym środowisku, będą między nimi pewne fazy, a następnie po prostu postępuj zgodnie z tymi metodami scrum.

Poniższy diagram przedstawia kategoryzację różnych typów testów:

Rodzaje testów

Wyzwania

Testowanie to uciążliwy proces, który sam w sobie jest podatny na błędy! Podczas testowania aplikacji napotyka się wiele wyzwań. Poniżej podano kilka najlepszych praktyk ratunkowych.

Najlepsze praktyki

Rozchmurz się! Próbujesz znaleźć błędy w kodzie. Musisz zwrócić uwagę na ogólne działanie oprogramowania.

  • Zawsze wskazane jest, aby spojrzeć na aplikację świeżym spojrzeniem, BEZ PRZEPROWADZANIA PRZYPADKÓW TESTOWYCH.
  • Postępuj zgodnie ze ścieżką nawigacji swojego oprogramowania (AUT).
  • Zapoznaj się z AUT.
  • Przeczytaj teraz przypadki testowe (wszystkie) dowolnego konkretnego modułu (może do wyboru).
  • Teraz przejdź do AUT i porównaj wyniki z tymi wymienionymi w oczekiwanej sekcji przypadków testowych.
  • Ideą jest przetestowanie każdej wymienionej funkcji na każdej obsługiwanej platformie.
  • Zanotuj każde odchylenie, jakkolwiek błahe się wydaje.
  • Zapisz kroki prowadzące do odchylenia, zrób zrzuty ekranu, przechwytuj dzienniki błędów, dzienniki serwera i inną dokumentację pomocniczą, która może udowodnić istnienie usterek.
  • Nie wahaj się zapytać. Chociaż masz dokument wymagań, będą chwile, kiedy będziesz mieć wątpliwości.
  • W razie wątpliwości skontaktuj się z programistami (jeśli siedzą obok Ciebie lub są osiągalni), zanim dotrzesz do Właściciela Produktu. Zapoznaj się z perspektywą programisty dotyczącą działania oprogramowania. Zrozumieć ich. Jeśli uważasz, że ta implementacja nie jest zgodna z wymaganiami, poinformuj o tym kierownika testów.

# 5) Przed wydaniem

Zanim wprowadzimy jakikolwiek produkt na rynek, należy zapewnić jego jakość. Oprogramowanie jest tworzone raz, ale w rzeczywistości jest testowane, dopóki nie zostanie zastąpione lub usunięte.

Wyzwania

Oprogramowanie musi być rygorystycznie testowane pod kątem wielu parametrów.

Parametry nie mogą być ograniczone do:

  • Funkcjonalność / behawioralna.
  • Wydajność.
  • Skalowalność.
  • Kompatybilny z wymienionymi platformami.

Wyzwaniem jest również przewidzenie wskaźnika sukcesu aplikacji, który zależy od wielu iteracji przeprowadzonych testów.

Najlepsze praktyki

  • Upewnij się, że przetestowano wszystkie funkcje na wszystkich platformach.
  • Podkreśl obszary, które nie są testowane lub te, które wymagają więcej testów.
  • Zachowaj macierz wszystkich wyników testów przed wydaniem. Macierz testowa da ogólny obraz stabilności produktu. Pomoże również kierownictwu odebrać telefon w sprawie dat premiery.
  • Przekaż zespołowi swoje uwagi / sugestie dotyczące doświadczeń podczas testowania produktu.
  • Twoje uwagi, uważając siebie za użytkownika końcowego, przyniosą korzyści oprogramowaniu.
  • Z powodu kryzysu czasowego lub jakiejkolwiek innej takiej sytuacji, albo pomijamy niektóre testy, albo nie zagłębiamy się w to. Nie wahaj się i poinformuj przełożonego o stanie testów.
  • Przedstaw interesariuszom kartę zdrowia aplikacji. Karty zdrowia powinny zawierać liczbę wszystkich zarejestrowanych, otwartych, zamkniętych, sporadycznych usterek wraz z ich wagą i priorytetem.
  • Przygotuj dokument wersji i udostępnij go zespołowi.
  • Praca nad przygotowanym dokumentem wydania.
  • Popraw obszary, które zostały zasugerowane przez kierownictwo / zespół.

Poniższy rysunek przedstawia mapę cyklu życia wersji oprogramowania:

Przed wydaniem

# 6) Zwolnij

Wreszcie przychodzi czas, kiedy musimy dostarczyć produkt do jego zamierzonych użytkowników. Wszyscy jako zespół ciężko pracowaliśmy, aby wyrejestrować produkt i pozwolić oprogramowaniu pomóc użytkownikom.

Wyzwania

Inżynierowie testujący oprogramowanie są przede wszystkim odpowiedzialni za wydanie dowolnego oprogramowania. To działanie wymaga przepływu pracy zorientowanego na proces. Oto niektóre z najlepszych praktyk stosowanych na tym etapie.

Najlepsze praktyki

  • Zawsze pamiętaj, że nie pracujesz nad dokumentem wydania w dniu RZECZYWISTEGO WYDANIA.
  • Zawsze planuj publikację przed faktyczną datą premiery.
  • Standaryzuj dokument zgodnie z polityką firmy.
  • Dokument wersji powinien zawierać pozytywne oczekiwania wobec oprogramowania.
  • Wymień wyraźnie w dokumencie wszystkie wymagania dotyczące oprogramowania i sprzętu specyficzne dla ich wersji.
  • Uwzględnij wszystkie otwarte wady i ich powagę.
  • Nie zakrywaj głównych obszarów dotkniętych przez otwarte defekty. Daj im miejsce w dokumencie wydania.
  • Poproś o sprawdzenie dokumentu i podpisanie go cyfrowo (może się różnić zgodnie z polityką firmy).
  • Bądź pewien i wyślij dokument wersji razem z oprogramowaniem.

Proces testowania jakości w rzeczywistym projekcie - metoda wodospadu

Otrzymałem ciekawe pytanie od czytelnika, Jak przeprowadzane są testy w firmie, czyli w praktyce?

Ci, którzy właśnie kończą studia i zaczynają szukać pracy, mają tę ciekawość - jak wyglądałoby rzeczywiste środowisko pracy w firmie?

Tutaj skupiłem się na rzeczywistym procesie pracy Testowanie oprogramowania w firmach .

Rzeczywisty proces testowania w firmach

Za każdym razem, gdy otrzymujemy nowy projekt, odbywa się wstępne spotkanie dotyczące projektu. Na tym spotkaniu w zasadzie omawiamy, kto jest klientem? jaki jest czas trwania projektu i kiedy następuje jego realizacja? Kto jest zaangażowany w projekt, tj. Kierownik, liderzy techniczni, liderzy kontroli jakości, programiści, testerzy itp.?

Na podstawie SRS (specyfikacji wymagań oprogramowania) opracowywany jest plan projektu. Obowiązkiem testerów jest stworzenie planu testów oprogramowania na podstawie niniejszego SRS i planu projektu. Programiści zaczynają kodować od projektu. Prace projektowe są podzielone na różne moduły, a te moduły projektowe są dystrybuowane między programistów.

W międzyczasie obowiązkiem testera jest stworzenie scenariusza testowego i napisanie przypadków testowych zgodnie z przypisanymi modułami. Staramy się objąć prawie wszystkie funkcjonalne przypadki testowe z SRS. Dane można utrzymywać ręcznie w niektórych szablonach przypadków testowych programu Excel lub narzędziach do śledzenia błędów.

Kiedy programiści skończą poszczególne moduły, te moduły są przypisywane do testerów. Na tych modułach wykonywane są testy dymu, a jeśli nie przejdą tego testu, moduły są ponownie przypisywane do odpowiednich programistów w celu usunięcia.

W przypadku zaliczonych modułów testy manualne są przeprowadzane na podstawie pisemnych przypadków testowych. Jeśli zostanie znaleziony błąd, który zostanie przypisany do programisty modułu i zaloguje się do narzędzie do śledzenia błędów . Po naprawieniu błędu tester przeprowadza weryfikację błędów i testy regresyjne wszystkich powiązanych modułów. Jeśli błąd przejdzie weryfikację, zostanie oznaczony jako zweryfikowany i oznaczony jako zamknięty. W przeciwnym razie powyższy cykl błędów zostanie powtórzony. (O cyklu życia błędu w innym poście)

Na poszczególnych modułach wykonywane są różne testy, a na integracji modułów testy integracyjne. Testy te obejmują testowanie zgodności, tj. Testowanie aplikacji na różnym sprzęcie, wersjach systemu operacyjnego, platformach oprogramowania, różnych przeglądarkach itp.

Testy obciążeniowe i naprężeniowe są również przeprowadzane zgodnie z SRS. Wreszcie testowanie systemu polega na utworzeniu wirtualnego środowiska klienta. Po wykonaniu wszystkich przypadków testowych przygotowywany jest raport z testów i podejmowana jest decyzja o wydaniu produktu!

Kroki w wymaganiach do wydania

Poniżej podano szczegóły każdego etapu testowania, który jest przeprowadzany w każdym cyklu życia jakości i testowania oprogramowania określonym przez Normy IEEE i ISO.

# 1) Przegląd SRS : Przegląd specyfikacji wymagań oprogramowania.

# 2) Cele są przeznaczone dla głównych wydań.

# 3) Data docelowa planowane na Wydania.

4) Szczegółowy plan projektu jest zbudowany. Obejmuje to decyzję dotyczącą specyfikacji projektu.

5) Opracuj plan testów opiera się na Specyfikacjach Projektowych.

# 6) Plan testów: Obejmuje to cele, metodologię przyjętą podczas testowania, funkcje do przetestowania, a nie do przetestowania, kryteria ryzyka, harmonogram testów, obsługę wielu platform i przydział zasobów do testowania.

# 7) Specyfikacje testu: Ten dokument zawiera szczegóły techniczne (wymagania dotyczące oprogramowania) wymagane przed testowaniem.

# 8) Pisanie przypadków testowych

  • Palić ( BVT ) przypadki testowe
  • Przypadki testów poczytalności
  • Przypadki testów regresji
  • Negatywne przypadki testowe
  • Rozszerzone przypadki testowe

# 9) Rozwój: Moduły są opracowywane jeden po drugim.

# 10) Wiązanie instalatorów: Instalatorzy budowani są wokół pojedynczego produktu.

przekazanie tablicy do metody java

#jedenaście) Procedura budowania : Kompilacja zawiera instalatory dostępnych produktów - wiele platform.

# 12) Testowanie: Smoke Test (BVT): Podstawowy test aplikacji pozwalający na podjęcie decyzji o dalszych testach.

  • Testowanie nowych funkcji
  • Wiele przeglądarek i testy międzyplatformowe
  • Testowanie warunków skrajnych i testowanie wycieków pamięci.

# 13) Raport podsumowujący test

# 14) Kod zamrożony

  • W tym momencie nie są dodawane żadne nowe funkcje.

# 15) Testowanie: Testowanie kompilacji i regresji.

# 16) Decyzja o wydaniu produktu.

# 17) Scenariusz po wydaniu dla dalszych celów.

Było to podsumowanie rzeczywistego procesu testowania w środowisku firmowym.

Wniosek

Praca testera oprogramowania jest pełna wyzwań, ale przyjemna. To jest dla kogoś, kto jest równie namiętny, zmotywowany i pełen entuzjazmu. Znajdowanie w kimś błędów nie zawsze jest łatwym zadaniem! Wymaga to wielu umiejętności i strzału w dziesiątkę wady.

Oprócz wszystkich cech tester powinien być również zorientowany na proces. Podobnie jak we wszystkich innych branżach, projekty w IT są również realizowane etapami, gdzie każda faza ma dobrze zdefiniowane cele. Każdy cel ma dobrze określone kryterium akceptacji. Inżynier testów musi nosić na swoich barkach wiele jakości oprogramowania.

Pracując na dowolnym etapie oprogramowania, testerzy powinni postępować zgodnie z najlepszymi praktykami i powinni dostosować się do procesu występującego w odpowiednich fazach. Postępowanie zgodnie z najlepszymi praktykami i dobrze sformułowanym procesem nie tylko ułatwia pracę testerom, ale także pomaga w zapewnieniu jakości oprogramowania.

Czy byłeś częścią którejkolwiek z powyższych faz? Zapraszam do podzielenia się swoimi doświadczeniami poniżej.

rekomendowane lektury

^