Redakcja
Na naszym portalu staramy się pisać przede wszystkim o praktycznych aspektach testowania, rzadziej natomiast o teoretycznych. Nie oznacza to bynajmniej, że kwestie teoretyczne są dla nas mniej ważne. Wręcz przeciwnie - uważamy, że praktyka potrzebuje teorii, tak samo jak teoria praktyki. Teoria stanowi dla nas punkt odniesienia, pożądany stan, do osiągnięcia którego powinniśmy dążyć, a którego realizacja z różnych względów (presji czasu, możliwości finansowych, niewystarczającej wiedzy) okazuje się często wręcz niemożliwa. W rezultacie czynności, które wykonujemy w naszej codziennej pracy różnią się od tego, czego uczono nas na studiach czy też na różnego rodzaju szkoleniach.
Bywa jednak i tak, że praktyka i teoria stanowią niemal jedno i to samo, czego przykładem może być metoda wytwarzania oprogramowania, w której linie kodu (produkcyjne i/lub testowe) modułu są pisane przez dwóch programistów siedzących przy jednym komputerze, co oznacza odbywający się w czasie rzeczywistym nieustanny przegląd kodu. Metodę tę określa się mianem programowania parami. Jej celem jest nie tylko zadbanie o czytelność pisanego kodu, ale przede wszystkim ograniczenie ryzyka popełnienia przez programistów błędów, stanowiących źródło nie zawsze łatwych do znalezienia defektów i potencjalnych awarii.
O ile pojęcie programowania parami jest pojęciem dość często spotykanym w literaturze przedmiotu, o tyle pojęcie testowania parami występuje zdecydowanie rzadziej. Istnieją jednak sytuacje, kiedy współpraca testerów może nie tylko skrócić czas potrzebny na przeprowadzenie testów, których wynik powinien budzić zaufanie co do jakości danego oprogramowania czy też rozwiązania, ale także znacząco poprawić jego jakość - po usunięciu znalezionych defektów.
O korzyściach płynących z testowania parami przekonaliśmy się sami, nie tak dawno, albowiem w trakcie testów aplikacji dla komisji sędziowskiej tegorocznych Mistrzostw Polski w Testowaniu, które odbędą się w Katowicach. Z punktu widzenia planowanych testów kluczowym podlegającym weryfikacji wymaganiem była możliwość skorzystania z aplikacji przez kilku użytkowników równocześnie. Najczęściej stosowanym w tego typu sytuacjach rozwiązaniem jest uruchomienie aplikacji w kilku instancjach na tym samym komputerze lub też na osobnych stanowiskach i próba symulacji pracy większej liczby użytkowników. Takie podejście ma jednak jedną dość poważną wadę - nie pozwala zweryfikować konkretnej funkcjonalności, gdy korzysta z niej co najmniej dwóch użytkowników dokładnie w tym samym czasie. Wówczas testowanie parami okazuje się niezastąpione. Pół godziny przeprowadzonych w ten sposób testów pozwoliło nam na znalezienie 5 defektów, których priorytet określiliśmy za krytyczny ze względu na fakt zakończenia działania aplikacji i konieczności ponownego jej uruchomienia.
Testowanie parami ma jednak również i inne zalety. Stanowi także doskonałą okazję do wymiany doświadczeń, wiedzy oraz opinii dotyczących sposobu zwiększenia jakości testów pomiędzy testerami, inaczej mówiąc stanowi doskonałą okazję do podniesienia ich umiejętności testerskich. Ponadto przez wiele lat popularnym podejście do zarządzania zespołami, również zespołami testerskimi, było podejście, które kluczową rolę we wzroście wydajności pracy przypisywało rywalizacji - konfliktowi (zarządzanie konfliktem). Bardzo szybko okazało się jednak, że podejście to przynosi korzyści jedynie na krótką metę, w dłuższej perspektywie negatywnie wpływa bowiem na atmosferę pracy, motywację pracowników, w efekcie prowadząc nie do dalszego wzrostu, ale do spadku wydajności pracy. Alternatywną dla tego typu podejścia jest niewątpliwie to, które silny nacisk kładzie na współpracę, a którego przykładem może być omawiane w niniejszym artykule testowanie parami. Pomimo zalet, testowanie parami nadal nie znalazło jednak należytego miejsca w teorii testowania, czego wyrazem może być chociażby fakt, że pominięte zostało przez twórców ISTQB.
Autor: Grzegorz Libor
