Борьба с багами, или как мы провели внутренний эксперимент с командой QA

[Mizar91]

У меня вопрос - а куда они собрались поставить причину? В угол?

[talya_youth]

конечно же, на счетчик, чтобы было неповадно))

если без шуток, то выше пишу, что было добавлено отдельное поле в шаблон для заведения дефектов в jira:)

[yanpurvenes]

В итоге можно было не проводить это все, а просто обращать на тех долг, на хороший груминг фич и т.д.

[talya_youth]

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

[alcochtivo]

@talya_youth Если не забудете - отпишитесь тут через месяц, что по багам после внедрения изменений. Будет интересно посмотреть.

[talya_youth]

спасибо, обязательно отпишусь)

[S1rFluffy]

Наташа, спасибо за статью, впечатляющий результат по закрытию багов ☺️

А как решали проблему с путаницей техдолга и ошибок разработки? Появились ли у команд выработанные критерии?

[talya_youth]

спасибо за комментарий и вопрос)
на самом деле до сих пор нет какой-то явной прозрачности между этими двумя причинами возникновения дефекта. для этого команды так же проводят совместные встречи и обсуждают реальную причину.

[gigimon]

Т.е. вы экспериментальным путем подтвердили и так известные знания, что ошибки возникают из-за разработки? :)

[talya_youth]

иногда бывает так, что разработка ошибается из-за совокупности различных факторов. как писала выше, могут быть недоработаны требований, могут быть не учтены моменты дизайна, могут быть не оговорены корнер-кейсы или не хватило времени. говорить о том, что всегда на 100% виновата разработка, не совсем точно, и это мы и хотели подсветить:)

[vgurov_crystaltest]

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

Что касается будущего, то я уверен, что результаты не заставят себя долго ждать. Особенно важен 4-й пункт. Только следуйте ему последовательно и дисциплинированно, без поблажек и отговорок разработки типа "это занимает драгоценное время", "трудно поддерживать" и т.п. Я видел команды с хорошо поставленным юнит-тестированием, которые уверенно и быстро развивали продукт. Видел и другие, которые игнорировали юнит тесты. Эти не вылезали из бесконечной фиксации как новых, так и регрессивных багов, сыпящихся на них от тестировщиков и конечных пользователей.

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

[talya_youth]

спасибо большое за комментарий)
как раз делаем первые шаги в эту сторону и начинаем активно следить за юнит-тестами)