testowanie.net

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.

Kiedy odkrywasz defekt, informujesz o nim programistę. Raport błędu jest nośnikiem tej informacji. Głównym celem tworzenia raportu jest umożliwienie programiście zobaczenie i zrozumienie problemu.

W skrócie: raport błędu jest dokumentem, który opisuje różnicę pomiędzy oczekiwanym rezultatem i aktualnym stanem np. funkcji systemu. Dostarcza też informacji jak wywołać błąd ponownie.

Po znalezieniu defektu.
- Zapisz tę informację od razu jak tylko upewnisz się, że to błąd. Nie czekaj do końca dnia.

- Poświęć czas na diagnozę błędu, który zgłaszasz. Pomyśl o możliwych przyczynach. Może okazać się, że odkryjesz więcej problemów w tym samym miejscu systemu. Nadmień o swoich przypuszczeniach przy opisywaniu błędu. Programiści będą ci wdzięczni, że zrobiłeś tę część pracy.

- Nie wysyłaj raportu od razu. Daj sobie czas na ponowne przeczytanie go i ewentualne dodanie/poprawienie części opisu.

- Nie wyolbrzymiaj znaczenia błędu w opisie.

- Jakikolwiek znalazłeś błąd pamiętaj, że opis dotyczy zaistniałej sytuacji nie zaś osoby, która kodowała daną funkcjonalność.

Tags: błędy, raporty, zgłaszanie błędów

Posted in Testowanie | No Comments »

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 jest zgłoszenie problemu. Niektórzy z nas mogą iść o krok dalej wskazując błąd ORAZ programistę aby skłonić go do lepszej pracy. To nie pomaga. Spekulowanie - kto, w jakim miejscu i kiedy, zrobił błąd, jest złe z dwóch powodów:
- szukanie winnych nie pozwala skupić się na pracy
- to źródło konfliktów w grupie

Tags: Komunikacja w zespole, programista, tester

Posted in Komunikacja w zespole | 1 Comment »

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 spoglądając na tworzoną aplikację z różnej perspektywy. Typowym błędem jest postrzeganie testerów jako “młodszych programistów”, a co za tym idzie zachęcanie ich do rozwijania umiejętności i nastawienia typowego dla programistów.

W rzeczywistości dobry tester posiada cechy kontrastujące z tymi, których potrzebuje dobry programista. Rozumiejąc to, menedżer może połączyć owe cechy w jeden, dobrze funkcjonujący zespół.

Wielu programistów nie zdaje sobie sprawy jak trudnym zadaniem jest testowanie. Cierpliwość, elastyczność, umiejętność dostrzegania szczegółów i obraz całego mechanizmu działania systemu.
Wielu testerów jest sfrustrowanych, pracując z programistami, którzy uważają testowanie za oraz pracę “drugiej kategorii” lub coś co robić może każdy.

Testerzy potrzebują tego rodzaju wiedzy, który posiadają końcowi użytkownicy systemu. To pozwala im na używanie produktu w sposób w jaki robi to klient zamiast tak jak chciałby tego programista. Dobre pytanie - czy znajomość wewnętrznej architektury aplikacji pomaga czy przeszkadza w przeprowadzeniu testów? Moim zdaniem nie jest konieczna do wykonania testów.

Testerzy powinni przejawiać specyficzny rodzaj ignorancji czy co więcej -naiwności w odniesieniu do testowanego systemu. Programiści nie. Jest to jedną z przyczyn dla której programiści mogą uznać testera za osobę zadającą oczywiste czy wręcz głupie pytania
Dobrzy testerzy posiadają wiedzę zarówno na temat wymagań klienta jak i - do pewnego stopnia - działania systemu wewnątrz. Pozwala to spojrzeć na testowany system z innej niż programista strony.

Cechy dobrego testera:
- nie obawia się reakcji na złe wiadomości, które przynosi
- potrafi rozdzielić błąd od osoby, która go popełniła
- informację o znalezionym błędzie potrafi przedstawić w neutralny sposób

Tags: cechy testera, programista, tester, współpraca

Posted in Komunikacja w zespole | No Comments »

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 i wykonywanie testów. Oznacza to, że testerzy przystępują do pracy bez przygotowanych wcześniej przypadków użycia (test cases), ale za to z wyznaczonym celem. Testy oprogramowania tą metodą pozwalają na odkrycie nowych, zależności pomiędzy np. modułami systemu. To z kolei może wpłynąć na przyjętą strategię testowania i akcje podejmowane w kolejnych iteracjach testów.

Jednym z najlepszych powodów do stosowania tego rodzaju testów jest “odkrywanie”. Czytanie wymagań czy specyfikacji (jeśli istnieje) nie daje kompletnego obrazu działania systemu. Również dokumentacja użytkownika (pliki help, tutoriale) nie oddaje całkowicie tego w jaki sposób system działa i jak zachowuje się w określonych sytuacjach.

Testy metodą ad-hoc pozwalają na znalezienie “dziur” w strategii testowania i ujawnienie np. brakujących przypadków testowych (Test Cases).

Błędy znalezione przy testowaniu metodą ad-hoc są często sygnałem o istnieniu całych klas nieopracowanych przypadków testowych. To z kolei sugeruje dokonanie analizy przyczyn powstania błędu w testowanej części aplikacji.

Drugim zastosowaniem techniki ad-hoc jest określanie priorytetów dla poszczególnych przypadków testowych. Funkcjonalności, które działają poprawnie podczas testów ad-hoc, mogą otrzymać niższy priorytet lub zostać odłożone podczas fazy formalnych testów.

Jednym z problemów związanych z testami eksploracyjnymi są metryki, a właściwie ich brak. Zazwyczaj projekt jest zainteresowany informacją na temat postępu testów (procentowym pokryciem testami funkcjonalności, ilością wykonanych przypadków testowych, których przecież nie ma, itp.) wyrażoną choćby w postaci cyfr. Rozwiązaniem mogą być np. organizowane okresowo sesje na których zespół testowy wraz z osobami zainteresowanymi takimi informacjami, przedstawia i dyskutuje bieżącą sytuację. Taka forma pomiaru sprawdza się w projektach prowadzonych wg metodologii Agile.

Tags: testowanie ad-hoc, testy eksploracyjne, typy testów

Posted in Testowanie | No Comments »

Testy funkcjonalne

W tym rodzaju testów oprogramowanie jest sprawdzane pod kątem wymagań funkcjonalnych. Przypadki testowe pisane są pod kątem sprawdzenia czy aplikacja zachwuje się w oczekiwany sposób. Pomimo, ze testy funkcjonalne wykonywane są często pod koniec cyklu wytarzania oprogramowania, mogą - i powinny być uruchamiane znacznie wcześniej. Poszczególne komponenty i procesy mogą być sprawdzane przed uruchomieniem takich testów dla całego systemu.

Testy funkcjonalne odpowiadają na pytanie jak system wykonuje funkcje, które ma za zadanie udostępniać włączając w to komendy użytkownika, operacje na danych, wyszukiwanie, procesy biznesowe i ekrany użytkownika.

Testy funkcjonalne pokrywają zarówno funkcje dostępne dla użytkownika poprzez interfejs aplikacji jak i operacje typu back-end (np. jak bezpieczeństwo czy jaki wpływ na działanie systemu aktualizacja środowiska)

Tags: Testowanie, testy funkcjonalne, typy testów

Posted in Testowanie | No Comments »