Temat: Testy regresji na środowisku przedprodukcyjnym
Aleksandra G.:
Piotr Tomasz P.:
im bardziej skomplikowany proces biznesowy tym bardziej takie % można sobie w nos wsadzić
Podane wartości to tylko wstęp do dyskusji, są oczywiście bardziej specyficzne wyliczenia, do przedstawienia których zachętę stanowi pewna doza uprzejmości w wypowiedziach
mnie wystarczy że źle się przelicza na 1 grosz - i to jest już podstawa do odrzucenia
:)
Powyższa wypowiedź stwarza wrażenie, że pomylono kwestie rozkładu błędów w produkcie z działaniem konkretnych ścieżek danych kodu źródłowego
a wracając do regresji
znowu odnosząc się do wszelkich aplikacji gdzie w jakiś sposób dotykamy spraw finansowych - bardzo ciężko określić w jaki sposób zmiana w systemie ingeruje w resztę funkcjonalności i tu testy regresji w pewien sposób zabezpieczają nas przed grubymi wpadkami przynajmniej
Popieram, tylko staram się właśnie zacząć pisać o tym jakie są konsekwencje zmian w systemie i jak w odpowiedzi na nie należy zastosować dokładniej celowane testy regresywne.
poza tym ja wolę powiedzieć klientowi
"Nowa wersja aplikacji działa poprawnie - da się na niej pracować"
niż
"Na nowej wersji aplikacji działają nowe procesy"
Czyli bardziej kompleksowo, choć testy nowych funkcji często wykrywają więcej błędów niż testy regresywne
Zaplanowanie testów regresji mądrze - tak aby sprawdzić istotne części systemu to naprawdę duży projekt - i wydaje mi się że trzeba dobrze znać system aby coś takiego zrobić
Dodatkowo można wziąć pod uwagę koszt posiadania u klienta TCO (lub inne występujące w modelu biznesowym parametry finansowe) - w uproszczeniu rozpatrzyć, od strony biznesowej, które funkcje w przypadku ich nie działania spowodują największe straty finansowe u klienta.
Wszystko powyższe to zaledwie wstępne tezy do zbudowania "dokładniejszej" strategii testów regresywnych, gdzie proponowanego przez Panią podejścia nie uważam za błędne, tylko odpowiednie na początek.