Postmortem: учимся на собственных ошибках
•Download as PPTX, PDF•
1 like•1,036 views
SQA Days 11. День 2. Cекция A Анна Северинко Parallels Москва, Россия
Recommended
More Related Content
Similar to Postmortem: учимся на собственных ошибках
Similar to Postmortem: учимся на собственных ошибках (9)
More from SQALab
More from SQALab (20)
Postmortem: учимся на собственных ошибках
- 1. Postmortem: учимся на собственных ошибках TM Profit from the Cloud Анна Северинко
- 2. О себе 7 лет в тестировании 7 крупных и 200+ небольших релизов Руководитель отдела тестирования Server Virtualization & Cloud Platform
- 3. Понятие Postmortem Проект 1 Проект 2 Postmortem Postmortem в – это анализ процесса разработки в рамках конкретного проекта по горячим следам. TM 3 Profit from the Cloud
- 4. Подготовка Выделите время Выберите ответственного Согласуйте формат TM 4 Profit from the Cloud
- 5. Обратная связь от инженеров Тестировщики Разработчики Выберите человека, которому Переводчики доверяют Технические писатели Уточняйте детали Аналитики Архитекторы TM 5 Profit from the Cloud
- 6. Вопросы инженерам 3 плохие вещи 3 хорошие вещи 3 вещи, снижавшие эффективность TM 6 Profit from the Cloud
- 7. Что может снижать эффективность инженеров? TM 7 Profit from the Cloud
- 8. Выбираем самые популярные Сгруппируйте похожие Разбейте по командам Отсортируйте по популярности TM 8 Profit from the Cloud
- 9. Вопросы лидерам 3 плохие вещи 3 хорошие вещи 3 плохих решения 3 хороших решения 3 вещи, снижавшие эффективность TM 9 Profit from the Cloud
- 10. Цель – задуматься! Проанализируйте и запишите TM 10 Profit from the Cloud
- 11. Открытые баги Отметьте этапы проекта Проанализируйте скачки TM 11 Profit from the Cloud
- 12. Открытые баги TM 12 Profit from the Cloud
- 13. Критичность багов Снижайте количество блокеров! Обращайте внимание на всплески критичных багов TM 13 Profit from the Cloud
- 14. Resolutions Анализируйте количество Invalid & Cannot Reproduce багов TM 14 Profit from the Cloud
- 15. «Переоткрытые» баги Чем меньше, тем лучше! Проанализируйте всплески TM 15 Profit from the Cloud
- 16. Баги от бета-пользователей TM 16 Profit from the Cloud
- 17. Качество новой функциональности Фичи, переданные в тестирование, не работают? Повод разобраться! TM 17 Profit from the Cloud
- 18. Мозговой штурм Руководитель Найдите отклонения проекта Аналитик «от идеала» Обсудите причины Составьте план действий Руководитель отдела тестирования TM 18 Profit from the Cloud
- 19. Обсуждаем с командой Подготовьте презентацию Раскажите про хорошее и плохое Выслушайте и запишите предложения TM 19 Profit from the Cloud
- 20. Отслеживаем прогресс Контролируйте статус и сроки запланированных действий Регулярно смотрите на текущие метрики TM 20 Profit from the Cloud
- 21. Чего мы добились за 4 года? 15% «переоткрытых» 4% «переоткрытых» багов багов >18% фич, переданных Все фичи приходят в в тестирование, не тестирование без работают блокирующих багов Множество полезных Отсутствие репортов от репортов от бета- бета-пользователей пользователей Суббота – «официальный» В выходные отдыхаем! рабочий день Задержки релизов Задержки релизов более, чем на год менее, чем на месяц TM 21 Profit from the Cloud
- 22. E-mail: aseverinko@parallels.com Skype: anna_severinko Profit from the Cloud 22 TM
Editor's Notes
- 4 года назад были темные времена, на год задержали взвин, неконтролируемый процесс разработки, непонятно когда сходимся.Я надеюсь, что мой доклад поможет вам ... (понять, внедрить,получить след результат)
- Если мы говорим о вещах, которые снижают эффективность, доходит до смешного. Например, однажды выяснилось, что люди уходят с работы пораньше, потому что у нас рано заканчиваются печенюшки..Вы даже бы даже не догадались, что инженеры так страдают без печенек, если бы не этот опросник ;)
- Да и команде приятно, когда лидер честно признается, что понимает, что то или иное решение было плохое
- Пример: раньше имели тенденцию «копить» баги.Теперь стали раз в неделю анализировать и закрывать/переносить на следующие этапы баги, которые не собираемся исправлять в текущей версии.Второй график обычно строим, чтобы лучше понять что происходило на первомHint: Если команда постоянная, эти значения можно использовать для оценок сроков будущих релизов
- Пример: раньше имели тенденцию «копить» баги.Теперь стали раз в неделю анализировать и закрывать/переносить на следующие этапы баги, которые не собираемся исправлять в текущей версии.Второй график обычно строим, чтобы лучше понять что происходило на первомHint: Если команда постоянная, эти значения можно использовать для оценок сроков будущих релизов
- Пример с взвиномпро три критичные фичиПриняли решение избегать добавления большой и сложной функциональности на конечной стадии проекта.Показывайте график decision-maker-ам!
- Примеры:Ввели шаблоны багов (согласованный с разработчиками)Сделали автоматический сбор необходимой информации и логовВвели дополнительный этап согласования новой функциональности между аналитиками, разработчикам и тестировщиками
- Для разработчиков подготовили тестовую среду, идентичную той, которая используется в тестированииМного переоткрытых багов на финальной стадии – потому что именно там начинают их верифицировать! стали верифаить в теч всего жизненного циклаКстати, такое еще возможно, если баги просто нельзя заверифицировать – они заблокированы другими багами
- Мы долго были убеждены, что серверные бета-пользователи для мебелиУстановили минимальную продолжительность бета программы - 2 месяца
- Ввели ответственного за каждую новую функциональность