Проводится ли тестирование программного обеспечения на профессиональных проектах?

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

По моим оценкам, менее 20% проектов проходят методическую проверку. Под методическим тестированием я имею в виду любое тестирование, кроме специального тестирования без плана.

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

Два вопроса

1. Каковы ваши процентные оценки по этому вопросу?
2. Каков ваш профессиональный опыт в тестировании программного обеспечения?

Дополнительное примечание

Поскольку на вопрос методического тестирования могут быть получены весьма предвзятые ответы (людям нравится хвастаться превосходством над другими), я призываю других разработчиков (тех, кто не подвергался методическому тестированию) также предоставить свой ответ, поскольку в противном случае это будет выглядеть делается везде ... кроме как в вашей компании.

Модель, которую я видел при тестировании по моей карьере, показывает сильную связь с риском неудачи в проекте. Большие проекты с большей вероятностью будут протестированы, чем маленькие, критически важные приложения с большей вероятностью будут протестированы, чем отдельные маркетинговые веб-сайты, в домашних системах реже будут тестироваться, чем общедоступные.

Тем не менее, есть еще проекты, которые были чрезмерно проверены и те, которые не были проверены достаточно, но это меньшинство.

Все, что мы производим, проходит полную проверку. Если наша внутренняя команда QA перегружена, у нас есть оффшорная команда, которая тестирует проекты. Они не так хороши, как наша внутренняя команда, но это другая тема.

Все три компании, в которых я работал в течение последних 15 лет, проходили модульные тесты, которые запускались автоматически.

В двух из этих компаний я настаивал на том, чтобы представить их.

За последние 9 лет я в основном встречал только приемочные / регрессионные тесты. Было только несколько юнит-тестов.

Да.

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

На веб-сайтах довольно часто встречаются баг-дыры (неработающие ссылки являются дефектом).

Видеоигры часто глючат.

Windows (наконец-то) довольно надежна.

Маршрутизаторы очень надежны

Больничные мониторы "не ломаются"

Обратите внимание, что фискальная стоимость отказа также связана с надежностью.

За 10 лет я никогда не работал над проектом с формальным тестированием кода.

В моей текущей работе у нас есть только функциональное тестирование.

Проблема в том, что никто из руководства даже не знает о тестировании кода. Отдел тестирования даже не знает о тестировании кода, он просто следует спецификации высокого уровня и проверяет, соблюдаем ли мы его с поведенческой / функциональной точки зрения.

У нас нет квалифицированного программного лидера, который заставляет нас хорошо кодировать. В результате получается код спагетти, множество регрессий, пропущенные графики и так далее ...

Мы являемся оффшорной компанией среднего размера в Южной Азии. Тем не менее, мы всегда делаем проекты в США и напрямую работаем с требованиями, присланными компанией США.

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

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

Тем не менее, я не думаю, что планирование управления рисками является причиной отсутствия формализованного тестирования. Я думаю, что это скорее результат того, что нетехнические менеджеры не понимают ценность, которую они предоставляют, а видят только стоимость.

Моя выборка очень мала, чтобы вывести проценты от нее, но все равно идет.

Одним из них была компания Fabless Chip + Firmware, которая провела фанатическое тестирование. 24/7 автоматизированные тесты на десятках установок, каждая из которых тестирует десятки устройств параллельно. Программные команды, занимающиеся разработкой программного обеспечения для тестирования. Аппаратные группы, занимающиеся сборкой испытательных стендов Тестирование на совместимость с десятками конкурентов. Черт возьми, они даже купили установку для тестирования микросхем стоимостью в несколько миллионов долларов, чтобы разработать и отладить некоторые тесты, которые тесты проводят, когда чипы покидают литейный завод.

Еще один был банком. Это совершенно другая среда: нет выпусков продукта, но есть много собственного программного обеспечения для непрерывной работы. Эти парни тестировали результат каждого изменения, которое они сделали. У них было очень строгое разделение сред DEV / QA / PROD, автоматическое регрессионное тестирование, обязательное тестирование QA, подписанное конечными пользователями перед выпуском в эксплуатацию, и т. Д.

Так что да, люди проводят методическое тестирование. Но, как вы можете заметить, я никогда не работал в месте, где поставляется типичное программное обеспечение с графическим интерфейсом для обычного пользователя компьютера.

В настоящее время я пишу встроенную прошивку для небольшой начинающей компании, производящей беспроводные медицинские устройства. От нас требуется тщательное тестирование, и у нас есть совершенно отдельный отдел качества, который возглавляет тот, кто подчиняется непосредственно генеральному директору. Я никогда раньше не проводил такого тщательного тестирования моего кода отдельными тестировщиками (единственное время, которое можно сравнить - это когда я работал над системами спутникового телевидения около 15 лет назад).

Результаты наших тестов отправляются в FDA (до сих пор мы получили два разрешения FDA - каждое представление было около 500 страниц). И наша методология разработки, и тестирование являются предметом периодического аудита.

Так что не только крупные компании проводят большое формальное тестирование.

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

Практически в каждой компании я проходил методическое тестирование. В моей нынешней компании есть несколько базовых тестов, но этого недостаточно. У нас были некоторые проблемы с качеством из-за этого. Я настоятельно рекомендую провести независимое тщательное тестирование любого проекта, который будет использоваться кем-либо, кроме вас. Потраченные деньги будут того стоить. Приложения, которые не работают, не привыкают. Это касается как внутренней, так и внешней.

За последние двадцать или около того лет моей карьеры в восьми или более компаниях я никогда не работал над проектом, который не проводил тестирование. Количество тестирований в каждой компании было разным, но каждый проект по профессиональной разработке, над которым я когда-либо работал, проводил формальное тестирование. Это в равной степени относится как к малым, так и к средним компаниям (где «маленький» означает менее 10 сотрудников, а «средний» означает пару тысяч сотрудников или менее).

У некоторых компаний не было большого количества автоматизированного тестирования, у некоторых не было большого количества ручного тестирования, но у них было по крайней мере одно или другое.

Это зависит от потребностей клиента. В контрактной ситуации возможно есть приемочные испытания. В доме, как правило, слабость с небольшим испытанием. Потребительские вещи, как правило, сильно покрыты частыми функциями, но по краям шероховатые

Краткий ответ: да

Длинный ответ:

1. У меня нет хорошей оценки для первой категории (это, вероятно, некоторое расстояние от нуля, но сколько?), Но мой опыт фактически подтверждает вашу вторую оценку. Трудно дать значимые проценты, так как объем и тип тестирования зависят от типа разрабатываемого приложения, доступных сроков, а также от навыков разработчиков и от того, как выполняется проект. На практике самым важным препятствием для разработчиков будет приемочный тест, поскольку это важный этап для выставления счетов. Но это также время, когда может произойти непредвиденное (больше требований), и на разработчиков может быть оказано давление, чтобы они доставили и обошлись с любым временным тестированием, которое возможно и своевременно (на данном этапе), сверх времени, необходимого для устранения неполадок и преодоления. неожиданный.

2. Я прошел через множество проектов с различной комбинацией факторов, упомянутых выше:

   • нет формальных юнит-тестов, только интеграционные тесты и в основном специальные тесты

   • очень формальный - от модульных тестов до подробных планов тестирования, включающих выделенные ресурсы QA, автоматическое тестирование (проводимое тестировщиками с их собственным набором инструментов) и отчеты о покрытии кода. Но они не всегда значимы для разработчиков так же, как для менеджеров

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