🎯 Охота на баги - не наша работа "Нашёл 8 багов за спринт!" - думаешь это круто? А может ты просто нашёл 8 способов потратить время команды (и своё в том числе)
Это ловушка джунов:- Гордиться количеством багов в отчётах
- Радоваться находя CRITICAL прямо перед релизом
А что если твоя задача - не находить баги, а не дать им появиться? Занавес 🤯 Крутой тестировщик:- Участвует в планировании, чтобы предотвратить баги
- Помогает уточнять требования ДО написания кода
- Стремится сделать процесс разработки качественнее
- Учит команду думать о качестве
Баг-репорт - это не твоя история успеха. Это сигнал о проблеме в процессе. Посмотри видос в конце статьи (под кнопкой буста каналу)
В своем выступлении Алан Пейдж говорит: Мы не последняя линия обороны перед клиентом. Мы не те, кто убирает за парадом. Мы те, кто ускоряет доставку качества клиентам.
Не перебирай таски бездумно следуя кейсам, разбирайся в том, какую пользу несёшь компании. Для этого измеряй важдные показатели. 🔘Процессные метрики (время фикса, участие в планировании) 🔘Метрики качества (баги в проде vs разработке) 🔘Технические метрики (плотность дефектов)
🔍 Проводи Post-Mortem по каждому багу хотя бы для себя:◾️Где в процессе образовалась дыра? ◾️Можно ли было поймать баг раньше? ◾️Какие проверки добавить?
⚡️ Quick Tips: 🔹Внедряй парное тестирование на сложный задачах 🔹Показывай тест-план аналитикам, они много полезного посоветуют. 🔹Веди базу знаний по выявленным проблемам 🔹Делись находками с командой 🔹Используй данные для принятия решений, не впечатления и эмоции
Знаю, не везде можно внедрить всё это сразу. Начни с малого. Через месяц посмотри что изменится.
Калибруй свои метрики успеха.
Багов много бывает даже в качественных сервисах. Багов мало бывает и в глючном берьмище. Следи за качеством, а не количеством созданных задач 😉
БУСТ КАНАЛА⚡️⚡️⚡️ 📱 Видео Adventures in Modern Testing - Alan Page, Unity Technologies
А у вас считают баги? Как относятся к метрикам "количество найденных багов"?
