Czy testy jednostkowe są opracowywane czy testowane?

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ę?

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

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.

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.

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.

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

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.

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.

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.

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.

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.