Репозиторий тест-кейсов может легко переполниться устаревшими тест-кейсами, если его регулярно не очищать. Тестировщики выполнят ряд тест-кейсов, отметят их как проваленные (failed), а затем эти тест-кейсы будут закрыты владельцем продукта и в итоге обернутся ненужной тратой ресурсов. Мы все это проходили.
Тест-кейс пишется на основе пользовательской истории (user story). А несколько спринтов спустя новая пользовательская история изменяет рабочий процесс или функциональность, и как следствие, пишется новый тест-кейс. Если предыдущий тест-кейс не был обновлен или удален, может возникнуть недопонимание между тестировщиками, разработкой и менеджером продукта. Чтобы избежать этой неудобной ситуации, я дам несколько советов по эффективному управлению тест-кейсами в agile-среде. Проактивно управляя тест-кейсами в каждом спринте, QA-команда сможет избежать случайного выполнения устаревших тест-кейсов, а также не будет регистрировать невалидные баги, что позволит создать более эффективный процесс обеспечения тестового покрытия.
Проблема гибкого управления тест-кейсами
Одна из самых больших ошибок, которую может совершить QA-команда, — это свалить все тест-кейсы в одну кучу, чтобы использовать их для регрессионного тестирования. Я часто видел, как это происходит, потому что в тот момент казалось, что стоит сосредоточиться на более важных проблемах. Это приводит не только к попаданию устаревших тест-кейсов в регрессионный тест-сьют, но и к значительному повышению требований к управлению тест-кейсами в будущем.
И вот почему: часто бывает так, что тестировщик в рамках спринта создает тест-кейсы из пользовательской истории. Это валидные тест-кейсы, необходимые для тестирования в течение спринта, но в конце спринта они будут перемещены в базу, которая включает все тест-кейсы из всех предыдущих спринтов. Тесты накапливаются, и когда приходит время для регрессионного тестирования, команда сталкивается с огромном количеством тест-кейсов, включая дубликаты и невалидные тесты. Обычно для проведения полной регрессии появляется лишь небольшое временное окно, и команде приходится просмотреть все тесты и определить, какие из них следует выполнить. Выполнение неправильных тест-кейсов на этом этапе снижает производительность и увеличивает время, необходимое для завершения регрессионного тестирования. Последнее, чего хочет QA — это отложить релиз из-за того, что они не были достаточно подготовлены к завершению регрессионного тестирования.
Решение для гибкого управления тест-кейсами
Решение на самом деле простое, но оно требует определенного уровня проактивности, чтобы команда не металась в поисках обновления регрессионных тестов в момент проведения регрессии. Отведите в каждом спринте время на управление регрессионными тест-кейсами. Изменения для каждой пользовательской истории будут относиться к одной или нескольким из следующих четырех категорий. Оцените каждую пользовательскую историю и все тесты, а затем решите, к какому набору или категории относятся тесты для пользовательской истории. Возможно, что для одной пользовательской истории потребуется одновременно добавить, обновить и удалить тесты.
Добавление тестов. Когда вводится основная функциональность, тесты, созданные для тестирования во время спринта, должны быть добавлены в набор регрессионных тестов. Это может включать также добавление теста в дымовой (smoke) тест или санитарный (sanity) тест. Место добавления теста будет определяться значимостью функциональности или фичи. Если это фича высокого уровня, которую будет использовать большинство пользователей, то ее следует добавить как в регрессионное, так и в дымовое/санитарное тестирование. Добавление теста обычно происходит по умолчанию, что приводит к проблемам, о которых я говорил выше. Убедитесь, что тест действительно должен быть добавлен в регрессионное тестирование, чтобы избежать дублирования. Это приводит нас к следующему варианту — обновлению тестов.
Обновление тестов. В случае, если рабочий процесс обновляется, но, например, в функциональность значительные изменения не вносятся, нет необходимости создавать новые тесты. Достаточно просто отредактировать их в соответствии с новым рабочим процессом, и в этом случае тесты для данной функциональности в регрессионном тест-сьюте нужно перенести в спринт и обновить в соответствии с новым рабочим процессом или поведением. Если автор тест-кейса просто напишет новый тест вместо того, чтобы обновить предыдущий, то у вас будет дублированный/устаревший тест-кейс в регрессии. Если это происходит снова и снова, то вы столкнетесь с проблемами во время проведения регрессионного тестирования. Не забывайте обновлять существующий тест-кейс перед включением его в план тестирования спринта, а оригинальный тест должен быть обновлен и включен в спринт.
Удаление тестов. В некоторых пользовательских историях просто требуется удалить фичу, которая больше не используется. Когда дело доходит до обновления тест-кейсов, важно как удалить ненужные детали, как и добавить новые актуальные. Если на работу принимается новый тестировщик, он не будет сразу знать историю продукта. Если тестировщику поручат набор устаревших регрессионных тест-кейсов, они в результате выполнения будут указывать на невалидные баги. Это отнимает время у тестировщика, который ими занимается, у продуктовой команды, которая их читает и комментирует, и у старшего тестировщика, который должен сообщить всем причину невалидности бага. Всего один невалидный баг влечет за собой ненужную трату стольких ресурсов! Всего этого можно избежать, удалив недействительный тест-кейс.
Ничего не делать. Для пользовательских историй, в которых просто настраивается изображение, цветовая схема или текст, необходимо иметь тест-кейсы, созданные в ходе тестирования. Этим тестам не место в регрессионном тест-сьюте. Это валидные тесты, и возможно их потребуется выполнять каждый раз, когда программное обеспечение развертывается в новой среде, но после этого их следует отложить в сторону. Элементы, которые часто меняются и которые вряд ли будут затронуты, если не будет создана еще одна пользовательская история, не пригодятся в регрессионном тестировании или в дымовом/санитарном тестировании. В этом случае после завершения спринта и внедрения изменений в продакшн оставьте эти тесты для истории.
Заключение
Ключом к поддержанию актуальности репозитория тест-кейсов является проактивность. Обновляйте его вслед за изменениями в пользовательских историях. Хорошо упорядоченный репозиторий тест-кейсов позволяет легко вовлекать в проекты новых тестировщиков. Вы когда-нибудь хотели привлечь тестировщика из другого проекта, но не хотели тратить время на его обучение? Актуальные тест-кейсы сделают это за вас. Поручите новому члену команды выполнение набора валидных тест-кейсов, и он очень быстро изучит продукт. С другой стороны, если вы по ошибке назначите нового члена команды на устаревшие тест-кейсы с неправильными ожидаемыми результатами, то это приведет только к путанице и потерянному времени. Когда речь идет о тест-кейсах, регулярная небольшая работа в каждом спринте позволяет сэкономить много времени в будущем.
Тест-дизайн и тест-анализ — это одно и то же? Разберемся в этом вопросе на открытом уроке, а также рассмотрим техники и того и другого. В результате занятия:
увидите, чем различаются тест-дизайн и тест-анализ;
сможете определять, какие техники относятся к ТД, а какие к ТА.
Записаться на урок можно на странице курса "QA Engineer. Basic".