Peer review, czyli lepsza jakość oprogramowania przed etapem testów

Peer reviewKilka 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

  1. Mobilizacja dla programistów – moja praca będzie poddana ocenie kolegi z zespołu
  2. Zaangażowanie w aplikację, a nie tylko w realizowane przez siebie funkcje – programiści poznają oprogramowanie
  3. 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)
  4. Weryfikacja, czy oprogramowanie spełnia określone wymagania – co było do zrobienia vs. to, co zostało zrobione
  5. Poprawa jakości aplikacji na etapie implementacji, wczesne wykrycie błędów
  6. „Wyłapanie” sporej ilości błędów w krótkim czasie – wysoka efektywność testów
  7. Dostarczenie do testów aplikacji bardziej stabilnej, w efekcie zapewnienie bardziej efektywnej pracy testerów
  8. 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.

Więcej wpisów autora: Karolina Jarocka

“Zarządzanie projektami dla początkujących. Jak zmienić wyzwanie w proste zadanie” – recenzja

Bardzo często prosicie mnie o polecenie książki dla początkujących project managerów. Właściwie...
Czytaj dalej

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *