Lesson 182

Сегодня было снежное замечательное утро.
Вот пруфпик снега:

Альбом: office

Вот пруфпики замечательности - раз:

Альбом: office

два:

Альбом: office

и три:

Альбом: office

Слово Канеру

Качественное планирование тестирования делает последующие изменения легкими.

Если изменения на поздних этапах неизбежны, наша задача — создать процесс тестирования, который сможет с ними работать. Вот несколько советов:

- Вместо разработки большого набора тестов до начала тестирования, разрабатывайте тесты тогда, когда они вам нужны. Если дальнейшие изменения в продукте сделают их устаревшими, то они будут полезными хотя бы какое-то время.
- Не создавайте огромных документов по тестированию, требующих больших эксплуатационных расходов, таких как подробные сценарии тестирования. Держите документы настолько маленькими, насколько это возможно.
- Не привязывайте ручные или автоматизированные тесты к специфике GUI, кроме тестов, специально для этого предназначенных. Даже если вы тестируете в качестве конечного пользователя, обязательно работающего через интерфейс, не завязывайте ваши тесты на мелкие детали интерфейса, так как они могут меняться.
- Проектируйте автоматизированные тесты так, чтоб максимизировать их ремонтопригодность и переносимость между платформами. (См. часть 5, «Автоматизация тестирования»)
- Создайте набор тестов, следящих за действиями, которые повторяются в программе постоянно. Это сохранит время на планирование и упростит делегирование, когда будуту добавлены фичи или функциональность будет изменена.
- Создайте качественный набор Smoke тестов, для быстрого обнаружения сбоев в ПО. Если программисты вносят значительные изменения, то они, вероятно, часто пересобирают ПО и с удовольствием будут высылать вам новые билды как можно чаще. Smopke-тесты дешево находят плохие сборки, что делает их полезными для того, чтоб справиться с частыми билдами.
- Всерьез рассмотрите возможность использования техник экстремального программирования для разработки автоматизированных тестов (Beck 1999 и Jeffries в 2000). В частности мы рекомендуем разработать общую архитектуру для автоматизированных тестов, а затем итеративно дорабатывать их код, минимизируя риски проекта (здесь проект автоматизации рассматривается как подпроект продукта). Попробуйте программирование в парах, общайтесь с заинтересованными лицами (другими тестировщиками, менеджерами) чтоб определить направления работы.
- Разработайте модель пользователя продукта, определите пользу, которую хочет получить пользователь от продукта. Создайте комплексные тесты на основе этой модели. Большинство таких тестов не будет быстро меняться, так как они ориентированы на цели пользователя, а не на детали реализации.
- Помогите программистам создать большой набор юнит-тестов и других тестов, проверяющих базовую функциональность продукта. Они могут запускаться каждый раз при изменении кода, перед отправкой в тестирование.

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