Программное обеспечение без багов
Серьезный тестировщикОтсутствие багов – заблуждение, в которое я раньше верил. Пока это убеждение не разбилось о реальность.
Возвращаясь в университетские будни, помню, как мы общались с другом, который работал в одной местной компании по разработке ПО. Он сказал, что у них на днях состоялся релиз (по каскадной модели разработки) и в нём было x,xxx багов.
Я был потрясён. Просто в шоке. Как же можно реализовать ПО с багами? Баги, о которых вы знали, баги, которые вы задокументировали и глядя на которые вы решили «ой, и так сойдёт, отправляем». Бедные клиенты!
Спустя годы, возможно, я стал более циничным или всё-таки начал смотреть более реалистичным взглядом, но есть много способов показать, что в любом коммерческом ПО баги отсутствуют.
Финансовая выгода от исправления багов
В реальном мире всем нужно зарабатывать деньги. Естественно, клиенты хотят получить от вас функцию, а в этих функциях (особенно в очень свежих) скорее всего есть баги/проблемы. Большинство разработчиков/QA с удовольствием исправили бы это. Но всё сводится к тому, насколько это финансово выгодно. Вы тратите 6 месяцев на исправление всех багов, которые знаете (а то и находите новые), или вы получаете новую функцию, клиенты платят вам деньги, и вы в процессе выясняете, с какими конкретно багами они сталкиваются и что нужно исправить?
Очевидно, что переложить ответственность на клиентов «протестить» ваше ПО не самый идеальный вариант, ведь если в нём очевидные дефекты, то вы потеряете и клиентов, и деньги. Поэтому, исправляем основные баги, самые очевидные и опасные, критические и самые важные. После релиза/регрессионного тестирования начнётся игра баланса – достаточно ли идеально ПО? Есть ли у нас запасной план по типу патча или исправления, выпускаемого в рамках технической поддержки, или может быть обходной путь, где помогут специалисты технической поддержки?
Как понять, что багов нет? Кто исправляет исправления?
Итак, ПО протестировано. Вся команда это проверила. Вы нашли уйму багов. Допустим, вы их исправите. Откуда вам знать, что этим вы не создали ещё больше багов? Обычно, запускается дымовой тест или регрессионное тестирование для проверки критических участков. Окей, вы найдёте ещё парочку и исправите их? Как вы можете знать, что не создали этим ещё больше проблем? Так может продолжаться вечно, но суть одна – исправление багов может создать новые проблемы, о которых вы даже не предполагаете.
Как знать наверняка, что все баги найдены?
Как и в предыдущем случае, вы скорее всего выполнили регрессионное тестирование. В идеале разработчики также провели модульное тестирование. Отлично! Этого достаточно? Они протестируют ВООБЩЕ ВСЁ?
Скажем, они охватывают достаточный масштаб. Супер, они проверяют орфографию в приложении? Что насчёт тестирования пользовательского интерфейса, вы тестируете каждый браузер? Каждую комбинацию прошивки с тестируемым устройством? Все возможные разрешения экранов? Всегда есть что тестировать, и как следствие, находятся ещё больше багов. Уже запустили статический анализ? Тут их найдётся ещё больше.
Ага, но я мог бы это доказать!
Существует несколько прекрасных теоретических статей, которые я достал в университете, где наглядно математически показано, что функция работает правильно. Это был ужас, ведь для простого метода потребовалась целая вечность. Может быть и можно доказать, что та или иная функция работает, но это также предполагает отсутствие багов в ваших доказательствах…
Один код в поле не воин
В инженерной фирме, мы столкнулись с одним багом из-за которого платы становились тоньше и тоньше, по причине того, что альфа-частицы буквально проникали внутрь и выполняли жонглирование битами. Может прозвучать, как преувеличение, но эти программные ошибки вызвали проблемы на национальных выборах и среди производителей автомобилей! Их код может быть идеален, но если биты переключаются и этого никто не обнаруживает, то держите новый баг в ПО, который от кода даже не зависит.
Ваш код не работает сам по себе. Скорее всего, он сидит поверх ОС, которая использует код драйвера, так что, вы можете передавать данные или использовать сторонние библиотеки, которые могут вызвать баги или уже иметь их в наличии, тем самым, выливаясь в проблемы в вашем коде.
Пользователь никогда так не сделает
Много лет назад мы столкнулись с проблемой в ПО обеспечения управления воздушного движения. Был инструмент для моделирования, с помощью которого авиадиспетчер мог обводить самолёты, проводить линии между ними и тому подобное. Инструментом без проблем пользовались годами, самолёты по всему экрану, линии везде где можно. Но ведь это была лишь простая утилита для рисования линий, никто её не использовал для чего-то большего, так?
А теперь, перенесёмся в дни Рождества, когда диспетчер от скуки решил ночью нарисовать на своём экране северного оленя. Огромное количество соединённых линий вызвало переполнение графической библиотеки и вывело всю систему из строя. Никто не мог подумать, что такой сценарий вообще возможен.
Что такое баг?
Некоторые баги, к сожалению, субъективны. В конце концов, качество ПО должен определять конечный пользователь/заказчик, и, если он посчитает что в ПО баг, даже если вы так не думаете, это уже недопонимание, ошибка в требованиях или проблема в потоке взаимодействии с пользователем. Поэтому, даже если вы считаете, что в ПО баги отсутствуют, тот факт, что ни одно масштабное приложение не получает 5 звёзд в отзывах от каждого пользователя, говорит о том, что всё равно найдётся нечто, что будет расстраивать клиентов.
Отличные новости!
Вот только не стоит из-за этого расстраиваться. Внести утешения, скажу - всё хорошо, что в меру. Не стремитесь к совершенству, стремитесь изо дня в день создавать классное, качественное ПО, которое порадует клиентов. С кем-то это всё равно не сработает, и это нормально, просто помните.
Оригинал статьи: https://itnext.io/there-are-zero-bugs-in-the-software-8e50d02d298e