Lesson 102
Слово Канеру:
Ускорить процесс разработки вместо экономии нескольких долларов на тестировании.
Усилия по автоматизации тестирования, направленные на сокращение расходов тестирования редко привлекают внимание и поддержку, необходимую для достижения успеха.
Если ты ждешь поддержки, сфокусируй усилия на уменьшении рисков разработки.
Сценарии тестирования являются настолько мощными, насколько они помогают получать вам и вашей команде информацию о тестируемом продукте. Автоматизированное тестирование увеличивает их мощь, помогая быстрее собирать и обрабатывать информацию , давая быструю обратную связь программистам. Наиболее успешные компании автоматизируют тестирование для увеличения гибкости разработки. Вот некоторые цели их усилий:
- Быстрое обнаружение дестабилизирующих изменений в новых билдах.
- Максимально быстрое обнаружение регрессионных дефектов.
- Быстрое информирование о проблемах, так как это делает их исправление простым.
Быстрые исправления сохраняют код стабильным. Стабильный код сохраняет время (несколько человек не потратят время на ошибку),облегчает рефакторинг и другие усилия по улучшению структуры кода, выпрямляет запутанный код.
Если кодовая база в значительной степени стабильна и покрыта большим набором автоматизированных тестов, программисты могут пытаться вносить большие изменения с меньшим риском. Также, команда продукта может варьировать объем функциональности ии дату выпуска продуктов и в кратчайшие сроки реагировать на потребности рынка.
Вот несколько примеров для поддержания высоких темпов разработки.
Автоматизированные Smoke-тесты Термин smoke-тест пришел из тестирования аппаратного обеспечения. Ты подключал новую плату и включал питание. Если ты видел дым - ты выключал питание и делать какие-любо другие тесты не было необходимости. Smoke-тесты (или тесты вирификации билда) как можно шире покрывают фичи продукта за ограниченное время - обычно за обед или за ночь. Если ключевые фичи не работают или ключевые ошибки не исправлены, команда не будет тратить время на инсталляцию и тестирование билда. Исправление этих проблем становится приоритетной задачей программистов.
Автоматизированные юнит тесты. Эти тесты также упорядочивают процесс разработки, предотвращают дефекты и поддерживают движение. Это большой набор тестов сосредоточен на тестировании низкоуровневых функций и классов продукта.
Наибольшая ценность smoke и unit тестов в том, что любой тест может быть запущен в любой момент. Их автоматический запуск - часть процесса разработки. Их наличие позволяет отдельным программистам создавать минибилды включающие одно или несколько изменений. Если один из минибитлов сломан, то программисту известно, с чего начинать расследование. Если минибилды в порядке, то и большой билд, собирающий все изменения, пройдет успешно. Это преимущество руководитель проекта, несомненно, оценит.
Эти виды автоматизированных тестов теебуют времени, усилий, мастерства и денег. Unit-тесты, скорее всего, создадут программисты, хотя вы бы могли стимулировать эту работу, написав код вместе с ними, как часть парного программирования. Со всеми этими преимуществами вам будет проще обеспечить сотрудничество, чем если бы вы направили усилия на сохранение времени ручного тестирования (Beck 1999, Часть 20).
Ускорить процесс разработки вместо экономии нескольких долларов на тестировании.
Усилия по автоматизации тестирования, направленные на сокращение расходов тестирования редко привлекают внимание и поддержку, необходимую для достижения успеха.
Если ты ждешь поддержки, сфокусируй усилия на уменьшении рисков разработки.
Сценарии тестирования являются настолько мощными, насколько они помогают получать вам и вашей команде информацию о тестируемом продукте. Автоматизированное тестирование увеличивает их мощь, помогая быстрее собирать и обрабатывать информацию , давая быструю обратную связь программистам. Наиболее успешные компании автоматизируют тестирование для увеличения гибкости разработки. Вот некоторые цели их усилий:
- Быстрое обнаружение дестабилизирующих изменений в новых билдах.
- Максимально быстрое обнаружение регрессионных дефектов.
- Быстрое информирование о проблемах, так как это делает их исправление простым.
Быстрые исправления сохраняют код стабильным. Стабильный код сохраняет время (несколько человек не потратят время на ошибку),облегчает рефакторинг и другие усилия по улучшению структуры кода, выпрямляет запутанный код.
Если кодовая база в значительной степени стабильна и покрыта большим набором автоматизированных тестов, программисты могут пытаться вносить большие изменения с меньшим риском. Также, команда продукта может варьировать объем функциональности ии дату выпуска продуктов и в кратчайшие сроки реагировать на потребности рынка.
Вот несколько примеров для поддержания высоких темпов разработки.
Автоматизированные Smoke-тесты Термин smoke-тест пришел из тестирования аппаратного обеспечения. Ты подключал новую плату и включал питание. Если ты видел дым - ты выключал питание и делать какие-любо другие тесты не было необходимости. Smoke-тесты (или тесты вирификации билда) как можно шире покрывают фичи продукта за ограниченное время - обычно за обед или за ночь. Если ключевые фичи не работают или ключевые ошибки не исправлены, команда не будет тратить время на инсталляцию и тестирование билда. Исправление этих проблем становится приоритетной задачей программистов.
Автоматизированные юнит тесты. Эти тесты также упорядочивают процесс разработки, предотвращают дефекты и поддерживают движение. Это большой набор тестов сосредоточен на тестировании низкоуровневых функций и классов продукта.
Наибольшая ценность smoke и unit тестов в том, что любой тест может быть запущен в любой момент. Их автоматический запуск - часть процесса разработки. Их наличие позволяет отдельным программистам создавать минибилды включающие одно или несколько изменений. Если один из минибитлов сломан, то программисту известно, с чего начинать расследование. Если минибилды в порядке, то и большой билд, собирающий все изменения, пройдет успешно. Это преимущество руководитель проекта, несомненно, оценит.
Эти виды автоматизированных тестов теебуют времени, усилий, мастерства и денег. Unit-тесты, скорее всего, создадут программисты, хотя вы бы могли стимулировать эту работу, написав код вместе с ними, как часть парного программирования. Со всеми этими преимуществами вам будет проще обеспечить сотрудничество, чем если бы вы направили усилия на сохранение времени ручного тестирования (Beck 1999, Часть 20).