При создании набора приемочных тестов необходимо учитывать множество факторов и применение непрерывной интеграции (CI) на проекте накладывает дополнительные требования для организации автоматизированных тестов.
Такими дополнительными требованиями можно назвать, например:
1. Скорость разработки и отладки тестов.
Такие тесты необходимы как можно раньше, их приоритет выше остальных автоматизированных тестов. Запуск тестов после каждого нового изменения в продукте позволяет быстро реагировать на появление проблем и убедиться, что новая версия проходит хотя бы приемочное тестирование.
2. Легкость взаимодействия с системой непрерывной интеграцией и другими компонентами, задействованными на проекте.
Необходима простота запуска тестов и анализа результатов. Взаимодействие с популярными фреймворками и плагинами и работа с привычными форматами файлов могут существенно облегчить жизнь и сохранить ваше время.
3. Стабильность тестов.
Это требование применимо к любым тестам, но к приёмочным оно особенно строго оценивается. Автоматизированные приёмочные тесты должны сообщать о проблемах, которые действительно есть на проекте, у вас не будет времени анализировать результаты после каждого запуска тестов и проверять все упавшие тесты. Просто потому что они запускаются в час ночи, когда вы спите.
Одновременно с этим мы должны помнить, что еще больше трудностей возникнет, если автоматизированные тесты будут ложно-положительными, потому что в этом случае мы теряем сразу все преимущества непрерывной интеграции, снова тратим время на обнаружение проблемы и поиска причин ее возникновения.
Тестирование на основе историй использования является практикой, позволяющей реализовать почти идеальные автоматизированные приемочные тесты.
Вот те преимущества, которые мы получаем (некоторые из них очевидны, да):
1. Тесты понятны всем. Они понятны самим тестировщикам, программистам, менеджерам и заказчикам. Можно смело отправлять их на анализ команде разработки или заказчику и получить ценные рекомендации по их улучшению. Если тест не пройден, то все могут повторить шаги теста и проверить вручную функционал, в котором была найдена ошибка.
2. Тесты состоят из повторяющихся шагов. Это не такое очевидное преимущество, но оно действительно важно, и чем сложнее продукт и сами тесты, тем более важно это преимущество. Если вы допустили неточность в написании кода тестов, вам легче найти эту оплошность просто потому, что этот некорректный блок будет использоваться во всех тестах и где-нибудь это обязательно проявится. Создание 5-10 простых блоков, которые используются во всех тестах, так же имеет преимущество перед оформлением каждого теста в виде исходного текста в том, что кода получается мало, а значит поддерживать его в надлежащем состоянии намного проще.
3. Просто огромная скорость разработки новых тестов. Конечно, по сравнению с другими подходами. Например, даже начинающие автоматизаторы, посмотрев примеры уже созданных тестов, могут быстро и качественно создать множество подобных тестов, тестирующих уже другой функционал. В среднем во время интенсивной разработки вы можете написать несколько десятков (а при прокачанном скиле - несколько сотен) автотестов в день. При этом не написав ни строчки кода ни на одном из языков программирования. Вы просто пишете истории использования, создавая их из готовых строчек текста.
И заметьте, в процессе разработки новых тестов вы не изменяете исходный код уже созданных шагов, а значит, теоретически сразу же сокращаете возможность внести дефекты в ранее разработанные и проверенные тесты.
Такими дополнительными требованиями можно назвать, например:
1. Скорость разработки и отладки тестов.
Такие тесты необходимы как можно раньше, их приоритет выше остальных автоматизированных тестов. Запуск тестов после каждого нового изменения в продукте позволяет быстро реагировать на появление проблем и убедиться, что новая версия проходит хотя бы приемочное тестирование.
2. Легкость взаимодействия с системой непрерывной интеграцией и другими компонентами, задействованными на проекте.
Необходима простота запуска тестов и анализа результатов. Взаимодействие с популярными фреймворками и плагинами и работа с привычными форматами файлов могут существенно облегчить жизнь и сохранить ваше время.
3. Стабильность тестов.
Это требование применимо к любым тестам, но к приёмочным оно особенно строго оценивается. Автоматизированные приёмочные тесты должны сообщать о проблемах, которые действительно есть на проекте, у вас не будет времени анализировать результаты после каждого запуска тестов и проверять все упавшие тесты. Просто потому что они запускаются в час ночи, когда вы спите.
Одновременно с этим мы должны помнить, что еще больше трудностей возникнет, если автоматизированные тесты будут ложно-положительными, потому что в этом случае мы теряем сразу все преимущества непрерывной интеграции, снова тратим время на обнаружение проблемы и поиска причин ее возникновения.
Тестирование на основе историй использования является практикой, позволяющей реализовать почти идеальные автоматизированные приемочные тесты.
Вот те преимущества, которые мы получаем (некоторые из них очевидны, да):
1. Тесты понятны всем. Они понятны самим тестировщикам, программистам, менеджерам и заказчикам. Можно смело отправлять их на анализ команде разработки или заказчику и получить ценные рекомендации по их улучшению. Если тест не пройден, то все могут повторить шаги теста и проверить вручную функционал, в котором была найдена ошибка.
2. Тесты состоят из повторяющихся шагов. Это не такое очевидное преимущество, но оно действительно важно, и чем сложнее продукт и сами тесты, тем более важно это преимущество. Если вы допустили неточность в написании кода тестов, вам легче найти эту оплошность просто потому, что этот некорректный блок будет использоваться во всех тестах и где-нибудь это обязательно проявится. Создание 5-10 простых блоков, которые используются во всех тестах, так же имеет преимущество перед оформлением каждого теста в виде исходного текста в том, что кода получается мало, а значит поддерживать его в надлежащем состоянии намного проще.
3. Просто огромная скорость разработки новых тестов. Конечно, по сравнению с другими подходами. Например, даже начинающие автоматизаторы, посмотрев примеры уже созданных тестов, могут быстро и качественно создать множество подобных тестов, тестирующих уже другой функционал. В среднем во время интенсивной разработки вы можете написать несколько десятков (а при прокачанном скиле - несколько сотен) автотестов в день. При этом не написав ни строчки кода ни на одном из языков программирования. Вы просто пишете истории использования, создавая их из готовых строчек текста.
И заметьте, в процессе разработки новых тестов вы не изменяете исходный код уже созданных шагов, а значит, теоретически сразу же сокращаете возможность внести дефекты в ранее разработанные и проверенные тесты.
Комментариев нет:
Отправить комментарий
Я признателен Вам за то, что делитесь своим мнением