Defekt cyklu życia - jak być może już wiesz, wykonywanie testu jest fazą, w której tester faktycznie wykonuje skrypty testowe. Proces wykonywania skryptów testowych różni się w zależności od firmy i może być inny w różnych projektach w ramach tej samej firmy.
Teraz są dostępne narzędzia do wykonywania testów, takie jak - Quality Center, Microsoft Visual Studio i tak dalej. Rzeczywisty proces wykonywania każdego kroku w celu porównania rzeczywistego i oczekiwanego wyniku pozostaje taki sam dla testera funkcjonalnego, niezależnie od użytych narzędzi.
- Co się stanie, jeśli rzeczywiste zachowanie nie jest równe oczekiwanemu?
Gdy tester stwierdzi, że rzeczywisty wynik testu nie jest równy oczekiwanemu wynikowi, rejestrowana jest wada.
- Jak zalogować usterkę?
Obecnie dostępnych jest wiele narzędzi, niektóre z narzędzi do rejestrowania defektów to ClearQuest od IBM, HP Quality Center, narzędzia open source, takie jak cykl życia defektów w JIRA i tak dalej.
Istnieje kilka obowiązkowych pól, które są wspólne dla różnych narzędzi do rejestrowania defektów, pola te to:
- Cykl życia wady Opis
- Podsumowanie cyklu życia wady
- Wada zalogowana przez
- Wada przypisana do
- Istotność defektu
- Priorytet wady
- Dodatkowe migawki
- Numer wydania / nazwa
Cykl życia wady
Wada Cykl życia rozpoczyna się od zarejestrowania nowej wady. Ilekroć wada jest rejestrowana, przechodzi w stan „Nowy”.
Tester - nowa wada
Komu przypisać nową wadę?
Tester może przypisać wadę deweloperowi lub potencjalnemu deweloperowi. Ta decyzja o przypisaniu wady różni się w zależności od projektu. W niektórych miejscach pracy istnieje proces cyklu życia defektu, aby przypisać go bezpośrednio do odpowiedniego dewelopera, aw niektórych miejscach defekt jest najpierw przypisywany do leadu deweloperskiego, a lead dev z kolei przypisuje go deweloperowi.
Przypisanie defektu (nowość) - programista wadliwego cyklu życia
Przypisanie defektu (nowość) - programista Dev Leadà
Analiza defektów
Deweloper przeanalizuje defekt, aby sprawdzić, czy jest on odtwarzalny. Tutaj najważniejszym wkładem testera jest uwzględnienie wszystkich niezbędnych szczegółów w usterce. Podsumowanie defektów, szczegółowy opis defektów to pola, które pomagają interesariuszom zrozumieć defekt za jednym razem. Podsumowanie defektu powinno zawsze zawierać wyłącznie informacje o wysokim poziomie defektu. Jednocześnie powinien mieć wystarczające informacje, aby opisać przegląd defektu w jednym wierszu.
Opis wady to miejsce, w którym oczekuje się, że tester będzie zawierać wszystkie niezbędne informacje, takie jak środowisko, scenariusz, użyte dane testowe, oczekiwany wynik, rzeczywisty wynik, odniesienie do plików / danych i odniesienie do migawki.
Oto krótki przegląd różnych elementów wady Szczegółowy opis -
Środowisko
Środowisko testowe, w którym znaleziono defekt. Często projekty mają wiele środowisk testowych, w których zespół testowy wykonuje testy. Na przykład - AT (środowisko testowania zestawu), PT (środowisko testowania produktu), UAT (środowisko testowania akceptacji użytkownika) i tak dalej. Posiadanie różnych środowisk ma na celu zapewnienie elastyczności w zespole programistów i testerów w celu wdrożenia kodu w dowolnym dostępnym środowisku w celu rozpoczęcia testów na czas.
Są chwile, kiedy test produktu (zwany również testem systemowym) i testowanie UAT nakładają się, dlatego posiadanie wielu środowisk jest koniecznością, aby kontynuować równoległe testowanie.
Zdarzają się przypadki, gdy zespół programistów potrzebuje dodatkowego środowiska do debugowania problemów zgłaszanych przez zespół testujący. Zespół programistów ma również dedykowane środowisko do testowania jednostkowego.
Dlatego w przypadku wielu środowisk należy wspomnieć wady o konkretnym środowisku, w którym znaleziono problem.
Scenariusz
Scenariusz to zestaw kroków wykonanych przez testera, które doprowadziły do usterki. W tym przypadku oczekuje się, że tester wymieni wszystkie kroki, które deweloper może wykonać w celu odtworzenia wady. Często zdarza się, że tester zgłasza wadę, ale programista nie jest w stanie jej powtórzyć, a zatem wada zostaje odrzucona. Może się to zdarzyć z powodu nieprawidłowych kroków / brakujących kroków wymienionych w opisie. Jasne kroki pomagają każdemu zrozumieć defekt i powielić go bez konieczności kontaktowania się z testerem w celu uzyskania danych wejściowych. Dobrze udokumentowany scenariusz składa się z łatwych do odczytania, łatwych do zrozumienia i precyzyjnych kroków, które należy wykonać w celu odtworzenia usterki.
Dane testowe
Tester powinien wspomnieć o danych wykorzystanych podczas przepływu testów, które doprowadziły do problemu. Informacje te dają programistom szansę wykorzystania podobnych danych w celu odtworzenia wady i znalezienia przyczyny tego samego.
Istnieje kilka scenariuszy, w których tester znajduje defekt przy użyciu określonych danych, ale ten sam problem nie jest powtarzalny przy użyciu podobnych danych. Może się to zdarzyć z powodu uszkodzenia danych, dlatego wprowadzanie danych daje szansę ustalenia pierwotnej przyczyny wady. Deweloper może nie przekopać się do poziomu kodu, jeśli nastąpi uszkodzenie danych. Ten rodzaj defektu można przekształcić w defekt danych.
Oczekiwany i rzeczywisty wynik
Jest to wyróżnienie pola szczegółowego opisu, w którym tester udowadnia, że napotkany błąd jest rzeczywiście wadą. Jasne wzmianki o oczekiwanym wyniku wyjaśniają wszystkim zainteresowanym stronom, że uważają błąd za wadę. Wyobraź sobie, że wada jest rejestrowana ze wszystkimi szczegółami, ale nie określa oczekiwanego wyniku scenariusza!
Zwykle tester wprowadza tylko oczekiwany wynik może być w linii lub dwóch, jednak bardzo ważne jest, aby wspomnieć o źródle oczekiwanego wyniku. Źródło tutaj odniesienie do dokumentu, w którym wspomniany jest oczekiwany wynik. Może to być dokument wymagań lub odniesienie do scenorysu.
Odniesienie do plików / danych
Czasami wada polega na generowaniu pliku lub wprowadzania jako pliku. W tego rodzaju scenariuszach tester powinien dostarczyć informacje o pliku, który został użyty i który spowodował problem w aplikacji. Pliki te można dołączyć za pomocą narzędzia do zarządzania defektami lub można podać odniesienie do nich. Te lokalizacje referencyjne powinny być dostępne dla wszystkich zainteresowanych stron.
Odniesienie do migawki
Migawki odgrywają bardzo ważną rolę, gdy chcesz pokazać im dokładny komunikat o błędzie podziału strony wyświetlany na ekranie lub gdy chcesz pokazać szczegóły nawigacji na ekranie. Migawka daje szybki obraz napotkanej wady, ekranu, na którym znaleziono wadę, danych użytych na ekranie i tak dalej. Każde narzędzie do zarządzania defektami ma opcję dołączania migawek. Czasami tester może również załączyć arkusze kalkulacyjne Excel lub dokumenty Word.
Były to różne elementy rejestrowania defektów i najlepsze praktyki dla każdego z nich. Wracając do cyklu życia wady, po przypisaniu wady deweloperowi, przeanalizuje ją na podstawie danych podanych w pozycji wady. Jeśli zgodnie z analizą zarejestrowany problem jest rzeczywiście wadą, programista „otworzy” wadę, aby zająć się jej naprawą.
Polecane kursy
- Usługi sieciowe w pakiecie szkoleniowym Java
- Szkolenie z tworzenia gier w C ++
- Ukończ szkolenie z zakresu etycznego hakowania
- Szkolenia Vegas Pro 13
Nowe - otwarte
Wada w stanie Otwartym pokazuje, że znajduje się ona na płycie programistycznej, a programiści pracują nad jej poprawką. Jeśli analiza wykaże, że zarejestrowany problem nie jest wadą, może się to zdarzyć, gdy istnieje luka w zrozumieniu oczekiwanego zachowania systemu. Jeśli z analizy wynika, że wada jest nieważna, programista odrzuci tę wadę. Terminologia to „Odrzucony” lub „Powrót do testowania”.
Nowość - Wróć do testowania.
Jak tester powinien sprawdzić, czy wada była rzeczywiście wadą nieprawidłową?
Jest to scenariusz, w którym precyzyjny dokument wymagań pomaga wszystkim członkom zespołu dojść do wniosku, jeśli zarejestrowana wada była nieprawidłowa lub ważna. Odwoływanie się do dokumentów wymagań pomaga zarówno testerowi, jak i programistom dojść do takich samych wniosków i naprawdę ułatwia proces dyskusji.
Istnieją sytuacje, w których poprawność dokumentów projektowych i wymagań jest kwestionowana podczas odwoływania się do tych dokumentów w czasie dyskusji na temat wad, w takim przypadku powrót do Business Analyst jest uważany za najlepszą opcję wyjaśnienia zapytań.
Jako najlepszą praktykę dokumenty wymagań i projektu powinny być zawsze aktualne, aby można je było odsyłać bez żadnych dwuznaczności.
W stanie „Otwarty” zespół programistów pracuje nad naprawą wady, po naprawieniu wady status zmienia się na „Gotowy do wdrożenia”.
Otwarty - gotowy do wdrożenia
Wdrożenie to proces, w którym zmiany są przesyłane na serwer, dzięki czemu zespół testujący może pracować nad poprawioną wersją kodu. Zazwyczaj każdy projekt ma osobny zespół wdrożeniowy do tego zadania.
Na wysokim poziomie zespół programistów składa się głównie z tych 3 grup -
- Rozwój
- Cykl życia defektu podczas testowania
- Wdrożenie (lub czasami nazywane zespołem kompilacji)
Po wdrożeniu kompilacji i ponownym udostępnieniu defektu do ponownego przetestowania, zostaje on przypisany do odpowiedniego testera do zadania ponownego testowania.
Defekt przypisany do - przewodu pomiarowego.
Przewód pomiarowy - tester indywidualny.
Przypisany defekt - indywidualny tester.
W niektórych miejscach pracy wada jest najpierw przypisywana do przewodu pomiarowego, a on / ona z kolei przypisuje ją do pojedynczego testera, jednak w niektórych miejscach wada jest bezpośrednio przypisywana testerowi, który będzie go testował lub temu, który podniósł wadę.
Status tutaj zmienia się z Gotowy do wdrożenia - Gotowy test SIT.
Teraz wada znajduje się na płycie testera. Zespół testujący zweryfikuje wadę i istnieją 2 możliwości, albo poprawka zadziała poprawnie, albo ponownie pojawi się ten sam problem. W zależności od wyniku wada może przejść do następujących stanów:
Gotowe testy SIT - zamknięte
Gotowe testy SIT - ponownie otwarte
W obu powyższych scenariuszach tester jest zobowiązany do dodania komentarzy do przeprowadzonych testów. Obejmuje to wzmiankę o przetestowanych scenariuszach i wykorzystanych danych. Jeśli wada zostanie ponownie otwarta, tester powinien podać dokładnie wykonane kroki, które ponownie doprowadziły do błędu.
Status ponownego otwarcia jest taki sam jak status „Nowa” wada.
Po ponownym otwarciu wada będzie ponownie wykonywać ten sam cykl.
Defekty cyklu życia
- Decydowanie o istotności defektu - jest to jeden z częstych tematów dyskusji (często walki) wśród programistów testujących v / s.
- Wada nie jest powtarzalna w systemie dewelopera.
- Wada zgłoszona w scenariuszu niewymienionym w wymaganiach i dokumentach projektowych.
- Wada została wykryta, ale nie można jej zgłosić, ponieważ wystąpienie scenariusza w środowisku produkcyjnym jest niemożliwe.
Jak tester powinien pokonać powyższe wyzwania?
- Istotność jest wprost proporcjonalna do wpływu, jaki wada wywiera na aplikację, jeśli tester nie może kontynuować pracy z powodu wady, z pewnością jest oznaczony jako najwyższy.
- Jeśli istnieje sposób obejścia tego problemu, należy go oznaczyć jako średni poziom ważności. Oprócz uwzględnienia wpływu dalszych testów cyklu życia defektu, ważność można również zdecydować, biorąc pod uwagę sytuację, w której cały moduł ulega awarii, w tym przypadku, mimo że można przeprowadzić test innego modułu, ale istotność dla bieżącego modułu jest wysoka dlatego wada powinna być oznaczona z najwyższą dotkliwością.
- Jeśli wada nie jest odtwarzalna w systemie programisty, istnieje prawdopodobieństwo, że środowisko programistyczne i testowe nie będzie zsynchronizowane. Wada odtwarzalna w systemie testowym jest zawsze uważana za prawidłową wadę.
- Istnieją sytuacje, w których wada jest rejestrowana z uwzględnieniem ogólnego scenariusza biznesowego, ale scenariusz bezpośredni nie jest wymieniony w wymaganiach ani dokumencie projektowym. Najlepszym rozwiązaniem jest zawsze uwzględnianie rzeczywistych scenariuszy biznesowych, a nie tylko wykonywanie kroków testowych. Komunikacja z analitykami biznesowymi i innymi interesariuszami produktu odgrywa ważną rolę w rejestrowaniu takich wad.
- Istnieją scenariusze, w których tester odkrywa lukę w logice biznesowej podczas fazy testowania. Znalezienie takich luk jest ponownie uważane za duży plus dla testera. Luki w projektowaniu są zazwyczaj usuwane poprzez ulepszenia.
- Ulepszenie - jeśli zachodzi potrzeba zmiany zachowania podczas fazy testowania cyklu życia oprogramowania, tworzone jest ulepszenie, które można zastosować w bieżącej lub następnej wersji, biorąc pod uwagę ramy czasowe i przepustowość zespołów opracowujących i testujących.
- Istnieje kilka scenariuszy, które tester może przetestować podczas testów ad hoc, które mogą być scenariuszami nieprawidłowymi, biorąc pod uwagę możliwość ich wystąpienia w produkcji.
Kto jest najlepszym przyjacielem testera?
Gdzie powinien iść tester w przypadku niejasności? Odpowiedź zależy od rodzaju zapytania, jeśli zapytanie dotyczy wymagań, zaleca się najpierw przedyskutować w zespole, aby poprawnie zrozumieć system, konsultując się ze starszymi członkami. Następnym punktem kontaktowym powinni być analitycy biznesowi.
Jeśli zapytanie dotyczy procesu testowania, wskazane jest skontaktowanie się z przewodem testowym lub kierownikiem testów.
Jeśli zapytanie dotyczy zrozumienia szczegółów technicznych aplikacji, członkiem zespołu programistów może być odpowiednia osoba.
Ponieważ testowanie jest procesem wymagającym ogólnego zrozumienia systemu, komunikacja pomaga testerowi uzyskać szybką odpowiedź na pytania, zależy to tylko od zadawania właściwych pytań właściwym osobom. Unikanie zadawania pytań w odpowiednim czasie może prowadzić do wady wycieku do środowiska produkcyjnego.
Jak ważna jest dzisiaj rola testera w firmie?
Istnieją projekty, w których zespół testujący jest równie ważny jak zespół programistów, aw niektórych scenariuszach istnieje większa zależność od zespołu testowego niż od zespołu programistycznego. Późniejszy scenariusz jest rzadki, ale istnieje w niektórych miejscach pracy. Stało się to z czasem i może trwać przez określony czas, gdy zespół programistów nie ma dużego doświadczenia w porównaniu z zespołem testującym. Są ludzie, którzy lepiej rozumieją ogólny przepływ i funkcjonalność niż większość innych członków zespołu. Taka osoba może być częścią zespołu testującego / programistycznego. Jest to jeden z czynników decydujących o zależności od zespołu / osoby dla konkretnego projektu.
Jaka jest ścieżka kariery testera?
Osoba może poświęcić trochę czasu na zrozumienie ogólnego procesu testowania, dziedziny i innych zadań, nad którymi ma pracować w życiu codziennym. W oparciu o to zrozumienie wskazane jest podjęcie decyzji o zbadaniu dalszych obszarów, które może zająć tester. Proces ten zawsze umożliwia zautomatyzowanie różnych przepływów. Tworzenie małych narzędzi może również pomóc zespołowi na wielką skalę. Jeśli tester jest dobry w programowaniu, jest to uważane za duży plus. Otwiera to możliwości ról automatyzacji. Testowanie wydajności jest również jednym z torów kariery dla testerów. Analityk biznesowy to kolejna opcja. Dobra znajomość domeny i dobre umiejętności komunikacyjne są wymaganymi umiejętnościami, aby być analitykiem biznesowym. Testowanie stwarza testerom wiele możliwości pracy w różnych domenach, narzędziach, procesach itd. To zależy tylko od osoby, która odbierze i zacznie wchodzić głęboko w jeden z głównych obszarów testowych. Istnieje wiele certyfikatów specyficznych dla różnych narzędzi specjalizujących się w jednym z obszarów testowania. Posiadanie certyfikatu od standardowego dostawcy jest zaletą, aby przyspieszyć karierę, ale sam certyfikat nie może pomóc na dłuższą metę, jeśli nie zostanie połączony z odpowiednim doświadczeniem zawodowym.
Polecane artykuły
Oto kilka artykułów, które pomogą ci uzyskać więcej informacji na temat testowania oprogramowania, więc po prostu przejdź przez link.
- 6 najbardziej niesamowitych pytań do wywiadu podczas testowania oprogramowania
- Kariery w testowaniu oprogramowania
- Jak uzyskać lepszy wzrost kariery w pracy testera oprogramowania