7 шагов к улучшению процесса тестирования в больших проектах

Если вы чувствуете, что несмотря на все ваши усилия, работа по управлению тестированием превращается в хаос, если вам сложно ответить на вопрос «Когда мы сможем выйти в релиз?», если не вы управляете процессом, а он начинает управлять вами, есть несколько идей, которые могут помочь вернуть контроль. Я хочу поделиться проблемными ситуациями, с которыми мы столкнулись в реальных проектах, и решениями, которые добавили организованности и избавили нас от лишних хлопот.
В докладе будут и советы от Капитана Очевидность (которые, впрочем, не казались такими очевидными, пока мы им не следовали), и best practices, адаптированные под наши нужды, и решения, придуманные нами самостоятельно, для облегчения своей жизни.
Итак, сегодня на арене:
- Работа с багтрекингом: как в любой момент знать сколько багов осталось исправить до релиза
- Хранение результатов тестирования: как в любой момент ответить руководителю на вопрос: «Какое состояние продукта?»
- Регрессионное тестирование: как сократить его объем, но гарантированно поймать то, что могло «посыпаться»
- Взаимодействие с разработчиками: как не запутаться в просьбах: «протестируй то, проверь это»
- Работа с гейзенбагами: как сделать так, чтобы разработчик смог исправить проблему, даже если она воспроизвелась у вас всего лишь раз
- Планирование и эстимейты: как легко оценить время на тестирование, если вы накопите немного статистики
- Работа с отложенными задачами: как не забыть после релиза сделать все, что вы откладывали на «после релиза»
Подчеркну, что речь идет об относительно больших и сложных проектах, т. е. Таких, где полное тестирование занимает больше двух недель, а проекты содержат более 20 отдельных функциональностей. В небольших проектах подобные решения могут не пригодиться.
Доклад будет полезен тест менеджерам и руководителям проектов, как впрочем и тестировщикам, которые интересуются судьбой своего проекта.

Презентация