Menu

Jak przetestować aplikację bez wymagań?

how test an application without requirements

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Z technicznego punktu widzenia nie ma aplikacji bez wymagań. Wyobraź sobie oprogramowanie, które nie robi nic konkretnego, ale po prostu ciągnie się wiersz po wierszu kodu. Będą to schody prowadzące donikąd.

Każde oprogramowanie ma wymagania i jest przeznaczone do określonego zadania; w szczególności jest to rozwiązanie problemu. Więc bez wymagań oprogramowanie nie jest możliwe.

Jednak oprogramowanie bez udokumentowanych wymagań to rzeczywistość, z którą niestety większość z nas ma do czynienia częściej lubimy. Gorsze może być tylko to, że dokumentacja jest niewystarczająca, niedokładna lub strasznie nieaktualna. Niestety tak się też dzieje.

test bez wymagań

Szczerze mówiąc, naprawdę nic nie zastąpi dobrze udokumentowanego dokumentu wymagań funkcjonalnych / systemowych z rozbudowanymi przypadkami użycia i makietami ekranów. Chociaż musimy przyznać, że staje się to rzadkością w branży ze względu na szybkie cykle rozwojowe i zmianę paradygmatu w kierunku minimum lub braku dokumentacji.

Dlatego ten artykuł jest próbą niektórych praktyk, których przestrzegaliśmy, gdy znaleźliśmy się w takich sytuacjach.

Przeczytaj także:

sql egzamin pytania i odpowiedzi pdf

Przyjrzyjmy się najpierw kilku powody, dla których może nie być dokumentacji, na początek:

  1. Ponownie otwierany projekt półkowy
  2. Dokumentacja bez formatu pracy - proces
  3. Dokumentacja może istnieć, ale może nie być szczegółowa lub kompletna
  4. Wersje ciągłe i informacje związane ze starszymi wersjami nie zostały zarchiwizowane, co skutkuje luką w zrozumieniu, jak istniejąca funkcjonalność reaguje na nową

To wszystko są przeszkody, które my, testerzy, musimy odważnie pokonać i wyjść pomyślnie. Ale jak dokładnie, prawda?

Oto 3 najlepsze metody testowania aplikacji bez wymagań:

Metoda nr 1:

Pracuj z każdą małą dokumentacją, którą możesz zdobyć. Może to być podstawowy prosty backlog (w projektach zwinnych), plik pomocy, e-mail, starsza wersja BRD / FRD lub stare przypadki testowe (sprawdź je w swoich narzędziach ALM, a być może je znajdziesz) itp.

Zbadaj, popytaj i zawsze istnieje udokumentowana próba, nawet jeśli jest cienka.

Jeśli to nie zadziała, nie pomniejszaj swojego doświadczenia jako użytkownika oprogramowania.Na przykładjeśli musisz przetestować operację przelewu na konto bankowe, nikt nie musi nam mówić, jak to zrobić, prawda? Ponieważ jako klienci bankowości internetowej wszyscy wiemy, że potrzebujemy zi na rachunki, na które można przelać pewną liczbę środków.

Zgodzili się, że nie wszystkie sytuacje będą tak proste, ale znowu mogą być.

Metoda nr 2:

Użyj starszej / aktualnej wersji aplikacji jako odniesienia do przetestowania przyszłej wersji oprogramowania. Teraz przyznaję, że jest to zaprzeczeniem reguły „Nigdy nie pisz przypadków testowych, używając aplikacji jako odniesienia”. Jednak gdy pracujemy w niezbyt idealnej sytuacji, musimy dostosować zasady do naszych potrzeb.

Pomaga przy tym zachować perspektywę następujących aspektów:

  • Aplikacja może zawierać błędy - więc jeśli po rejestracji system przeniesie Cię bezpośrednio do Screen1 (pewien hipotetyczny ekran na potrzeby naszego przykładu) - Nigdy nie zakładaj, że jest to prawidłowe zachowanie. Również jeśli pole przyjmuje znaki alfanumeryczne i jest numerem telefonu - pytanie to i upewnij się, że nie bierzesz aplikacji jako przykładu dla oczekiwanej funkcjonalności.
  • W powyższych sytuacjach kieruj się własną oceną i skorzystaj z pomocy aplikacji, aby od razu rozpocząć pracę, ale bądź krytyczny wobec niej, aby kwestionować jej działanie.

Metoda nr 3:

Porozmawiaj z członkami zespołu projektowego:

  • Zaproponuj uczestnictwo w spotkaniach.
  • Zapytaj, czy możesz uczestniczyć w etapach testów jednostkowych i integracyjnych.
  • Jeśli nie, zapytaj, czy zespół programistów może udostępnić wyniki testów jednostkowych i testów integracji.
  • Umów się na transfer wiedzy w dogodnym czasie.

Teraz zastosujmy metody z przykładu:

Załóżmy, że istnieje witryna sklepowa, w której można dodawać produkty do koszyka. Najlepiej, gdyby była dokumentacja, która musi nam powiedzieć, jak dodać do niej pozycje, ile może mieć pozycji w danym momencie, co się stanie, gdy dodany przez Ciebie artykuł nagle się skończy, jaka jest maksymalna liczba tych samych przedmiotów, które możesz kupić w tym samym czasie itp. Nasza sytuacja jest taka, że ​​ŻADEN z tego nie jest obecnie dostępny.

Zastosuj metodę nr 1:

Znajdź jakąkolwiek dokumentację, jaką możesz. Zapytaj swojego zespołu programistów, czy mają makiety / wygląd w narzędziu ALM lub cokolwiek w ogóle. Jeśli coś znajdziesz, będzie to dobry punkt wyjścia. Ale jeśli ta metoda nic nie da, możesz użyć swojego osąd / intuicja testera.

Wszyscy wiemy, jak działają wózki sklepowe, więc przyjmij swoje założenia i opracuj kilka podstawowych scenariuszy, takich jak:

  • Przedmioty można dodawać do koszyka po ich przeglądaniu lub wyszukiwaniu
  • Po dodaniu pozycji do koszyka lista pozycji powinna się odświeżyć
  • Użytkownik powinien mieć możliwość kontynuowania zakupów nawet po dodaniu kilku pozycji do koszyka
  • Dwukrotne dodanie tej samej pozycji spowoduje zwiększenie liczby dodanych pozycji
  • Pozycje można aktualizować
  • Pozycje można usunąć
  • Suma powinna odpowiadać sumie wszystkich dodanych cen
  • Podatki należy obliczać na podstawie wprowadzonego kodu pocztowego
  • Należy odpowiednio doliczyć koszty wysyłki

Możemy kontynuować, ale jestem pewien, że masz obraz.

Zastosuj metodę nr 2:

Jeśli dostępna jest starsza wersja aplikacji, może to być pomocne w pisaniu przypadków testowych, ponieważ będziesz musiał napisać dokładne kroki, gdzie kliknąć, gdzie wprowadzić dane wejściowe, co sprawdzić itp. Zrzuty ekranu / makiety / przewody- ramki - jeśli są dostępne, mogą być również świetnymi zamiennikami.

Jak widać na poniższym ekranie, te rzeczy są oczywiste - nazwy pól, przyciski lub inne obecne elementy itp. (kliknij na zdjęcie, aby powiększyć)

test bez wymagań

W tym momencie testerzy mają kilka pytań, takich jak:

  1. Co się stanie, gdy podam znak w polu kwoty?
  2. Kiedy dodać zbyt wiele pozycji?
  3. Jaka jest maksymalna liczba przedmiotów, które to może zająć? Itp.

Zastosuj metodę nr 3 :

Zanieś listę pytań do licencjata, programisty lub nawet klienta i poproś o wyjaśnienia. Po wykonaniu metody 3 powinieneś być wyposażony we wszystkie informacje potrzebne do napisania szczegółowych przypadków testowych i przeprowadzenia testów z taką pewnością, jak gdyby była dostępna obszerna dokumentacja.

Zgodziliśmy się, że jest o wiele więcej kroków i dużo więcej działań następczych, ale aby zapewnić testowanie jakości, te kroki są nieuniknione.

Podsumowując, nie wszystko jest stracone, gdy dokumentacja nie istnieje lub jest niewystarczająca. Wciąż jest nadzieja! Podziel się swoimi doświadczeniami w podobnych sytuacjach.

O autorze: Ten pomocny post został napisany przez członka naszego zespołu STH Swati S.

Jak zawsze Twoje uwagi, pytania i sugestie są mile widziane.

rekomendowane lektury

^