Redakcja
Jedną z największych bolączek testerów manualnych jest wielokrotne wykonywanie tych samych przypadków testowych. Nasza praca zaczyna przypominać pracę Charliego Chaplina w "Moder times" [dla niecierpliwych akcja zaczyna się od 1:30].
Aby zrozumieć, z czego się to bierze, należy sięgnąć do źródła.
1) Jesteśmy zmuszani do uruchomienia wszystkich przypadków, ponieważ kierownictwo nie wie, co znajduje się w poszczególnych wersjach oprogramowania. Wykonanie przypadków staje się więc potwierdzeniem, czy coś w nim jest czy też nie.
Aby tego uniknąć, należy już na poziomie planowania wersji definiować co ma się znaleźć w oprogramowaniu, a później w notach wydania (release notes) opisywać co rzeczywiście zostało do oprogramowania wprowadzone.
2) Jesteśmy zmuszani do uruchomienia wszystkich przypadków, ponieważ kierownictwo nie potrafi odpowiedzieć na pytanie, jakie są powiązania wewnątrz oprogramowania. Tak więc, aby zapewnić, że drobna poprawka nie uszkodzi (nie wpłynie na działanie) jakiegoś kluczowego obszaru aplikacji, testujemy wszystko.
Kluczem do rozwiązania jest tu analiza wpływu realizowana przez wszystkich członków zespołu od programisty przez architekta, aż po klienta, dzięki której oceniamy jaki wpływ na poprawność działania będzie miała dana poprawka.
Z drugiej strony testerzy muszą zbudować zestaw testów regresywnych (różny od zestawu wszystkich przypadków testowych), uruchamianych na każdej nowej wersji. Zestaw ten dobrze jest zautomatyzować.
3) Uruchomienie wszystkich przypadków związane jest z brakiem zaufania do programistów. Z tym niestety nie jesteśmy stanie nic zrobić.
Zmuszanie do wykonywania powtarzalnej czy nudnej pracy jest silnie demotywujące. Każdy przełożony powinien być świadomy zgubnego wpływu takich nakazów na chęć pracy w danej firmie.
Czekamy na dalsze pytania na redakcja@testerzy.pl.
| SPRAWDŹ TAKŻE |
|---|
Testerzy odpowiadają testerom 1  |
