testowanie.net

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 »

Technika czarnej skrzynki, białej skrzynki

Testy przeprowadzane metodami czarnej skrzynki (black box) i białej skrzynki (white box) określają perspektywę z której tester wykonuje swoją pracę. Black box jest spojrzeniem od zewnątrz na testowany obiekt natomiast White box “zagląda do środka” testowanej aplikacji.

Testowanie oprogramowania częściowo opiera się na intuicji jednak w przeważającej mierze jest to systematyczna praca za którą stoi wiedza na temat technik przeprowadzania testów i znajomość narzędzi.

Definicja: Testowanie jest procesem uruchamiania oprogramowania w kontrolowany sposób w celu stwierdzenia czy oprogramowanie zachwuje się w oczekiwany sposób.

Testowanie oprogramowania łączy się z jego weryfikacją i walidacją.
Weryfikacja oznacza sprawdzanie elementów systemu pod kątem ich zgodności z dołączoną specyfikacją.
Walidacja jest procesem pozwalającym określić czy to co znajduje się w specyfikacji jest tym czego oczekiwał klient.

Techniki testowania metodą Black Box:
- Functional Testing
- Stress Testing
- Load Testing
- Ad-hoc Testing
- Exploratory Testing
- Usability Testing
- Performance Testing
- Smoke Testing
- Recovery Testing
- Volume Testing
- Domain Testing
- Scenario testing
- Regression Testing
- User Acceptance
- Alpha Testing
- Beta Testing

Techniki testowania metodą White Box:
- Unit Testing
- Static & dynamic Analysis
- Statement Coverage
- Branch Coverage
- Security Testing
- Mutation Testing

Zalety testowania metodą czarnej skrzynki:
- testy są powtarzalne
- testowane jest środowisko w którym przeprowadzane są testy
- zainwestowany wysiłek może być użyty wielokrotnie

Wady testowania metodą czarnej skrzynki:
- Wyniki testów mogą szacowane nazbyt optymistycznie
- Nie wszystkie właściwości systemu mogą zostać przetestowane
- Przyczyna błędu nie jest znana

Zalety testowania metodą białej skrzynki:
- ponieważ wymagana jest znajomość struktury kodu, łatwo jest określić jaki typ danych wejściowych/wyjściowych jest potrzebny, aby efektywnie przetestować aplikację
- oprócz głównego zastosowania - testów, pomaga zoptymalizować kod aplikacji
- pozwala dokładnie określić przyczynę i miejsce w którym znajduje się błąd

Wady testowania metodą białej skrzynki:
- ponieważ wymagana jest znajomość struktury kodu, do przeprowadzenia testów potrzebny jest tester ze znajomością programowania co podnosi koszty.
- jest prawie niemożliwym przeglądniecie każdej linii kodu w poszukiwaniu ukrytych błędów co może powodować błędy po fazie testów.

Tags: biała skrzynka, black box, czarna skrzynka, techniki testowania, white box

Posted in Testowanie | 1 Comment »