Wprowadzenie do pracy testera oprogramowania
Co jest pierwszą rzeczą, która przychodzi Ci na myśl, gdy myślisz o testowaniu oprogramowania? Praca niekodująca? Lub zawód, który jest bardzo łatwy, ponieważ daje możliwość znalezienia błędów w pracy innych osób (znalezienie błędów, gdy w innych jest najłatwiejszym zadaniem dla nas wszystkich)? A może myślisz o tym jako o zawodzie zajmującym się sprawdzaniem poprawności produktu? Wszystkie te myśli są poprawne i stanowią codzienne czynności związane z pracą testera oprogramowania. Jednak testowanie oprogramowania nie ogranicza się tylko do tych działań.
Zrozumienie zastosowania
Aplikacja może pochodzić z dowolnej domeny - opieki zdrowotnej, ubezpieczeń, finansów itp. Nauka domeny aplikacji jest bardzo ważna dla każdego oprogramowania, aby otworzyć drzwi do myślenia z różnych punktów widzenia i różnych perspektyw użytkownika podczas testowania aplikacji. Odkrycie i zweryfikowanie oczywistych i nie tak oczywistych ścieżek zastosowania jest zawsze głównym oczekiwaniem. Posiadanie dogłębnej wiedzy na temat aplikacji pomaga skutecznie zweryfikować produkt, a jednocześnie tester może stać się atutem projektu, w którym uważa się go za jedno z głównych źródeł wiedzy na temat zachowania produktu.
Podczas gdy nauka domeny i funkcjonalności jest procesem ciągłym, każdy inny ważny czynnik to wiedza na temat procesu testowania.
Proces testowania
Proces testowania może się różnić w zależności od firmy, a nawet od jednego projektu do drugiego. Dzisiaj mamy różne modele rozwoju oprogramowania, takie jak model V, model prototypowania lub zupełnie inną metodologię, taką jak zwinne podejście do tworzenia oprogramowania. Wraz ze zmianą modelu programowania zmienia się również podejście do testowania, które należy zastosować. Praca w modelu V będzie miała dobrze zdefiniowane procesy, podczas gdy oczekuje się, że ta praca w zwinnej metodologii sprawdzi się w ciągle zmieniających się warunkach.
Zadanie nie jest jeszcze płynne, z posiadaniem akceptowalnej wiedzy w dziedzinie i zrozumienia procesu testowania, kolejnym wyzwaniem związanym z życiem jest nauka różnych narzędzi.
Przybory
Narzędzia obejmują narzędzia do zarządzania testami, narzędzia do rejestrowania defektów, narzędzia do zarządzania bazami danych i tak dalej.
Dzięki różnym cechom i narzędziom do rejestrowania defektów, niektórym narzędziom typu open source i niektórym licencjonowanym, zawsze wiedza o więcej niż jednym narzędziu jest zaletą. Pomaga w łatwym przenoszeniu projektów lub zespołów według różnych narzędzi. Przy odpowiedniej wiedzy na temat domeny, procesu i narzędzi życie Software Testera ma jeszcze więcej, co sprawia, że jego dni pracy są trudne i ekscytujące. Współpraca w zespołach jest jednym z ważnych czynników sukcesu każdego projektu, a dla efektywnej współpracy komunikacja odgrywa bardzo ważną rolę.
Polecane kursy
- Ukończ kurs kompleksowy J2EE
- Szkolenie z programowania online R.
- Idź kurs programowania
- Szkolenie certyfikacyjne online w programie Haskell
Komunikacja
Komunikacja odgrywa bardzo ważną rolę dla jakości oprogramowania, ponieważ od początkowych faz tworzenia oprogramowania, członkowie zespołu testującego są zaangażowani (jako najlepsza praktyka) w dyskusję na temat wymagań, kwestionując analityków biznesowych w przypadku jakichkolwiek zapytań lub luk w wymaganiach. Tster ze skutecznymi umiejętnościami komunikacyjnymi może skutecznie komunikować ryzyko, może skutecznie komunikować się z zespołem programistycznym i może skutecznie komunikować wyniki testów i raporty z testów.
Planowanie pracy testera oprogramowania
Jak sama nazwa wskazuje, planowanie testów jest fazą przygotowania się do testów. Przygotowanie do testu będzie wiązało się z różnego rodzaju czynnościami, które wykonuje on w celu skutecznego zastosowania. Pomoże to w sprawdzeniu poprawności wniosku i skutecznym wykryciu wad w aplikacji. Aby rozpocząć planowanie, teste spełnia wymagania, aby zrozumieć oczekiwania.
1. Wymagania
Zespół testujący może otrzymać wymagania w postaci szkieletów, scenariuszy, arkuszy programu Excel. Celem wszystkich tych dokumentów jest przedstawienie wymagań klienta w sposób wydajny i łatwy do zrozumienia. Dokument szkieletowy jest niczym innym jak dokumentem, który może być w formie prezentacji PowerPoint, która przedstawia wymagania klienta. Na tych samych liniach scenorysy zwykle przedstawiają wymagany wygląd / wygląd ekranów. Obecnie na rynku dostępne są różne narzędzia, których można użyć do przygotowania wymaganych dokumentów. Tworzenie wymaganych dokumentów jest podstawowym obowiązkiem Analityka Biznesowego. Oczekuje się, że smak dokładnie zrozumie wymagania. Aby zarówno teste, jak i programiści mogli poprawnie zrozumieć wymagania, analitycy biznesowi zapewniają forum otwarte dla wszystkich, którzy mogą zgłaszać zapytania i uzyskiwać odpowiedzi na pytania dotyczące dowolnych wymagań. Platforma do dyskusji i przekazywania otwartych pytań i zapytań różni się w zależności od projektu. Może to być ciąg wiadomości e-mail lub połączenie konferencyjne, a nawet utrzymywane repozytorium dysków, aby śledzić wszystkie otwarte pytania i odpowiedzi udzielone przez analityka biznesowego.
Przejrzysta komunikacja i zapis komunikacji odgrywają bardzo ważną rolę jako dowód. Małe założenie w wymaganiu może czasami prowadzić do poważnej wady produktu. Na każdym etapie zaleca się cechy testera oprogramowania, aby utrzymać czystość komunikacji. Tester oprogramowania Komunikacja w pracy może odbywać się z analitykami biznesowymi lub nawet w zespole. Przejrzysta komunikacja pomaga uniknąć założeń podczas planowania i realizacji. Jednocześnie zaleca się rejestrowanie komunikacji (najlepiej komunikacji e-mail). Posiadanie pisemnej komunikacji dotyczącej zapytań w wymaganiach pomaga na późniejszych etapach wykonywania testów, gdzie funkcjonalność mogła nie zostać opracowana, co potwierdzono w zarejestrowanej komunikacji.
2. Scenariusz
Po zrozumieniu wymagań tester rozpoczyna dokumentowanie scenariuszy w dokumencie Scenariusz testowy. Scenariusz, jak sugeruje nazwa, to przepływ funkcji, które użytkownik wykonuje w celu wykonania zadania.
Przykłady scenariuszy -
- Użytkownik powinien mieć możliwość zalogowania się pomyślnie.
- Użytkownik powinien mieć możliwość rezerwacji biletów w systemie.
- Użytkownik powinien mieć możliwość anulowania biletów w systemie.
- Użytkownik powinien mieć możliwość przeglądania / aktualizowania szczegółów profilu.
Są to logiczne zadania, które użytkownik wykonuje w systemie. Te logiczne zadania po zgrupowaniu pomagają proverowi zanotować wszystkie możliwe scenariusze, które powinien wykonać użytkownik. Te scenariusze są zwykle dokumentowane w arkuszach Excela lub czasami przy użyciu niektórych narzędzi. Prover rozwija się, wyciągając wszystkie takie scenariusze z dokumentów wymagań. Dokument zawierający takie scenariusze nazywa się Dokumentem scenariusza testowego (lub dokumentem scenariusza wysokiego poziomu). Ten dokument służy jako dokument wejściowy do opracowywania przypadków testowych.
3. Case
Ten przypadek jest bardziej szczegółową wersją scenariusza pracy Software Tester, w którym scenariusz jest podzielony na bardziej szczegółowe kroki, które użytkownik faktycznie wykona podczas korzystania z aplikacji. Prostym przykładem opartym na wyżej wymienionych scenariuszach jest:
Scenariusz - użytkownik powinien mieć możliwość zalogowania się pomyślnie.
Przypadki testowe:
- Sprawdź, czy użytkownik może wprowadzić poprawną nazwę użytkownika.
- Sprawdź, czy użytkownik może wprowadzić hasło.
- Sprawdź, czy kliknięcie przycisku Zaloguj się po wprowadzeniu prawidłowej nazwy użytkownika i hasła pozwala użytkownikowi zalogować się pomyślnie.
Taka lista takich przypadków może obejmować sprawdzenie poprawności w każdym polu, sprawdzanie negatywnych scenariuszy i tak dalej.
Poniżej znajdują się dodatkowe przykłady tych przypadków -
- Sprawdź, czy ta nazwa użytkownika nie została wprowadzona, system zgłasza odpowiedni błąd.
- Sprawdź, czy hasło, gdy nie zostało wprowadzone, system zgłasza odpowiedni błąd.
- Sprawdź, czy nazwa użytkownika i hasło nie zostały wprowadzone, system zgłasza odpowiedni błąd.
- Sprawdź, czy wpisując nieprawidłowe hasło, system wyświetla odpowiedni komunikat o błędzie.
- Sprawdź, czy po wprowadzeniu niepoprawnej nazwy użytkownika system wyświetla odpowiedni komunikat o błędzie.
4. Matryca śledzenia wymagań (RTM)
Macierz śledzenia wymagań, jak sugeruje nazwa, pomaga w sprawdzeniu i uwzględnieniu zakresu wymagań określonych przez firmę w dokumentach testowych, takich jak scenariusze i przypadki testowe.
Zgodnie z najlepszą praktyką jest to osobny dokument przedstawiający przyporządkowanie numeru wymagania do scenariuszy / przypadków zawierających ten wymóg.
Ten dokument może nie być używany przez wszystkie rodzaje projektów, ale gdy jest używany, pomaga w silny sposób prześledzić scenariusze wysokiego poziomu odwzorowane na wymagania. Wskazuje zasięg i może być użyty do sprawdzenia obecności co najmniej jednego z tych przypadków w odniesieniu do każdego wymagania. Tworzenie i utrzymywanie dokumentu RTM jest uważane za najlepszą praktykę, jednak nie wszystkie rodzaje projektów (jak Agile) używają oprogramowania potwierdzającego dokument roboczy. Gdy wymagania zmieniają się bardzo często, utrzymanie tego dokumentu może być podsłuchane. Aby uniknąć tego narzutu i jednocześnie mieć sposób na śledzenie wymagań, niektóre projekty zawierają część dotyczącą możliwości śledzenia w przypadku roboczym Software Tester lub w samym dokumencie ze scenariuszem.
Ważnym aspektem jest możliwość śledzenia scenariuszy / przypadków do wymagań i odwrotnie. Dobrze udokumentowane wymagania ułatwiają Proverowi tworzenie i zarządzanie tymi dokumentami. Niejednoznaczne wymagania, ciągle zmieniające się wymagania sprawiają, że życie provera jest trudniejsze i może prowadzić do niespójnych dokumentów, które mogą zostać dostarczone, co spowoduje utratę pewnej walidacji, a tym samym wadę produktu końcowego.
Dotychczasowa podróż testera planowała i przygotowywała się do testów. Ponieważ przygotowanie do wojny jest częścią wojny, to samo dotyczy tutaj. Im bardziej zwięzłe są te dokumenty, tym łatwiej jest zweryfikować funkcjonalność i wykryć prawie wszystkie usterki. Kolejnym etapem podróży testera jest wykonanie.
Wykonanie testera oprogramowania działa
Jest to faza, w której wszystkie wyżej wymienione dokumenty są wykorzystywane. Do stworzenia scenariusza wykorzystano wymagania, do stworzenia scenariusza użyto Przypadki. ten dokument sprawy jest tutaj samowystarczalny, aby rozpocząć walidację wniosku. Prover rozpoczyna sprawdzanie poprawności aplikacji, wykonując kroki z tego dokumentu sprawy. Wiele przypadków może być wykorzystanych do zatwierdzenia jednego scenariusza lub nawet jeden przypadek testowy może odpowiadać jednemu scenariuszowi testowemu. Wszystko zależy od złożoności scenariuszy lub czasami standardu stosowanego w zespole testowym. Dlatego pojedynczy dokument przypadku testowego może zawierać 20-50 przypadków testowych lub może zawierać 100-120 przypadków testowych. Liczby te służą wyłącznie celom wyjaśniającym, mogą się znacznie różnić w zależności od projektu. Wynikiem tej fazy są wady testowe. Liczba ważnych wad zgłoszonych na tym etapie daje dobre wyobrażenie o stabilności aplikacji, jakości testowania, jakości wykonania i wielu innych czynnikach, które bezpośrednio wpływają na produkt. Ta faza jest najważniejszą fazą, ponieważ tester rozwija się, aby objąć wszystkie przypadki testowe (sprawdzając poprawność prawie wszystkich wymaganych ścieżek użytkownika) i jednocześnie zgłosić jak najwięcej prawidłowych defektów. Wszystkie przygotowania, umiejętności komunikacyjne, zapytania zadawane firmie są dostępne na tym etapie testów.
Wady testera oprogramowania działa
Podczas wykonywania tego przypadku każde zachowanie, które nie jest równe oczekiwanemu wynikowi, jest zgłaszane jako Wada. Każdy przypadek testowy ma opis, oczekiwany wynik i kolumnę rzeczywistego wyniku. Podczas planowania dokument pracy Software Tester zawiera opis i oczekiwane wyniki oraz pustą kolumnę dla rzeczywistych wyników. Podczas wykonywania przypadków testowych tester powinien wypełnić kolumnę wyników rzeczywistych. Jednocześnie, jeśli rzeczywista wartość nie jest równa oczekiwanemu wynikowi, wada jest rejestrowana. Zapisanie usterki nie oznacza po prostu poinformowania programisty o problemie. Jest to ponownie formalny proces zwykle wykonywany za pomocą narzędzia. Obecnie na rynku dostępne są różne narzędzia, niektóre open source, a niektóre licencjonowane. Każde narzędzie do rejestrowania defektów ma następujące pola -
- Nazwa projektu / wydania
- Podsumowanie wady
- Szczegółowy opis wady
- Istotność defektu
- Priorytet wady
- Faza została znaleziona wada
- Przypisane do
- Załączniki
Jak widzimy, celem wszystkich tych pól jest formalne wyszukanie szczegółowych informacji na temat problemu. Pomaga to programistom odtworzyć defekt w swoim środowisku i naprawić go. Poniżej znajduje się krótki opis wszystkich tych pól -
- Nazwa projektu / wydania - nazwa wydania, w którym znaleziono defekt, zwykle projekt ma wiele wydań i ten sam projekt może mieć wiele podprojektów. To pole pomaga podnieść problem dotyczący konkretnego wydania.
- Podsumowanie defektu - Krótki opis jednej linijki znalezionej wady.
- Szczegółowy opis wady - jest to szczegółowy opis wady, powinien zawierać szczegółowe informacje, takie jak środowisko, w którym znaleziono wadę, i wykorzystane dane testowe, rzeczywiste wyniki oczekiwały wyniku oraz wszelkie dodatkowe informacje, które dodają cenniejsze informacje dla interesariuszy, aby zrozumieć wada.
- Istotność defektu - oznacza, jak poważna jest wada. Zwykle ma wartości podobne do Krytycznych, Wysokich, Średnich, Niskich lub wartości liczbowych, takich jak 4, 3, 2, 1.
- Priorytet defektu - oznacza, jak pilne jest usunięcie wady.
- Faza znaleziono defekt - Ponieważ istnieje wiele faz, w których można zarejestrować defekt, faza testowania jednostkowego, SIT (test integracji systemu), UAT (test akceptacji użytkownika), a nawet faza produkcyjna.
- Przypisany do - nazwa programisty lub potencjalnego klienta.
- Załączniki - dało to testerowi opcję dołączenia migawki ekranu, na którym wystąpił problem.
Wykonywanie testów i rejestrowanie defektów to faza, w której tester może napotkać wiele wyzwań. Niektóre z nich skutecznie komunikują się z programistami. Czy możemy argumentować, że rejestrowanie wady ze wszystkimi niezbędnymi informacjami jest niewystarczające, aby programiści mogli ją zrozumieć?
W niektórych przypadkach wymaga to dodatkowych wyjaśnień / dyskusji z twórcami. Są przypadki, w których tester napotyka nieoczekiwane zachowanie, którego może nie być pewien, czy jest to wada. W takich okolicznościach zwykle spotykają się nowi członkowie zespołu, posiadający ograniczoną wiedzę domenową lub niejasności co do wymagań. Cóż, testera nie należy obwiniać tutaj, jeśli są napięte terminy i ciągle zmieniają się wymagania, aw większości przypadków prover dowiaduje się o domenie podczas faktycznego planowania i wykonywania przypadków testowych. Jak widzimy, ścieżka testera nie jest tak łatwa, jak jest postrzegana. Wymaga to nieustannej postawy uczenia się, dobrych umiejętności komunikacyjnych, dobrych umiejętności współpracy i chęci dostosowania się w warunkach, w których zachodzą zmiany w domenach, narzędziach i procesach. Podczas gdy rozmawialiśmy o podróży ręcznych testerów, cały proces dotyczy również testerów automatyzacji. Z drugiej strony automatyzacja ma znaczące zmiany w procesie, ponieważ zakres testowania i planowania, wykonanie różni się znacznie.
Biorąc pod uwagę podróż provera, jak omówiono powyżej, czy nadal możemy powiedzieć, że praca testerów oprogramowania jest łatwiejsza niż praca programisty?
Można powiedzieć, że bardziej niż porównywanie ról programistów testujących v / s, bardziej użyteczna będzie dyskusja na temat tego, w jaki sposób współpraca dwóch może doprowadzić do znacznego sukcesu produktu jako całości. Czasami zapominamy, że zadaniem testera jest znajdowanie problemów w aplikacji, a nie wskazywanie błędów programistów. Kiedy zapominamy o samej idei naszej pracy, czasami prowadzi to do niepotrzebnej dyskusji. Jednak zaobserwowano, że istnieją równie dobre testy, zespoły programistów, w których wszyscy rozumieją, że ostatecznym celem jest sprawienie, aby aplikacja działała zgodnie z oczekiwaniami. Miejmy nadzieję, że wszyscy spojrzą na pozytywną stronę zadania testowego jako rolę, która pomaga w czyszczeniu produktu, a nie tę, która po prostu znajduje błędy!
Polecane artykuły
Jest to przewodnik do odkrywania i sprawdzania oczywistych i nie tak oczywistych ścieżek aplikacji, które zawsze są podstawowym oczekiwaniem od pracy testera oprogramowania. Są to następujące linki zewnętrzne związane z pracą testera oprogramowania.
- Cykl życia defektu w testowaniu oprogramowania
- 6 najbardziej niesamowitych pytań do wywiadu podczas testowania oprogramowania
- Kariery w testowaniu oprogramowania