Menu

Szkolenie z testowania oprogramowania: szkolenie od początku do końca dotyczące projektu na żywo - bezpłatne szkolenie online z kontroli jakości, część 1

software testing training

DarmowySzkolenie z testowania oprogramowaniaW projekcie na żywo w czasie rzeczywistym:

Jesteśmy bardzo podekscytowani, że możemy zaprezentować to następne seria bezpłatnych samouczków z testowania oprogramowania. Zamierzamy zasymulować od końca do końca projekt oprogramowania w czasie rzeczywistym, szczegółowo omawiając każdą fazę, ze szczególnym naciskiem na procesy szkoleniowe QA, fazy, role i obowiązki, produkty itp.

Krótko mówiąc, przygotuj się na krótki kurs online z testowania oprogramowania.

_Koniec, aby zakończyć szkolenie w projekcie na żywo

Ważna uwaga : Poniższe bezpłatne samouczki są przydatne na początek, ale jeśli interesuje Cię najlepszy internetowy kurs testowania oprogramowania LIVE od ekspertów, sprawdź tę stronę.

Testowanie szkolenia QA

=> Tutaj jestlista wszystkich tutorialiw tym bezpłatnym cyklu szkoleniowym Live Project QA:

Dlaczego to bezpłatne szkolenie QA?

dbms open source to:

Otrzymujemy wiele zapytań od naszych czytelników, aby podzielić się naszym doświadczeniem na temat dokładny proces testowania oprogramowania a następnie zespoły testujące oprogramowanie. Postanowiliśmy więc udokumentować ten kompletny STLC za pomocą przykładowej aplikacji na żywo, która jest dostępna do przetestowania w Internecie.

Będziemy używać tego projektu na żywo w naszej serii szkoleń z testowania oprogramowania. Zdecydowanie zalecamy uważne śledzenie tej serii, ponieważ będzie to szybki kurs do nauki i wdrażania praktyki testowania w aplikacji na żywo.

Czego się nauczysz:

Szkolenie z testowania oprogramowania w projekcie na żywo - co to jest?

Zanim przejdziemy dalej, pozwólcie mi poświęcić chwilę, aby wyjaśnić, o co chodzi w tej serii kursów testowania oprogramowania i jak będzie się kształtować w miarę postępów.

Wybraliśmy aplikację na żywo (której szczegóły znajdują się poniżej) i zaczynamy od:

- Zasadniczo wszystko, co zwykle robilibyśmy w projekcie testowania oprogramowania w czasie rzeczywistym - z przykładami, artefaktami i materiałami dostarczanymi w czasie rzeczywistym tworzonymi w trakcie procesu.

Jak postępować zgodnie z tą serią kursów testowania oprogramowania?

Krok 1) Wprowadzenie i przewodnik po SRS - ten mini kurs testowania oprogramowania rozpoczniemy od przewodnika po SRS. Stworzyliśmy i udostępniliśmy przykładowy dokument SRS. Wykonaj to, ponieważ wszystkie dalsze kroki zależą od zrozumienia tej aplikacji.

Krok 2) Przegląd SRS i przygotowanie scenariusza testowego.

Krok 3) Plan testów - zakończ proces tworzenia planu testów od podstaw. Ostateczna wersja planu testów zostanie udostępniona w celach informacyjnych.

Krok 4) Przypadki testowe - pełny proces pisania przypadków testowych z kilkoma przykładowymi przypadkami testowymi. Do pisania przypadków testowych możemy używać dowolnego narzędzia do zarządzania testami lub arkusza kalkulacyjnego.

Krok 5) Przewodnik po aplikacji i wykonanie testów - jak wykonywać przypadki testowe i zapisywać wyniki testów?

Krok 6) Zgłaszanie defektów

Krok 7) Weryfikacja defektów, regresyjny proces testowania

Krok 8) Podpis QA

Celem jest zapewnienie wszystkim poczucia doświadczenia i wiedzy projektowej w czasie rzeczywistym. Mamy nadzieję, że ta seria okaże się przydatna.

Aplikacja, której będziemy używać dalej

Wprowadzenie

Klient: Pomarańczowy
Podanie: Demo OrangeHRM .
Dostawca usługi: SoftwareTestingHelp.com

Opis Projektu

Orange chce stworzyć komercyjny produkt do zarządzania zasobami ludzkimi, który może być używany i dostosowywany przez średnie firmy zlokalizowane w jednym kraju i na całym świecie.

Posiada 2 wersje: Profesjonalne i korporacyjne.

Funkcje obejmują

  • Zarządzanie danymi osobowymi
  • Zaawansowane zarządzanie urlopami
  • Śledzenie czasu i obecności
  • Zarządzanie wydajnością pracowników
  • Rekrutacja
  • Zaawansowane raportowanie
  • Zarządzanie pracownikami w oparciu o kraj / lokalizację
  • Zlokalizowane zasady urlopowe
  • Konfigurowalne przepływy pracy
  • Wsparcie Platinum
  • Raportowanie na podstawie kraju / lokalizacji
  • Raportowanie niestandardowe

Uwaga : Dla uproszczenia i dla ograniczenia zakresu rozważmy moduł pracowniczy tego portalu HRM, w którym użytkownik ma możliwość wprowadzenia swoich danych osobowych.

Gdy klient lub właściciel firmy ma potrzebę zapuszczenia się w świat online lub wprowadzenia aktualizacji w już istniejącej witrynie lub aplikacji, potrzeba jest problemem biznesowym, a oprogramowanie to fragment kodu, który ma na celu rozwiązanie tego problemu biznesowego.

Następnie klient zwraca się do dostawcy usług oprogramowania, aby uczynić to oprogramowanie dla siebie. Wtedy zaczyna się projekt oprogramowania.

Tradycyjny Projekt wodospadu (SDLC) ma następujące fazy:

Proces tworzenia oprogramowania

  • Jako pracownicy kontroli jakości wszyscy wiemy, że chociaż „Test” jest piątym krokiem tego przepływu, nie jest to jedyne miejsce, w którym my, testerzy, odgrywamy znaczącą rolę.
  • Testowanie to również praca reaktywna. Bez kodu / aplikacji gotowej do przetestowania nie możemy tak naprawdę niczego „przetestować”. Aby być gotowym i reagować w możliwie najbardziej efektywny sposób, staramy się jak najlepiej zaplanować i przygotować się z wyprzedzeniem. Tak więc, mimo że faza 5 jest przeznaczona na testy, nasze działania zaczynają się z dużym wyprzedzeniem.

Krótko mówiąc, to właśnie dzieje się w każdej fazie !!

Zainicjować:

Po ustaleniu przez producenta i klienta warunków - rozpoczyna się produkcja oprogramowania.

  • Na tym etapie zbierane i analizowane są wymagania biznesowe. Analiza obejmie między innymi decyzje dotyczące aspektów technologicznych, specyfikacji sprzętu i oprogramowania, ludzi, wysiłku, czasu, znaczenia i ulepszeń.
  • W tym kroku uczestniczą analitycy biznesowi, kierownicy projektów i przedstawiciele klientów.
  • Pod koniec tego kroku i podstawowego projektu przygotowywany jest plan.
  • Tworzone są dokumenty specyficzne dla projektu, takie jak dokument zakresu i / lub wymagania biznesowe.
  • Na tym etapie zwykle nie oczekuje się zaangażowania w kontrolę jakości. (Jest to niewielkie odchylenie od tego, co powinno być, ponieważ aby zidentyfikować problemy na wczesnym etapie rozwoju, najlepiej jest włączyć kontrolę jakości od samego początku).

Definiować:

Sfinalizowane wymagania biznesowe są danymi wejściowymi dla tego kroku.

  • Ta faza obejmuje tłumaczenie wymagań biznesowych na wymagania funkcjonalne oprogramowania. Na przykład , jeśli wymaganiem biznesowym jest umożliwienie użytkownikowi zakupu czegoś w witrynie. Wymóg funkcjonalny będzie zawierał szczegóły, takie jak Format strony-> Nazwa i umiejscowienie opcji menu-> Wyszukaj produkt-> Koszyk-> Do kasy (rejestracja lub nie) -> Opcje płatności-> Potwierdzenie sprzedaży.
  • W tej fazie zaangażowani są deweloperzy, analitycy biznesowi, kierownicy projektów
  • Efektem tej fazy jest szczegółowy dokument zawierający wymagania funkcjonalne oprogramowania. Do tego dokumentu odnosi się wiele nazw - specyfikacja wymagań oprogramowania (SRS), dokument wymagań funkcjonalnych (FRD) lub specyfikacja wymagań funkcjonalnych (FRS).
  • Tu angażuje się zespół QA - po skompletowaniu dokumentacji SRS.
  • Podczas finalizowania wymagań funkcjonalnych i dokumentacji SRS, kierownik / lider QA jest zaangażowany w przygotowanie projektu wstępna wersja planu testów i stwórz zespół ds. kontroli jakości.
  • Zaangażowanie zespołu QA nastąpi po udokumentowaniu SRS.
  • Na tym etapie zespół programistów lub analityk biznesowy, a czasem nawet kierownik zespołu QA przedstawi zespołowi QA przegląd SRS.
  • W przypadku nowego projektu najlepiej sprawdza się dokładny opis przejścia w formie konferencji lub spotkania
  • W przypadku późniejszych wydań dla istniejącego projektu dokument jest wysyłany pocztą elektroniczną lub umieszczany we wspólnym repozytorium do zespołu QA. Zespół kontroli jakości w tym momencie przeczyta / przejrzy go w trybie offline i dokładnie zrozumie system.
  • Ponieważ głównymi odbiorcami docelowymi dokumentu SRS są nie tylko testerzy, nie wszystkie z nich są dla nas przydatne. My, testerzy, powinniśmy być wystarczająco sumienni podczas przeglądania tego dokumentu, aby zdecydować, które jego części są dla nas przydatne, a które nie.

Dokument SRS dla tego projektu na żywo

Przykładowy dokument SRS jest dołączony do tego postu aby dać Ci wyobrażenie o tym, jak ten dokument wygląda, w jakim formacie jest napisany, jakie informacje zawiera itp. W następnym artykule zajmiemy się tym, jak ten dokument jest używany przez zespół ds. kontroli jakości, aby przejść dalej w naszych projektach testowych.

==> Pobierz dokument SRS dotyczący projektu na żywo .

Wniosek

W tym artykule wprowadziliśmy Cię w proces tworzenia i testowania oprogramowania. Udostępniliśmy również przykładowy dokument SRS dotyczący projektu na żywo, który zamierzamy przetestować.

=> Nadchodzący artykuł z tej serii szkoleń poświęconych testowaniu oprogramowania będzie - Przegląd SRS i proces tworzenia scenariuszy testowych .

pytania i odpowiedzi na wywiady z inżynierem pomocy technicznej

Uwaga: Podczas pisania następnego artykułu z tej serii szkoleń dotyczących zapewniania jakości, pracuj z nami równolegle w celu uzyskania większość doświadczeń na żywo . Postaraj się dobrze przeczytać dokument SRS, a kiedy znów się spotkamy, będziemy kontynuować kolejne kroki.

Miłego testowania, do tego czasu!

O autorze: Swati Seela, członek zespołu STH, pomaga nam w prezentacji serii szkoleń dotyczących kontroli jakości projektu na żywo.

rekomendowane lektury

^