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.
źródło
Odpowiedzi:
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.
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.
źródło
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ć.
źródło
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.
źródło
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
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?
źródło
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ć.
źródło