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