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

35

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?

Jackie
źródło
2
Choć w praktyce jest to uproszczone, skaluj na zewnątrz, na ile pozwala na to środowisko, zachowując konwersację w praktyce w porównaniu z izolowanym, co zwykle istnieje. Pomyśl o zespole od końca do końca jako o czymś więcej niż segregacja i więcej o zestawie umiejętności, każda drużyna reprezentuje zróżnicowany zestaw umiejętności, który należy wykorzystać, aby osiągnąć sukces od końca do końca. Zespół powinien być odpowiedzialny za sukces których potrzebne są testy do osiągnięcia. Sposób, w jaki rozwiązuje się je w zakresie wdrażania, jest po prostu szczegółem wdrożenia opartym na zestawie umiejętności.
Aaron McIver,
1
Odpowiedź na to pytanie będzie zależeć również od poziomu umiejętności pozostałych członków zespołu. Na przykład w zespole, w którym QA nie ma silnych umiejętności programistycznych, programiści mogą znaleźć więcej niż w zespole, w którym QA może pisać własne uprzęże testowe.
neontapir,
Dobrym kryterium jest automatyzacja testów. Programiści potrafią automatyzować rzeczy za pomocą kodu.
rwong

Odpowiedzi:

44

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.

Bryan Oakley
źródło
Z całego serca zgadzam się z dostarczeniem wysokiej jakości części kodu. Miałem na myśli raczej dobry kod „ponad i poza”. Na przykład, czy zmiany, które są uważane za „wolne od błędów” w twojej perspektywie, mają negatywny wpływ na inne obszary. Najlepszy przykład, jaki mogę wymyślić, to to, że wymaganie nie zostało właściwie sprawdzone pod kątem obciążenia. Więc mój kod powoduje problemy z ładowaniem na serwerze, mimo że jest „wolny od błędów” (ok, więc można argumentować, że nie jest to tylko humor). PS Myślę, że twoja część zaufania jest tutaj kluczowa.
Jackie,
10
Twoim obowiązkiem jest dostarczenie kodu wolnego od wad. Deweloper jest odpowiedzialny za zbudowanie tego, o co poproszono . Wady mogą wynikać z wymagań źle zebranych / zinterpretowanych, problemów środowiskowych w danym wdrożeniu, konfliktów w systemie operacyjnym itp. O ile nie zostanie przeprowadzona analiza przyczyn źródłowych dla każdej wady, kod wolny od wad w firmie oznacza, że oczekują robić to, czego oczekuje użytkownik, a cokolwiek mniej jest wadą. Nierealistyczne jest zakładanie, że programista może pozostać zaangażowany przez cały SDLC, aby po prostu zwiększyć zaufanie; to się nie skaluje.
Aaron McIver,
2
„Testowanie programów może być bardzo skutecznym sposobem na wykazanie obecności błędów, ale jest beznadziejnie nieodpowiednie do wykazania ich nieobecności”. - Edsger W. Dijkstra, „The Humble Programmer” (wykład Turinga), 1972.
John R. Strohm,
1
„Twoim obowiązkiem jest dostarczenie kodu wolnego od wad”. to kraina wróżek. Możesz dostarczyć to, czego wymaga zakres, ale wyjątkowe przypadki i interpretacje logiki biznesowej uniemożliwiają spełnienie twojego oświadczenia. Jak myślisz, dlaczego każda ważna wersja oprogramowania zawiera wydania i poprawki itp.? Ponieważ wszyscy jesteśmy niedoskonali, w tym logika biznesowa.
Jason Sebring,
4
Czy każdy, kto kwestionuje pierwsze zdanie tej odpowiedzi, byłby szczęśliwszy, gdyby Bryan sformułował ją „Twoim celem jest dostarczenie kodu wolnego od wad”?
Carson63000,
13

To może ci pomóc:

Zwinne kwadraty testowe

Q1 zostały napisane przez programistów.

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

kod kreskowy
źródło
Programiści często biorą również udział w testowaniu w czwartym kwartale.
neontapir,
Nie można już znaleźć połączonego pliku.
Dušan Rychnovský
3

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
scriptin
źródło
3

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

Pablo Lascano
źródło
2

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.

nunomvbarreiro
źródło
1

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

m3th0dman
źródło
1

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.

Jason Sebring
źródło
1

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.

Steve314
źródło
0

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.

Honus Wagner
źródło
Myślę, że staram się osiągnąć to, co jest uważane za skuteczne „uderzenie młotem”.
Jackie,
To zdecydowanie subiektywne. Powiedziałbym, że każdy rodzaj testu dotyczy twojego projektu (oczywiście nie wszystkie typy testów dotyczą wszystkich projektów). Oto porządna lista: softwaretestinghelp.com/types-of-software-testing . To, co robisz sam i co chcesz zrezygnować, zależy oczywiście od twojego czasu, zasobów i umiejętności. Na przykład może nie być możliwe przeprowadzenie testu akceptacji, ponieważ istnieją pewne reguły, których przestrzegał tylko użytkownik. Krótko mówiąc, zrób wszystko, co możliwe w danym czasie.
Honus Wagner,
W moich projektach, które są w większości sieciowe, zazwyczaj staram się objąć jednostkę, funkcjonalność, użyteczność, regresję, wydajność bez względu na wszystko. Jeśli mam czas, wybieram White Box, Stres, Kompatybilność, a nawet Akceptację, jeśli wiem wystarczająco dużo. Mój ogólny styl kodowania jest bardzo nastawiony na wydajność, dlatego obniżam swój priorytet. Nic z tego nie oznacza, że ​​QA nie znajdzie czegoś złego w żadnym z tych typów testów, oznacza tylko, że znajdzie mniej i ułatwi znacznie drugą rundę.
Honus Wagner,
0

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.

Michelle Cannon
źródło
1
Jedyny problem, jaki mam z tym, to to, że powinna istnieć pewna izolacja między programistami a zespołem testującym, w przeciwnym razie zespół testujący zostanie skażony opinią programisty na temat „kodu działa”. Kontrola jakości i programiści mają przeciwne cele; programista stara się, aby działał, podczas gdy zespół kontroli jakości próbuje go zepsuć, a programista nie zawsze ma najlepsze spojrzenie na trafność testu.
Robert Harvey,
Nie zgadzam się w stu procentach, ale potem znowu jestem zaangażowany w aplikacje mobilne i myślę, że wymagają one poziomu integracji nieco przekraczającego to, co tradycyjne. Uwaga Używam terminu integracja. może istnieć izolacja, ale oba zespoły powinny dokonać przeglądu i przyczynić się do przypadków testowych. Jest mało prawdopodobne, że programiści mieliby dostęp do wszystkich wymaganych zasobów testowych w celu przeprowadzenia właściwego testowania, jest również mało prawdopodobne, aby testerzy mieli wiedzę do opracowania przypadków testowych dla czegoś tak zaawansowanego jak przesyłanie strumieniowe wideo przez sieci komórkowe. za dużo izolacji = kłopot.
Michelle Cannon,
ponadto myślę, że im bardziej pionowy jest rynek i im bardziej wyspecjalizowany, potrzebna jest większa integracja między zespołami. właściwie każdy powinien przejść do fazy testowej z założeniem, że kod działa w niektórych testowanych warunkach, ale jest bardziej prawdopodobne, że jest wadliwy
Michelle Cannon
Wydaje się, że to działa, zespół testowy tworzy dokument przypadku użycia na podstawie specyfikacji funkcjonalnej. Zespół programistów przegląda dokumentację przypadku na podstawie specyfikacji technicznych i funkcjonalnych i dodaje przypadki w razie potrzeby. Zespół testowy opracowuje scenariusze testowe na podstawie przypadków użycia. Przypadki testowe przeglądu testów rozwojowych. Czasochłonne, ale lepsze niż testowanie później na etapie wdrażania lub produkcji.
Michelle Cannon,