Результаты опроса о тестировании

С 26 ноября по 2 декабря 2009 мы проводили опрос о тестировании. Было получено 378 анкет.

Отношению к тестированию ПО

Отношение

Модульное тестирование

Как выполняется модульное тестирование в зависимости от размера команды

модульное тестирование в зависимости от размера команды

Как выполняется модульное тестирование в зависимости от области применения проекта

модульное тестирование в зависимости от области применения проекта

Функциональное тестирование

Как выполняется функциональное тестирование в зависимости от размера команды

функциональное тестирование в зависимости от размера команды

Как выполняется функциональное тестирование в зависимости от области применения проекта</р4>
функциональное тестирование в зависимости от области применения проекта

Довольны ли качеством своего процесса тестирования

Довольны ли качеством

Continuous integration

Использование CI

ci

Использование CI в зависимости от размера команды проекта

CI в зависимости от размера команды проекта

Использование CI в зависимости от области применения проекта

CI в зависимости от области применения проекта
👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube

17 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

2Олег Бабий: спасибо, учту, я доверился дизайнерам из Microsoft которые вот такие цвета сделали дефолтными в Excel.

2 Макс Ищенко и дизайнерамК диаграмме — Глазам тяжело: Не пишите черным по синему, красному и фиолетовому?, а только по зеленому и по бледным цветам (голубой и т.д.)

QA =~ качество. Каждая компания/проект/продукт имеет свой приоритет, кто-то стремится улучшить пропорцию «Цена / Качество», кто-то фокусируется на Time-To-Market параметре и игнорирует качество пытаясь заполучить сегмент рынка за счет свежей идеи, кто-то пытается переходит на стадию enterprise-ready и тратится на серьезное тестирование.2 Batter: 100% покрытие для серьезного продукта — чистая теория. Именно для этого и существуют QA менеджеры чтобы правильно проанализировать риски и принять решение как оптимизировать качество за отведенное время. Могу сказать из собственного опыта, что самые «крутые» фирмы (IBM, HP, Borland, Oracle,...) с дорогущими продуктами под бизнес (Toyota, Citibank, Coca-Cola, Nokia,...) выпускают продукт с заведомо известными дефектами в сотнях и даже тысячах... Здесь фокус не на качестве в чистом виде, а на качестве лучше чем у конкурента. 2 Tech: насколько я знаю Adobe не давал в Украину аутсорса полного цикла, т.е. все координировалось QA менеджером оттуда, а здесь был уровень ТимЛидов пищущих свои STP на основании работающим по спущенного оттуда MTP (master test plan). Неужели они каждую фичу принимали под подпись? Если так, то что-то не так в коммуникации — такое недоверие к долгосрочному партнерству врядли приведет — возможно не было Проектного Менеджера или Аккаунт Менеджера на этой стороне чтобы добится доверия от заказчика. P.S. Хотя Adobe мог и внедрять такую политику — у них было желание (которое они и осуществили) вылезти в верхний кводрант Гартнера по WebConferencing и догнать cisco, microsoft и ibm и они устраивали непопулярные меры по контролю качества во всей компании. Кстати, а что именно от Adobe вы тестировали? (если NDA позволяет конечно) 2 andy_iaa: мы таки да начинаем тестирование со стадии дизайна:)

@Руслан обязательно, только после НГ. Похоже с опросами на сайте я в последнее время переборщил.

// кстати — жутко интересный был бы такой-же опрос по объему документации (кроме кода) и по планированию срокам.

2 Tech

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

вот это круто., а больше подробостей есть или очень суровое NDA?

Все зависит от проекта. Сэм Канер сравнивает сверхнадежное ПО с Роллс-Ройсом — очень качественно, но и очень дорого.Вопрос в том, какова будет стоимость возможной ошибки в работе программы: баг в homepage и баг в софте для управления атомным реактором имеют разные цены. В одной из крупных аутсорсинговых компаний в Украине, которая работала с Adobe, прохождение каждого приемо-сдаточного теста заверялось подписями и печатями в присутствии юристов с одной и другой стороны. При ограничении времени и ресурсов основное внимание уделяется тестированию ключевых функций ПО.

автоматизация контроля за качеством должно быть экономически обоснованным. зачем автоматизировать тест-кейсы по небольшому проекту, который не предполагается развивать.имхо «быть или не быть» автоматизации зависит от множества факторов, навскидку: — размера проекта- прирост «фич» в ед.времени- требования к качеству- требования к скорости добавления фич- etc

что грустно, так это то, что совсем не упоминается, что тестирование должно начинаться на этапе дизайна. (и кто на практика это использует) начинать тестирование после написания продукта в 10 раз дороже.

иногда модульные тесты — это единственный вариант, если QA отсутсвует как класс (opensource проект, например). сидеть и ждать пока пользователи потестируют и напишут багрепорты, по-моему, не этично. тестирование разработчиками — это конечно хорошо, но не совсем то. это всё таки не формальное тестирование, в отличие от модульного и QA.с моей личной точки зрения, корректный вопрос будет звучать не «тратить ли ресурсы на тестирование», а «хватает ли ресурсов на тестирование». потому что тестирование сократит время до релиза (ошибки всё равно придётся исправлять, никуда от этого не деться, чем раньше обнаружатся — тем лучше), а время — это основной ресурс. черта — по обстоятельствам, наверное.

На самом деле, идея опроса появилась в процессе обдумывания вопроса: всегда ли тестирование приносит пользу или есть черта, после которой тестирование дает отрицательный результат. Я общался с ребятами из Майрософт, они уверены что тестирование нужно всегда и тестирование всегда окупается. По моему опыту, это не так. Часто тратить свое время на написание тестов, создание тестовых обвязок, автоматизацию функциональных тестов и т.п. нерационально, т.е. затраты времени перевешивают возможные выгоды. Было интересно узнать, что думают об этом другие разработчики.

Банковское! = покрытое.Лично знаю систему с нулевым покрытием:)

Банковское ПО. Может быть ярким примером со 100% покрытием.

Если покрыто 80% кода — это очень хорошо. Вряд ли можно покрыть 100%.

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

Результат определенно не порадовал.

100%-е покрытие кода тестами очень дорогое удовольствие. Да и непонятно какой толк от этого. Кто голосовал за 100%-е покрытие — можете рассказать как справляетесь?

Подписаться на комментарии