Какие есть самые распространённые причины появления багов?

Question

[Filipp42]

Какие есть причины возникновения багов? Полагаю, можно выявит ряд случаев, которые часто приводят к их появлению. Есть ли какие-то книги, которые рассматривают этот вопрос?
Что говорит ваша практика как программистов? Можете ли вы накидать список?

Comments

[Alexandroppolus]

самая распространенная причина багов - это программисты..

[Сергей delphinpro]

Alexandroppolus, с языка снял )

[Сергей delphinpro]

Причин множество. Напишу об одной.

Набор данных для тестирования.

Был случай. Писал ЦРМку, куча сущностей, куча связей. Ошибся в одной связи (невнимательность). В результате, на небольшом объеме тестовых данных все работало по той причине, что база перед тестированием очищалась и сидировалась заново, все идентификаторы шли с единички, и условно связь с идентификатором 1 указывала на нужную сущность. Когда залили реальную базу, все полетело к чертям, потому что условно связь с ИД 5000 уже указывала вообще на не существующий объект.

Answer 1

[Василий Банников]

"самой распространённой причины" не существует. Она будет сильно зависеть от конкретного продукта и процессов разработки.

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

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

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

4. Регресс. Разработчик нормально реализовал спецификацию, но тестировщик проверил только новую фичу и не стал проверять регресс - в итоге новая фича работает, а какая-то старая - сломалась, из-за того что её задели при разработке.

5. Несоответствие среды выполнения на этапе разработки, тестирования и в продакшене.
Например разрабатывали и тестировали на мощном железе, а при работе на слабом - всё плохо. Или сетевые задержки приводят к ошибкам, или на целевой машине стоит старая версия ОС, браузера, каких-то ещё зависимостей и поведение совсем меняется.

6. Во время разработки у заказчика поменялись планы. Старая спецификация больше не отвечает новым требованиям. Нужны доработки.

Чтобы минимизировать вышеперечисленное, нужно:
1. Плотное общение между разработчиком, аналитиком, и QA.
2. QA должен начинать тестирование ещё на этапе спецификации
3. Разработчик должен сообщать аналитику о всех случаях, когда он не может что-то реализовать или о каких-то пробелах.
4. Разработчик должен сообщать QA о возможном регрессе в других фичах.
5. Должны быть автотесты, чтобы уменьшить нагрузку на QA и чтобы минимизировать шанс на регресс
6. Тестирование должно обязательно производиться на том оборудовании и в том окружении, на котором система будет потом работать.
7. Чем чаще релизы - тем лучше.

Comments

[rPman]

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

Answer 2

[Snakecharmer]

Я никогда не встречал книг где рассматривались бы исключительно причины появления багов. Почитайте лучше просто книгу о тестировании. Например Базовый курс тестирования Святослава Куликова.

Причин много, всех не перечислить. Из-за чего может быть несоответствие требованиям / техническому заданию / документации (шире - несоответствие ожидаемого результата фактическому)?

1. Конфликт функциональностей: код новой фичи случайно затронул код другой фичи. Какая-то функциональность перестала работать должным образом.
2. Вышла новая версия используемого ПО (например новая версия ЯП) - и часть кода приходится переписывать, чтобы функционал снова заработал.
3. Какие то вещи просто сложно реализовать и у разработчика не хватает квалификации. И на выходе получается нечто страшное-ужасное.

Чтобы все это предотвратить нужно просто ответственно подходить к работе.

1. Менеджерам (в том числе менеджеру по продажам) и аналитикам лишний раз уточнить требования и сценарии использования.
2. Четко определить что именно понимается под понятиями: быстро, медленно, хорошо, долго, красиво...
3. Программист должен сообщать какие другие функциональности могли потенциально быть затронуты в процессе разработки. Чтобы тестировщик их тоже проверил.
4. Просто отталкиваться от здравого смысла.

Answer 3

[As56]

Криворукость программиста - самая распространенная причина бага, его некомпетентность и говнокодерство

Answer 4

[cyBEERkotleta]

На такой философский вопрос я бы ответила так: недостаток чистоты кода. Когда код структурирован; когда все переменные, методы, классы названы так, что становится понятно, для чего они; когда всё разделено на логические части - вероятность возникновения багов существенно снижается.