Spędzamy więcej czasu na wdrażaniu testu funkcjonalnego niż na wdrażaniu samego systemu, czy to normalne?

12

Zasadniczo mamy trzy główne projekty, dwa z nich to usługi sieciowe, a drugi to aplikacja internetowa. Chociaż jestem zadowolony z objęcia jak największej liczby naszych usług internetowych testami funkcjonalnymi (wszystkie trzy projekty mają odpowiednie testy jednostkowe), testy funkcjonalne aplikacji sieciowej zajmują dużo czasu. Mam na myśli dwa razy, a czasem więcej, czas potrzebny na wdrożenie testowanej funkcjonalności wraz z testem jednostkowym.

Polityka menedżera polega na testowaniu każdej dodanej przez nas funkcji, nawet jeśli nie jest to krytyczne z punktu widzenia biznesu (tj. Nowa CRUD).

Zgadzam się z testowaniem wszystkich funkcji usług internetowych, ponieważ trudno jest je ręcznie przetestować, a także testy te przebiegają szybko i nie wymagają zbyt wiele do wdrożenia.

Jaka jest zatem wartość spędzania więcej czasu na pisaniu testu funkcjonalnego niż pisanie kodu systemowego, test jednostkowy i naprawianie biletów QA? Czy to normalne? Czy nie powinniśmy pisać testów funkcjonalnych tylko pod kątem funkcjonalności krytycznej i pozwolić QA przeprowadzać testy regresji zamiast funkcji krytycznych?

Uwaga: nie tworzymy oprogramowania medycznego ani oprogramowania NASA ani niczego, co jest krytyczne.

Pablo Lascano
źródło
14
Nie mamy testów. Poświęcamy ogromną ilość czasu na naprawę rzeczy po fakcie. „Możesz mi zapłacić teraz lub później”. Jest później i nie jest ładna.
MetalMikester
3
Tak - częścią obrazu jest zdecydowanie to, że dobrze utrzymany zestaw testów skraca czas potrzebny na faktyczną implementację.
Michael Borgwardt

Odpowiedzi:

16

Testy funkcjonalne są bardzo ważne. Tak, poświęcają czas na pisanie, ale jeśli piszesz odpowiednie testy funkcjonalne, będą więcej niż warte tego.

Istnieje kilka dobrych powodów, aby przeprowadzać automatyczne testy funkcjonalne aplikacji.

  • Gdy nowa funkcja zostanie dodana do Twojej witryny, natychmiast poinformuje Cię, czy zmiany wprowadzone dla tej nowej funkcji naruszają inne funkcje w Twojej witrynie.
  • Udokumentowana wiedza na temat działania aplikacji i współpracy w celu spełnienia wymagań biznesowych.
  • Kiedy nadszedł czas na aktualizację biblioteki innej firmy, możesz ją zaktualizować i uruchomić pakiet testów funkcjonalnych, aby sprawdzić, czy coś się psuje. Zamiast konieczności samodzielnego przeglądania każdej strony, możesz poprosić komputer, aby zrobił to za Ciebie i podał listę wszystkich testów, które się zepsuły.
  • Testowanie obciążenia! Możesz symulować tysiące jednoczesnych użytkowników, którzy jednocześnie odwiedzają Twoją witrynę, i możesz zobaczyć, gdzie Twoja strona zwalnia i zapada się pod presją. Możesz zobaczyć, jak zachowuje się Twoja strona internetowa na długo przed otrzymaniem telefonu późno w nocy, że witryna uległa awarii.
  • Testy funkcjonalne wymagają czasu ręcznego. Tak, napisanie skrzynek zajmuje dużo czasu, ale jeśli musiałbyś usiąść z segregatorem z 500 stronami testów, które musiałeś ukończyć przed wysłaniem produktu, chciałbyś, abyś miał zautomatyzowane testy!
  • Testowanie dokumentów szybko staje się nieaktualne. Po dodaniu nowej funkcji należy zaktualizować główny dokument testowy. Jeśli ktoś pominie niektóre testy, nagle robaki wkradają się na „gotowe i przetestowane” strony. Obecnie pracuję w takim środowisku i zapewniam cię, że to koszmar.

W końcu tak, napisanie tych spraw zajmuje trochę czasu, ale powinieneś być dumny z ich pisania. To twój sposób na udowodnienie, bez cienia wątpliwości, że Twój kod działa i działa ze wszystkimi innymi funkcjami. Kiedy QA przychodzi do ciebie i mówi, że jest błąd, napraw go, a następnie dodaj go do swojego zestawu testów, aby pokazać, że został naprawiony i upewnić się, że nigdy więcej się nie powtórzy.

To twoja siatka bezpieczeństwa. Gdy ktoś wejdzie i przejmie przechowywany proc i dokona niewielkiej zmiany, aby działał on z jego kodem, zauważysz, że złamał on 3 inne funkcje w tym procesie. Złapiesz ją tej nocy, a nie tej przed terminem!

Co do pisania testów funkcjonalnych tylko dla funkcji krytycznych dla systemu. To nie da ci całego obrazu i pozwoli na przemycenie błędów. Wystarczy dodać jedną małą funkcję, która nie jest krytyczna dla systemu, ale pośrednio współdziała z funkcją krytyczną dla systemu i masz możliwość wprowadzenia błędu.

Tyanna
źródło
dzięki za odpowiedź. Wiem o znaczeniu i zaletach testów funkcjonalnych, moje obawy dotyczą kosztów i korzyści testowania WSZYSTKICH. Opracowywaliśmy test funkcjonalny przez ostatnie trzy lata, ale teraz w tym projekcie wydaje mi się, że koszt wdrożenia testu ALL to znacznie więcej niż znalezienie błędu w produkcji, podniesienie biletu i naprawienie go ... Zastanawiam się, czy istnieją pewne okoliczności, w których NIE wykonanie testu funkcjonalnego jest lepsze (pod względem kosztów i korzyści) niż nie zrobienie go, i zastanawiam się, czy jesteśmy w takich okolicznościach, gdzie lepiej mądrze wybrać, co przetestować.
Pablo Lascano
@donsenior ~ jeśli uważasz, że testowanie trwa zbyt długo, to spójrz na używane narzędzia. Czy używasz ich poprawnie? Czy używasz nawet narzędzi oszczędzających czas? Pisanie testów trwa dłużej niż pisanie kodu, ponieważ masz więcej kodu do napisania. Taka jest natura testowania. Jeśli zaczniesz wybierać i wybierać, po co pisać testy, dojdzie do tego, że nikt nie napisze testów, albo te testy będą niechlujne.
Tyanna
mój pomysł na wybór tego, co ma być testowane, nie jest przypadkowym wyborem, ale wybranie najbardziej krytycznej funkcjonalności biznesowej (i to nie byłaby decyzja programistów, ale menedżera). I uważam, że wręcz przeciwnie, programiści piszą teraz niechlujny test, ponieważ muszą przetestować wszystko, nawet tę funkcję, która trwa pięć minut na przetestowanie kontroli jakości i dwa dni na automatyzację programisty. Zgadzam się, że być może narzędzia, których używamy, nie są najlepsze do testowania naszej aplikacji internetowej (fitnesse i java). Obawiam się, że zbliżamy się do napisania i utrzymania testu funkcjonalnego bardziej niż systemu
Pablo Lascano,
@donsenior ~ Jasne, testowanie przypadku zajmuje QA 5 minut, ale testowanie go zajmuje komputer w mniej niż sekundę. Powinieneś zapytać: „Dlaczego napisanie czegoś ręcznie zajmuje 5 minut”? Ponownie spójrz na swoje narzędzia. Być może QA powinien również napisać kilka przypadków testowych? Problemem nie jest pisanie przypadków testowych dla twojego systemu, to sposób pisania tych przypadków testowych.
Tyanna,
cóż, testy te trwają znacznie dłużej niż sekundę (pamiętaj, że są to testy funkcjonalne, a nie testy jednostkowe). Ale to nie problem, biegają w nocy. Myślę, że masz rację, że QA powinna również napisać kilka przypadków testowych, ale niestety nie jest to decyzja, którą mogę podjąć. Bardzo dziękuję za odpowiedzi, oznaczyłem tę jako zaakceptowaną!
Pablo Lascano
7

Ponad 2 razy ... wydaje mi się trochę dużo. Możesz przeanalizować przyczyny tego, mogą one obejmować:

  • zła obsługa narzędzi do tworzenia i utrzymywania testów

  • umowy o usługi sieciowe nie są wystarczająco opisane w projekcie. Deweloperzy muszą opracowywać umowy podczas testowania, co zwykle zajmuje dużo czasu.

Porozmawiaj z programistami.

Zakładając, że rozwijasz się w sprintach, przeprowadzasz te testy funkcjonalne, jeśli tylko są częścią sprintu. Nie da się tego zrobić bez tych testów. Jeśli go nie masz, czas na testowanie integracji po fazie programowania może się podwoić.

Andreas Huppert
źródło
Zgadzam się, może nie używamy odpowiedniego narzędzia do testowania aplikacji internetowej. Nie ma jednak problemu z testowaniem naszych usług internetowych. W każdym razie, oprócz właściwego lub niewłaściwego sposobu wdrożenia testów, martwię się o koszty. Myślę, że w tym momencie lepiej (pod względem kosztów / korzyści) pozwolić przetestować dział kontroli jakości i naprawić błędy, nawet jeśli zostaną znalezione w produkcji.
Pablo Lascano
Pominąłeś źle zaprojektowane klasy jako potencjalny powód zbyt długiego testowania. Jest to zdecydowanie najczęstszy powód, dla którego widzę, że ludzie nieustannie testują swój kod.
Dunk
4

Czy spędzanie więcej czasu na wdrażaniu testu funkcjonalnego niż wdrażanie samego systemu jest normalne?

Absolutnie. Pisanie naprawdę dobrych testów prawdopodobnie zajmie większość czasu w wielu (dobrych) sklepach.
Tak więc stosunek 2-1 jest w porządku. Sami mniej doświadczeni programiści często nie biorą pod uwagę testów.

Michael Durrant
źródło
2

Istnieje prawo malejących zysków. Zakładając, że najpierw piszesz testy dla najbardziej ryzykownego kodu, wartość generowana przez kolejne testy zmniejsza się z czasem.

Testy jednostkowe są kodem, więc będą zawierać błędy (podobnie jak wszystkie inne kody). Naprawienie tych błędów wymaga czasu.

Z mojego doświadczenia wynika, że ​​testy jednostkowe zawierają znacznie więcej błędów niż testowany system, a ich naprawianie jest ciągłym obciążeniem.


źródło
1

Chodzi o jakość.

Jeśli potrzebujesz zdobyć rynek - rozwiniesz swoją aplikację tak szybko, jak to możliwe. Możesz nawet w ogóle nie mieć automatycznych testów =), ale przekażesz swoją aplikację słuchową przed konkurencją.

Ale jeśli wiesz, że twoje słuchy nie odejdą, zrobisz wszystko, aby ich nie zawieść. Każdy bilet na błąd obniży Twoją reputację. Wyobraź sobie, że jeden błąd usunie 50 procent twojej reputacji, następny - kolejne 25 procent i tak dalej. Czy może być więc zbyt wiele testów?

Nikita U.
źródło
cóż, nie jestem do końca pewien, czy w tym momencie faktycznie ograniczamy bilety. Być może zmniejszyliśmy (ale niewiele) bilety QA, ale odsetek błędów wykrytych w tym teście nie jest wystarczająco duży (z mojego punktu widzenia), aby uzasadnić taki koszt posiadania 2/3 czasu twórców oprogramowania na opracowanie testów funkcjonalnych.
Pablo Lascano
0

Jeśli przez „czy to normalne” pytasz, czy to jest powszechne, nie, z pewnością nie jest. Wiele zespołów programistów ma kiepskie praktyki testowe (należę do jednej), a nawet dobrej jakości książki przeczytałem porady, aby spędzić mniej więcej tyle samo czasu na kodowaniu funkcjonalności niż testy. Jeśli normalnie zapytasz, czy jest zdrowy, to zależy, ale dwa razy więcej testów niż potrzeba jest lepsze niż brak testu.

To nie musi być krytyczne . Kiedy testujesz funkcjonalność, testujesz coś przydatnego dla użytkowników końcowych, a Twoim obowiązkiem jest wiedzieć (a nie zgadywać), że cały czas działa poprawnie. Jeśli potrzebujesz dwa razy więcej na ten cel, należy to zrobić w ten sposób - jeśli to możliwe.

Możliwe też, że twoja polityka jest zbyt rygorystyczna w zakresie testów automatycznych, ale trudno powiedzieć bez wiedzy o jakości, do której dążą, o ich zasobach i do czego jeszcze mogliby je przypisać.

Arthur Havlicek
źródło