Czy testy oprogramowania są faktycznie przeprowadzane na profesjonalnych projektach?

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.

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.

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.

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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.