Цена исправления ошибки в тестировании

Если мы заметили ошибку на этапе написания требований, то исправить ее — дело 1 минуты, просто скорректировали предложение в тексте, и все.

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

Но это еще реально. А вот если мы уже все построили (написали код), то некоторые изменения просто нельзя внести и приходится мириться с багом. А даже если можно, то стоить это будет сильно дороже:
— аналитику поправить ТЗ;
— архитектору придумать, как поправить минимальными усилиями;
— разработчикам внести правки.

Но это еще реально. А вот если мы уже все построили (написали код), то некоторые изменения просто нельзя внести и приходится мириться с багом. А даже если можно, то стоить это будет сильно дороже:
— аналитику поправить ТЗ;
— архитектору придумать, как поправить минимальными усилиями;
— разработчикам внести правки.

Почему на картинке Lee Copeland есть еще Release с самой большой стоимостью?

Картинка из книги Lee Copeland

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

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

Картинка из книги Lee Copeland

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

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

Тем не менее такой подход до сих пор используют в больших организациях на сотни человек. Там с требованиями работает один отдел аналитики, потом передают дальше и так по каскаду все приходит в тестирование. С проблемами ошибки в требованиях приходится мириться…

Так что запоминаем: чем раньше найдена ошибка, тем проще ее исправить!

Поэтому тестировщики так важны. Чем раньше они заметят проблемы, тем проще будет их исправить!

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

Цена ошибки: как экономия приводит к повышенным тратам

Поэтому тестировщики так важны. Чем раньше они заметят проблемы, тем проще будет их исправить!

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

Цена ошибки: как экономия приводит к повышенным тратам

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

Экономия затрагивает самые разные сферы проекта и специалистов. В этой статье рассмотрим обеспечение качества (QA). Бизнес нередко считает, что тестирование – та часть проекта, на которой можно сэкономить, что за качество должны отвечать разработчики, а QA-специалистов иногда можно и не привлекать. Наш коллега Андрей на конкретных примерах покажет, к каким последствиям приводят наиболее популярные случаи экономии на QA.

Вариант 1. Отсутствие тестирования на ранних этапах

Начнем с классического случая экономии на проекте – отсутствия тестирования на ранних этапах жизненного цикла ПО.  

Первоначальная выгода от такого решения кажется очевидной – пока не накопилось достаточного объема кода для тестирования, подключение QA-специалистов некритично. Однако оправданность такого решения при детальном рассмотрении оказывается сомнительной.  

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

1. Идея

2. Написание технического задания (далее – ТЗ)

3. Реализация

4. Тестирование

5. Выход в релиз

Обратите внимание, что на этой схеме QA подключаются довольно поздно – на этапе тестирования. Используя этот алгоритм, легко вычислить, что: 

• Если в фиче нет дефектов, то каждый участник жизненного цикла затрачивает свое время 1 раз, таким образом разработка стоит 5 условных часов.

• Если баг допущен на этапе реализации и найден на этапе тестирования, то разработчик и QA затрачивают по одной дополнительной единице времени: на фикс бага и на повторное тестирование (ретест) исправленной фичи, соответственно. В итоге получается: 5+2=7 единиц времени. У вас может возникнуть вопрос, почему мы считаем 5 часов, а не 4, если после тестирования фича не пошла в релиз? Потому что после исправлений и повторного тестирования все равно наступает релиз.

• Если баг допущен на этапе написания ТЗ и найден на этапе тестирования, то единиц времени будет 8 (5+3 на: исправление ТЗ, фикс бага , ретест)

• Если баг допущен в самой идее фичи и выявлен на этапе тестирования, то будет затрачено 9 единиц времени (5+4 на: коррекцию идеи, исправление ТЗ, фикс бага, ретест исправлений)

 Теперь давайте представим, что QA подключается на более раннем этапе – между написанием ТЗ и разработкой – и тестирует требования. В этом случае баги можно будет выявить раньше и сэкономить время.

Тестирование постановок (ТЗ) – одно из популярных решений тренда на раннее тестирование или, как это называют некоторые компании,  «shift left».

В третьем и четвертом случаях это будет 1 и 2 единицы времени соответственно. Однако можно заметить, что в первом и втором случаях происходит увеличение затрачиваемого времени на 1 единицу. Где же выгода? Добавим в теоретическую модель данные о статистике возникновения дефектов и реально затрачиваемом времени на тестирование требований и исправления постановок и кода.

 Начнем с возникновения дефектов. Мы собрали статистику со 117 проектов в различных сферах и анализ показал, что 66 % багов возникают на этапе реализации (написания кода), 31% — на этапе постановки задачи и 3% дефектов содержатся в идеях фич.

Возникает вопрос: «А как же интеграционные баги?» Фича рассматривается как самостоятельная сущность, а интеграционный баг – это либо проблема внешнего сервиса и ее не решить силами команды, либо фича неправильно взаимодействует с исправным внешним компонентом.  

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

Переходим ко времени, которое затрачивается на тестирование требований.

Практика показывает, что тестирование требований на одну фичу (именно требований, а не фич) в среднем занимает от 25 минут до 6 часов. Значения более 2,5 часов встречаются крайне редко, а 4 и более часа ревью свидетельствуют о том, что фича перегружена требованиями и ей требуется декомпозиция.

Теперь рассмотрим время, затрачиваемое на корректировку ТЗ.

Исправления ТЗ занимают от 10 минут в случае мелких опечаток до 9-10 часов, если нужна серьезная переработка логики, получение дополнительной информации, созвоны, согласования, ожидание ответов и т.д.

И наконец, изучим распределение времени, которое тратится на исправление кода.

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

Анализ диаграмм позволяет сделать несколько выводов:

• Весомая доля (около 31%) дефектов зарождается на этапе создания ТЗ

• Типичное время тестирования ТЗ меньше, чем типичное время исправления кода (багофикса)

Обогащение модели жизненного цикла фичи реальными данными было бы не полным без сравнения затрат времени на реализацию. Однако, тут прикладывать какие бы то ни было диаграммы распределения времени сложно, поскольку информация получена с разных проектов, где фичи сильно различаются по размеру и трудоемкости. Значит, без объяснения, что делалось при реализации задачи, трудно понять затраты времени на нее. Более показательна статистика с проектов, где внедрили тестирование требований, как один из вариантов тестирования на ранних этапах разработки. 

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

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

Например, на тестирование требований не обязательно подключаться всем QA команды. Это могут делать отдельные сотрудники. Кроме того, в результате проверки требований часто происходят мелкие правки ТЗ, которые делают его более понятным и однозначным, что в итоге сокращает время, которое  уходит на вопросы и пояснения при разработке. 

Вариант 2. Тестирование силами разработчика

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

Тестирование ПО возникло практически одновременно с появлением софта для компьютеров. Изначально оно было исчерпывающим. При таком тестировании перебирались все возможные входные параметры программы. Занимались этим сами разработчики. Однако усложнение ПО сделало исчерпывающее тестирование слишком долгим, а в итоге и невозможным. Вследствие этого от специалистов понадобились специальные навыки, которыми не обладали разработчики. Так появились профессиональные тестировщики.  Разработчик может заниматься тестированием, только он будет это делать не слишком эффективно, поскольку он не специализируется на этом виде деятельности.

Наши QA-специалисты нередко подключаются на проекты, где не было тестирования как процесса,  выполняемого отдельными людьми. Приемочный аудит таких проектов показывает, что отношение количества багов критичности major и выше к общему количеству фичей составляет 26,4 % 

После подключения профессиональных QA этот процент сокращается до 1,3 %. Небольшой процент сохраняется, так как в выборке присутствуют проекты, где допустимо выкатывать релизы с определенным количеством major багов.

Еще один аргумент против тестирования силами разработчика – экономическая нецелесообразность. Пока он тестирует, процесс создания новых фич стоит на месте. А если принять во внимание стоимость рабочего часа, то вывод напрашивается сам собой: использовать разработчиков для полноценного тестирования ПО – дорого, медленно и малоэффективно. При этом мы еще не учитываем упущенную выгоду из-за пользователей, которые обнаружили пропущенные дефекты в продукте и отказались от его использования, репутационные потери и прочее.

Вариант 3. Отказ от регресса

Регрессионное тестирование (далее – регресс) – проверка ранее протестированного ПО или его отдельных компонентов, которая позволяет удостовериться, что последние внесенные изменения не повлекли за собой появления дефектов в неизмененной части программы.

Важная особенность регресса – в его регулярности. При этом может возникнуть вопрос: зачем тестировать то, что уже протестировано? Это непонимание впоследствии перерождается в отказ от проведения регрессионного тестирования.

 Необходимость и польза его проведения становится очевидной при детальном изучении жизненного цикла ПО.

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

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

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

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

Для исследования мы выбрали 46 проектов, каждый из которых был выпущен в релиз и просуществовал не менее полугода.

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

Анализ частоты возникновения регрессионных дефектов позволяет выделить два факта:

• Появление регрессионных дефектов с развитием проекта неизбежно.

• Чем сложнее и крупнее проект, тем больше вероятность появления регрессионных багов.

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

Кроме технических решений, разумно применять оптимизацию процессов тестирования и разделять регрессы по количеству производимых проверок на:

– крупные, которые будут проводится после изменений в ключевых компонентах;

– средние – в зависимости от серьезности внесенных изменений;

– мелкие, прогоняемые после каждого изменения в ПО.

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

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

Вариант 4. Отказ от тестовой документации

Тестовая документация – совокупность документов, которые создаются перед началом тестирования, а в некоторых случаях и в процессе. Она описывает покрытие требований тестами, а также процесс выполнения проверки ПО. В документации указывается вся информация, необходимая для тестирования. С точки зрения процессов она используется для структурирования работы QA.

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

Разумеется, создание тестовой документации требует времени, на котором часто экономят. Бытует мнение, что тестовая документация – это неоправданная трата времени и можно тестировать ПО без нее. Такое суждение складывается из-за непонимания последствий её отсутствия и неумения применять оптимальные виды документации в зависимости от особенностей проекта.

Начнем с первого. Тестовая документация позволяет планомерно, обстоятельно и полноценно оценить смысл и масштабы проверяемого функционала и покрыть его тестами. Её отсутствие не позволяет понять полную картину проекта и необходимого объема проверок. Без четких целей, пошагового плана их достижения и указания всех важных условий ожидаемый результат не будет ясен. В таких случаях велика вероятность забыть важные проверки и пропустить критичные баги. Это особенно актуально при работе со сложными продуктами или часто меняющихся требованиях.

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

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

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

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

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

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

Вместо вывода

Антирегрессионное тестирование – минимизируйте затраты

Регрессионное тестирование играет важнейшую роль в разработке продукта и считается непростой задачей. С этим трудно не согласиться, когда вы тестируете то, что уже было протестировано, а потом тестируете это снова. Термин «регрессия» ассоциируется у членов команды с большими усилиями. Мы знаем, насколько головоломным и вместе с тем незаменимым может быть регрессионное тестирование для процесса релиза и спрашиваем «Приведет ли невыполненное регрессионное тестирование к неудовлетворительному результату?» и «Нужно ли проводить регрессионное тестирование, если программа без ошибок – это недостижимая цель?» Что ж, ответом будет «Да! Регрессионное тестирование нужно проводить регулярно».

Что подразумевается под регрессионным тестированием?

На этот вопрос можно ответить одной фразой: «Исправляя одну ошибку, вы привносите в приложение несколько новых ошибок». Регрессионное тестирование – это то, что позволяет обеспечить исправление ошибки без побочных эффектов.
Во время тестирования выявляются некоторые ошибки, при этом разработчики проекта проводят быструю отладку. Тестировщики и разработчики проводят регрессионное тестирование, чтобы исправление ошибок не привело к нарушению функционала приложения.

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

Антирегрессионное тестирование

Сам термин «регрессионное тестирование» в некотором роде неточен. Правильнее было бы назвать тестирование «антирегрессионным», так как мы выполняем тесты, чтобы проверить, что система не регрессировала (то есть в результате внесения изменений в ней не возникло еще больше ошибок). Точнее говоря, цель регрессионного тестирования состоит в том, чтобы убедиться, что изменение или улучшение кода программы или среды не нарушило функциональность и не создало побочных эффектов.

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

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

Почему с регрессионными дефектами трудно иметь дело?

Регрессионные ошибки зачастую неизбежны и требуют исправления до развертывания. Регрессионные ошибки трудно исправить по нескольким причинам.

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

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

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

Тонкости исправления регрессионных дефектов

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

Существенные изменения программы и ошибки – обычные явления в разработке продукта. При необходимости каких-либо доработок необходимо обсудить их на совещании, на котором количество ошибок в регрессионном тестировании сводится к минимуму.

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

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

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

Сравнение регрессионного тестирования и повторного тестирования

Очень тонкая линия разделяет регрессионное тестирование и повторное тестирование.

Цель регрессионного тестирования – убедиться, что изменения не повлияли на неизмененённую часть. Повторное тестирование проводится для того, чтобы проверить, что тестовые сценарии, не прошедшие во время последнего выполнения, работают после исправления дефектов. Регрессионное тестирование не проводится для исправления конкретных дефектов. Повторное тестирование выполняется на основе исправлений дефектов.

Автоматизация – ключевой фактор регрессионного тестирования, тогда как повторное тестирование невозможно автоматизировать по причине неопределенности. Проверка дефекта проводится только в рамках повторного тестирования.

Когда применяется регрессионное тестирование?

Регрессионное тестирование рекомендуется выполнять при возникновении следующих событий:

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

Источник

Цена качества: 7 принципов оптимизации затрат на тестирование

Думаете, как сэкономить на тестировании вашего ПО? Вы не одиноки. Возникает лишь одно маленькое но: если софт не дотестировать, возможны самые негативные сценарии – от дорогостоящей и крайне невыгодной вам доработки приложения на поздних стадиях до потери репутации и ухода клиентов/заказчиков к конкурентам.

Готовы взять к себе в штат 50 самых опытных тестировщиков, чтобы обеспечить качество продукта? Вот же круто! А зачем? Нужно понимать: если выделите слишком большие ресурсы на тестирование в тех случаях, когда это неоправданно, вы раздуете бюджет и софт будет слишком дорогой. Обрадуются ли этому ваши пользователи и заказчики? Вы снова рискуете.

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

Принцип №1. Начинайте тестировать как можно раньше

Одна из самых распространенных ошибок – это начинать тестировать продукт на поздних стадиях, когда он практически готов к релизу. Чем раньше команда тестирования (QA) подключается к процессу разработки, тем ниже вероятность пропустить ошибку в продакшн. Кроме того, ошибка выявленная на ранней стадии разработки обойдется дешевле. В разы. Наш опыт показывает, что цена фикса на поздних этапах может оказаться в 30 раз дороже, чем фикс этой же ошибки, например, на стадии прототипа.

Случай из практики: мы очень долго ждали в тестирование серверное приложение, которое собирало и обрабатывало большой массив данных пользователей. Разработчики просто отказывались отдавать его, мотивируя это тем, что у них много проблем, а тестирование можно провести и в конце. В итоге они работали над новой версией четыре месяца.

Когда мы начали тестировать приложение с реальным объемом пользовательских данных, оказалось, что выбранная архитектура базы данных не справляется с такой нагрузкой. Команде разработчиков из пяти человек пришлось заново всё планировать, переписывать дизайн и архитектуру приложения, а нам – тестировать его с нуля. Релиз состоялся на шесть недель позже планового.

Итог: желание сэкономить 150 человеко-часов на тестировании и отодвинуть его к релизу привело к потере 1100 человеко-часов своих сотрудников и двойным затратам на тестирование.

Принцип №2. Экономьте, но только не на аналитике

Допустим, вы прислушались к нашим аргументам и решили реализовать первый принцип. На каком этапе разработки продукта выгоднее всего раскошелиться и подключить команду тестирования? Ответ: на этапе планирования архитектуры приложения, ну или хотя бы на этапе анализа и подготовки требований.

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

Мы помним страшилку о приложении для бега, которое было заточено под пользователей из Азии. Оно бы обязательно понравилось ЦА и принесло прибыль, если бы клиенты смогли установить приложение на свои смартфоны. Но они не смогли, а знаете почему? На этапе сбора требований была допущена ошибка, из-за которой приложение тестировалось на айфонах и смартфонах Samsung, которых в Азии – минимум. Ведь азиатские пользователи однозначно отдают предпочтение Huawei и OPPO.

В нашем примере сэкономить у разработчика опять не получилось. Мало того, что пришлось потратить 300 человеко-часов на доработку и тестирование продукта, так еще и репутационные издержки практически поставили проект на колени.

Итог: вы можете пригласить специалистов со стороны или ограничиться своими силами, главное – помните, что потребительское тестирование на этапе поддержки обходится в десятки раз дороже. И под дороже мы подразумеваем не столько денежные убытки, сколько репутационные издержки. Не экономьте на аналитике. Только не на ней!

Принцип №3. Определите цели и ожидания

Конечно же, вы хотите, чтобы всё работало, и работало хорошо. Но этого мало. Вам нужно понимать, насколько хорошо и почему именно настолько.

Знаете, как распознать хорошего тест-менеджера? Он сразу начинает «пытать» вас, чтобы понять, какого именно качества продукт вам нужен. Мы называем это сбором ожиданий. Качество вашего ПО складывается из определенных кирпичиков. Опытный тест-менеджер захочет узнать, какие именно кирпичики нужно положить в фундамент качества.

Когда к нам приходит заказчик и говорит: «Я хочу, чтобы оно работало», мы начинаем его расспрашивать: какая основная цель создания продукта? какие функции наиболее востребованы пользователями? как они их используют?

После сбора ожиданий идет постановка SMART-целей, их декомпозиция, построение задач и таблиц KPI. В итоге мы четко определяем:

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

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

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

Принцип №4. Автоматизируйте

…Но мудро. И предварительно посчитав ROI.

Чтобы автоматизация экономила ваши деньги, продукт должен быть стабильным. Впрочем, если он очень динамично меняется, это не значит, что автоматизация вам не поможет. Использование тулов и специализированных программ – уже автоматизация. Например, вы поможете автоматить рутинные операции, съедающие время ваших тестировщиков. Скажем, написать утилиту, которая собирает нужные конфигурации.

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

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

Итог: автоматизация может сократить трудозатраты на тестирование в десятки раз, а может слить бюджет впустую. Без умения анализировать и считать ROI вы всегда рискуете навсегда разочароваться в автоматизации.

Принцип №5. Научитесь использовать новичков

Не хотите автоматизировать? Тестеры с опытом бьют по бюджету? Подумываете нанять рукастых выпускников вузов за небольшую, но разумную зарплату? Неплохая идея, но есть несколько нюансов. Даже если у вас несложный продукт, одних новичков вам не хватит.

Ребенок может найти баг в игре и сломать приложение по методу манки-тестинг, но найдет ли он все баги? Конечно нет. Мы очень любим новичков, но они, как правило, не владеют методами исследовательского тестирования. Зато они могут «ходить» по тестам. Поэтому на компанию новичков с горящими глазами нужен «старичок», который пропишет проверки на том уровне, который будет понятен вашим новичкам.

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

Фрагмент набора кейсов для тестирования страхового продукта представлен ниже.

«Пакет новичка» может включать что-то совсем простое, но полезное, типа генератора данных.

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

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

Итог: выгодно использовать труд новичков без потери качества и скорости тестирования вполне возможно. Junior способен приносить реальную пользу на проекте уже со второй недели, сократив потери времени на адаптацию в 4 раза (со 160 до 40 часов).

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

Принцип №6. Вам не нужны сто тестировщиков, вам нужны те, кто работает головой

Тестировщиков не должно быть много, их должно быть достаточно. Вы же не хотите потратиться на отличных опытных ребят, которые будут просто скучать на работе или заводить никому не нужные миноры? Точно так же вы не захотите, чтобы сорок разработчиков завалили одного несчастного специалиста по тестированию всеми своими фиксами и у него не хватало ни времени, ни энергии на качественную работу над задачами. Итак, шестое правило баланса цены и качества – искать этот баланс.

Интуиция – это важно, но всё же старайтесь прибегать к помощи стратегов и аналитиков, которые помогут вам оценить объем задач, необходимое вам количество людей и их квалификацию.

Распространенный случай из практики. Не так давно к нам обратился клиент, у которого в команде было 12 тестировщиков: ТМ, senior, middle и 9 junior. Мы провели аудит процессов тестирования и отказались от восьми тысяч ненужных задач (таких как регресс незатронутой обновлениями функциональности, заведение миноров и т.д.), плюс придумали, как оптимизировать тесты. Оказалось, что проект нуждается в трех автоматизаторах (предложили своих) и еще одном middlе, которого вырастили из числа junior. От остальных новичков пришлось отказаться.

Далее мы оставили тестирование критичного функционала в блоке «Идентификация и квитовка» на middle. Они проверяли его вручную, исследовательским тестированием. Все остальные блоки практически полностью ушли на автоматизаторов.

В итоге это позволило:

– Снизить стоимость предрелизного тестирования с 232 400 до 35 200 рублей.

– Повысить ROI тестирования за счет автоматизации в 5 раз.

– Снизить управленческую нагрузку на руководство.

– Сократить время предрелизного тестирования на 23 человеко-часа.

– Повысить качество тестирования, оставив на проекте только опытных тестировщиков.

Принцип №7. Посчитайте, что вам выгоднее: штат или аутсорс

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

Еще один кейс из нашей практики: Как сэкономить более полутора миллионов рублей в год, наняв вместо девяти штатных тестировщиков с зарплатой 70 тысяч рублей девять аутсорсеров с зарплатой 130 тысяч.

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

В нашем примере штатный тестировщик с окладом 70 тысяч рублей в месяц обходится компании на 14 877 рублей дороже, чем более дорогостоящий специалист-аутсорсер, имеющий почти вдвое больший оклад. Если взять в расчет отдел из 9 человек, которые отработали год, то выгода составит 1 606 716 рублей. А это уже деньги.

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

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

Коротко о сказанном

1. По версии «Национального Института Стандартов и Технологии» стоимость тестирования в конце разработки может превышать её стоимость на начальных этапах в 15 раз, а после релиза в 30 раз.

Не хотите переплачивать? Начинайте тестировать как можно раньше!

2. Непонимание своей ЦА и её требований к продукту похоронило множество отличных проектов.

Экономите на аналитике? Готовьтесь платить за игру в угадайку!

3. Анализировать нужно не только ЦА, но и пожелания заказчиков. На их основе нужно уметь ставить и декомпозировать SMART-цели.

Не умеете ставить чёткие цели? Ваши цели непонятны заказчику? Закладывайте затраты на доработку и переделку!

4. Автоматизация помогает оптимизировать затраты на тестирование. Но не везде и не всегда.

Считаете, что руками тестировать выгоднее? Посчитайте ROI от автоматизации по нескольким сценариям и сравните цифры!

5. Новички в тестировании полны энтузиазма, но им не хватает опыта. Хороший наставник и «пакет новичка» повышает КПД джуна на проекте в 2-3 раза.

Набрали вчерашних выпускников за разумную плату? Готовьтесь доплатить за их превращение из «обезьянки» в человека!

6. Качество не равно количеству. Хороший специалист стоит дороже, потому что он даёт лучший результат.

Не хотите экономить, работая на результат? Тогда вам не стоит проводить аудит команды тестирования и оптимизировать её состав.

7. Аутсорс тестирования позволяет получить на проект опытную команду с гарантией результата. Но подходит аутсорс далеко не всем.

Хотите готовое решение с демократичным ценником? Рассчитайте преимущества от штата и от аутсорса, возможно второй вариант окажется в разы выгоднее.

Вместо эпилога

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

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

Нина Агеева,
Deputy Director at Лаборатория качества.

Источник

Этапы тестирования ПО

Тестирование является неотъемлемой частью жизненного цикла программного обеспечения. Само по себе тестирование – длительный процесс проверок на соответствие ожидаемого результата. Нельзя выделить какой-то один этап как важный, каждый из них имеет одинаковый вес. При создании продукта тестировщик не просто играет важную роль, а участвует на каждом этапе разработки от концепции до выхода продукта в свет.

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

Всего принято выделять 7 этапов тестирования:

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

Этап 1. Работа с требованиями

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

Тщательное изучение требований должно:

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

Этап 2. Разработка стратегии тестирования и планирование процедур контроля качества

Данный этап важен для лидов или менеджеров, поскольку от понимания полученной на предыдущем этапе информации зависит качество тестирования.

Этап 3. Создание тестовой документации

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

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

Тестовая документация может состоять из:

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

Этап 4. Тестирование прототипа

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

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

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

Этап 5. Основное тестирование

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

Важно понимать: невозможно найти все ошибки в продукте. Но и не найти ошибки при тестировании можно считать провалом. Главная цель — не сделать идеальный продукт без ошибок, а найти максимальное количество дефектов, которые потенциально могут сломать систему.

Этап 6. Стабилизация

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

Если продукт существует в какой-то большой системе, то на данном этапе также проверяется коммуникация системы и продукта, то есть проводится интеграционное тестирование.

Этап 7. Эксплуатация и поддержка

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

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

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

Источник

Цена ошибки: кто и сколько платит за промахи программистов?

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

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

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

Поговорим о деньгах, потерянных из-за ошибок в программном обеспечении, и росте нашей зависимости от программного кода. Тема неоднократно обсуждаемая (в том числе моим коллегой — Андреем Карповым — «Большой Калькулятор выходит из-под контроля»), и каждый новый пример доказывает: качество кода — не то, чем можно пренебрегать.

Космос

Дорогой дефис

Спутник Mariner 1 в 1962 году должен был отправиться к Венере. Стартовав с мыса Канаверал, ракета практически сразу сильно отклонилась от курса, что создало серьезную угрозу падения на землю. Для предотвращения возможной катастрофы NASA было принято решение запустить систему самоуничтожения ракеты. Спустя 293 секунды с момента старта, Mariner 1 был ликвидирован.

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

Программист неправильно перевел написанную формулу в компьютерный код, пропустив макрон или надчёркивание (что значит «n-ое сглаживание значения производной радиуса R по времени»).

Программа даже незначительные изменения скорости воспринимала как весьма существенные и проводила корректировку курса (источник).

Цена «пропущенного дефиса» — 18 млн долларов (на тот момент).

Российский GPS, опустившийся на дно

Ярким примером того, как из-за программной ошибки могут быть потеряны миллионы, является относительно недавний случай. Казалось бы, в 21 веке есть все необходимое для написания надёжных программ, особенно, если речь идет о космической отрасли. Опытные специалисты с отличным образованием, хорошее финансирование, возможность использования лучших инструментов для проверки программного обеспечения. Все это не помогло. 5 декабря 2010 года ракета-носитель «Протон-М» с тремя спутниками «Глонасс-М» — российский аналог GPS, упала в Тихий океан.

Причину аварии, после завершения расследования, озвучил официальный представитель Генпрокуратуры РФ Александр Куренной: «Установлено, что причиной аварии стало применение неверной формулы, в результате чего масса заправленного в бак окислителя разгонного блока жидкого кислорода на 1582 кг превысила максимально допустимую величину, что повлекло выведение ракеты-носителя на незамкнутую орбиту и его падение в акваторию Тихого океана» (источник).

Интересный момент в этой истории — документ о необходимости корректировки формулы был, но его списали как исполненный. Руководство же не удосужилось проверить выполнение своих указаний. Все причастные к аварии лица были привлечены к уголовной ответственности и крупным штрафам. Но это не компенсирует потери, составившие 138 миллионов долларов.

Автомобили

Еще в 2009 году профессор информатики в Техническом университете Мюнхена, эксперт по программному обеспечению в автомобилях Манфред Бра, сказал: «Программное обеспечение автомобиля премиум-класса содержит около 100 миллионов строк кода» (источник). С того момента прошло уже восемь лет, и совсем не обязательно быть поклонником передачи Top Gear, чтобы заметить: современные автомобили — это настоящие интеллектуальные машины.

По заявлению все того же эксперта, стоимость программного обеспечения и электроники в автомобиле составляет порядка 40% от его цены на рынке. И это касается бензиновых моторов, что же говорить о гибридах и электрокарах, где это значение равно примерно 70%!

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

Садиться за руль современных комфортных и «умных» авто или ездить на олдскульных, но понятных машинах? Решать вам, я же предлагаю небольшую подборку багов в программном обеспечении автомобилей.

И снова Toyota

Японские автомобили Toyota имеют положительную репутацию, но периодически в СМИ попадает информация об отзыве некоторого количества машин. В нашем блоге уже есть статья о программной ошибке в Toyota — «Toyota: 81 514 нарушений в коде», но этот случай, к сожалению, не единичный.

В 2005 году было отозвано 160 тыс. гибридов Toyota Prius 2004 года выпуска и начала 2005. Проблема заключалась в том, что машина могла в любой момент остановиться и заглохнуть. На устранение бага было затрачено около 90 минут на одно транспортное средство или около 240 тыс. человеко-часов.

Chrysler и Volkswagen

В мае 2008 года Chrysler отозвал 24535 автомобилей Jeep Commanders 2006 года выпуска. Причина — программная ошибка в модуле управления автоматической трансмиссией. Сбой приводил к неконтролируемой остановке двигателя.

В июне того же года Volkswagen отзывает около 4000 Passat и 2500 Tiguans. Здесь ошибка в программном обеспечении оказывала воздействие на увеличение оборотов двигателя. Показания тахометра начинали ползти вверх при включенном кондиционере.

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

Tesla

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

Поговорим, конечно же, о Tesla Model S. 7 мая 2016 Джошуа Браун, прославившийся благодаря своим роликам на YouTube, посвященным восхвалениям электромобиля, попал в автокатастрофу. Он находился за рулем Tesla Model S. Будучи на 100% уверенным в интеллекте машины, он доверился автопилоту. Результат доверия трагичный — от полученных травм Джошуа скончался на месте.

Катастрофа получила широкую огласку. Началось расследование. Удалось установить, что, по всей видимости, Браун самостоятельно не следил за дорогой, а автопилот столкнулся с ситуацией, которая не нашла отражение в его программном коде. Перед Tesla Джошуа двигался грузовик с прицепом. Автомобиль планировал выполнить маневр — левый поворот, соответственно, требовалось сбавить скорость. Но Tesla, едущий позади, не начал тормозить, т.к. системы автопилота не распознали находящийся впереди объект.

Произошло это, скорее всего, из-за яркого солнца. Лучи отражались от прицепа и автопилот воспринял грузовик единым целым с небом. В официальном докладе это объяснялось следующим образом: «Системы автоматического торможения Теслы являются технологией избегания столкновения в редких случаях и не спроектированы для надежного выполнения во всех режимах аварии, включая столкновения в результате пересечения путей» (источник). Полный отчет об аварии находится в свободном доступе.

Иными словами, автопилот призван помогать водителю (более совершенный круиз-контроль, грубо говоря), а не заменять его функции. Конечно, репутацию Tesla такое оправдание не сильно спасло. Работы над совершенствованием программного обеспечения продолжились, но Tesla Model S с дорог отозваны не были.

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

И это не риторический вопрос. Судя по новостям биржи, вопреки нашумевшей аварии, акции Tesla выросли на 50% с начала 2017 года. Способствуют этому два значимых фактора: популярность движений, выступающих за улучшение экологии в мире, и высокий личный рейтинг главы Tesla — Илона Маска.

Всеобщий масштаб — Беда 2038 года

Не могла не привести в завершении статьи этот пример. Подробно о Беде 2038 года вы можете прочитать в статье «2038: остался всего 21 год», я же остановлю внимание на одном важном моменте.

Оборудование для заводов: всевозможные станки, конвейеры; бытовая техника и другие сложные агрегаты, оснащенные специализированным программным обеспечением, имеют достаточно продолжительный срок службы. Вероятность того, что выпущенный в 2017 году станок будет функционировать и в 2038 очень и очень велика. Отсюда логично сделать вывод: проблема, когда 32-битные значения типа time_t больше не смогут корректно отображать даты, уже актуальна!

Если сейчас разработчики программного обеспечения не будут брать ее в расчет, то что же ждет программистов в 2038 году?! Есть все шансы на то, что ПО для встроенных систем устроит немало сюрпризов. Но, думаю, мы будем тому свидетелями.

Заключение

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

Можно ли найти виновного? Иногда да, иногда — нет. Но смысл не в том, чтобы найти крайнего и каким-то образом покарать его. Идея в другом — программы усложняются, они все больше входят в нашу жизнь, а значит и требования к надежности кода растут. Увеличивается цена типовых ошибок, ответственность за качество кода тяжелой ношей ложится на плечи разработчиков.

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

Желаю вам не допускать промахов, а вашим проектам никогда не попасть в подборку, аналогичную той, что приведена в этой статье.

Источник

пятница, 23 марта 2018 г.

Стоимость исправления ошибки на разных этапах разработки ПО

Если мы заметили ошибку на этапе написания требований, то исправить ее — дело 1 минуты, просто скорректировали предложение в тексте, и все.

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

Но это еще реально. А вот если мы уже все построили (написали код), то некоторые изменения просто нельзя внести и приходится мириться с багом. А даже если можно, то стоить это будет сильно дороже:
— аналитику поправить ТЗ;
— архитектору придумать, как поправить минимальными усилиями;
— разработчикам внести правки.

Почему на картинке Lee Copeland есть еще Release с самой большой стоимостью?

Картинка из книги Lee Copeland

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

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

Тем не менее такой подход до сих пор используют в больших организациях на сотни человек. Там с требованиями работает один отдел аналитики, потом передают дальше и так по каскаду все приходит в тестирование. С проблемами ошибки в требованиях приходится мириться…

Так что запоминаем: чем раньше найдена ошибка, тем проще ее исправить!

Поэтому тестировщики так важны. Чем раньше они заметят проблемы, тем проще будет их исправить!

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

Источник

7 принципов тестирования. Часть 2

В статье использованы материалы книги «Foundations of Software Testing: ISTQB Certification» by Dorothy Graham, Erik van Veenendaal, Isabel Evans & Rex Black.

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

Принцип 3. Раннее тестирование

Тестовые активности должны начинаться как можно раньше в цикле разработки и быть сфокусированы на определенных целях.
Этот принцип связан с понятием «цена дефекта» (cost of defect). Цена дефекта существенно растет на протяжении жизненного цикла разработки ПО. Чем раньше обнаружен дефект, тем быстрее, проще и дешевле его исправить.

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

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

Вот почему важно начинать тестирование как можно раньше, со статических техник.

Еще одно важное преимущество раннего тестирования – экономия времени. Тестовые активности могут начинаться еще до того, как написана первая строчка кода. По мере того, как готовятся требования и спецификации, тестировщики могут приступать к разработке и ревью тест-кейсов. И когда появится первая тестовая версия, можно будет сразу приступать к выполнению тестов.

Принцип 4. Скопление дефектов

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

Многие тестировщики наблюдали такой эффект – дефекты «кучкуются». Это может происходить потому, что определенная область кода особенно сложна и запутана, или потому, что внесение изменений производит «эффект домино». Это знание часто используется для оценки рисков при планировании тестов – тестировщики фокусируются на известных «проблемных зонах».

О том, где «кучкуются» дефекты, можно узнать еще на ранних этапах, когда проводится статическое тестирование (например, code review и анализ кода при помощи специальных инструментах). Когда дойдет дело до динамического тестирования, можно сфокусироваться на тех областях, где было обнаружено больше дефектов статическими методами.

Также полезно проводить анализ первопричин (root cause analysis), чтобы предотвратить повторное появление дефектов, обнаружить причины возникновения скоплений дефектов и спрогнозировать потенциальные скопления дефектов в будущем.

Источник

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

С ростом сложности ИТ- инфраструктуры из-за количества интегрируемых ИТ-систем происходит естественное увеличение потребности в тестировании ПО. Увеличивается количество и сложность тестов, а это, в свою очередь, существенно замедляет выпуск продуктов в эксплуатацию. С другой стороны, почти все организации стремятся сократить время выпуска программных продуктов, поэтому удлинение жизненного цикла ПО за счет возрастающих объемов тестирования воспринимается негативно. Иногда это превращается в частичный или даже полный отказ от тестирования и приводит к заметному снижению качества ИТ-услуг.

Пренебрежение тестированием приводит к следующим последствиям:

Желательно тестирование вводить как можно раньше, на этапе анализа требований, но давайте определим оптимальный момент, когда можно начинать тестировать.

Согласно исследованиям компании IBM стоимость дефекта увеличивается со временем (подробный отчет здесь).

График, представленный ниже, иллюстрирует зависимость стоимости устранения дефекта во времени жизни продукта:

Прямая времени (time) содержит несколько точек на своей оси:

A: дефект появился в системе вместе с коммитом кода.
B: Прошло менее одного дня, дефект не проявлялся раньше, но воспроизвелся при выполнении некоторой последовательности шагов. Такой дефект очень легко исправить.
C: Через несколько дней: мы помним какие изменения были произведены в системе, которые могли стать причиной дефекта, что может вызвать необходимость перепроверить дополнительные изменения, которые были введены в систему после тех, что стали причиной дефекта. Но, тем не менее, его все еще можно исправить без существенных затрат.
D: Выпуск/релиз: дефект начинает влиять на потребителя, а также на целостность вашей системы. Пофиксить дефект станет сложнее, это потребует дополнительных усилий.
E: Дефект пробыл в продукте на протяжении какого-то времени после релиза и уже повлиял на те части кода, которые не подвергались изменениям. Пользователи знают о том, что он есть, и вынуждены смириться с его существованием. Тем не менее, починить его становится сложнее, поскольку он уже глубоко в системе, и разработчик практически забыл, какие изменения стали причиной его возникновения.
F: Дефект существует в системе уже длительное время, и человек, который вводил изменения, вызвавшие данный дефект, больше не работает в компании. Починить такой дефект крайне сложно.

Зеленая линия отображает сумму всех затрат на исправление дефекта с течением времени и включает в себя:

Наиболее известны потери компании Toyota, обнаруженные в продукте после релиза.

В 2009 году Toyota отзывала проданные автомобили в связи с заклиниванием педали акселератора. Один из пассажиров Lexus ES350 позвонил в службу спасения: автомобиль начал неконтролируемо ускоряться на скорости 100 км/час и перестал реагировать на педаль тормоза. Погибли четверо пассажиров. В ноябре 2009 дилерам было предписано укоротить педаль газа, обновить программное обеспечение автомобилей и протестировать приложение содержащее ошибку, вызвавшую задержку в работе тормозной системы. Таким образом, к 2010 году было отозвано около 8,2 млн автомобилей. Не трудно представить масштаб затрат на исправление этой ошибки.

Стоит также отметить, что есть 2 вида затрат: косвенные и прямые.

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

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

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

Источник

Понравилась статья?

Подпишитесь на рассылку SimbirSoft! Пришлём письма о лайфхаках в разработке, поделимся опытом управления командами и компанией, а также расскажем о новых ивентах SimbirSoft.