Нет ни одного программного продукта в котором нету ни единой ошибки. Это
аксиома и все про это знают. И если с мелкими и незначительными ошибками,
которые не препятствуют использованию продукта можно мирится, то другие ошибки,
которые порой вызывают катастрофы мирового масштаба нужно что то делать. Ниже я
попытаюсь разобраться в причине, почему же все таки такие ошибки возникают, что
является их причиной и можно ли сделать что нибудь что бы их устранить еще на
самом раннем этапе. Итак, топ-10 источников ошибок в программном продукте.
1. Человеческий фактор
Итак это самое очевидное и с этим пунктом все понятно. Любой программист
является обыкновенным человеком, которому свойственно делать ошибки, даже
самому квалифицированному, и самому опытному. Тут ничего нельзя поделать и нету
универсального средства, как избежать таких ошибок. Разве что попросить разработчиков быть повнимательнее.
2. Проблемы коммуникации
Источником это проблемы может быть непонимание разработчиком в деталях того,
что от него хотят. В итоге получим продукт который выглядит как задумано, но
делает все немного не так. Другой причиной ошибок из этой категории может быть неочевидность и нелогичность разрабатываемой
функциональности. Чем более запутанная логика тем больше шансов, что ее
реализацию будет неидеальна. Что можно сделать в этом случае? Достаточно будет
просто сделать все требования простыми, логичными и понятными. Согласен это не
всегда возможно, но нужно хотя бы к этому стремится.
3. Сжатые сроки разработки
Любая задача, даже самая простая, требует времени на осмысление,
проектирование, реализацию и, наконец, тестирование. В реальности часто бывает
что программные продукты создаются в сжатые сроки и с недостаточными ресурсами.
Как результат времени хватает только на, собственно, реализацию, и то не
всегда. Как результат времени на проектирование, тестирование и все остальное
просто нету. Результат очевиден. Что-то делать? Ответ лежит на поверхности
добавить времени и ресурсов.
4. Плохое проектирование
Данная проблема может иметь место про разработке сложной большой системы.
Процессу проектирования не предшествовал в должной мере этап анализа требований,
изучение всевозможных нюансов работы системы и поиск наиболее подходящих
решений для реализации. Причиной того, что качество проектирования не было
высоким, не обязательно должна быть недостаточная квалификация проектировщиков,
чаще причиной является опять таки недостаток времени или внутренние правила
проектирования которые препятствовали созданию качественной архитектуры.
Решение очевидно –потратить на проектирование столько времени сколько нужно, а
не столько, сколько возможно.
5. Плохие практики разработки
Плохие практики разработки применяемые сотрудниками во время работы над
проектом также имеют плачевные последствия. Неправильный механизм обработки
ошибок и исключений, отсутствие логирования, валидации данных – все это очень
негативно сказывается на качестве кода и как следствие количеству ошибок в
результате. Для исправление ситуации всегда нужно работать над усовершенствованием
применяемых практик, до во время и после осуществления этапа разработки.
6. Отсутствие системы контроля версий
Казалось бы причем тут система контроля версий. Благодаря ей можно
отслеживать все изменения в коде, весь прогресс проделанной работы, иметь перед
глазами информацию о найденных и исправленных дефектах и изменениях. Список
тест-кейсов для регрессионного тестирования позволит вам никогда не пропустить
какую нибудь мелочь, которая приведет к большому краху вашего продукта.
Используйте систему контроля версий – она действительно сделать вещи проще и
лучще.
7. Глючные сторонние инструменты
Достаточно часто, если не сказать больше – практически всегда – в проектах
используются сторонние компоненты, библиотеки и инструменты. Не все они
идеальны и иногда можно столкнуться с ситуацией когда использование
некачественного компонента является той самой причиной из-за которой проблемы
имеются и в вашем решении. Поэтому нужно использовать только качественные и
хорошо протестированные сторонние решения.
8. Недостаток квалифицированного тестирования
Увы, такое тоже встречается везде и повсеместно. Даже если на вашем проекте
уделяется достаточно внимания тестированию и ресурсам для тестирования это не
значит что это полностью решит проблему с дефектами на вашем проекте. Постоянно
работайте над повышением квалификации ваших QA и совершенствованием применяемых ими методик тестирования.
9. Изменения за 10 минут до релиза
Я верю что эта проблема становиться все менее актуальной, но понимаю что
моей веры недостаточно что бы ликвидировать проблему целиком. Прискорбно, но даже
на самом «правильном» проекте случаются ситуации когда вроде бы все и написано и
протестировано и в целом все хорошо. Но вот за минуту до того как нужно
осуществлять деплой проекта возникает необходимость какого-то незначительного
изменения который «ну уж точно ни на что не повлияет» . И очень часто именно
это изменение является тем злом которое породило новые дефекты в вашем
продукте.
Постойте, а где же десятая причина? Хех, я знаю что она есть, но часто
оказывается что отличается от проекта к проекту. Поэтому последний пункт я
оставил для вас, моих читателей, что бы вы сами поведали всему миру он вашей
десятой причине, прямо здесь в комментариях к этой статье.
Не перевод, но за основу взята
статья http://software-testing-zone.blogspot.com/2008/12/why-are-bugsdefects-in-software.html
