Właściwe sformułowanie celu testów i w konsekwencji organizacja testowania mogą mieć kluczowe znaczenie dla powodzenia projektu.

Testujemy po to, by jak najwcześniej wykryć jak najwięcej błędów w tworzonym czy wdrażanym oprogramowaniu. Można się jednak zastanawiać, czy zawsze takie podejście jest właściwe, a w każdym razie, czy jest to jedyne lub jedynie słuszne sformułowanie celów. Na pewno akcenty da się rozłożyć inaczej. A może da się przeformułować sam cel?

Ogólne sformułowanie celu testowania można przełożyć na konkretne cele projektu, biorąc pod uwagę lokalne uwarunkowania dotyczące terminów i zasobów. Celem testów może być np. uzyskanie pewności, że testowany system nadaje się do wdrożenia, np. działają wszystkie istotne funkcje, nie wykryto błędów wykluczających wdrożenie, terminowe wdrożenie systemu jest na tyle ważne, że akceptowalne jest ryzyko pojawienia się błędów powdrożeniowych. Czasem można skoncentrować się jedynie na potwierdzeniu braku poważnych błędów w najistotniejszych funkcjach systemu.

To, co właśnie napisałem, brzmi trochę jak herezja - przecież testy są bardzo ważne, testować trzeba jak najdłużej i jak najwięcej. Ale popatrzmy na praktykę. Testy są z reguły tą fazą projektu, którą najłatwiej jest skrócić lub ograniczyć. Śledząc artykuły prasowe i wystąpienia na konferencjach dotyczących testowania, słyszymy ciągłe narzekania na brak czasu, środków i wysoko wykwalifikowanych pracowników.

Często podawany jest przykład szkoleń - o wiele prościej jest znaleźć środki i uzyskać akceptację szkoleń dla programistów niż dla członków zespołu zajmującego się testowaniem. Na porządku dziennym są pomysły zatrudniania w charakterze testerów tzw. ludzi z ulicy, bo "przecież można ich przyuczyć, a są o wiele tańsi niż profesjonalni specjaliści". Ciekawe, że rzadko się słyszy takie propozycje odnośnie do programistów lub analityków.

O co chodzi

Jeśli spojrzeć na testy z takiej perspektywy, to jasno widać, że definiując cele testów, musimy brać pod uwagę realia. Musimy ocenić możliwości zespołu, terminy wewnętrzne projektu, (czyli te, które możemy zmieniać na naszym poziomie uprawnień) czy terminy narzucone z zewnątrz i na tej podstawie tak sformułować cel testów, by stało się realne jego osiągnięcie w tych właśnie warunkach.

Nie jest dobrze, gdy definiujemy cele, które ładnie wyglądają w dokumentach projektu i początkowych prezentacjach, a później, w praktyce, okazują się całkowicie nierealistyczne. Ważne jest, by u osób kluczowych dla projektu istniała świadomość ograniczeń nałożonych na testy. Trzeba też wiedzieć, że definicje lub sformułowania celu testów dostosowane do realiów narzucają odmienną strukturę organizacyjną projektu. Dotyczy to umiejscowienia zespołu testów w projekcie i zasad rządzących współpracą wewnątrz zespołów projektowych.

Kierownik projektu nie zawsze zdaje sobie z tego sprawę już od początku. Z reguły na projekt patrzymy jako na przedsięwzięcie, które ma dostarczyć określony produkt, a przez to zrealizować jasno postawione zadania biznesowe, finansowe i organizacyjne. Cele poszczególnych faz projektu muszą być oczywiście podporządkowane celom projektu jako całości. Jednak, jak wspomniałem na wstępie, wiele zależy od rozłożenia akcentów i idących za tym posunięć organizacyjnych. Te niekiedy drobne dopasowania celów cząstkowych czynią osiągnięcie celów głównych projektów bardziej prawdopodobnymi.

Gdy cel testów zdefiniujemy następująco: "Testujemy, by wykryć jak największą liczbę błędów", zakładamy zapewne bardzo dużą autonomię zespołu testów, co oczywiście w praktyce nieczęsto się zdarza. W domyśle zakładamy, że zespół testujący nie jest od zastanawiania się, czy system będzie wdrożony w terminie, czy zostaną osiągnięte cele biznesowe projektu. Ma wykrywać błędy, ma ich wykryć jak najwięcej. Można nawet powiedzieć, że ma udowodnić, że system jest zły.

Takie podejście jest bardzo kuszące, bo bardzo wygodne dla członków zespołu testowego. Czasami jest to również wygodne dla kierownika projektu - szczególnie wtedy, gdy za dostarczenie systemu jest odpowiedzialna firma zewnętrzna. Wtedy kierownik projektu ma alibi, bo w przypadku niepowodzenia projektu powie: "Przecież to ONI dostarczyli zły produkt! Patrzcie, moi testerzy znaleźli w nim tyle błędów! Tego praktycznie nie da się używać".

Formalnie zawinił dostawca - system ma błędy i nie nadaje się do wdrożenia (pomijam tu aspekt organizacji testów po stronie dostawcy). Co oczywiste, sytuacja jest czysta tylko z pozoru. Wina leży bowiem po obu stronach. Przecież można było dokładniej popracować nad wymaganiami - wiele błędów bierze się ze zwyczajnego niezrozumienia wymagań przez pracowników dostawcy. Inaczej można było także zorganizować prace projektowe. Pomocne byłoby zwłaszcza wcześniejsze włączenie się klienta w prace prowadzone przez deweloperów dostawcy.

Często w takim przypadku pomagają inspekcje, spotkania, przeglądy już wykonanych części systemu. Już na tym etapie często dochodzi do wykrywania wielu nieporozumień i błędów w analizie. Ten etap pozwala także na zadzierzgnięcie współpracy pomiędzy członkami zespołów projektowych po obu stronach. Wreszcie bardzo ważne jest takie zdefiniowanie warunków umowy, by już z niej wynikało, że nie jest możliwe dostarczenie do testów systemu, który będzie miał taką liczbę błędów, która uniemożliwi dalsze testy już po stronie zamawiającego.