на каком этапе дороже всего исправить найденную ошибку
Цена ошибки: кто и сколько платит за промахи программистов?
Современные программисты живут в интересное время, когда программное обеспечение проникает буквально во все сферы жизни человека и начинает существовать в бесчисленном количестве устройств, плотно вошедших в наш обиход. Сейчас уже никого не удивишь программами в холодильниках, часах и кофе-машинах. Однако, параллельно с торжеством удобства растет и зависимость людей от умной техники. Неизбежное последствие: на первый план выходит надежность программного обеспечения. Сложно кого-то напугать взбесившейся кофеваркой, хотя и она может натворить много бед (литры кипящего кофе стекают по вашей белоснежной мраморной столешнице. ). Но мысль о растущих требованиях к качеству ПО важна, поэтому поговорим об ошибках в коде, которые повлекли за собой существенные траты времени и денег.
Цель повествования — борьба с идеей, что к дефектам в программах можно относиться так же пренебрежительно, как и раньше. Теперь ошибки в программах — это не только неправильно нарисованный юнит в игре, сейчас от кода зависит сохранность имущества и здоровье людей. В этой статье я хочу привести несколько новых примеров необходимости трепетного отношения к коду.
Нельзя отрицать, что сложные программы все активнее входят в нашу жизнь: управляемая со смартфона бытовая техника, гаджеты, наделенные таким функционалом, о котором еще 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.
Косвенные — это затраты, связанные с качеством продукта, привыканием пользователей к новому продукту. В случае если тестирование продукта происходило с момента начала разработки проекта, прямые затраты на поддержку качества продукта всегда остаются примерно на одном уровне и растут только вместе с ростом проекта, а косвенные затраты минимизированы. В случае же когда тестирование не проводится вовсе, стоимость прямых затрат на тестирование отсутствует, а косвенные затраты от некачественного ПО растут безгранично. Для того, чтобы уменьшить рост косвенных затрат, необходимо вводить тестирование как можно раньше, как минимум до релиза, лучше всего в начале анализа требований к продукту и подготовке проектной документации.
Исходя из вышеперечисленного можно сделать вывод, что наиболее безболезненно и наименее затратно выпустить продукт в релиз можно в случае, если тестирование на предмет существования дефектов вводить как можно раньше, а именно на этапе формирования требований или во время разработки проекта. Не стоит экономить на тестировании, отсутствие которого приводит к недовольству пользователей продуктом, неконтролируемым расходам и может вылиться в потерю значительных средств.