Czy testy end-to-end i testy integracyjne są tego warte w przypadku zadań o znaczeniu innym niż misyjny?

Powszechnie wiadomo, że kompleksowe testy integracyjne są kosztowne. Oczywiście, jeśli opracujemy aplikacje, w których ludzie mogą umrzeć, jeśli coś pójdzie nie tak, warto zainwestować. Jednak w aplikacjach, w których błędy nie są końcem świata, nie byłoby taniej całkowicie pominąć testy E2E i testy integracyjne i zamiast tego opracować plan tworzenia kopii zapasowych, jeśli coś pójdzie nie tak? Czy to wystarczy ręczny test historii użytkowników + testy jednostkowe + przy użyciu statycznie wpisanego języka?

Na przykład, jeśli sklep internetowy stracił zamówienie, mógł zamiast tego wysłać go za darmo + inny przedmiot jako przeprosiny. W ten sposób użytkownik końcowy może być jeszcze szczęśliwszy, a firma ogólnie oszczędza pieniądze.

Chyba moje pytanie brzmi: ile kosztuje test integracji i test E2E i ile pieniędzy to oszczędza? Czy istnieje sposób na obliczenie ryzyka / kosztów w tym celu?

Nie ma znaczenia, czy implementujesz E2E i testy integracyjne, czy nie, potrzebujesz planu tworzenia kopii zapasowych w obu przypadkach . Nigdy nie oczekuj, że system będzie wolny od błędów tylko dlatego, że został przetestowany.

Tak więc w oszacowaniu kosztów nie porównujesz kosztów wdrożenia testów E2E z kosztami oszacowanymi w planie tworzenia kopii zapasowych w przypadku awarii, porównujesz:

• Koszty ręcznego wykonywania testów E2E (kilka razy, przed każdą nową wersją)

vs.

• Koszty budowy (i utrzymania) automatycznych testów E2E

W przypadku, gdy możesz skorzystać z tych testów E2E kilka razy, zwykle będzie wiele testów, w których koszty osiągną próg rentowności. To powinna być miara, którą zastosujesz, kiedy chcesz zaplanować z wyprzedzeniem, które testy E2E zrobisz ręcznie, a które zautomatyzujesz.

Należy pamiętać, że mogą istnieć pewne rodzaje testów E2E, które można łatwo wdrożyć, gdzie ROI jest natychmiast jasny, ale są też rodzaje testów E2E, w których opracowanie i konserwacja mogą być droższe niż wykonywanie ich ręcznie przez okres kilku lat.

Być może wbrew intuicyjnemu testowanie automatyczne może faktycznie skrócić czas programowania w porównaniu do braku testowania. To wygrana wygrana.

Chodzi o to, że testy przyczyniają się do wielu poziomów

1. Wymuszanie ścisłego zbierania wymagań i specyfikacji

   Ma to ogromny wpływ na szybkość rozwoju. Nie trzeba wracać z prośbą o więcej szczegółów, żadnych nieporozumień, żadnych niepotrzebnych funkcji itp

2. Programiści wiedzą, kiedy funkcja jest ukończona

   Większość testów jest wykonywana przez programistów podczas pisania kodu, a nie przez testujących sprawdzających gotowy produkt. Automatyzacja tych testów zmniejsza to obciążenie pracą

3. Błędy wprowadzone przez nowe funkcje natychmiast wykryte.

   Mogą one z łatwością kosztować cię sprintem i wymagają przepisania całej funkcji, jeśli nie zostaną wykryte.

4. Szybszy cykl wydawania

   Oznacza to mniej kodu w locie, co oznacza mniej scalania, co oznacza mniej pracy i mniej złożoności dla programistów

Zwłaszcza jeśli masz konfigurację środowiska testowego, pisanie tych testów zajmuje mniej czasu niż oszczędzasz na tych wydajnościach.

Ponadto oszczędzasz na ręcznym testowaniu, a na końcu dostajesz lepszy produkt.

Moja odpowiedź? Być może nie .

Testy EOE są dobre, gdy są bardzo proste. Jeśli planujesz objąć podstawowe scenariusze, możesz uzyskać przewagę dzięki testom EOE. Ale jeśli masz naprawdę złożoną i dużą aplikację (o znaczeniu krytycznym lub nie), te testy EOE będą kosztowne w utrzymaniu i musisz znać swój scenariusz, aby wycenić, jeśli warto.

Kilka lat temu blog testowy Google omawia ten temat. Mogę tylko zgodzić się z autorem. Dobry test musi być szybki , niezawodny i izolować awarie , cechy, których testy EOE nie są w stanie dostarczyć.

Pracowałem nad aplikacją, która ma ponad 12 godzin kompleksowych testów obejmujących wiele scenariuszy. W końcu udało nam się rozpowszechnić te testy na różnych komputerach, kontrolując rozpoczęcie, wykonanie i zakończenie testów, zbierając i scalając wyniki. Testowana aplikacja była aplikacją monolityczną (co jest łatwiejsze do uruchomienia i uruchomienia w celu przetestowania) i była koszmarem w utrzymaniu testów.

Przez większość czasu przeprowadzaliśmy testy zamiast łapać błędy z ich wyników. Odkrywanie źródła błędu w kompleksowym teście zajmuje dużo czasu. Zajęliśmy się również wieloma testami „fałszywie ujemnymi” i mało czasu na zrozumienie problemu i jego rozwiązanie: problemy z ładowaniem apletów Java, oczekiwany element nie został znaleziony na stronie (plus inne problemy dotyczące szybkości automatyzacji), utrzymuj kod zapytania, który są po prostu używane w teście pamięci bazy danych (ponieważ oryginalne zapytanie używa kodu specyficznego dla bazy danych) itp.

Wszystko to wymaga od ludzi utrzymania i działania. Na koniec zaczynamy usuwać niektóre testy EOE i zastępować je wieloma testami jednostkowymi / integracyjnymi.

Tak więc moją konserwatywną radą jest użycie piramidy testującej od Google:

Na pierwszy rzut oka Google często sugeruje podział 70/20/10: 70% testów jednostkowych, 20% testów integracyjnych i 10% testów kompleksowych. Dokładna mieszanka będzie inna dla każdej drużyny, ale ogólnie powinna zachować ten kształt piramidy.

Z mojego doświadczenia wynika, że ​​testy E2E, niezależnie od krytyczności aplikacji, są zawsze ostrożne. Zawsze myślę w kategoriach najgorszego scenariusza: jeśli coś pójdzie w gruszkę, czy czujesz się komfortowo, stojąc przed zarządem i uzasadniając swoje podejście? Jeśli nie, musisz zmienić swoje podejście. Wiele organizacji minimalizuje znaczenie i zasoby przeznaczone na testowanie, ale możesz mieć pewność, że gdy coś pójdzie nie tak, wszyscy szukają kogoś, kogo można obwinić, a jeśli zdecydowałeś się ograniczyć testowanie lub dałeś taką radę, to ty jesteś na pierwszym miejscu linia.

Rozwój oprogramowania zbyt często wymaga polityki organizacyjnej.

„Powszechnie wiadomo, że kompleksowe testy integracyjne są kosztowne”.

Myślę, że nie zgadzam się z tym twierdzeniem.

Po pierwsze, testy E2E są ważne dla użytkowników końcowych i mogą być najbardziej efektywnymi czasowo / najtańszymi opcjami testowania złożonych systemów. Na przykład, gdy ktoś kupuje samochód, większość ludzi nie rozbija go na części i nie rozpoczyna testowania węglowodanów, skrzyni biegów i kół w izolacji. Zamiast tego biorą to na jazdę próbną.

Po drugie, jeśli chodzi o oprzyrządowanie, E2E nie spowalnia wewnętrznej ewolucji produktu i trwa dłużej. Jeśli się nad tym zastanowić, faktyczna funkcjonalna powierzchnia większości produktów rzadko tak bardzo się zmienia, a wewnętrznie może podlegać różnego rodzaju zmianom. W rezultacie, gdy oprzyrządowanie testowe jest już uruchomione, zwykle trwa wyjątkowo dobrze. Na przykład, jeśli wrócimy do analogii samochodu. Ten sam przypadek testowy „weź to na dysk” działałby właściwie w modelu Ford T i Tesli. Podobnie jak inwestycje w drogi, tunele aerodynamiczne, konfiguracje testów szczelności itp. Ile testów wewnętrznych komponentów miałoby tak dobry zwrot z inwestycji przez cały okres ich użytkowania?

Tam, gdzie testowanie E2E bywa droższe / nieodpowiednie, jest w początkowej konfiguracji i czy jest używane do testowania wszystkiego. Pragmatycznie myślę, że najlepszym sposobem na uniknięcie tej pułapki są priorytety automatyzujące testowanie rzeczy, które:

1. Są łatwe do zautomatyzowania i prawdopodobnie nie będą wymagały dużo konserwacji, aby mogły działać.
2. Poświęć najwięcej czasu na zastosowanie spójnych, odpowiednich, ręcznych procesów testowania.
3. Ryzykuj, że ty lub twój szef będziecie wyglądać jak idioci, jeśli produkt zostanie wypuszczony z uszkodzonym produktem.

Użyj dowolnej formy testowania, w tym E2E, którą uważasz za właściwą. Skoncentruj się na nich.

Nie można tak naprawdę porównać kosztów testów integracyjnych z kosztem najlepszego scenariusza, w którym błąd wpływa tylko na jedno zamówienie. Błąd logiczny miałby równie duży wpływ na dużą liczbę zamówień. Powiedzmy, że błąd oznacza, że ​​żadne płatności nie są rejestrowane - może to mieć katastrofalne skutki dla każdej firmy.

Powinieneś zapytać, jaki jest najgorszy przypadek błędu, który realistycznie mógłby skończyć w produkcji z powodu braku testów E2E. I pamiętajcie prawo Murphysa.

Zakładam, że to pytanie dotyczy korporacyjnych aplikacji internetowych.

Moja rekomendacja dla średnio-krytycznych rzeczy:

• Przeprowadź automatyczne testowanie interfejsów API zaplecza, upewniając się, że działa ono zgodnie z oczekiwaniami. Testy te powinny zostać napisane przez programistów podczas implementacji interfejsu API.
• Nie przejmuj się automatycznymi testami interfejsu użytkownika, czyli ręcznie wykonuj testy interfejsu użytkownika.

Myślę, że większość testów powinna być na poziomie interfejsu API lub komponentu. Nie dbam o testy jednostkowe, które wykonują tylko niektóre funkcje wewnętrzne.