Одна из первых причин - это недопонимание между разработчиком и заказчиком. Бизнес люди и разработчики, фигурально выражаясь, говорят на разных языках. Каждый считает, что его язык предельно прост и понятен, но на самом деле это не так. Недаром существуют системы, которые пытаются сблизить логику мышления Business and Technical people. Недопонимание разработчиков и заказчиков ведет к недопониманию того, что ПО должно или не должно делать.
Следующая причина, которая тaкже затрагивает коммуникации между заказчиком и разработчиком это плохо задокументированные и плохо согласованные с заказчиком требования. Спросите себя, какой процент проектов у вас был с хорошими требованиями (requirements) и историями пользователей (user stories). Хаос может породить только хаос.
Человек существо неугомонное. Он постоянно стремится к совершенству. Ни одному проекту не суждено избежать запросов на изменение (change request). Конечный пользователь обычно не понимает всех последствий, которые могут быть при внесении изменений в работающий код. Будь то изменения в дизайне или изменения, связанные с функционалом ПО. Более того всех последствий таких изменений не может предсказать и сам разработчик.
Особенно много ошибок может возникнуть, если процесс внесения запросов на изменения не контролируется и не документируется. Очень часто сведения об изменениях в функционале ПО не доходят до отдела тестирования. Заказчик или менеджер обсудили в кулуарах (email, ICQ, Skype) изменения, затем разработчики реализовали их. Test Lead и его команда очень часто не включается в CC такого обсуждения. Так появляются баги, которые на самом деле не баги...
Правильно спланировать процесс разработки и тестирования сложная задача! Зачастую такое планирование ведется интуитивно или на основе опыта, полученного на похожих проектах. Когда проект не укладывается в срок и разработка ведется ускоренными темпами, а на тестирование вообще не остается времени ошибок не избежать.
Существует статистика, которая свидетельствует об увеличении ДТП с участием водителей, имеющих 3-4 летний опыт вождения. Это происходит из-за переоценки своего мастерства. Самомнение членов команды разработки еще одна причина возникновения багов на проекте. Люди зачастую не могут реально оценить сложность поставленной перед ними задачи. Вместо адекватной оценки они говорят: “Без проблем”, “Для меня это пустяки” и т.д. Это, увы, приводит к ошибкам в разработке...
Мало писать код красиво, нужно код документировать! Плохо документированный код - источник ошибки.
Плохо документированные и плохо согласованные с заказчиком требования, отсутствие процесса управления требованиями являются причинами неудач многих проектов.
В статьях, приведенных ниже, вы можете сравнить возможности наиболее известных систем управления требованиями:
http://www.paper-review.com/tools/rms/read.php
http://www.processimpact.com/articles/rm_tools.html
Последней причиной в нашем списке, но не последней по значению является плохо организованное тестирование. Все дефекты найти невозможно, но грамотно построенный процесс тестирования сводит процент значимых для пользователя багов к нулю.
