Мартыненко Сергей

Мне нравится научный метод познания мира.

1. Выдвигаем гипотезу. Делаем её верифицируемой (научной).

2. Проводим эксперимент.

3. Принимаем результаты эксперимента.

Иногда мы с коллегами проводим эксперименты. Некоторые результаты поразили даже меня. Например, задачи на анализ, тестировщики решают лучше аналитиков. В докладе я расскажу результаты эксперимента создания программного обеспечения по плохим требованиям. И постараюсь показать, как сделать их хорошими.

Перед докладом крайне рекомендую прочитать книги Голдратта «Синдром стога сена» и «Цель-1». Материал сложен без предварительного изучения базы. По трехбалльной шкале сложности этот материал примерно на пятерку.
Для затравки приведу список метрик, которые в принципе можно измерять. Как будет показано на докладе, это путь в никуда. 

1. Количество найденных багов.
- В целом
- По времени
- На пользователя
- Только критичные для функциональности ПО
2. Количество репортов от заказчика / клиента.
3. Время, затрачиваемое на тестирование очередной поставки.
4. Количество тестов которые прошли успешно или не успешно.
5. Проценты покрытия кода ( “Что можно получить от отслеживания данного показателя?”).
6. Процент покрытия требований тестами.
7. Количество отказов ПО за период времени.
8. Количество элементов, которые тестировщик поклацал (покрыл ручным тестированием).
9. Количество повторно открытых задач на тестирование.

Этот список – скорее информационный шум, нежели информация.

В куче книг по разработке ПО написано, что требования нужно тестировать. И по статистике на уровнях создания требований и проектирования в продукт закладывается больше ошибок, чем во время написания кода. 

Но.

Как только доходит до практики, требования часто просто не выверяют (а иногда и не читают). Если же доходит до выверки, то обычно все заканчивается проверкой орфографии и пунктуации. И потом ошибки попадают к конечному пользователю. Почему? Причин этому много. Первое – это психология. Здесь и «это придумано не у нас» и разные контексты мышления и многое другое. Второе это отсутствие описанных техник верификации. Литературы и тренингов по написанию требований довольно много, а вот по верификации практически нет.

На мастер-классе будут рассмотрены:

* психологические барьеры, мешающие верификации;

* техники верификации;

* пример верификации юзкейса, присланного участником сообщества uml2.ru.

Мастер-класс является частью моего тренинга по написанию и верификации требований.

Уровень сложности доклада очень высокий.