Na co zwrócić uwagę podczas testowania: 1. Testujemy w oparciu o kryteria akceptacji. Powinny one opisywać ścieżki pozytywne oraz negatywne. Zwracamy uwagę na wartości brzegowe oraz klasy równoważne. Jeśli kryteria akceptacji są spełnione to: 2. Wykonujemy testy regresji. Sprawdzamy, czy wprowadzona funkcjonalność/fix nie popsuła czegoś „na około” lub w obszarach powiązanych z tą funkcjonalnością. Jeśli jest ok, to: 3. Wykonujemy tzw „atak usterkowy”. Jeśli nasze doświadczenie z innymi aplikacjami podpowiada nam, że tego typu funkcjonalność podatna jest na jakiś konkretny błąd to warto to sprawdzić. Jeśl jest ok lub jeśli nie mamy takiej wiedzy to możemy się pokusić o: 4. Testy eksploracyjne. Czyli np. sprawdzamy cały przypadek użycia, który zawiara daną funkcjonalność. Pkt 4 i 5: wykonujemy, gdy mamy na to czas, jednak zachęcam by go na to znaleźć. Pamiętajmy, że zazwyczaj testujemy z perspektywy użytkownika końcowego, którego nie obchodzi kod tylko to jak działa aplikacja  Dodatkowo zawsze warto mieć odpaloną consolę, żeby wyłapać błędy, których nie widać w GUI. Jeśli podczas testowania natrafimy na tzw egde case (bardzo małe prawdopodobieństwo wystąpienia) to decyzja co z tym zrobić powinna należeć do interesariuszy (klienta). Jeśli testujemy ponownie (po znalezieniu błędu w danej funkcojnalności i jego naprawieniu) to mówimy wtedy o re-teście i zazwyczaj trzymamy się wtedy powyższego planu, chyba, że błąd był trywialny, np. literówka itp.

Na co zwrócić uwagę podczas testowania: 1. Testujemy w oparciu o kryteria akceptacji. Powinny one opisywać ścieżki pozytywne oraz negatywne. Zwracamy uwagę na wartości brzegowe oraz klasy równoważne. Jeśli kryteria akceptacji są spełnione to: 2. Wykonujemy testy regresji. Sprawdzamy, czy wprowadzona funkcjonalność/fix nie popsuła czegoś „na około” lub w obszarach powiązanych z tą funkcjonalnością. Jeśli jest ok, to: 3. Wykonujemy tzw „atak usterkowy”. Jeśli nasze doświadczenie z innymi aplikacjami podpowiada nam, że tego typu funkcjonalność podatna jest na jakiś konkretny błąd to warto to sprawdzić. Jeśl jest ok lub jeśli nie mamy takiej wiedzy to możemy się pokusić o: 4. Testy eksploracyjne. Czyli np. sprawdzamy cały przypadek użycia, który zawiara daną funkcjonalność. Pkt 4 i 5: wykonujemy, gdy mamy na to czas, jednak zachęcam by go na to znaleźć. Pamiętajmy, że zazwyczaj testujemy z perspektywy użytkownika końcowego, którego nie obchodzi kod tylko to jak działa aplikacja  Dodatkowo zawsze warto mieć odpaloną consolę, żeby wyłapać błędy, których nie widać w GUI. Jeśli podczas testowania natrafimy na tzw egde case (bardzo małe prawdopodobieństwo wystąpienia) to decyzja co z tym zrobić powinna należeć do interesariuszy (klienta). Jeśli testujemy ponownie (po znalezieniu błędu w danej funkcojnalności i jego naprawieniu) to mówimy wtedy o re-teście i zazwyczaj trzymamy się wtedy powyższego planu, chyba, że błąd był trywialny, np. literówka itp.

Na co zwrócić uwagę podczas testowania: 1. Testujemy w oparciu o kryteria akceptacji. Powinny one opisywać ścieżki pozytywne oraz negatywne. Zwracamy uwagę na wartości brzegowe oraz klasy równoważne. Jeśli kryteria akceptacji są spełnione to: 2. Wykonujemy testy regresji. Sprawdzamy, czy wprowadzona funkcjonalność/fix nie popsuła czegoś „na około” lub w obszarach powiązanych z tą funkcjonalnością. Jeśli jest ok, to: 3. Wykonujemy tzw „atak usterkowy”. Jeśli nasze doświadczenie z innymi aplikacjami podpowiada nam, że tego typu funkcjonalność podatna jest na jakiś konkretny błąd to warto to sprawdzić. Jeśl jest ok lub jeśli nie mamy takiej wiedzy to możemy się pokusić o: 4. Testy eksploracyjne. Czyli np. sprawdzamy cały przypadek użycia, który zawiara daną funkcjonalność. Pkt 4 i 5: wykonujemy, gdy mamy na to czas, jednak zachęcam by go na to znaleźć. Pamiętajmy, że zazwyczaj testujemy z perspektywy użytkownika końcowego, którego nie obchodzi kod tylko to jak działa aplikacja  Dodatkowo zawsze warto mieć odpaloną consolę, żeby wyłapać błędy, których nie widać w GUI. Jeśli podczas testowania natrafimy na tzw egde case (bardzo małe prawdopodobieństwo wystąpienia) to decyzja co z tym zrobić powinna należeć do interesariuszy (klienta). Jeśli testujemy ponownie (po znalezieniu błędu w danej funkcojnalności i jego naprawieniu) to mówimy wtedy o re-teście i zazwyczaj trzymamy się wtedy powyższego planu, chyba, że błąd był trywialny, np. literówka itp.