Analiza opłacalności automatyzacji testów - studium przypadku

*) Analiza została okrojona o elementy, które mogą identyfikować firmę.

Opis firmy

Duża firma produkująca systemy kontrolne i interfejsy użytkowników dla sprzętu AGD. Wykonawca podzespołów dla wiodących marek na międzynarodowym rynku.

Specyfika analizowanego projektu

Celem projektu jest wytworzenie elektroniki, sprzętu i oprogramowania do sterowania sprzętu AGD nazywanego dalej Produktem.

Zespół programistów będzie implementował Scrum, ale testerzy są odseparowani od części programistycznej. Scrum jest tutaj jedynie formą organizacji pracy i nie jest wspierany, ani wymagany przez Zamawiającego Produkt. Nie są wymagane ciągłe dostawy, a zdefiniowane dostawy realizowane są w kamieniach milowych w ramach modelu.

Zespół programistyczny zaimplementuje metody znane ze Scrum, ale nie będą to wszystkie wytyczne znane ze Scrum Guide.

W analizie udało się zauważyć, ze Wykonawca nie zarządza ryzykami produktowymi, a jedynie ryzykami projektowymi.

Podstawą wyspecyfikowania Produktu jest tzw. UI Specification - akceptowany przez klienta. Dokument jest na tyle niskopoziomowy, że stanowi już podstawę do implementacji. Z drugiej strony Zamawiający deklaruje jego akceptację. Dokument staje się więc platformą komunikacji między firmą wytwarzającą i Zamawiającym. Takie podejście wydaje się redukować do minimum ryzyka związane z przekłamaniem w komunikacji.

Projekt z perspektywy Zamawiającego będzie miał zamrożone wymagania na początku, nabywa więc cech modelu kaskadowego. Zmawiający zadeklarował również zdefiniowanie priorytetów dla wymagań. Wiadomo jednak z doświadczenia, że Zamawiający będzie zmieniał swoje wymagania w trakcie trwania projektu. Część zmian będzie akceptowana w ramach „bufora projektowego”, ale część, szczególnie te większe zmiany, będzie wymagała uruchomienia procesu zarządzania zmianą.

Proponowana strategia testowania

Testowanie musi być realizowane na wielu poziomach, a kluczowym poziomem będzie testowanie jednostkowe. Potencjalna zmienność wymagań klienta będzie wpływała na stabilność struktury testów automatycznych i będzie wymagała długotrwałych i kosztownych zmian i modyfikacji dla tych testów. Łatwiej będzie zadbać o tę część Produktu, która narażona jest potencjalnie najmniej na zmiany. Dodatkowo wdrożenie metodyki zwinnej powinno ten proces ułatwić. Ponieważ wysiłek na automatyzację testów interfejsów zewnętrznych przerzucony jest w całości na zespół testerski, to tworzenie skryptów powinno silnie bazować na predefiniowanym business case.

Opłacalność automatyzacji powinna zostać pomierzona. W ramach analizy określono, że specyfika testowania automatycznego dla oprogramowania wbudowanego nie stanowi większej przeszkody w testowaniu interfejsu. Mnogość zastosowanych narzędzi, zarówno zewnętrznych, jak i wewnętrznych, daje możliwość nawet 100% zautomatyzowania testów oprogramowania. Koszty jednak takich działań mogą okazać się zbyt wysokie do czasu i środków przewidzianych w projekcie.

Koszty automatyzacji w zestawieniu do testowania manualnego można przeliczyć w oparciu o koszty przeprowadzania testów automatycznych i manualnych. Plik XLS opisany na końcu artykułu powinien wspomóc tę analizę.

Każdy z wdrożonych poziomów testów jak i każda zastosowana technika powinny być monitorowane pod kątem skuteczności w kontroli jakości i opłacalności. Zapewni to wyeliminowanie ryzyka przeinwestowania w techniki nieskuteczne i kosztowne.

Przykładowo:

• poziom pokrycia kodu przez testy jednostkowe w zestawieniu z liczbą defektów znajdowanych w kolejnym poziomie testów (integracji)
• koszty wytworzenia testów jednostkowych w połączeniu z kosztami (czasem) poświęconym na tworzenie kodu
• itd.

Czas trwania testów oraz ich liczba powinny silnie zależeć od predefiniowanych przez Zamawiającego priorytetów w wymaganiach. Budżet na testy należy rozdzielić proporcjonalnie do definiowanej kluczowości funkcji i cech niefunkcjonalnych. Obszary najbardziej kluczowe należy pokryć scenariuszami testowymi, a obszary o mniejszym priorytecie lub obszary styku między funkcjami - zweryfikować przez testy eksploracyjne.

Należy również zapewnić mapowanie procesu testowego na Scrum, zapewniając dostępność niezależnego zespołu testerskiego na odbiór oprogramowania i późniejsze jego pogłębione wewnętrzne testy akceptacyjne.

Rekomendacje

1. UI Specification powinno zostać zweryfikowane w procesie wytwórczym zarówno przez testerów oprogramowania, jak i przez programistów.

b. Programiści pokażą implementowalność rozwiązania.

2. Pozostawienie niezależnego zespołu testerskiego, odseparowanego od grup programistycznych.

3. Dołączenie testera do zespołu Scrumowego pomagającego i motywującego do wykonywania testów jednostkowych. Dodatkową rolą testera może być sprawdzenie jakości kodu, którego konieczność zachowania jest kluczowa do ułatwienia jego utrzymania, szczególnie w warunkach dużej dynamiki zmian w zakresie HR.

4. Wykonywanie peer review przez łączony zespół programistyczno-testerski.

5. Rekomenduje się zdefiniowanie w ramach Scruma kryteriów akceptacji pozwalających określać, czy sprint zakończył się powodzeniem czy też niepowodzeniem.

6. Przygotowanie i uruchomianie testów jednostkowych, których dostępność i poprawność wykonania stanowi kryterium sukcesu dla sprintu.

7. Wymóg testowania przez programistów integracji, na warstwach: sprzętowej, sterowników, systemu operacyjnego i interfejsów zewnętrznych.

8. Ponieważ programiści nie mieli do tej pory do czynienia z TDD (wytwarzaniem opartym na testowaniu), nie rekomenduje się tej techniki w tym projekcie.

Plik XLS

Załączony plik pozwala zestawić podstawowe parametry procesu testowania automatycznego i testowania manualnego.

Kalkulacja końcowa pokazuje koszty testowania automatycznego i testowania manualnego oraz czas potrzebny na przeprowadenie testów.

W oparciu o przykładowe dane pokazany jest czytelnie koszt testów automatycznych, który jest niższy na poziomie uruchomienia, ale znaczący dla utrzymania skryptów.

Chcesz poznać plik XLS wspierający kalkulowanie kosztów testowania i opłacalność automatyzacji?

Jest on dostępny za darmo dla uczestników naszego szkolenia: Dobry Menedżer Testów, ISTQB Poziom Zaawansowany - Kierownik Testów oraz Automatyzacja testowania.

Można go również kupić na stronie (29,99 PLN netto) [z prawego menu wybierz opcję po zakupie]: http://edu.ittraining.pl/material/analiza-kosztow-testowania-manualnego-i-automatycznego

Opis świadczonej przez nas usługi doradztwa >>