Testowanie bez dokumentacji wymagań nie musi być horrorem

testowanie bez dokumentacji

Czym jest dokumentacja wymagań? Coś, o czym wszyscy słyszeli, ale rzadko widzieli. Zwłaszcza w małych, dynamicznych projektach. Dlaczego tak jest? Start-upy nie mają zazwyczaj zdefiniowanych jasno celów, konkretnej definicji tego, co robią. Koncepcja istnieje, ale narzędzia do osiągnięcia celu mogą się bardzo zmienić.

Testowanie bez dokumentacji – jak to zrobić?

W tym momencie pojawia się pytanie – czy możesz pomyślnie przetestować aplikację, jeśli nie masz dostępu dokumentacji wymagań? Odpowiedź brzmi: tak! Nie jest to łatwe, ale postaramy się wyjaśnić, jak to zrobić poprawnie, aby nie skończyć z oprogramowaniem, które jest częściowo zepsute. Słowem kluczowym jest tutaj standaryzacja i formalizacja. Testowanie bez dokumentacji nie oznacza ślepego klikania w aplikację. Wymaga to większego skupienia, wysiłku i po prostu jest pracochłonne, aby osiągnąć podobny rezultat, jak gdyby była obecna dokumentacja i specyfikacja. Poniżej znajdziesz instrukcję krok po kroku, jak może wyglądać testowanie bez dokumentacji.

0.1 Zbierz wymagania

Na wszelki wypadek… Zanim przejdziesz przez proces testowania bez dokumentacji, upewnij się, że naprawdę nie ma sposobu, aby uzyskać prostą dokumentację. Jeśli nie, postępuj zgodnie z moimi radami.

1. Wywiad

Pierwszy i kluczowy etap testowania bez dokumentacji to wywiad. Skup się na zrozumieniu aplikacji tak bardzo, jak to tylko możliwe. Jak to zrobić? Zbierz wszystkie możliwe informacje. Nie mam na myśli tylko plików. Utwórz listę wszystkich zaangażowanych osób. Zapytaj właściciela produktu, kierownika projektu, programistów, inne osoby, które były częścią projektu. Spróbuj skontaktować się z użytkownikami końcowymi, jeśli są dostępni. Pamiętaj, aby pukać do wszystkich drzwi.

2. Oceń cele aplikacji

Zapisz wszystkie cele biznesowe, które znasz lub zakładasz. Sprawdź, czy możesz wymyślić jakieś dodatkowe cele, jakie aplikacja musi osiągnąć? Utwórz przegląd tego, czym jest produkt. Pomoże ci to w ocenie ryzyka i skupieniu się tylko na niezbędnych działaniach.

3. Funkcje hamowania

Przejdź przez aplikację. Rozejrzyj się. Sprawdź, czego nauczyłeś się w kroku 1. Lista kontrolna jest zawsze dobrym pomysłem. Tym razem z funkcjonalnościami systemu. Nie musisz robić tego dobrze za pierwszym razem. Osobiście lubię rysować funkcje. Pamiętaj, że to nic formalnego. Wystarczy, że pomoże Ci zbadać różne funkcje, które należy omówić, oraz ich związek z celami biznesowymi i ze sobą nawzajem. Oto przykład, jak to robię.

4. Przeanalizuj konkurencję

W przypadku testowania bez dokumentacji najlepszym sposobem na poznanie wymagań, jakie może mieć użytkownik końcowy, jest zbadanie podobnych rozwiązań. Przeglądaj sieć za pomocą kluczowych fraz. Znajdź firmy związane z tą, którą będziesz testować. W ten sposób dowiesz się, czego może oczekiwać użytkownik.

5. Przeanalizuj ryzyko

Czy wiesz, dlaczego musisz przeanalizować ryzyko? Częścią pracy testera jest minimalizacja ryzyka w celu utrzymania wysokiej jakości oprogramowania. To również mówi ci, na czym należy się skupić. Jak analizować ryzyko i znaczenie? Utwórz macierz ryzyka. Najpierw zdecyduj, które części oprogramowania są najważniejsze dla osiągnięcia zakresu, a które nie. Oznacz je od 1 (nieważne) do 5 (najważniejsze). Zapisz wszystkie ryzyka, które mogą wystąpić. Zapisz potencjalne ryzyko dla każdej funkcji i zaznacz prawdopodobieństwo 1-5 i wpływ 1-5. Jeśli ją pomnożysz, poniesiesz ryzyko.

Należy pamiętać, że nawet funkcje niskiego ryzyka w bardzo ważnej części oprogramowania należy najpierw przetestować! Zobacz wcześniej poniższy rysunek, aby sprawdzić dwa różne podejścia – tabelę i wykres.

6. Plan

Pamiętaj, że masz ograniczoną liczbę godzin i nie masz formalnego odniesienia. Dlatego musisz zaplanować swoje działania. Nie trać czasu na ślepe klikanie aplikacji i próbowanie zapamiętania wszystkiego, co masz zrobić. Twoim celem powinno być objęcie przynajmniej pozycji wysokiego ryzyka. Pomyśl o testach aplikacji do wykonania. Zapisz je wcześniej.

7. Przygotuj środowisko

Nie ma czasu do stracenia. Nie ma czasu na rozpoczęcie testów aplikacji i wstrzymanie ich z powodu pewnych problemów z dostępem i kontem. Przygotuj jak najwięcej danych testowych na zaplanowane testy. Nie jesteś w tym sam. Jestem pewien, że programiści pomogą Ci dokonać pewnych wpisów w bazie danych. Przed rozpoczęciem testów upewnij się, że masz przygotowane wszystkie dane testowe i wszystkie poświadczenia. Przygotuj się w taki sposób, aby po rozpoczęciu testować. Bez zbędnych postojów.

8. Sformalizuj testowanie aplikacji

Potrzebujesz czegoś, na czym możesz polegać, gdy ludzie pytają cię „gdzie jesteśmy?”. Coś do zbierania metryk, oznaczania postępów, oceny stanu aplikacji. W takiej sytuacji możesz polegać na mniej sformalizowanych dokumentach, takich jak karta testu. Jest to lista kontrolna dotycząca sterydu, która gromadzi wszystkie elementy, o których wspomnieliśmy powyżej, i pozwala łatwo sprawdzić, co zostało zrobione, co zostało pominięte, a co pozostało do zrobienia. Zobacz przykład takiego raportu poniżej.

9. Wykonaj

Zrobiłeś dobry plan. Teraz nadszedł czas, aby to wykonać. Pilnuj czasu. Postępuj zgodnie z harmonogramem. Użyj karty testu jako listy kontrolnej. Upewnij się, że utrzymujesz cel testowania aplikacji. Jeśli wydarzy się coś nieoczekiwanego, nie trzymaj się ślepo planu. Po prostu go dostosuj i kontynuuj.

10. Zakończ testowanie bez dokumentacji

Kiedy zakończyć testowanie bez dokumentacji na przykładzie aplikacji? Gdy kryteria wyjścia są spełnione. Istnieje wiele powodów, takich jak:

  • Przetestowanie wszystkich scenariuszy
  • Zbliżający się deadline
  • Duże zmiany w testowanych modułach

Po zakończeniu testowania aplikacji należy utworzyć kilka elementów dostarczanych. Na szczęście karta testowa zawiera prawie wszystko. Podczas testów aplikacji stworzyłeś raporty błędów za pomocą narzędzia do zarządzania projektami. Wszystkie metryki znajdują się w karcie testów. Wraz z nim archiwizowane są również dane testowe. Ważne jest, aby po prostu nie przekazywać danych. Najpierw je przeanalizuj! Sprawdź, czy możesz znaleźć miejsca, w których nagromadziły się błędy (możesz założyć, że 20% błędów generuje 80% błędów, a 1% błędnego kodu odpowiada za 50% błędów). Te informacje mogą być pomocne dla zespołu deweloperów. Podziel się wynikami z tymi, którzy powinni być poinformowani.

Zawsze najlepiej jest pracować z pełną dokumentacją i wymaganiami. Ale wszyscy wiemy, że nie zawsze tak jest. W rzeczywistości znajdziesz tylko fragmenty potrzebnych informacji. Dlatego wykwalifikowany tester musi być elastyczny i biegle dostosowywać się do takich sytuacji. Musimy być surowi i formalni, jeśli chodzi o wejście w chaos testowania aplikacji. Nie daj się ponieść emocjom. Opracuj swój plan. Podążaj za tym. Testuj.


Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *