Czy testy oprogramowania są faktycznie przeprowadzane na profesjonalnych projektach?

25

Brałem udział w wielu projektach w kilku firmach, ponieważ od dłuższego czasu jestem programistą i wykonawcą.

Szacuję, że mniej niż 20% projektów jest testowanych metodycznie. Przez testowane metodycznie mam na myśli wszelkie testy poza testowaniem ad hoc bez planu.

Szacuję również, że mniej niż 10% projektów jest dokładnie testowanych metodycznie, w których mają dedykowanych testerów jako część zespołu, dokument planu testów, w którym programiści piszą testy automatyczne, a następnie śledzą zasięg testów i mierzą wyniki.

Dwa pytania

  1. Jakie są twoje procentowe szacunki dotyczące tego problemu?
  2. Jakie masz doświadczenie zawodowe w testowaniu oprogramowania?

Uwaga dodatkowa

Ponieważ metodyczne pytanie testowe może uzyskać dość stronnicze odpowiedzi (ludzie lubią się chwalić, że są lepsi od innych), zachęcam innych programistów (tych, którzy nie są narażeni na testowanie metodyczne) również do udzielenia odpowiedzi, ponieważ w przeciwnym razie wyglądałoby to na testowanie robione wszędzie ... z wyjątkiem twojej firmy.

Robert Koritnik
źródło
Świetne pytanie, dziękuję za poświęcenie czasu na przeformułowanie!
@Mark Trapp: Dzięki. Myślę, że to dość proste, ale mogę zadać jeszcze kilka (w oparciu o poprzedni zestaw pytań)
Robert Koritnik

Odpowiedzi:

8

Wzorzec, który widziałem podczas testowania w trakcie mojej kariery zawodowej, wykazuje silną zgodność z ryzykiem niepowodzenia projektu. Większe projekty będą częściej testowane niż małe, aplikacje o znaczeniu krytycznym będą częściej testowane niż jednorazowe witryny marketingowe, systemy wewnętrzne rzadziej będą testowane niż publiczne.

To powiedziawszy, wciąż istnieją projekty, które zostały nadmiernie przetestowane i te, które nie zostały wystarczająco przetestowane, ale są to mniejszości.

Martin Brown
źródło
Lekko zredagowałem moje pytanie. Czy możesz również podać swoje prognozy?
Robert Koritnik
Niemal wszystkie projekty (80% +), w które byłem zaangażowany, zostały metodycznie przetestowane, ale potem prawie wyłącznie wykonałem aplikacje o kluczowym znaczeniu dla firmy.
Martin Brown
Pracuję dla korporacji farmaceutycznej. Powiedziałbym, że 80% aplikacji jest testowanych przez profesjonalnych testerów i programistów. Te 20% to aplikacje niskiego ryzyka, takie jak prezentacja promocyjna na iPadzie. ale nawet ten jest przez kogoś sprawdzany ad-hoc.
yoosiba,
5

Wszystko, co produkujemy, jest całkowicie testowane. Jeśli nasz wewnętrzny zespół ds. Kontroli jakości jest przeciążony, mamy zespół offshore, który testuje projekty. Nie są tak dobre jak nasz wewnętrzny zespół, ale to inny temat.

Ali
źródło
Lekko zredagowałem moje pytanie. Czy możesz podać swoje szacunki dotyczące rynku profesjonalnych deweloperów. Ponieważ twoje projekty podlegają kontroli. A czy twoje testy są zautomatyzowane czy nie?
Robert Koritnik
Kim jest ten zespół offshore? Czy dałbyś im rekomendację?
Martin Brown
Zwykle duże firmy mają centra badawczo-rozwojowe w innych krajach (głównie w Azji). Gdzie odbywa się rozwój offshore. Celem rozwoju offshore jest obniżenie kosztów rozwoju (pewna jego część).
Nipuna
2

Wszystkie trzy firmy, w których pracowałem przez ostatnie 15 lat, miały testy jednostkowe, które były uruchamiane automatycznie.

W dwóch z tych firm naciskałem na ich wprowadzenie.

sbi
źródło
Lekko zredagowałem moje pytanie. Czy możesz podać również swoje szacunki dotyczące testowania oprogramowania na rynku profesjonalnym?
Robert Koritnik
@Robert: Nie miałem dość pracy, żeby podać ogólne oszacowanie. Z tego, co niewiele wiem, sprawy stają się lepsze. Ale potem to ja
nalegałem
Ale rozmawiasz z innymi programistami w innych firmach, prawda?
Robert Koritnik
2

W ciągu ostatnich 9 lat w zasadzie spełniałem tylko testy akceptacyjne / regresyjne. Było tylko kilka testów jednostkowych.

LennyProgrammers
źródło
Lekko zredagowałem moje pytanie. Czy możesz podać swoje szacunki dotyczące testowania oprogramowania również na rynku profesjonalnym?
Robert Koritnik
2

Tak.

Ilość testów jest proporcjonalna do wymaganej niezawodności aplikacji, a także do dojrzałości kultury programisty.

Strony internetowe dość często chodzą po lukach (uszkodzone linki wadą).

Gry wideo są często wadliwe.

Windows (wreszcie) jest dość niezawodny.

Routery są bardzo niezawodne

Monitory szpitalne „nie łamią się”

Należy zauważyć, że fiskalny koszt awarii jest również skorelowany z niezawodnością.

Paul Nathan
źródło
2
Zdecydowanie się z tobą nie zgadzam - nigdy nie widziałeś awarii routera? Czy gry Xbox, Playstation i Wii blokują się? Czy kiedykolwiek miałeś niebieski ekran lub „Aplikacja nie odpowiada” w systemie Windows?
JBRWilkinson
@JBRWilkinson Wydaje mi się, że brakuje ci modyfikatorów nasilenia, a także prawdopodobnie wcielasz się w znaczną większość gier komputerowych, które, jak mówi Paul, są często błędne. W każdym razie na liście prawdopodobnie można by wprowadzić pewne ulepszenia, ale sentyment jest poprawny: niezawodność często koreluje ze stratami fiskalnymi związanymi z awarią.
Jay Carr
1

Przez 10 lat nigdy nie pracowałem nad projektem z formalnym testowaniem kodu.

W mojej obecnej pracy mamy tylko testy funkcjonalne.

Problem polega na tym, że nikt z kierownictwa nie wie nawet o testowaniu kodu. Dział testowy nawet nie wie o testowaniu kodu, po prostu postępuje zgodnie ze specyfikacją wysokiego poziomu i sprawdza, czy przestrzegamy go z behawioralnego / funkcjonalnego punktu widzenia.

Nie mamy wykwalifikowanego lidera oprogramowania, który zmusza nas do dobrego kodowania. Rezultatem jest kod spaghetti, wiele regresji, brak harmonogramu i tak dalej ...

Wizard79
źródło
Dziękujemy za uczciwą odpowiedź. Jakie są twoje prognozy (sprawdź moje edytowane pytanie)?
Robert Koritnik
Mój szacunek dla Włoch to mniej niż 10% formalnych testów kodu. Być może prawie tylko kod krytyczny dla misji.
Wizard79
Pracowałem w Irlandii, Anglii, Szkocji i Słowenii i, jak się wydaje, Włochy niczym się nie różnią.
Robert Koritnik,
1

Jesteśmy średniej wielkości firmą offshore w Azji Południowej. Jednak zawsze wykonujemy projekty w USA i bezpośrednio pracujemy z wymaganiami przesłanymi przez amerykańską firmę.

Stosujemy testy metodyczne do każdej budowanej przez nas aplikacji. Być może jakość testowania nie odpowiada standardom, ale my je stosujemy.

Shamim Hafiz
źródło
Czy testy te byłyby zautomatyzowane czy głównie ręczne? Lekko zredagowałem moje pytanie. Czy możesz podać swoje szacunki dotyczące testowania oprogramowania również na rynku profesjonalnym?
Robert Koritnik
Większość naszych testów odbywa się ręcznie.
Shamim Hafiz
1

O ile purysta we mnie nie chce pogodzić się z tym, że w podejmowaniu decyzji o tym, jak rygorystycznie testujesz lub czy przeprowadzasz formalne testy, musi być wbudowane zarządzanie ryzykiem. W przypadku aplikacji wewnętrznych, które, jak podejrzewam, stanowią duży% projektów programistycznych, koszt usunięcia usterki, a następnie szybkiego jej załatania po zauważeniu, może czasem zostać zrównoważony kosztem pełnego zespołu testującego. Oczywiście zależy to od aplikacji i potencjalnego kosztu awarii.

To powiedziawszy, nie sądzę, że planowanie zarządzania ryzykiem jest przyczyną braku sformalizowanych testów. Myślę, że bardziej wynika to z tego, że menedżerowie nietechniczni nie rozumieją wartości, jaką zapewnia, i widzą jedynie koszty.

JohnFx
źródło
2
Słyszę, co mówisz, ale trudno to uzasadnić. Badania wykazały, że im dłużej błąd pozostaje niezauważony, tym bardziej kosztuje wykładniczo. Koszt błędów, które trafiają do klienta, jest ogromny, a łatanie ich często powoduje nowe błędy, jeśli nie ma szkieletu testowania jednostkowego (prawdopodobny scenariusz, gdy obecny jest ten rodzaj mentalności „łatania i naprawiania”). W konsekwencji rozsądne użycie narzędzi i metod testowania może być znacznie tańsze niż łatanie i poprawianie.
Robert Harvey
3
Coraz bardziej sceptycznie podchodzę do tego dogmatu, zwłaszcza jego powszechnego zastosowania. Jestem pewien, że czasami tak jest, ale nie wszystkie błędy są tworzone jednakowo, podobnie jak wszystkie aplikacje. Bardzo trudno jest przełknąć, że błąd w wewnętrznej aplikacji używanej przez 10 osób jest znacznie droższy do naprawienia, jeśli zostanie wykryty podczas testów jednostkowych w porównaniu z wydaniem łatki. Może to być wykładniczo bardziej zawstydzające, ale nie bardziej kosztowne, chyba że zignorujesz rzeczywiste koszty czasu, jaki tester spędza na znalezieniu błędu.
JohnFx
2
Zastanawiam się również, czy te statystyki nie miały większego zastosowania do ogromnych projektów (np. Systemów operacyjnych), z których zostały utworzone i nie przekładają się na aplikacje typu CRUD, z których większość z nas buduje na życie.
JohnFx
Zgadzam się z oboje i widziałem oba przypadki. Ale z pewnością wydaje mi się, że mój udział w kosztach wykładniczych opisuje Robert, szczególnie gdy błąd w oprogramowaniu jest tak długi, że inne funkcje faktycznie zaczną się psować, jeśli zostanie naprawione. Przy wystarczająco tandetnym, gorączkowym kodowaniu, gdy ludzie pracują nad problemami wystarczająco długo, a błędy, które pozostają w wystarczająco długim czasie, 1 + 1 to nie 2. To 7. To jeśli nie jest 7, wszystko się rozpadnie.
1

Moja próbka jest bardzo mała, aby wydedukować procenty, ale i tak tu jest.

Jednym z nich była firma Fabless z chipsetem i oprogramowaniem, która przeprowadzała fanatyczne testy. 24/7 zautomatyzowane testy dziesiątek instalacji, każda testująca kilkadziesiąt jednostek równolegle. Zespoły programistów zajmujące się opracowywaniem oprogramowania testowego. Zespoły sprzętowe zajmujące się budowaniem platform testowych. Testy zgodności z dziesiątkami konkurentów. Heck, nawet kupili instalację testera chipów o wartości wielu milionów dolarów, aby opracować i debugować niektóre testy, które fab przeprowadzają, gdy chipy opuszczają odlewnię.

Kolejnym był bank. To jest zupełnie inne środowisko: nie ma żadnych wydań produktów, ale mnóstwo wewnętrznego oprogramowania, które pozwala na ciągłe działanie. Ci goście testowali cr * p z każdej wprowadzonej zmiany. Mieli bardzo ścisłą separację środowisk DEV / QA / PROD, zautomatyzowane testy regresji, obowiązkowe testy QA podpisane przez użytkowników końcowych przed wprowadzeniem do produkcji itp.

Tak, ludzie przeprowadzają testy metodyczne. Ale jak możesz powiedzieć, nigdy nie pracowałem w miejscu, w którym jest dostarczane typowe oprogramowanie GUI dla typowego użytkownika komputera.

Roman Starkov
źródło
1

Obecnie piszę wbudowane oprogramowanie dla małej firmy produkującej bezprzewodowe urządzenia medyczne. Jesteśmy zobowiązani do przeprowadzenia rygorystycznych testów i dysponowania całkowicie oddzielnym działem jakości kierowanym przez osobę, która podlega bezpośrednio dyrektorowi generalnemu. Nigdy wcześniej nie testowałem tak dokładnie kodu przez oddzielnych testerów (jedyny czas, który można porównać, to kiedy pracowałem nad systemami telewizji satelitarnej około 15 lat temu).

Nasze wyniki testów są przesyłane do FDA (do tej pory otrzymaliśmy dwa zezwolenia FDA - każde przesłanie miało około 500 stron). Zarówno nasze metody opracowywania, jak i testowania podlegają okresowym audytom.

Tak więc nie tylko duże firmy przeprowadzają wiele formalnych testów.

Uwaga - przez ponad 25 lat programowania / doradztwa kontraktowego pracowałem również dla wielu firm, które praktycznie nie przeprowadziły formalnych testów. Większość z nich już nie ma.

tcrosley
źródło
Jestem także w firmie produkującej wyroby medyczne, a wprowadzenie do GMP (Good Manufacturing Practices, FDA-speak for kontroled design / test process) było dla mnie dość otwarte. To uczyniło mnie lepszym inżynierem (i niestety ekspertem od docbooków)
Bill Gribble
0

Prawie w każdej firmie przeprowadziłem testy metodyczne. Moja obecna firma ma kilka podstawowych testów w stylu jednostek, co nie jest wystarczające. Z tego powodu mieliśmy pewne problemy z jakością. Gorąco polecam niezależne dokładne testy każdego projektu, który będzie używany przez kogokolwiek poza tobą. Wydane pieniądze będą tego warte. Aplikacje, które nie działają, nie są używane. Dotyczy to zarówno okładzin wewnętrznych, jak i zewnętrznych.

Bill Leeper
źródło
Lekko zredagowałem moje pytanie. Czy możesz podać swoje szacunki dotyczące testowania oprogramowania również na rynku profesjonalnym?
Robert Koritnik
@Robert: Nie rozumiem twojego pytania „szacunki testowania oprogramowania”. Czy pytasz mnie o opinię, ile firm testuje? Mój szacunek wyniósłby może 90% lub więcej w oparciu o to, co widziałem na własne oczy. Testowanie jest wspólną częścią rozwoju zawodowego.
Bryan Oakley,
0

W ciągu ostatnich dwudziestu lat mojej kariery w ośmiu firmach nigdy nie pracowałem nad projektem, który nie przeprowadzałby testów. Ilość testów różniła się w poszczególnych firmach, ale każdy projekt rozwoju zawodowego, nad którym kiedykolwiek pracowałem, przeprowadzał testy formalne. Dotyczy to zarówno małych, jak i średnich firm (gdzie „mały” oznacza mniej niż 10 pracowników, a „średni” oznacza kilka tysięcy pracowników lub mniej).

Niektóre firmy nie miały zbyt wielu testów automatycznych, niektóre nie miały zbyt wielu testów manualnych, ale miały co najmniej jedno lub drugie.

Bryan Oakley
źródło
0

To zależy od potrzeb klienta. W sytuacji kontraktowej prawdopodobnie przeprowadzane są testy akceptacyjne. In-house to zazwyczaj slapjob z niewielkimi testami. Artykuły konsumenckie są zwykle bardzo często objęte dużą funkcjonalnością, ale szorstkie na brzegach.

zaraz
źródło
0

Krótka odpowiedź: tak

Długa odpowiedź:

  1. Nie mam dobrego oszacowania dla pierwszej kategorii (prawdopodobnie jest to pewna odległość od zera, ale ile?), Ale moje doświadczenie faktycznie potwierdza twoje drugie oszacowanie. Trudno podać znaczące wartości procentowe, ponieważ ilość i rodzaj testowania zależy od rodzaju opracowywanej aplikacji, dostępnych ram czasowych, a także umiejętności programistów i sposobu prowadzenia projektu. W praktyce najważniejszą przeszkodą dla programistów byłby test akceptacyjny, ponieważ jest to ważny kamień milowy dla celów rozliczeniowych. Ale jest to także czas, w którym może się zdarzyć nieoczekiwane (więcej wymagań), a deweloperzy mogą być zmuszeni do dostarczenia i przetrwania wszelkich testów adhoc, które są możliwe i terminowe (na tym etapie), poza czasem potrzebnym na rozwiązywanie problemów i przezwyciężanie niespodziewane.

  2. Przeszedłem przez wiele projektów z różnymi kombinacjami czynników wymienionych powyżej:

    • bez formalnych testów jednostkowych, tylko testy integracyjne i głównie testy adhoc

    • bardzo formalne, od testów jednostkowych po szczegółowe plany testów obejmujące dedykowane zasoby kontroli jakości, testy automatyczne (przeprowadzane przez testerów z ich własnym zestawem narzędzi) i raporty pokrycia kodu. Ale nie zawsze mają one znaczenie zarówno dla programistów, jak i dla menedżerów

Na poziomie indywidualnym staram się zachować zrozumienie moich możliwości, jeśli chodzi o pisanie odpowiednich testów odpowiednich dla technologii, z którą mam do czynienia, i wykonywanie ich według własnego uznania. Zasadniczo rzeczy, które są naprawdę znaczące i korzystne dla mojej pracy, i nie tyle rozrabiają liczby.

prusswan
źródło