Czy programiści powinni być odpowiedzialni za testy inne niż testy jednostkowe, jeśli tak, które z nich są najczęstsze?

Obecnie pracuję nad dość dużym projektem i użyłem JUnit i EasyMock do dość obszernej funkcjonalności testów jednostkowych. Teraz jestem zainteresowany innymi rodzajami testów, o które powinienem się martwić. Czy jako programista mam obowiązek martwić się o takie testy funkcjonalne czy regresyjne? Czy istnieje dobry sposób na zintegrowanie ich w użyteczny sposób z narzędziami takimi jak Maven / Ant / Gradle? Czy lepiej nadają się do testera lub licencjata? Czy brakuje innych przydatnych rodzajów testów?

Twoim obowiązkiem jest dostarczenie kodu wolnego od wad. Powinieneś pisać, pomagać w pisaniu lub upewnić się, że testy zostały napisane lub przeprowadzone, abyś miał pewność co do dostarczanego kodu.

Uwaga: nie mówię, że musisz dostarczyć kod bez wad. Zamiast tego powinieneś spróbować napisać najlepszy możliwy kod dla podanych wymagań. Częściowo jest to możliwe, że kod powinien zostać przetestowany.

To, czy oznacza to, że jesteś osobiście odpowiedzialny za testy funkcjonalne i regresyjne, zależy głównie od organizacji Twojej firmy. Wszyscy najwyżej wykwalifikowani programiści, których znam, nie zadają sobie pytania „czy to mój obowiązek pisać testy typu X?”. Zamiast tego zadają sobie pytanie: „co muszę zrobić, aby upewnić się, że mój kod jest odpowiednio przetestowany?”. Odpowiedzią może być napisanie testów jednostkowych lub dodanie testów do regresji, lub może to oznaczać rozmowę z specjalistą ds. Kontroli jakości i pomóc im zrozumieć, jakie testy należy napisać. Jednak we wszystkich przypadkach oznacza to, że dbają wystarczająco o kod, który piszą, aby upewnić się, że jest odpowiednio przetestowany.

Podsumowując: powinieneś być odpowiedzialny za dostarczanie wysokiej jakości kodu. Jeśli to oznacza, że ​​musisz napisać testy funkcjonalne lub regresyjne, zrób to.

To może ci pomóc:

Q1 zostały napisane przez programistów.

Q2 są zautomatyzowane przez programistów i napisane we współpracy z firmą i / lub testerami.

Czy brakuje innych przydatnych rodzajów testów?

Istnieją testy akceptacyjne, dla których polecam frameworki w stylu BDD, które używają języka korniszonu : JBehave (Java), Cucumber (Ruby), Behat (PHP) itp. Ten typ testowania ma pewne zalety w porównaniu z testami jednostkowymi:

• Testy są łatwo czytelne dla programistów, dzięki czemu można je pokazać klientom
• Testy jasno opisują procesy biznesowe bez wchodzenia w szczegóły implementacji (nie mam na myśli, że implementacja nie jest ważna - na pewno jest - ale lepiej, gdy oddzielisz wymagania biznesowe od samego kodu)
• Testy wykonują czynności wykonywane przez użytkowników za pomocą Twojej aplikacji
• Łatwiej je pisać (IMHO, może zależeć od języka i frameworka): bez szyderstw, mniej szczegółów technicznych

Test funkcjonalny można zautomatyzować podobnie jak testy jednostkowe i są one bardzo przydatne do testowania współpracy różnych elementów projektu oraz tego, jak dobrze twój system odzwierciedla reguły biznesowe.

Ten automatyczny test służy również jako zestaw testów regresji i akceptacji dla wszelkich poważnych (lub drobnych) zmian, które musisz zrobić w oprogramowaniu (naprawa błędu, refaktoryzacja, zmiana biznesowa, nowa funkcjonalność itp.). Daje to deweloperom o wiele więcej pewności.

Istnieje kilka ram dla tego rodzaju testów, używamy fitnesse z bardzo dobrymi wynikami. Ma bardzo dobrą bibliotekę do testowania stron internetowych (używamy jej do testowania naszej aplikacji internetowej i naszych usług sieciowych) i bardzo dobrze integruje się z Maven i Jenkins .

Kiedyś też przeprowadzaliśmy „testowanie międzyfunkcyjne” między programistami, ale ten rodzaj testowania nie jest „powtarzalny”, więc jego użyteczność jest ograniczona ...

Jako programista uważam się za odpowiedzialnego za testowanie całego kodu i gwarantuję, że nie ma wad. Dlatego mamy do dyspozycji tak wiele narzędzi, jak kpiny. Celem tworzenia szydzących obiektów w testach jest właśnie próba odizolowania kodu od świata „zewnętrznego” i zagwarantowania, że ​​działa dobrze, a jeśli coś zawiedzie, „to nie twoja wina”.

To powiedziawszy, pomimo faktu, że to nie twoja wina i że Twój kod działa tak, jak powinien, nie oznacza to, że nie możesz pomóc w pozostałych testach. Uważam, że Twoim obowiązkiem jest również pomóc i zintegrować swoją pracę z pracą wykonaną przez innych. Zespoły programistów powinny za każdym razem pracować jako dobrze naoliwiona maszyna, współpracując z innymi działami (np. QA) jako większy zespół, aby zapewnić niezawodne oprogramowanie.

Ale to praca zespołu, nie tylko twojego.

Oczywiście testy integracyjne ; są ważniejsze i trudniejsze do napisania niż testy jednostkowe. To jest jak budowanie domu; dzięki testom jednostkowym upewniasz się tylko, że cegły są solidne i są odporne na ciśnienie, temperaturę, wilgotność i inne warunki. Ale nie masz pojęcia, jak wygląda i zachowuje się dom z połączonymi cegłami.

Problemem w dużych projektach, zwłaszcza w Javie rezydujących w kontenerze, jest to, że testowanie integracji jest trudne. Aby ułatwić testy integracji systemu w dużych projektach, potrzebna jest platforma testowa, stworzona specjalnie dla projektu, który jest zadaniem programisty do jej kodowania. Ostatnio dokonano wielkich ulepszeń w tej dziedzinie, a platformy takie jak Arquillian znacznie upraszczają pisanie frameworka testowego (a nawet go zastępuje).

W prawdziwym świecie jesteś tylko tak odpowiedzialny, jak twój zespół / szef pociąga cię do odpowiedzialności. Jeśli otrzymujesz wynagrodzenie lub zobowiązanie do niekończącego się trudu, aby znaleźć każdy zakątek i zakręcony brzeg i przejść do kaprysu interpretacji błędów logiki biznesowej przez twojego szefa (lub gorzej marketing), to za wszystko jesteś odpowiedzialny za wszystkich.

Innymi słowy, rób to, co jest wymagane przez podany zakres. Dobrze jest rzucić w jakimś zdrowym rozsądku lub zobaczyć, jak inni używają produktu, który budujesz, aby uzyskać poczucie przypadków użycia i możliwych problemów do rozwiązania, ale zwróć to swojemu zespołowi lub szefowi przed „naprawieniem”. Obejmuje to wybrane narzędzia. Wszystkie twoje wysiłki powinny być czymś, co wszyscy są na pokładzie.

Jeśli twoje pytanie dotyczy przydatnego śledzenia błędów, podoba mi się Bugzilla, Dokumenty Google, Zendesk lub BaseCamp pod względem systemów komunikacji.

Nie sądzę, że to już zostało omówione - przepraszam, jeśli przegapiłem.

Jednym z problemów jest efektywne wykorzystanie czasu programisty.

Deweloperom często brakuje umiejętności, aby być dobrym w niektórych rodzajach testów. Częściowo jest to po prostu naturalne. Z tego samego powodu autorzy mają redaktorów. Bardzo trudno jest dostrzec braki w czymś, jeśli jesteś zbyt blisko tego. Ale dotyczy to także różnych zestawów umiejętności i różnych specjalizacji.

W takim przypadku testowanie czasu przez programistę jest kiepskie pod względem kosztów: korzyści. Ten programista byłby bardziej produktywny, robiąc inne rzeczy, a specjalistyczny tester byłby bardziej produktywny podczas testowania.

Oczywiście przyjmuje to różne założenia, które niekoniecznie są ważne. Na przykład w małej firmie zatrudnianie osób specjalizujących się w testowaniu może nie mieć sensu. Chociaż bardziej sensowne może być zatrudnienie dodatkowego personelu pomocniczego i zlecenie mu przeprowadzenia testów, a przynajmniej zlecenie testowania kodu, którego sami nie napisali.

Uważam, że naszym obowiązkiem (także programistycznym) jest uwzględnienie wszystkich możliwych scenariuszy testowych przed wydaniem do kontroli jakości. Celem kontroli jakości jest sprawdzenie oprogramowania. Co więcej, wbicie własnego kodu pod kątem błędów zawsze sprawi, że będziesz dobrze wyglądać w czasie kontroli jakości.

Kto lepiej niż programista wie, które przypadki testowe są najbardziej odpowiednie. Deweloper powinien być odpowiedzialny za wykonanie wszystkich testów jednostkowych, w miarę możliwości powinien pomóc napisać i wykonać skrypty testowe. Ponieważ rzadko jest to możliwe w dużych projektach, deweloper powinien poświęcić czas na sprawdzenie wszystkich przypadków testowych. Ponadto programista powinien posiadać wiedzę i korzystać z szerokiej gamy dostępnych automatycznych narzędzi testowych.

W mojej karierze programistycznej stwierdzam, że projekty kończą się lepszymi wynikami, jeśli istnieje ścisła integracja między zespołami programistycznymi i zespołami testowymi.

przynajmniej jeden członek z każdego zespołu powinien zasiadać w pozostałych spotkaniach dotyczących planowania i wdrażania.