Как принести пользу разработке и упростить себе жизнь?
Download as PPT, PDF0 likes903 views
Презентация доклада Андрея Июдина на конференции SQADays-14, Львов 8-9 ноября 2013
![[Sqa days]risk driven testing](https://cdn.slidesharecdn.com/ss_thumbnails/sqadaysriskdriventesting-101120014814-phpapp02-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Viewers also liked (20)
Similar to Как принести пользу разработке и упростить себе жизнь? (20)
More from SQALab (20)
Как принести пользу разработке и упростить себе жизнь?
- 1. Как принести пользу разработке и упростить себе жизнь? Июдин Андрей. ЗАО БАРС-Груп
- 2. Прямые выгоды • Освобождение времени аналитиков и разработчиков • Увеличение числа найденных багов • Увеличение проверяемых вариантов работы продукта
- 3. Часть 1 О принципе «Разделяй и властвуй»
- 4. Проблема => Решение • Большой продукт сложно осознать целиком • Нет стартовой точки для того приступить к изучению продукта или его тестированию • Запутанность функциональностей Создание компонентов и разделов продукта
- 5. Путь решения • • • • Создать своё разбиение продукта на части Согласовать разбиения с PM’ами и аналитиками Создать схему связок компонентов и разделов продукта между собой Согласование окончательной «паутины» Дальнейшие доработки – работа аналитиков
- 6. Польза для тестирования • Удобство изучения продукта • Упрощение поиска смежных ошибок и последствий фиксинга • Упрощение планирования тестирования • Упрощение приёмочного и полного тестирования • Возможность одновременного тестирования продуктами несколькими тестировщиками
- 8. Плюшки проекту • Группа разработки может выделить зоны ответственности каждого разработчика • Группа аналитиков может выделить зоны ответственности каждого аналитика • Унификация процесса проектирования нового функционала или раздела • Удобство сбора продукта-конструктора
- 9. Часть 2 Говорите точно: сколько вешать?
- 10. Проблема => Решение • Объёмная логика функциональностей • Отсутствие знаний о нестандартных вариантах поведения системы • Сложности в написание тест-кейсов на функциональности Написание требований!
- 11. Путь решения • • • Взять наиболее понятный раздел продукта Описать требования на ТЕКУЩЕЕ состояние реализации Согласовать с аналитиками правильность поставленных требований на НЕОБХОДИМОЕ состояние Описание аналитиками требований на остальные компоненты Согласование написанных требований с тестировщиками
- 12. Польза для тестирования • Простота составления тест-кейсов • Возможность покрытия тест-кейсами всех аспектов функциональности • Чёткое планирование тестирования • Удобство автоматизации тестирования • Определение критичности возникающих ошибок • Отсутствие неверного понимания работы системы • Возможность тестирования спецификаций на новые компоненты
- 13. Плюшки проекту • Подробное изучение продукта самими аналитиками • Возможность увидеть продукт в нестандартных ситуациях поведения • Экономия времени на пояснение принципов работы функциональностей • Полная информация по необходимым доработкам в продукте (доведение состояния продукта до требований) • Предупреждение ошибок на уровне кодирования, возникавших из-за неясности в деталях реализации • Унификация доработки фунциональности в процессе: отмена требований => реализация новых требований
- 14. Часть 3 Порядок должен быть прежде всего в головах
- 15. Проблема => Решение • Нечёткие, расплывчатые постановки задач • Неорганизованный процесс приёмки задач • Отсутствие стандартов оформления задач Организовать процесс приёмки задач Выработать стандарты оформления задач
- 16. Общие плюшки • Разрешение споров между аналитикми и разработчиками • Уменьшение времени на консультации «треугольника» между собой по задачам • В задачах содержится вся необходимая для понимания информация • Задачи оформлены однотипно, следовательно они становятся более читаемы
- 18. И будет всем счастье • Разбиение продукта на разделы • Написание требований • Унификация постановки и приёмки задач Польза разработке. Облегчение жизни тестировщика