Тестування програмного забезпечення насправді проводиться на професійних проектах?

Я брав участь у багатьох проектах в декількох компаніях, тому що я давно був розробником і я підрядник.

Я вважаю, що менше 20% проектів є методично перевіреними. Маючи на увазі методично тестоване, я маю на увазі будь-яке тестування поза тестуванням без спеціального плану.

Я також вважаю, що менше 10% проектів ретельно методично перевіряються там, де у складі команди є спеціалізовані тестери, документ плану тестування, де розробники пишуть автоматизовані тести, а потім вони також відстежують покриття тесту та вимірюють результати.

Два питання

1. Які ваші відсоткові оцінки щодо цього питання?
2. Який ваш професійний досвід щодо тестування програмного забезпечення?

Додаткова примітка

Оскільки питання методичного тестування може отримати досить необ’єктивні відповіді (люди люблять похвалитися перевагою інших), я закликаю інших розробників (тих, хто не піддається методичному тестуванню), щоб вони також дали свою відповідь, оскільки в іншому випадку це виглядатиме як тестування що робиться скрізь ... крім у вашій компанії.

Модель, яку я бачив під час тестування протягом своєї кар'єри, свідчить про сильну відповідність ризику невдачі в проекті. Великі проекти, швидше за все, будуть перевірені, ніж малі, критичні програми місії швидше перевіряються, ніж одноразові маркетингові веб-сайти, в домашніх системах рідше тестуються, ніж громадські.

Це говорить про те, що все ще є проекти, які були надмірно перевірені, і ті, які недостатньо перевірені, але це меншість.

Все, що ми виробляємо, проходить повну перевірку. Якщо наша внутрішня команда з контролю якості перевантажена, у нас є офшорна команда, яка тестує проекти. Вони не такі хороші, як наша внутрішня команда, але це вже інша тема.

У трьох компаніях, над якими я працював протягом останніх 15 років, у всіх проходили одиничні тести, які виконувалися автоматично.

У двох із цих компаній я наполягав на тому, щоб їх представити.

В останні 9 років я в основному тільки виконував тести прийняття / регресії. Було лише кілька одиничних тестів.

Так.

Кількість тестування пропорційно надійності, необхідній додатку, а також зрілості культури програміста.

На веб-сайтах досить часто проходять помилки (пошкоджені посилання є дефектом).

Відео ігри часто бувають баггі.

Windows (нарешті) досить надійний.

Маршрутизатори дуже надійні

Госпітальні монітори "не ламаються"

Зауважимо, що фіскальна вартість відмови також корелює з надійністю.

За 10 років я ніколи не працював над проектом з формальним тестуванням коду.

У моїй теперішній роботі у нас є лише функціональне тестування.

Проблема в тому, що ніхто з керівництва навіть не знає про тестування коду. Тестовий відділ навіть не знає про тестування коду, вони просто дотримуються специфікації високого рівня і перевіряють, чи ми відповідаємо з поведінкової / функціональної точки зору.

У нас немає кваліфікованого лідера програмного забезпечення, яке змушує нас добре кодувати. Результат - код спагетті, безліч регресій, пропущені графіки і так далі ...

Ми - офшорна компанія середнього розміру в Південній Азії. Однак ми завжди робимо проекти на базі США та безпосередньо працюємо з вимогами, що надсилаються від американської компанії.

Ми застосовуємо методичне тестування до кожної створеної програми. Можливо, якість тестування не є стандартною, але ми їх застосовуємо.

Стільки ж, як пурист у мені не хоче погодитися, що в рішення повинно бути якесь управління ризиком, наскільки ретельно ви тестуєтесь чи взагалі ви формалізуєте тестування. Для внутрішніх додатків, на які я підозрюю, що це великий відсоток програм програмування, вартість випуску помилки та її швидкого виправлення після того, як вона помічена, іноді може бути перевершена вартістю повної команди тестування. Звичайно, це залежить від програми та потенційної вартості відмов.

Однак, я не думаю, що планування управління ризиками є причиною відсутності формалізованого тестування. Я думаю, що це скоріше результат того, що нетехнічні менеджери не розуміють цінності, яку вона надає, і бачать лише вартість.

Мій зразок дуже малий, щоб виводити відсотки з, але тут все одно.

Один був компанією fabless chip + firmware, яка робила фанатичне тестування. 24/7 автоматизованих випробувань на десятках установок, кожне тестування десятків одиниць паралельно. Команди програмного забезпечення, що займаються розробкою тестування програмного забезпечення. Команди обладнання, присвячені будівництву тестових установок. Тест на сумісність проти десятків конкурентів. Чорт забирають, вони навіть придбали багатомільйонну установку тестера для мікросхем, щоб розробити і налагодити деякі тести, які виконуються на платформі, коли чіпи залишають ливарну.

Ще одним був банк. Це зовсім інше середовище: не випускається продукт, але багато і багато власного програмного забезпечення, яке постійно працює. Ці хлопці випробовували кр * р на кожну зміну, яку вони внесли. У них було дуже жорстке відокремлення середовищ DEV / QA / PROD, автоматизоване тестування регресії, обов'язкове тестування якості, підписане кінцевими споживачами перед випуском у виробництво тощо.

Так так, люди роблять методичне тестування. Але як ви можете сказати, я ніколи не працював у місці, де постачається ваше типове програмне забезпечення для графічного інтерфейсу для типового користувача комп'ютера.

Я зараз пишу вбудовану прошивку для невеликої стартап-компанії, яка виготовляє бездротові медичні пристрої. Нам потрібно провести суворі тестування та мати повністю окремий відділ якості, який очолює хтось, хто звітує безпосередньо перед генеральним директором. Я ніколи не був так ретельно перевірений своїм кодом окремими тестерами (єдиний час, який порівнюється, це коли я працював над системами супутникового телебачення близько 15 років тому.)

Наші результати тестування надсилаються до FDA (поки що ми отримали два дозволи FDA - кожен подання становив близько 500 сторінок). Обидва наші методи розробки та тестування підлягають періодичному аудиту.

Тож не лише великі компанії проводять багато формальних тестувань.

Зауважте - за свої 25 років контрактного програмування / консалтингу я також працював у багатьох компаніях, які практично не проводили офіційних тестувань. Більшості з них вже немає навколо.

Практично в кожній компанії я проходив методичне тестування. Моя нинішня компанія має декілька базових тестів стилю, що недостатньо. У нас виникли проблеми з якістю через це. Я настійно рекомендую незалежне ретельне тестування будь-якого проекту, який буде використаний будь-хто, окрім вас самих. Витрачені кошти цілком варті того. Програми, які не працюють, не звикають. Це стосується як внутрішніх, так і зовнішніх.

В останні двадцять і більше років своєї кар'єри через вісім компаній, я ніколи не працював над проектом, який не робив тестування. Кількість тестувань відрізнялася у кожної компанії, але кожен проект професійного розвитку, над яким я коли-небудь працював, робив офіційне тестування. Це в рівній мірі стосується як малих, так і середніх компаній (де "малі" означають менше 10 працівників, а "середній розмір" означає пару тисяч працівників або менше).

Деякі компанії не мали багато автоматизованого тестування, деякі не мали багато ручного тестування, але вони мали принаймні те чи інше.

Це залежить від потреб замовника. У контрактній ситуації, ймовірно, є тести приймання. Внутрішній дім, як правило, є шахраєм з невеликим тестуванням. Споживчі речі, як правило, сильно покриті частою функціональністю, але грубі по краях.

Коротка відповідь: Так

Довга відповідь:

1. Я не маю гарної оцінки для першої категорії (це, мабуть, деяка відстань від нуля, але скільки?), Але мій досвід насправді підтверджує вашу другу оцінку. Важко дати значущі відсотки, оскільки кількість та тип тестування залежать від типу програми, що розробляється, наявних часових рамків, а також від набору навичок розробників та способів виконання проекту. На практиці найбільш важливим перешкодою для розробників буде тест прийняття, оскільки це є важливою віхою для цілей виставлення рахунків. Але це також час, коли може статися несподіване (більше вимог), і на розробників може бути надано тиск, щоб доставити та отримати будь-яке можливе та своєчасне тестування adhoc (на даному етапі), понад час, необхідний для усунення несправностей та подолання несподіване

2. Я брав участь у різноманітних проектах із різною комбінацією факторів, згаданих вище:

   • ніяких формальних одиничних тестів, лише інтеграційні тести та здебільшого тести adhoc

   • дуже формальне, починаючи від одиничних тестів до детальних планів випробувань, що передбачають спеціальні ресурси QA, автоматизоване тестування (як проводять тестери з власним набором інструментів) та звіти про покриття коду. Але вони не завжди значущі для розробників так само, як для менеджерів

На індивідуальному рівні я прагну до розуміння моїх варіантів, коли справа стосується написання належних тестів, відповідних технології, з якою я маю справу, і виконую їх на власний розсуд. В основному речі, які насправді значущі і корисні для моєї роботи, і не стільки викручують цифри.