Почему тесты должны быть частыми и небольшими: Игра для команды

Эта игра наглядно показывает, почему функционал должен тестироваться небольшими кусочками и часто. Для игры понадобятся деревянные блоков, например, из настольной игры дженга. Необходимо пронумеровать блоки числами от 1 до 36.

Предложите участникам выбрать себе роли: несколько Разработчиков, Тестировщик.

Задание:

1. Необходимо построить из 36 блоков здание как минимум 3 этажа
2. Необходимо использовать все имеющиеся (качественные) блоки

Игра будет состоять из трех итераций, правила каждой из которых необходимо рассказывать перед каждой из них:

1. Разработчики строят здание без обратной связи. После этого приходит тестировщик и обозначает заранее загаданные 4 числа (4 проблемных блока), которые разработчик должен удалить таким образом, чтобы первоначальные требования были соблюдены.
2. 4 возможности для обратной связи. На этом этапе тестировщик просит удалить 1 проблемный блок после того, как в построенное здание будет добавлено 9 блоков.
3. Тестировщик может работать совместно с Разработчиками и сразу сообщает том, что один из блоков (всего 4) содержит проблемы и не может быть использован для строительства здания.

Вопросы по итогам игры:

— Ребята, как ощущения?

— Что вы заметили?

— Какие выводы вы можете сделать?

— Какие решения вы как команда можете принять по итогам игры?

Возможные выводы и наблюдения:

Тестировщик и Разработчики при совместной работе обеспечивают высокое качество программного обеспечения с меньшим количеством ошибок. В первом случае показан элементы водопадной модели, когда тестирование происходит после создания программного обеспечения. Если обнаруженные ошибки более фундаментальны (например, ошибочные блоки на первом этаже), проект будет завершен позже и с большими затратами.

Во втором случае обратная связь быстрее. Разработчик может скорректировать код раньше, и риск меньше, чем в первом варианте.

Третий вариант демонстрирует самый быстрый способ, и Тестировщик помогает Разработчикам избежать проблем в процессе написания кода.

Количество дефектов было одинаковой на каждой итерации. То, что было другим, — это скорость, с которой команда обнаруживала ошибку. Было гораздо выгоднее найти ошибку быстро (итерация 3) по сравнению с концом (итерация 1). Более того, даже если в 3 итерации было бы вдвое больше дефектов, их все равно можно было бы найти быстрее и получить продукт лучшего качества, чем в итерации 1.

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

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

Источник: poweragile.com