Мартыненко Сергей
Биография:
Продолжаю писать "Байки для оруженосца".
Доклады
Ключевые метрики тестирования
Перед докладом крайне рекомендую прочитать книги Голдратта «Синдром стога сена» и «Цель-1». Материал сложен без предварительного изучения базы. По трехбалльной шкале сложности этот материал примерно на пятерку.
Для затравки приведу список метрик, которые в принципе можно измерять. Как будет показано на докладе, это путь в никуда.
1. Количество найденных багов.
- В целом
- По времени
- На пользователя
- Только критичные для функциональности ПО
2. Количество репортов от заказчика / клиента.
3. Время, затрачиваемое на тестирование очередной поставки.
4. Количество тестов которые прошли успешно или не успешно.
5. Проценты покрытия кода ( “Что можно получить от отслеживания данного показателя?”).
6. Процент покрытия требований тестами.
7. Количество отказов ПО за период времени.
8. Количество элементов, которые тестировщик поклацал (покрыл ручным тестированием).
9. Количество повторно открытых задач на тестирование.
Этот список – скорее информационный шум, нежели информация.
Жестокое обращение с ошибками в требованиях на глазах у публики
В куче книг по разработке ПО написано, что требования нужно тестировать. И по статистике на уровнях создания требований и проектирования в продукт закладывается больше ошибок, чем во время написания кода.
Но.
Как только доходит до практики, требования часто просто не
выверяют (а иногда и не читают). Если же доходит до выверки, то обычно все
заканчивается проверкой орфографии и пунктуации. И потом ошибки попадают к
конечному пользователю. Почему? Причин этому много. Первое – это психология.
Здесь и «это придумано не у нас» и разные контексты мышления и многое другое.
Второе это отсутствие описанных техник верификации. Литературы и тренингов по
написанию требований довольно много, а вот по верификации практически нет.
На мастер-классе будут рассмотрены:
* психологические барьеры, мешающие верификации;
* техники верификации;
* пример верификации юзкейса, присланного участником сообщества uml2.ru.
Мастер-класс является частью моего тренинга по написанию
и верификации требований.
Подготовка стратегии тестирования под высокорискованный, высокодоходный проект
4. Ошибка в системе, подобная описанной в "данетке для разработчика" (http://goo.gl/xJfVcj), может сделать фирму банкротом в течении часа.
В ходе доклада будет:
- Рассмотрен обобщенный алгоритм построения стратегии тестирования.
Подробно показано, как выстраивается фасет за фасетом стратегия и как улучшается поток в целом для конкретного случая.
Также будет показано отличие стратегию от не стратегии.
- В первую очередь тестменеджеры. Им это нужно, потому что им писать и отстаивать стратегию тестирования.
- Руководители проектов. Им согласовывать стратегию тестирования с общей стратегией разработки.
- Рядовые тестировщики. Им это нужно для понимания и приятия стратегии.
Уровень сложности доклада очень высокий.