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

7339
wyświetleń
Analiza opłacalności automatyzacji testów - studium przypadku
Jedną ze świadczonych przez nas usług jest analiza organizacji w obszarze testowania i zapewnienia jakości. Przedstawiamy "studium przypadku", gdzie na wejściu jest informacja o procesie, produkcie i specyfice firmy, a na wyjściu rekomendacje konsultanta odnośnie m.in. automatyzowania testów.
*) 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.

a. Testerzy zwrócą uwagę na testowalność elementów oprogramowania.

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 >>

 

7339
wyświetleń

To powinno Cię zainteresować