Temat: Strategia testów regresywnych
Piotr Tomasz Piotrowski:
Pytanie wiązało się z tym że w moim środowisku nie
ma zgody co do tego kiedy i w jakiej ilości prowadzić
testy regresywne. Druga kwestia jest taka że pojęcie
strategii zaliczam do podstaw, jej rozwinięcie do poziomu zaawansowanego, a używanie statystyki do poziomu ekspert - idąc według standardów ISTQB.
Ech, Piotr - może moja uwaga wynika z tego, że Twoje pytania są masakrycznie ogólne podczas kiedy interesuje Cię jakiś konkretny temat. Tzn. mam wrażenie, że pytasz się o "zwyczaje godowe dużych zwierząt z trąbą" podczas gdy w rzeczywistości chodzi Ci o "zwyczaje godowe słonia afrykańskiego hodowanego w ZOO".
Nie wiem co rozumiesz przez to, że strategię testów regresyjnych/regresywnych zaliczasz do podstaw a jej rozwinięcie do poziomu zaawansowanego.
Wracając do tematu: chyba wszyscy zgadzamy się z tym, że istotą testów regresji jest weryfikacja tego, że przy wprowadzaniu zmian do oprogramowania to co już działało nie uległo regresowi. Oczywiste jest zatem, że regresja ma kluczowe znaczenie w przypadku kiedy oprogramowanie podlega wielu zmianom - czyli w modelach przyrostowych (a już szczególnie w "zwinnym" podejściu do wytwarzania oprogramowania). Czy to jest Twój przypadek? Jeżeli tak to chyba sytuacja jest prosta - automatyzujesz tyle ile możesz i masz to w procesie ;)
Kolejna "oczywista oczywistość" to to, że przy regresji zazwyczaj nie wytwarzasz nowych przypadków testowych tylko wybierasz jakieś podzestawy z tych, które wykonywałeś wcześniej (oczywiście warto to połączyć z jakimiś eksperckimi testami ad-hoc). Tak więc istotą regresji jest wybór odpowiedniego podzestawu z tego czym dysponujesz. Jeżeli chodzi Ci o jakiś "wodospadowy" model wytwarzania oprogramowania kiedy po przejściu testów nowych funkcjonalności chcesz sprawdzić czy nic się nie zepsuło to polecam nie zastanawiać się nad statystyką tylko zastosować bardziej praktyczne podejście:
1) co się zmieniło i na co mogą mieć wpływ te zmiany? czyli jakaś
analiza wpływu - czy oprogramowanie jest modułowe czy nie? Ile funkcji jest współdzielonych? Gdzie wykorzystywane są dane, które dostarczają zmodyfikowane procedury, etc.
2) jakie
ryzyka niosą ze sobą te zmiany - tzn. jeżeli zmienił się moduł logowania i moduł rysowania wykresów to czy będę je testować równie intensywnie? Czy w module logowania jest dla mnie ważniejsze, żeby ktoś mógł zalogować się prawidłowo czy może najpierw muszę sprawdzić 100 przypadków kiedy ktoś nie powinien móc się zalogować? A może z tych 100 interesuje mnie tylko 30 bo pozostałe 70 zdarza się raz na 100.000 logowań? Tutaj oczywiście musisz wiedzieć z czego i w jakim stopniu korzystają klienci - fajnie, żeby Twój system w jakiś sposób udostępniał te dane (czasem chociażby logi z serwera WWW mogą Ci sporo powiedzieć ;)).
3) dane historyczne - jasne, fajnie wiedzieć gdzie znajdowane były błędy (w trakcie testów) a gdzie wychodziły dopiero na produkcji. Fajnie wiedzieć ile czasu zajęła poprzednio regresja... to wszystko może pomóc Ci lepiej zaplanować swoje działania.
Kontynuując cykl "oczywistych oczywistości" -
kiedy przeprowadzać regresję? Kiedy się coś zmienia:
- dochodzi Ci nowa funkcjonalność
- wprowadzane są poprawki błędów
- zmienia się środowisko:
- nowy system operacyjny
- nowa baza danych
- nowa przeglądarka
- nowa wersja bibliotek
- nowa wersja javy/flash playera, etc
Oczywiście do każdej z tych zmian możesz mieć inne zestawy testów regresji - chyba nie ma co testować logiki biznesowej w momencie kiedy pojawiła się nowa wersja przeglądarki i chcesz tylko sprawdzić czy Twoja aplikacja "ogólnie" działa dobrze i czy prawidłowo działają pewne krytyczne obszary (to tak nawiązując do tego, że zastanawiacie się kiedy i ile testować).
Automatyzacja? Na pewno trzeba się nad tym zastanowić ale nie należy zakładać, że opłaca się automatyzować oraz, że automatyzacja załatwi wszystkie Twoje problemy... zdaje się, że było o tym pisane w innych wątkach.
Nie wiem na jakim poziomie testujesz: white box, black box czy oba. Jeżeli masz dostęp do kodu i kogoś kto potrafi prześledzić i zrozumieć wpływ zmian to na pewno masz możliwość przeprowadzenia lepszej/szerszej regresji.
Czy potrzeba do tego statystyki? Nie wiem - może w jakichś dziwnych przypadkach tak ale mnie wewnętrznie to nie przekonuje, mam wrażenie, że to taka "sztuka dla sztuki". Można oczywiście obliczać szacowaną ilość błędów i próbować wykryć jak najwięcej z nich ale nie zawsze jest taka możliwość. Ze swojej strony będę testował tyle ile według mnie należy, żeby się upewnić, że oprogramowanie będzie działało zgodnie z moimi oczekiwaniami (tutaj pojawia się kwestia dostępnego czasu/zasobów i ryzyka, które mogę wziąć na klatę). Moja strategia przy regresji jest prosta: zrobić jak najmniej, żeby być pewnym, że nie będę musiał się później tłumaczyć z 200 reklamacji dziennie ;)
Nie wiem na ile odpowiada to na Twoje pytania - tak jak pisałem mam wrażenie, że rozmawiamy tu o "oczywistych oczywistościach" ale może po prostu strzeliłem niepotrzebny elaborat bo nie do końca Cię zrozumiałem ;)
Ogólna rada na przyszłość: precyzuj proszę swoje pytania ;]
Pozdr,
DP.
пропозиції роботи
