Kilka prawd na temat testów:
- Około 40-50% nakładu prac w oprogramowaniu pochłaniają przeróbki, których można było uniknąć
- Około 80% przeróbek, których można było uniknąć wynika z 20% błędów w aplikacji
- 80% wad generuje 20% funkcji
- Peer review pozwala wychwycić od 30 do 90% błędów (średnio 60%)
/Źródło: Software Defect Reduction Top 10 List, Software Management Jan 2001, Barry Boehm, Victor R. Basil/
Pomimo, że przedstawione powyżej dane pochodzą z 2001 roku, uważam je za wciąż aktualne. Jakkolwiek z liczbami można polemizować (nie znalazłam bardziej aktualnych danych), fakty te są czymś na kształt praw Edwarda Murphy’ego – opisują sytuacje pozornie nieprawdopodobne, jednak często występujące. Dają pewne wyobrażenie o skali.
Jak można poprawić jakość aplikacji jeszcze na etapie programowania?
Występowanie błędów w aplikacji to fakt, podobnie jak to, że testy nie wyeliminują błędów całkowicie, ani nie wykażą ich braku. Jednak możesz sprawić, aby aplikacja trafiająca do testów wewnętrznych była pewnych błędów pozbawiona i bardziej nadająca się do testowania. I tu z pomocą przychodzą peer review i programiści.
Peer review – przegląd funkcji wytworzonych w procesie programowania przeprowadzony przez kolegów twórcy oprogramowania, mający na celu wskazanie błędów i możliwości poprawek.
/Źródło: Słownik wyrażeń związanych z testowaniem, wersja 2.2 (2012)/
Na potrzeby realizowanych przeze mnie projektów opracowałam następujące założenia dla testów peer review:
- Każdy z programistów należących do zespołu projektowego testuje wskazany przez PM’a / team leadera zakres projektu (wybrane moduły / funkcje / procesy)
- Są to testy funkcjonalne, obejmują weryfikację zgodności z wymaganiami i kryteria akceptacji – jeśli są określone
- Każdy programista testuje nie swoje funkcje – testuje funkcje napisane przez innych programistów w ramach zespołu
- Testy trwają równolegle – wszyscy programiści testują w tym samym czasie
- Testy trwają około 2 – 4 godziny jednorazowo
- Testy odbywają się cykliczne, np. raz w miesiącu lub po zakończeniu prac nad wskazanym zakresem projektu (np. kamienie milowe)
- Błędy poprawiane są przez osoby odpowiedzialne za realizację – w krótkim czasie po zakończeniu testów (najlepiej tego samego lub następnego dnia)
- Dozwolone, a nawet wskazane jest poprawianie drobnych błędów już na etapie testów
- Dozwolony i mile widziane jest udział w testach TL’a / PM’a – ja również testuję :-)
Testy peer review (nazywane też przez zespoły, z którymi współpracuję, peer testami) spotkały się z ogromną aprobatą programistów. Pozwoliły na wyeliminowanie problemów technicznych i funkcjonalnych. Docenili je również testerzy. W efekcie prowadzą do wczesnego wyeliminowania części błędów i zminimalizowania kosztów ich naprawy.
Korzyści dla projektu i dla zespołu
- Mobilizacja dla programistów – moja praca będzie poddana ocenie kolegi z zespołu
- Zaangażowanie w aplikację, a nie tylko w realizowane przez siebie funkcje – programiści poznają oprogramowanie
- Spojrzenie osoby z boku – programiści nie dostrzegają swoich błędów, dlatego łatwiej im dokonać weryfikacji prac innych programistów (podobnie jak nie dostrzegamy literówek we własnym tekście)
- Weryfikacja, czy oprogramowanie spełnia określone wymagania – co było do zrobienia vs. to, co zostało zrobione
- Poprawa jakości aplikacji na etapie implementacji, wczesne wykrycie błędów
- „Wyłapanie” sporej ilości błędów w krótkim czasie – wysoka efektywność testów
- Dostarczenie do testów aplikacji bardziej stabilnej, w efekcie zapewnienie bardziej efektywnej pracy testerów
- Zredukowanie kosztów naprawy błędów na etapie testów
Podobnie jak dla programisty programowanie, tak dla testera testy są rutyną. Jednak zaangażowanie w testy programistów wychodzi poza pewien schemat, jest angażujące i potrzebne.Testy peer review mają istotne znaczenie dla zapewnienia jakości projektu, to według mnie jeden z najbardziej efektywnych sposobów na wyeliminowanie błędów przed etapem testów.
