Download to read offline
Uploaded bySQALab
Профилактика дефектов
Документ рассматривает профилактику дефектов в разработке программного обеспечения, описывая комплекс мероприятий, направленных на предотвращение их появления и выявление причин. Обсуждаются методы анализа и приоритизации дефектов, а также важность разработки документации и вовлечения команды в процесс. Используются различные подходы, такие как правило Парето и анализ '5 почему', для повышения качества сервиса и уменьшения времени на тестирование.
![[Sqa days]risk driven testing](https://cdn.slidesharecdn.com/ss_thumbnails/sqadaysriskdriventesting-101120014814-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Профилактика дефектов
- 1.
- 2.
- 3. Определение Деятельность по предотвращениюдефектов! Комплекс мероприятий, направленных на предупреждение возникновения дефектов, устранение факторов риска их появления. Процесс нахождения причины возникновения дефектов для предотвращения их возникновения в будущем
- 4. Виды профилактики дефектов Backlog POЗадачи Разработчики Код Тестирование Release- candidate ЭксплуатацияRelease Пользователи Хотелки, проблемы Support Manager Гипотезы, идеи Анализ ошибокАнализ требований (по Вигерсу)Тестирование требованийПроектирование, BDD, TDDCode Style, Static Code AnalysisCode ReviewReview Test CasesBeta TestingBackupingMonitoring Работа с пользователями в соцсетях FAQ
- 5. С чего начать??? Агрегироватьдефекты по общему признаку Приоритизировать дефекты Определить наиболее важные факторы влияющих на возникновение дефекта Оценка рисков
- 6.
- 7.
- 8. Системный подход, позволяющийна основе определения измеримых целей процесса, продукта повышать эффективность процессов в соответствии с потребностями проекта или организации. Цель вопрос вопрос вопрос метрика метрика метрикаметрика метрикаметрика Goals Question Metric
- 9. Goals Question Metric Повыситькачество сервиса Успешный ли запуск? Качественная ли картинка? Отношение всех запусков на количество успешных FPSбитрейт Потери Есть ли задержки в управлении? ping было 60% стало 90%
- 10. Анализ 5 почему? Долгаявыкладка сделанных задач: - много что нужно проверить перед релизом - после проверки не уверены в результате - отдаем в бэта тест на неделю. - не знаем, все проверили ли нет - в проекте почти нет документации Большое количество обращений с проблемой: - Баги проходят через тестирование - Низкая область покрытия тестами - Слишком много времени и ресурсов требуется для проверки текущего покрытия - Мы не знаем как оптимизировать время не потеряв в качестве - В проекте почти нет документации
- 11.
- 12. Анализ 5 почему? Многоуровневыйдокумент Много участников Есть результат ○ Гипотезы ○ Задачи
- 13.
- 14.
- 15.
- 16.
- 17. ВЫВОДЫ Главное начать … Вовлекайтедругих людей Не зацикливайтесь на одном … Относитесь к своему продукту по-человечески Внедряйте свои профилактики, если это действительно нужно.
- 18. Игры с «облаками» БельскихАндрей Тест-менеджер belskih@playkey.net Skype:wertuoz1986
Editor's Notes
- #2 1. Представиться и сказать пару слов о кампании 2. Нивелирует риски – стойкое впечатление 3. Поиск ответа
- #3 1. Соответсвеие болезни и дефекта – схожести 2. Конкретные профилактики 3. Орви – Бог плохой разработчик
- #4 1. Очевидно 2. Слова Гипократа – симптоматика 3. Уменьшение факторов риска – введение контроля качества на этапх жизненного цикла продукта 4. Помните увеличение времени на реализации ваших целей
- #5 1. Уменьшение рисков возникновения дефектов, увеличение реакции на дефекты и снижение негатива 2. Есть еще и Люди – некомпитенции 3. Конкретные болезни – конкретные профилактики. 4. Причина возникновения – Анализ дефектов – Что делать?
- #6 1. Группировка по признаку – примеры. Разбиение выборки по … 2. дефект – дефекту рознь – цифровой эквивалент – Аналитические данные, субъективное мнение, индекс риска 3. Одини дефекты важнее других – с числовыми данными можно строить графики
- #7 Классификации ошибок по типам
- #8 1. Супер крутой сервис облачных игр Play key 2. Много игр – много не критичных проблем 3. остылка к первому графику, виртуализация – новая техналогия – в нашем виде, пока ни где больше не используется 4. нет цели – нет результата. – но … дальше анализируем. Цель – это важно поэтому …
- #9 1. Качество продукта – какими вопросами мы оценим качество – запуск, картинка, задержки в управлении 2. реализация сбора данных метрик – анализируем их, для ее последующего улучшения
- #10 1. Метрические данные – для анализа факторов влияющих на данную метрику. 2. 3 месяца – вся команда
- #11 1. Бе-е-е. Просто. Почемучка. 2. Дождь и т.д. что придеться самому изучить термодинамику и молекулярную физику 3. Гнев на смертных – основная слабость 4. Единолично, безальтернативно
- #12 1. Альтернатива, привлечение команды, избегайте обвинений, не зацикливайтесь на цифре 5
- #13 1. Общий документ. Взгляд на проблему с разных сторон. 2. Один из примеров представил в виде схемы.
- #14 1. Похож но более комплексно. 2. Замечательный доклад Натальи Руколь и Олега Грабко – как оптимизировать тестирование на крупном проекте, рассмотрен на конкретном примере
- #15 1. Добавим еще проблем и зависимостей и …
- #16 1. Мешанина проблем и стрелочек. 2. Красные это корень зла всех ваших проблем. 3. Желтые узловые, слишком много стрелочек на входе и выходе – рассмотреть более внимательно, а не надуманные проблемы или не налаженные процессы 4. Прослеживается связь, опять виновата документация? Что-то не так 5. Книга теория ограничения Голдратта – дерево удущей реальности
- #17 1. Убрал вопросы и очевидные связи, чтобы они не нагромождали рисунок. 2. Проследим взяимосвязь метрики времени проверки релиза. Увеличилось, но засчет увеличения количества релизов
- #18 1. Не бойтесь ошибаться. Начните с малого. 2. Для вас очевидно или совсем не понятно посоветуйтесь со знающими людьми. 3. Не зацикливайтесь на одном инструменте или проблеме. 4. Такое отношение к вам вернется, земля то круглая. 5. Бог – создал болезни для профилактики.