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

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.

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.

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

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.

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.

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?

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