Как стать автором
Обновить

Багодельня: BUgHunting. Как найти 200 багов за день

Время на прочтение6 мин
Количество просмотров8.3K
Всего голосов 20: ↑20 и ↓0+20
Комментарии7

Комментарии 7

НЛО прилетело и опубликовало эту надпись здесь

Получается все эти баги были пропущены основными командами тестирования по проектам, анализировали с чем это связано? Может баги сложно воспроизводимые или времени не хватает.

— получилось так, что благодаря свежим силам, количеству участников и их разному опыту смогли нашли как интересные и хитрые баги, которые пропустили(тут повлияло и отсутствие времени и замыленный взгляд) команды, так и незначительные ошибки;
— какие-то фичи команды ещё толком не тестировали и к началу мероприятия мы их получили с пылу с жару;
— основные команды уже знали о части багов, но т.к. они были заведены у них в собственных проектах в JIRA, участники их не видели. Чтобы не заставлять всех тратить время на поиск этих тасков по всей багтрекинговой системе, мы предложили заводить все баги в новом проекте JIRA с чистого листа;
— были и дубли багов во время самого мероприятия.
Понятно что проводилось ознакомление с проектом. Но непонятно как потенциальные кандидаты ознакамливались с требованиями, особенно если они из другого проекта. И была ли процедура определения баг это или всё же фича? Сложилось впчатление что заводили все что нашли без розбирательства. Как все таки проходила процедура определения багов/фич?
Мне кажется, не стоит заострять на этом вопросе внимание во время такого мероприятия. Если ребята решили что это баг, даже если это не так, то это повод для исследования момента UI/UX дизайнером. Возможно, у новых пользователей программы возникают такие же мысли.
(Не имею отношения ни к авторам, ни к этому мероприятию)
Верно.
Плюс мы кратко рассказывали про каждый проект перед началом сессий и всегда можно было задать вопросы команде аудита.
Спасибо за ответ. Теперь стало более понятно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий