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

25

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

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

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

Два вопроса

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

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

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

Роберт Коритник
источник
Отличный вопрос, спасибо, что нашли время переформулировать!
@ Марк Трапп: Спасибо. Я думаю, что это довольно просто, но я могу задать еще несколько вопросов (основываясь на предыдущем наборе вопросов)
Роберт Коритник,

Ответы:

8

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

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

Мартин Браун
источник
Я немного отредактировал свой вопрос. Не могли бы вы также представить свои оценки?
Роберт Коритник
Почти все проекты (более 80%), в которых я принимал участие, прошли методическое тестирование, но затем я почти исключительно выполнил корпоративные критически важные приложения.
Мартин Браун
Я работаю в фармацевтической корпорации. Я бы сказал, что 80% приложений тестируются профессиональными тестировщиками и разработчиками. Эти 20% являются приложениями с низким уровнем риска, такими как рекламные презентации на iPad. но даже этот специально проверен кем-то.
yoosiba
5

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

Али
источник
Я немного отредактировал свой вопрос. Не могли бы вы дать свои оценки развития профессионального рынка. Потому что ваши проекты подвергаются тщательному анализу. А ваши тесты автоматизированы или нет?
Роберт Коритник
Кто эта оффшорная команда? Вы бы дали им рекомендацию?
Мартин Браун
Обычно крупные компании имеют центры исследований и разработок в других странах (в основном в Азии). Где оффшорная разработка сделана. Целью разработки на шельфе является снижение стоимости разработки (некоторая ее часть).
Нипуна
2

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

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

SBI
источник
Я немного отредактировал свой вопрос. Не могли бы вы дать свои оценки о тестировании программного обеспечения на профессиональном рынке?
Роберт Коритник
@ Роберт: Я не был достаточно занят, чтобы дать общую оценку. Из того, что я мало знаю, дела становятся лучше. Но потом, именно я настаивал на автоматических модульных тестах в двух из трех случаев, о которых я вам говорил ...
sbi
Но ведь вы общаетесь с другими разработчиками в других компаниях?
Роберт Коритник
2

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

LennyProgrammers
источник
Я немного отредактировал свой вопрос. Не могли бы вы также дать свои оценки тестирования программного обеспечения на профессиональном рынке?
Роберт Коритник
2

Да.

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

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

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

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

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

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

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

Пол Натан
источник
2
Я категорически не согласен с вами - вы никогда не видели сбой маршрутизатора? Есть ли блокировка игр для Xbox, Playstation и Wii? У вас когда-нибудь был синий экран или «Приложение не отвечает» в Windows?
Дж.Б. Уилкинсон
@JBRWilkinson Я думаю, что вы пропустили его модификаторы серьезности, а также, возможно, любили подавляющее большинство компьютерных игр, которые, как говорит Пол, часто глючат. В любом случае, список, вероятно, мог бы использовать некоторые улучшения, но мнение верное: надежность часто коррелирует с финансовыми потерями, связанными с отказом.
Джей Карр
1

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

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

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

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

Wizard79
источник
Спасибо за ваш честный ответ. Каковы ваши оценки (проверьте мой отредактированный вопрос)?
Роберт Коритник
Моя оценка для Италии составляет менее 10% формального тестирования кода. Возможно, почти только критически важный код.
Wizard79 15.09.10
Я работал в Ирландии, Англии, Шотландии и Словении, и, кажется, Италия ничем не отличается.
Роберт Коритник
1

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

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

Шамим Хафиз
источник
Будут ли эти тесты автоматизированы или в основном вручную? Я немного отредактировал свой вопрос. Не могли бы вы также дать свои оценки тестирования программного обеспечения на профессиональном рынке?
Роберт Коритник
Большая часть нашего тестирования проводится вручную.
Шамим Хафиз
1

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

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

JohnFx
источник
2
Я слышу, что вы говорите, но это трудно оправдать. Исследования показали, что чем дольше ошибка остается незамеченной, тем больше она экспоненциально стоит . Стоимость ошибок, доставляемых клиенту, огромна, и их исправление часто приводит к появлению новых ошибок, если отсутствует модульное тестирование (вероятный сценарий, когда присутствует такая ментальность «исправления и исправления»). Следовательно, разумное использование инструментов и методологий тестирования может оказаться намного дешевле, чем исправление и исправление.
Роберт Харви
3
Я все больше и больше скептически отношусь к этой догме, особенно к ее универсальному применению. Я уверен, что иногда это правда, но не все ошибки создаются одинаково, и не все приложения. Я нахожу очень трудным проглотить то, что ошибка во внутреннем приложении, используемом 10 людьми, значительно дороже исправить, если она обнаружена во время модульного тестирования, а не в выпуске патча. Это может быть экспоненциально более смущающим, но не более дорогостоящим, если вы не игнорируете реальные затраты времени, которое тестировщик тратит на поиск ошибки.
JohnFx
2
Мне также интересно, не были ли эти статистические данные более применимы к массовым проектам (например, операционным системам), из которых они были созданы, и не переводятся в приложения типа CRUD, которые большинство из нас создает для жизни.
JohnFx
Я согласен с вами обоими парнями и видел оба случая. Но мне, конечно, кажется, что моя доля экспоненциальных затрат, которые описывает Роберт, особенно когда ошибка в программном обеспечении была настолько долгой, что другие функции фактически начали бы ломаться, если бы она была исправлена. При достаточно скудном и безумном кодировании, когда люди работают над проблемами достаточно долго, а ошибки, которые остаются внутри достаточно долго, 1 + 1 - это не 2. Это 7. И если это не 7, все развалится.
1

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

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

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

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

Роман Старков
источник
1

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

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

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

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

tcrosley
источник
Я также работаю в компании, производящей медицинские устройства, и введение в GMP (Good Manufacturing Practices, FDA-говорит о контролируемом процессе проектирования / испытаний) было довольно откровенным для меня. Это сделало меня лучшим инженером (и, к сожалению, экспертом по документообороту)
Билл Гриббл
0

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

Билл Липер
источник
Я немного отредактировал свой вопрос. Не могли бы вы также дать свои оценки тестирования программного обеспечения на профессиональном рынке?
Роберт Коритник
@ Роберт: я не понимаю ваш вопрос "оценки тестирования программного обеспечения". Вы спрашиваете мое мнение о том, сколько компаний тестируют? Моя оценка была бы, возможно, 90% или больше на основе того, что я видел своими глазами. Тестирование является обычной частью профессионального развития.
Брайан Оукли
0

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

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

Брайан Оукли
источник
0

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

скоро
источник
0

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

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

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

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

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

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

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

prusswan
источник