10 prostych sposobów, aby programiści znienawidzili cię

Jeśli pracujesz jako tester, możesz wiedzieć coś na temat relacji tester vs. programista. Musimy współpracować, aby projekt szedł naprzód. Oto dziesięć sposobów, aby zniszczyć tę kruchą równowagę. Zgłaszaj błędy opisane jak najbardziej ogólnie Tytuł: „System nie działa” Opis: „System po pewnym czasie przestaje działać na moim komputerze Priorytet: krytyczny Programiści często czują się źle, kiedy w ich […]

Continue reading →

Cechy testera i programisty

Proces wytwarzania oprogramowania wymaga zaangażowania całej grupy projektowej. Skupię się jednak na dwóch rolach: testera i programisty. Ten sam projekt – zupełnie różne punkty spojrzenia. Inaczej mówiąc: dwie grupy pomiędzy którymi problemy w komunikacji stanowią źródło zagrożeń dla jakości systemu. W dobrze dobranym zespole projektowym testerzy i programiści uzupełniają się nawzajem, dostarczając umiejętności, wiedzę i […]

Continue reading →

Komunikacja, tester i programista

Testerzy nie powinni unikać konfrontacji. Przynoszenie “złych” wiadomości to ich praca, jednak nie zawsze jest to dobrze przyjmowane. Czasami trudno jest określić przyczynę błędu. Czy jest to błąd w wymaganiach, kodzie czy w dokumentacji. Zdarza się, że błędu nie ma, jednak tester nie jest pewien jak interpretować działanie aplikacji. Niezależnie od przyczyny – zadaniem testera […]

Continue reading →

Bug priority vs. bug severity

Zgłaszając błąd aplikacji, oprócz jego opisu, wersji środowiska, zrzutu ekranu czy załączników, określamy również jego priorytet i wpływ na działanie aplikacji. Defect severity – określa jak bardzo krytyczny dla aplikacji jest zgłaszany błąd. Defect priority – oznacza jak pilne jest poprawienie błędu. Opis na przykładzie: 1. High Severity and Low Priority : Testujemy aplikację bankową generującą raporty tygodniowy, miesięczny […]

Continue reading →

Testy ad-hoc, eksploracyjne

Ten typ testów przeprowadzany jest bez tworzenia formalnego Test Planu czy pisania przypadków testowych. Testy typu ad-hoc pomagają planować zakres i czas trwania innych rodzajów testów, pomagają także testerom nauczyć się aplikacji przed rozpoczęciem zaplanowanych, innych rodzajów testów. Jest to najmniej formalna metoda testowania. Testy ad-hoc (eksploracyjne) oznaczają jednoczesne poznawanie testowanej aplikacji, przygotowywanie dokumentacji testowej […]

Continue reading →

Jak efektywnie zgłaszać błędy

Jak często widzisz programistów, którzy żądają więcej informacji na temat opisanego przez ciebie błędu? Jak często słyszysz, że błędu nie da się powtórzyć i spędzasz czas nad zgłoszonym już i opisanym bugiem? Kończy się na tym, że więcej czasu poświęcamy na tego rodzaju przypadki niż na samo testowanie. Problem leży w jakości raportów o błędach. […]

Continue reading →

Testy regresywne

Celem przeprowadzania testów regresywnych jest upewnienie się, że aplikacja działa po dokonaniu w niej modyfikacji, poprawieniu błędów lub po dodaniu nowej funkcjonalności. Cecha: powtarzalność Co dają testy regresywne: Wyszukanie błędów powstałych w wyniku zmian kodu/środowiska. Ujawnienie wcześniej nie odkrytych błędów. Jest to dobry kandydat do automatyzacji ze względu na swoją powtarzalność. Iteracyjne metodologie oraz krótkie […]

Continue reading →

Kiedy należy przestać testować

Testować potencjalnie można bez końca. Nie możemy jednak kontynuować testów do momentu znalezienia ostatniego błędu w systemie. To oczywiście niemożliwe. W pewnym momencie należy przerwać i dostarczyć system do klienta. Pytanie brzmi, kiedy uznać, że oprogramowanie jest wystarczająco dobrze sprawdzone. Testowanie mieści się pomiędzy budżetem projektu, czasem na jego realizację i jakością dostarczanego rozwiązania. Project Triangle […]

Continue reading →

Bumper Stickers for Software Testers

Zbiór sentencji i cytatów na temat roli i pracy testera. Ask me about my latest bug. Honk if you love to crash software. My other car is a bug. Have you hugged your software tester today? Software Testers: Always looking for trouble. Software Testing is Like Fishing, But You Get Paid. Software Testers: “Depraved minds…Usefully […]

Continue reading →

Pięć problemów występujących w SDLC

Problem: niewystarczająco zdefiniowane wymagania – jeśli wymagania są niejasne, niekompletne, zbyt ogólne lub nietestowalne, na pewno pojawią się problemy nierealistyczny time plan projektu – zbyt wiele pracy zaplanowanej w zbyt krótkich przedziałach czasu niewystarczająca ilość testów – nikt nie wie jakiej jakości jest system, dopóki klient nie zacznie zgłaszać problemów. zmiany po zatwierdzeniu specyfikacji – […]

Continue reading →