Czy testy jednostkowe są opracowywane czy testowane?

24

Rozmawiałem z kierownikiem ds. Testów na temat roli testów jednostkowych i integracyjnych. Poprosiła programistów o zgłoszenie tego, co przetestowali w jednostkach i integracji oraz jak. Moim zdaniem testy jednostkowe i integracyjne są częścią procesu rozwoju, a nie procesu testowania. Poza semantyką mam na myśli to, że testy jednostkowe i integracyjne nie powinny być uwzględniane w raportach z testów, a testerzy systemów nie powinni się nimi przejmować. Moje rozumowanie opiera się na dwóch rzeczach.

  1. Testy jednostkowe i integracyjne są zawsze planowane i przeprowadzane w odniesieniu do interfejsu i umowy. Niezależnie od tego, czy korzystasz ze sformalizowanych umów, nadal testujesz, co np. Ma zrobić metoda, tj. Umowa.

    W testach integracyjnych testujesz interfejs między dwoma odrębnymi modułami. Interfejs i umowa określić, kiedy testy przechodzi. Ale zawsze testujesz ograniczoną część całego systemu. Z drugiej strony testy systemów są planowane i przeprowadzane zgodnie ze specyfikacjami systemu. Specyfikacja określa, kiedy test się powiedzie.

  2. Nie widzę żadnej wartości w przekazywaniu szerokości i głębokości testów jednostkowych i integracyjnych testerowi (systemowemu). Załóżmy, że piszę raport, w którym wyszczególniono, jakie testy jednostkowe są wykonywane na określonej klasie warstw biznesowych. Co on / ona ma od tego zabrać?

    Ocena, co powinno, a czego nie powinno być testowane na podstawie tego, jest fałszywym wnioskiem, ponieważ system może nadal nie działać tak, jak wymagają tego specyfikacje, mimo że wszystkie testy jednostkowe i integracyjne przebiegają pomyślnie.

Może się to wydawać bezużyteczną dyskusją akademicką, ale jeśli pracujesz w ściśle formalnym środowisku, tak jak ja, to tak naprawdę jest to ważne przy określaniu, jak to robimy. W każdym razie, czy całkowicie się mylę?

Rubio
źródło
9
Czy to ma znaczenie?
yannis
5
@YannisRizos Z tytułu nr. Z całego pytania, na pewno wydaje się tak dla osoby pytającej
Ludwig Magnusson,
2
@ Rubio Z twojego pytania zgadzam się, że raporty z testów jednostkowych są bezużyteczne dla testera systemu. Testy jednostkowe są pomocnym narzędziem dla programisty. W jaki sposób kierownik ds. Testów motywuje potrzebę tych raportów?
Ludwig Magnusson,
2
@LudwigMagnusson Prawda, ale jeśli ma to znaczenie tylko dla osoby pytającej, jest to zbyt zlokalizowane.
yannis
5
programiści zgłaszający się do kierownika testów są w błędzie, bez względu na wszystko. Gdyby przekazała tę prośbę za pośrednictwem ( menedżera deweloperów ), musiałbyś po prostu zrobić to, co powiedział ci szef. „Porozmawiaj z moim menadżerem” to broń, którą musisz wiedzieć, jak używać w „ściśle formalnym środowisku”, jak Twoja
komnata

Odpowiedzi:

30

Pisanie testów automatycznych jest zadaniem programisty; testy są częścią bazy kodu i powinny być traktowane jako takie - powinny podlegać takim samym przeglądom kodu, standardom kodowania, dyscyplinie kontroli źródła itp., jak reszta projektu.

Przeprowadzanie wspomnianych testów odbywa się z dwóch powodów: Po pierwsze, jako narzędzie do prowadzenia programistów. Przeprowadzasz testy, aby sprawdzić, czy właśnie napisany kod działa zgodnie z jego przeznaczeniem, używasz go jako dodatkowej dokumentacji i upewniasz się, że zmiany nie psują żadnej istniejącej funkcjonalności. Jeśli wykonujesz prawdziwy TDD, testy są również wiarygodnym źródłem specyfikacji technicznych. Drugim powodem korzystania z testów jest kontrola jakości i wdrożenie. Uruchomienie wszystkich automatycznych testów powinno być jednym z pierwszych kroków w każdej rundzie testów; uruchamianie testów automatycznych jest tanie (praktycznie nie wymaga siły roboczej) i nie ma sensu wchodzić w testy ręczne, jeśli testy automatyczne zawodzą.

Oznacza to, że obowiązki powinny wyglądać następująco:

  • Programiści piszą testy automatyczne
  • W razie potrzeby programiści przeprowadzają indywidualne testy automatyczne w ramach przepływu pracy programistycznej
  • QA uruchamia wszystkie automatyczne testy jako jeden z pierwszych etapów testowania

Jeśli masz serwer kompilacji, zadanie QA (dotyczące testów automatycznych) sprowadza się do „otwarcia raportu serwera kompilacji i sprawdzenia, czy wszystko jest zielone”.

tdammers
źródło
Doskonały post, dokładnie tak, jak zamierzałem zamieścić. Tylko Qualm zbyt mocno polega na testach jednostkowych, a testy integracyjne mogą prowadzić do problemów na dalszych etapach. Nie zgadzam się z faktem, że zadanie QA sprowadza się do sprawdzenia serwera kompilacji (zakładam, że masz na myśli coś takiego jak Hudson). Nakłada to cały ciężar testowania na programistów, aby cały czas pisali testy obejmujące CAŁĄ logikę biznesową, co wydaje się nadmiernie obciążać programistów.
dardo
4
@dardo: Oczywiście testy automatyczne nie są jedynymi testami, które powinieneś uruchomić, w przeciwnym razie możesz po prostu całkowicie pozbyć się kontroli jakości. To byłoby absurdalne - wiele bardzo istotnych aspektów jakiegokolwiek oprogramowania nie może być automatycznie testowanych. Mam na myśli to, że biorąc pod uwagę istnienie automatycznych testów, QA nie powinna się o nie martwić poza sprawdzaniem wyników serwera kompilacji; potem robią swoje normalne czynności - ręczne i półautomatyczne testowanie ukończonej kompilacji.
tdammers
Ach tak, zgadzam się w 100%
Coś
@tdammers - Testowanie to tylko niewielka część zapewniania jakości.
Matthew Flynn
2
Doskonała odpowiedź, jednak nie zgadzam się, że testy powinny być postrzegane jako an authoritative source of technical specifications. Testy powinny być potwierdzeniem specyfikacji, ale na pewno nie zamiennikiem. Nie oznacza to również, że opowiadam się za dużą specyfikacją z góry, ale raczej robię rozróżnienie, że stosujemy testy, aby zweryfikować rzeczy, które wiemy o sposobie, w jaki system powinien się zachowywać, zamiast mieć testy określają zachowanie. Może pedantyczne rozróżnienie, ale jednak ważne.
S.Robins
10

Myślę, że najważniejsze dla ciebie byłoby wyjaśnienie, dlaczego potrzebuje tego raportu.

Mogą istnieć różne wyjaśnienia (jak sugeruje kilka odpowiedzi), które wymagają bardzo różnych strategii.

  • jeśli jest rozsądną osobą, która po prostu chce uzyskać informacje pomocne w pracy zespołu testującego, warto dojść do porozumienia i wypracować rozwiązanie, które byłoby odpowiednie dla was obojga. Możesz omówić z nią naturę testów jednostkowych i podstawową różnicę między testami jednostkowymi a funkcjonalnymi / systemowymi / akceptacyjnymi. Mamy nadzieję, że zrozumiesz, że działają one na bardzo różnych poziomach i żaden z nich nie może zastąpić drugiego.
  • jeśli jest maniakiem kontroli lub biurokratą, domagającym się jedynie raportu, możesz wygenerować coś, co zaspokoi jej zachcianki przy najmniejszym wysiłku (np. co sugerował @Doc :-).
  • jeśli interesuje ją gra o władzę, możesz zapytać, czy ma prawo żądać raportów od programistów. Z mojego doświadczenia wynika, że ​​programiści zwykle nie powinni zgłaszać się do działu kontroli jakości.
Péter Török
źródło
Słuszne uwagi. Wydaje się być rozsądną osobą. Obawiam się, czego nie wyjaśniłem jasno, że testy jednostkowe prowadzą testerów w złym kierunku i fałszywe bezpieczeństwo w zakresie tego, czego potrzebują i czego nie potrzebują.
Rubio
2
@ Rubio, powinieneś wyjaśnić jej, że testy jednostkowe nie mogą zastąpić testów systemowych. W rzeczywistości wysoki zasięg testu jednostkowego określonego modułu może być nawet sygnałem ostrzegawczym, że moduł ten wymaga dodatkowej uwagi podczas testowania systemu! Jeśli programiści podjęli dodatkowy wysiłek, aby napisać tak wiele testów, kod mógł zostać ostatnio drastycznie zmieniony / rozszerzony i / lub jest pełen błędów.
Péter Török
7

Myślę, że rola kontroli jakości i rozwoju oraz wzajemne oddziaływanie mogą się bardzo różnić w zależności od organizacji. Ogólnie rzecz biorąc, w moim zespole mówię dołączającym się członkom, aby udawali, że nie ma zespołu zapewniania jakości, w tym sensie, że są odpowiedzialni za zmiany, które wprowadzają do produkcji. Z kolei nasz zespół ds. Kontroli jakości nie zakłada wiele o testowaniu przez programistów i wykonuje sporo testów systemu jako funkcjonalnej całości.

Z tego powodu nasz zespół ds. Kontroli jakości nie dba o to, co jest i nie jest testowany jednostkowo przed rozpoczęciem testów.

Wydaje mi się, że zespół QA powinien wiedzieć, co robią testy jednostkowe i nie obejmują ich na wysokim poziomie, abyśmy mogli wspólnie pracować nad identyfikacją luk i obszarów, które mogą wymagać większej dyscypliny. Więc może twój kolega szuka podsumowania na wysokim poziomie, w przeciwieństwie do krwawych szczegółów.

Paul Sanwald
źródło
5

Nalegała, aby deweloperzy informowali o testach jednostkowych i integracyjnych oraz o tym, w jaki sposób.

Czy ona naprawdę próbuje spierać się o to, czy tego rodzaju testowanie jest rzeczywiście w dziedzinie „rozwoju”, czy po prostu próbuje dowiedzieć się, jak dobrze twój kod jest objęty testowaniem jednostkowym? Patrząc na podane przez Ciebie informacje, wygląda na to, że chce wiedzieć, które części kodu są objęte i na czym powinna skupić wysiłek swojego zespołu.

Pracowałem w zespole testowym zaraz po szkole, zanim przeniosłem się do roli programisty i widzę, jak może to być cenne dla niej i jej zespołu.

Jason
źródło
1
Ale czy nie powinno się skupiać na specyfikacjach? Zdarzają się sytuacje, w których zmiany kodu mają nieoczekiwane konsekwencje, a następnie bardzo ważne jest, aby deweloper poinformował, że testy powinny obejmować to i to.
Rubio
1
@Rubio: Oczywiście, ale z czysto praktycznego punktu widzenia, spróbuj spojrzeć na to z jej perspektywy. Zakładając, że wszystkie części aplikacji nie będą miały idealnie równych ilości kodu objętego testami jednostkowymi, czy nie chciałbyś przeznaczyć więcej swoich ograniczonych zasobów na części aplikacji o mniejszym zasięgu? Dla mnie to po prostu kwestia spojrzenia na raport i powiedzenia mojemu zespołowi: „Hej, wygląda na to, że obszar X ma mniej kodu objętego testami niż obszar Y, spróbujmy skupić się na przeprowadzeniu testów na obszarze X”
Jason
@ Rubio: tak, ale jeśli robisz TDD (tj. BDD), to twoje testy powinny być przede wszystkim zgodne ze specyfikacjami. Jeśli Twoja firma była naprawdę oświecona, zespół testowy mógłby napisać testy dla zespołu programistów.
gbjbaanb
2
Co jest testowane: automatycznie generowany raport pokrycia kodu. Jak to jest testowane: przeczytaj kod testu jednostkowego. @gbjbaanb: „zespół testowy mógłby napisać testy dla zespołu programistów”. Jest tak wiele rzeczy złych w tym stwierdzeniu, że nie wiem od czego zacząć, oprócz powiedzenia: bardzo zły pomysł .
BryanH
5

Nie widzę, żeby to miało zbyt duże znaczenie.

Jeśli nie dostarczysz ich do kontroli jakości / testowania, a oni nie wykonają odpowiednich testów i nie powiedzie się to w produkcji, to ich wina polega na tym, że dopuszczają ją przez kontrolę jakości do produkcji bez sprawdzenia, czy działa ona zgodnie ze specyfikacją.

Jeśli dostarczysz je do kontroli jakości / testów, a oni nie wykonają odpowiednich testów ... taki sam wynik, jakbyś ich nie dostarczył.

Jednak jeśli je dostarczysz, mogą porównać je również ze specyfikacją i / lub zasugerować, które testy mogą być wadliwe lub wymagają zmiany, ponieważ znaleźli błąd.

Naprawdę, nie widzę w nich wiele wad. Nadal trwa kontrola jakości / testowanie w celu sprawdzenia zgodności ze specyfikacją. Jeśli pójdą leniwie i polegają tylko na tym, że twoje testy są wystarczająco dobre, ponieważ wszyscy zdali, to oni zawiedli w swojej pracy. Tak długo, jak nadal mają specyfikację, wyniki testów jednostkowych / integracyjnych są po prostu puchate i nie powinny cię zranić w taki czy inny sposób. To jest powód, dla którego mamy dev i QA. Wiele kontroli, które aplikacja wykonuje zgodnie z opisem.

Deweloperzy popełniają błędy, QA popełnia błędy, najlepiej nie obaj popełniają błąd w tym samym przedmiocie ... a jeśli popełniają ... to potencjalnie analityk upuścił piłkę, pisząc niejasną specyfikację.

CaffGeek
źródło
2
Minusem jest dla mnie dodatkowa praca, która nie zapewnia żadnej wartości lub ma niewielką wartość.
Rubio
@ Rubio, jaka dodatkowa praca? Po prostu wydrukuj wynik. Jeśli są dobrze nazwane, mówi im, co testujesz. Nie powinien potrzebować rzeczywistego kodu ani opisu sposobu działania metody. Jeśli to zrobią, sami mogą to sprawdzić.
CaffGeek
1
Wygenerowanie raportu z 3500 testów jednostek / integracji, które pomyślnie przeszły, byłby prawdopodobnie mało pomocny dla testera, nawet gdyby testy były dobrze nazwane (które powinny być, ale nie są). Aby dostarczyć testerom znaczących informacji o teście jednostkowym, deweloper musiałby przekopać test jednostkowy związany z określoną funkcją i w jakiś sposób przekazać testerowi, co jest faktycznie testowane i jak to potwierdzone. To dużo pracy.
Rubio
1
@ Rubio - automatyzacja jest twoim przyjacielem. Możesz skonfigurować serwer ciągłej integracji, który wysyła raporty pocztą e-mail za każdym razem, gdy następuje zameldowanie (to również pomoże). Jeśli QA prosi o wyjaśnienie testów i kodu, brzmi to tak, jakby przekroczyły poziom racjonalności i wkroczyły w sferę „nie pojmowania pojęcia”. Jeśli nie mogą lub nie chcą czytać kodu, są bezużyteczne. W tym momencie czat z menedżerem byłby korzystny i możesz go ułożyć w następujący sposób: „Kontrola jakości chce, żebym spędził x% mojego czasu na pomaganiu w czytaniu kodu, czy to w porządku?”
BryanH
1
+1 za stwierdzenie, że nie zwalnia to QA z odpowiedzialności za niezależne testowanie oprogramowania.
2

Za testowanie jednostkowe programiści odpowiadają, że testy mogą być przydatne do zrozumienia, w jaki sposób fragmenty kodu działają samodzielnie. Niektórzy mogą postrzegać to jako formę dokumentacji i dlatego mają pewną wartość, chociaż mogą wystąpić koszty ogólne, jeśli testy jednostkowe są regularnie zmieniane.

Inną wartością przy pomijaniu testów jest to, że pozwala to uniknąć podwojenia liczby testów, które mogą być zbędne pod względem zapewnienia podstawowej funkcjonalności.

Istnieją również testy akceptacji użytkownika, które są odrębne od tego wszystkiego, ponieważ użytkownik końcowy może mieć własną wiedzę na temat funkcjonowania systemu.

JB King
źródło
1
Testy redundantne są często używane jako argument i czasami mogą być prawdziwe. Jednak testy systemu są zawsze przeprowadzane na całym systemie, podczas gdy testy jednostek / integracji koncentrują się na konkretnej jednostce. Widzę tutaj niebezpieczeństwo.
Rubio
2

Jeśli Twoja firma ma określoną metodologię zapewniania jakości swoich produktów (jeśli są one zgodne z SOX lub próbują poprawić swój poziom CMMI, prawdopodobnie tak), to produkty muszą być w stanie wstać przed audytem, ​​aby pokazać, że proces był śledzony.

Często zdefiniowany proces obejmuje testowanie jednostkowe (co jest dobrą rzeczą). Niestety oznacza to również, że musisz udokumentować swoje testy jednostkowe i udowodnić, że zostały przeprowadzone w celu wzięcia udziału w audycie. Oznacza to, że potrzebujesz sposobu na raportowanie z testów jednostkowych.

Spójrz na narzędzie takie jak Sonar, które ci pomoże - poda poziom pokrycia kodu i wyniki testów jednostkowych.

Matthew Flynn
źródło
SOX nie, CMMI tak. Nasze testy jednostkowe / integracyjne są częścią procesu sprawdzania kodu i to nie przeszkadza w audycie. Mogę uzyskać wygenerowany raport z testu jednostkowego / integracji, ale dla testera jest to dość tajemnicze. Raport znajduje się również w raporcie, ale to samo w sobie nic nie znaczy.
Rubio
Po pierwsze, nie podawaj swoim testom tajemniczych nazw. Sprawdź dannorth.net/introducing-bdd . Po drugie, pokrycie kodu może nie mówić wiele o jakości testów, ale przynajmniej pokazuje, że testowane jednostki nie wybuchają, gdy większość kodu jest uruchomiona.
Matthew Flynn
Dobry link, dzięki. Pamiętam, jak przeczytałem doskonały artykuł w czasopiśmie eksplorujący różne sposoby nazwania testów jednostkowych, ale nie mogę go teraz znaleźć na śmierć. Może być Magazyn Visual Studio lub Code Magazine.
Rubio
2

To naprawdę zależy od firmy, ale z mojego doświadczenia pracowałem zarówno jako tester systemu w tradycyjnym podejściu, ale także jako tester pracujący w zwinnym zespole w modelu CD, wiedza o tym, co zostało przetestowane w jednostce i integracji jest niezwykle przydatna.

Za jakość odpowiada zespół - zarówno programiści, testerzy, jak i dział zarządzania produktem, a współpraca to najlepszy sposób, aby to zapewnić.

Menedżer testów chce wiedzieć, co zostało przetestowane pod kątem integracji i integracji, i jest to trochę więcej pracy dla programistów, ale oszczędza to całą pracę nad projektem! Przekazując informacje kierownikowi testów, mogą skoncentrować wysiłki swojego zespołu testowego na tym, co kluczowe i ważne. Jak wspomniano wcześniej, jeśli obszar kodu nie jest testowany jednostkowo, zespół może skoncentrować swój wysiłek na tym w porównaniu z obszarem, który jest mocno przetestowany - po co powielać wysiłek? Wszyscy dążycie do tego samego ostatecznego celu, jakim jest oprogramowanie wyższej jakości wydane na czas.

Lauren
źródło
1

Sądzę, że dobrze byłoby zapewnić tego rodzaju rzeczy. Zakres testów jednostkowych powinien być czymś znanym z opracowywania i testowania, aby mogli to wyjaśnić.

Oczywiście, bez względu na wszystko, musisz przetestować najważniejsze rzeczy biznesowe. Musisz mocno przetestować powszechnie używaną funkcjonalność, niezależnie od tego, czy ma ona doskonałe pokrycie testem jednostkowym. Nie mogło zaszkodzić poinformowanie ich, jakie inne miejsca są objęte testami jednostkowymi. Czy kod już sprawdza występujące przypadki krawędzi w tej jednej małej kontrolce? Tego rodzaju rzeczy są przydatne ze wszystkich stron firmy.

Chad Stewart
źródło
Już miałem napisać podobną odpowiedź. Chociaż testowanie jednostkowe powinno należeć do domeny twórcy oprogramowania, przekazanie zespołowi testującemu poczucia pokrycia kodu może pomóc zespołowi testującemu w zrozumieniu i ukierunkowaniu określonych obszarów, które mogą wymagać większej uwagi ze strony testerów. Może to być również sposób na utrzymanie deweloperów w grze pod kątem zapewnienia, że ​​uwzględniają tyle przypadków, ile jest to opłacalne. Umożliwia to zespołowi testującemu nie tylko sprawdzenie poprawności całego systemu, ale także rozliczenie wszystkich rzeczy, które w innym przypadku mogłyby być postrzegane jako kosztowne do przetestowania.
S.Robins
1

Warto wspomnieć o podejściu omówionym w książce „Jak Google testuje oprogramowanie”: Testowanie i kontrola jakości spoczywa na wszystkich, a standardy są rygorystyczne.

Prawdziwa rola tego, co tradycyjnie nazywa się „Testowanie” dział, w rzeczywistości jest produktywność dewelopera; tj. automatyzacja, aby umożliwić organizacji osiągnięcie wymaganego poziomu dyscypliny ekonomicznie.

William Payne
źródło