Wyższa jakość

Nauka na błędach

Projekt zakończony, produkt sprzedany, kod i dokumentacja złożone w archiwum i przekazane do działu zajmującego się serwisem - czy to już koniec pracy? Otóż, nie. Chociaż na poprawę jakości wytworzonego systemu jest już za późno, to z danych uzyskanych podczas testowania można wysnuć wnioski na przyszłość, by w kolejnych projektach podejmować lepsze decyzje.

Bogatym źródłem wiedzy jest baza danych z raportami błędów. Można np. szczegółowo przeanalizować pewną liczbę losowo wybranych raportów i spróbować odpowiedzieć na pytanie, jaka była pierwsza przyczyna zaistnienia danego błędu: niejasno sformułowane wymagania, niedostateczna znajomość języka przez programistów, a może niedociągnięcia organizacyjne? Warto też przyjrzeć się statystykom raportów błędów. Kiedy pojawiło się ich najwięcej? Jaki był czas naprawy błędu? Ile raportów okazało się fałszywych? Odpowiedzi na te pytania niejednokrotnie umożliwią zidentyfikowanie słabych punktów w procesach i procedurach projektów lub niedostatków organizacyjnych w przedsiębiorstwie.

By armia nie poszła w rozsypkę

Stworzenie osobnego zespołu testowego nie zawsze jest najlepszą formą organizacji testów. Zależnie od charakteru projektu, typu produktu czy przyjętej metody wytwarzania, może się okazać korzystne zastosowanie innych rozwiązań organizacyjnych. Oto ich przegląd.

  • Programiści sami testują własny kod. Metoda często stosowana w testach modułowych (jednostkowych, komponentów). Jej wady są oczywiste.

  • Testowanie "koleżeńskie" (buddy testing): programiści nawzajem testują swój kod. Stosowane m.in. w modnym ostatnio programowaniu ekstremalnym (XP, Extreme Programming).

  • Tester lub testerzy są członkami zespołu programistów i podlegają kierownikowi zespołu lub kierownikowi projektu.

  • Osobny zespół testujący, mający swojego kierownika.

  • Osobny dział w przedsiębiorstwie, zajmujący się pewnymi rodzajami testów.

  • Outsourcing testów do innego przedsiębiorstwa: stosowany wówczas, gdy jest wymagana niezależna certyfikacja jakości systemu i jest niezbędne skomplikowane, kosztowne środowisko testowe (np. w testowaniu konfiguracji czy zgodności z wymaganiami środowiskowymi itp.).
Wybór właściwej organizacji testowania jest zadaniem kierownika projektu. Warto pamiętać, że w większych projektach może współistnieć kilka różnych form organizacyjnych testowania, np. testowanie koleżeńskie na poziomie testów komponentów, odrębny zespół do testu systemowego, outsourcing w celu uzyskania niezależnej certyfikacji.

Na pożegnanie

Od kilku tygodni miałem przyjemność na łamach Computerworld dzielić się swoimi przemyśleniami i poglądami dotyczącymi testowania oprogramowania: dziedziny, o której rosnącym znaczeniu jestem przekonany. W pięciu artykułach zostały poruszone podstawowe zagadnienia dotyczące celów, organizacji, technik i narzędzi służących do testowania oprogramowania. Poruszone, bo każdy z tych tematów zasługuje na odrębne, obszerne opracowanie, w każdym razie dla osób, które zajmują się testowaniem profesjonalnie.

Skuteczne testowanie nie jest tylko i wyłącznie dziedziną czysto techniczną i organizacyjną. Nie jest też oczywiście ograniczone do wytwarzania oprogramowania. Test, weryfikacja, sprawdzian, kontrola - to rodzaj postawy filozoficznej, sposobu na życie, w którym poziom świadomie podejmowanego ryzyka jest dostosowany do dostrzeganego poziomu zagrożeń, a wszelkie działania wykonuje się dobrze i starannie, aby ze swojej pracy odczuwać satysfakcję i by inni mogli mieć zaufanie do jej wyników. W końcu, jak w każdej ludzkiej działalności, chodzi o sprawę najważniejszą: jakość życia.

Bogdan Bereza-Jarociński jest niezależnym konsultantem pracującym m.in. dla szwedzkiej firmy Enea. Można się z nim kontaktować pod adresem: [email protected]


TOP 200