@Filipp42

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

Какие есть причины возникновения багов? Полагаю, можно выявит ряд случаев, которые часто приводят к их появлению. Есть ли какие-то книги, которые рассматривают этот вопрос?
Что говорит ваша практика как программистов? Можете ли вы накидать список?
  • Вопрос задан
  • 199 просмотров
Пригласить эксперта
Ответы на вопрос 4
vabka
@vabka
Токсичный шарпист
"самой распространённой причины" не существует. Она будет сильно зависеть от конкретного продукта и процессов разработки.

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

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

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

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

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

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

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

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

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы