Как выбрать кейсы для регресса
Регрессионное тестирование на Scrum-проектах: руководство по проведению
Согласно отчету The State of Agile Report («О развитии методологии Agile»), 95% опрошенных компаний разрабатывают программное обеспечение по Agile.
Во-первых, гибкая методология позволяет выпускать качественный продукт быстрее конкурентов за счет тестирования в каждом спринте. Во-вторых, с ее помощью можно легко внести изменения в ПО благодаря тесной коммуникации между заказчиком и участниками проекта.
При этом тесты регрессии остаются одними из наиболее частых проверок перед релизом новой функциональности. Как выполнять их эффективно, особенно если время на тестирование ограничено всего одним спринтом, зачастую составляющим 2 недели? Что делать, если нужно внести изменения в функциональность продукта на поздней стадии спринта?
В этой статье мы ответим на эти вопросы, а также расскажем о том, как проводить регрессионное тестирование на Scrum-проектах и уверенно преодолевать возникающие сложности.
Регрессионное тестирование в Scrum-среде
Регрессионные проверки играют одну из ключевых ролей в тестировании полного цикла и помогают добиваться следующих целей:
повышать общее качество и стабильность ПО благодаря снижению вероятности критических ошибок при его использовании и многократному уменьшению числа дефектов к моменту релиза;
ускорять доставку решения на рынок, уменьшая время прогона тестов за счет автоматизации;
сокращать расходы на подготовку продукта к релизу с помощью раннего обнаружения дефектов и применения автоматизации.
На Scrum-проектах регрессионные проверки особенно важны, поскольку помогают командам сконцентрироваться на новой функциональности, обеспечив при этом корректную и непрерывную работу ПО с каждым новым инкрементом продукта.
Таким образом, QA-специалисты могут быть уверены в том, что доработки никак не повлияли на уже существующую функциональность.
Топ-5 распространенных проблем и способы их преоделения
При проведении регрессионного тестирования на Scrum-проектах важно сфокусироваться на двух аспектах.
Первый ― определить функциональность, затронутую изменениями в коде. Если это неочевидно, необходимо проверять всю функциональность и соответственно раньше начинать тестирование в спринте, чтобы уложиться в сроки. Однако если можно безошибочно установить затронутые изменениями модули, работа станет более таргетированной, что сократит время на QA.
Второй ― выбрать проверки, которые можно автоматизировать. Важно помнить, что использовать автоматизацию уместно не во всех случаях. Особенно это касается GUI-проверок, где малейшие правки в дизайне приложения приводит к пересмотру тест-кейса с нуля.
Автоматизированные проверки подойдут для более стабильной функциональности, которая изменяется редко. А при нехватке времени поможет проактивный подход. Например, разработчики, инженеры по автоматизированному и функциональному тестированию работают над новой функциональностью в параллели и покрывают всё автоматизированными тестами в ходе одного спринта.
Но даже при должном понимании влияния изменившихся функций на приложение в целом и объема автоматизации, Scrum-команды могут столкнуться с рядом сложностей. Давайте перечислим их и рассмотрим, как можно решить.
Возрастающий объем регрессии
На крупных проектах с каждым новым спринтом объем регрессионного тестирования может увеличиваться. Чтобы эффективно им управлять, важно пересматривать тест-кейсы и удалять устаревшие. Делать это стоит по возможности и в зависимости от частоты вмешательства в релизы. Кроме того, это первый звонок, что уже можно и нужно внедрять автоматизацию.
Недостаточная коммуникация между участниками проекта
Специалистам по тестированию, бизнес-аналитикам, разработчикам и руководителям проекта стоит непрерывно взаимодействовать друг с другом. Так они смогут лучше понять объем работ и обеспечить эффективность процесса, начиная с подготовки тестовой документации и заканчивая пониманием того, какая функциональность больше не нуждается в регрессионном тестировании.
Поддержка тестовых сценариев
С увеличением числа тест-кейсов, будь то автоматизированные или функциональные, их поддержка усложняется. Чтобы минимизировать их обслуживание, важно больше коммуницировать с бизнес-аналитиками, которые знают взаимосвязи в бизнес-логике продукта и могут выявить несоответствия в тест-кейсах в случае внесения изменений.
Частые доработки функциональности
Смоделируем ситуацию: на проекте возникли непредвиденные и объемные изменения в требованиях к функциональности продукта. Еще и в конце спринта. Что делать? Да, сроки имеют значение, но важно позаботиться о качестве и оценить, сколько времени займет перезапуск тестов с учетом входной информации, чтобы расширить спринт и перенести дату релиза.
Ложноположительные результаты тестов
Причина может заключаться в некорректной разработке автоматизированного тест-кейса. Исключить подобную вероятность поможет валидация инженером по функциональному тестированию, который проходит тест-кейс по шагам и проверяет соответствие ожидаемому результату. Кроме того, в спринтах стоит закладывать время на интуитивное (ad hoc) и исследовательское (exploratory) тестирование, чтобы максимально расширить тестовое покрытие.
Тестируем регрессию на Scrum-проекте: о чем важно помнить
Для эффективного проведения регрессионного тестирования на гибких проектах важно приступать к созданию тестовой документации еще в самом начале разработки и в дальнейшем непрерывно обновлять ее в зависимости от входящих требований.
Что еще нужно учитывать? Предлагаем рассмотреть 5 шагов, от которых напрямую зависит результативность регрессионного тестирования.
1. Подготовить план тестирования
Этот этап включает в себя подбор необходимых тест-кейсов, их дальнейшее улучшение и доработку, оценку времени создания и выполнения регрессионных тестов, валидации дефектов и разработки финального отчета. Важно также определить тест-кейсы, которые в дальнейшем можно будет автоматизировать. Кроме того, на начальном этапе работ при взаимодействии с разработчиками проводится анализ того, какие модули могут быть затронуты изменениями, чтобы уделить этим областям больше внимания при тестировании.
2. Создать доску регрессии
Все задачи, над которыми работают QA-инженеры Scrum-команды, располагаются на доске в порядке сверху вниз по приоритетности в зависимости от возможных рисков, важности для клиента и ряда других факторов. Переставляя элементы на доске, команда всегда будет понимать актуальность задач и сможет планировать свое время так, чтобы укладываться в сроки.
3. Анализировать отчеты о дефектах
Так QA-команда сможет получить подробную информацию о проведении регрессионных тестов: причины их невыполнения, шаги тест-кейса, на которых произошла ошибка, снимки экрана. Все это поможет быстрее выявить проблему и устранить ее.
4. Добавить исследовательское тестирование
С его помощью инженеры по тестированию по-новому взглянут на проект, расширят тестовое покрытие и обнаружат дефекты, которые могли бы оказать сильное влияние на конечного пользователя разрабатываемого продукта.
5. Настроить модель коммуникации на проекте
Например, непрерывное взаимодействие специалистов по тестированию с владельцами продуктов способствует своевременному отслеживанию изменений в требованиях. В то время как коммуникация QA-инженеров с разработчиками ― получению информации о внесенных в ходе итерации изменениях.
Заключение
Регрессионное тестирование позволяет минимизировать риски сбоев в работе программного продукта после внесения изменений.
В ходе регрессионного тестирования на Scrum-проектах команды сталкиваются с рядом сложностей, которые можно решить благодаря:
обеспечению непрерывной коммуникации между участниками проекта;
поддержке документации в актуальном состоянии;
расширению спринта в случае внесения изменений в функциональность перед релизом;
валидации автоматизированных тест-кейсов.
Чтобы эффективно организовать процесс тестирования, важно:
создать план выполнения регрессии;
использовать доску регрессии;
тщательнее работать над ошибками;
не забывать о преимуществах исследовательского тестирования;
обеспечить открытое взаимодействие между участниками проекта на всех уровнях.
Подобный подход поможет гарантировать качество и стабильность ПО, несмотря на непрерывные доработки, и обеспечить слаженную работу Scrum-команд.
Регрессионное Тестирование (Regression Testing)
Ты хочешь понять, что такое регрессионное тестирование, зачем оно нужно, почему про него говорят все тестировщики и при чем здесь автоматизация?
Тогда ты в правильном месте 🙂
В этой статье отвечаю на самые частые вопросы, связанные с этим типом тестирования.
Как обычно, начинаем с определений.
Что такое регрессионное тестирование?
Регрессионное тестирование (regression testing) это проверки ранее протестированной программы, выполняющиеся после изменения кода программы и/или ее окружения для получения уверенности в том, что новая версия программы не содержит дефектов в областях, не подвергавшихся изменениям.
Regression testing — testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed. [ISTQB Glossary]
Regression Testing является одним из двух видов тестирования, связанных с изменениями. [ISTQB FL]
Зачем нужно регрессионное тестирование?
Регрессионное тестирование необходимо для получения уверенности, что изменения ПО не коснулись и не сломали другие, не измененные, части ПО.
Здесь возникает вопрос: “Каким образом изменения одной части ПО могут сломать другие?”
Ответ: это загадка природы 🙂
В мире не бывает идеальных вещей и все мы ошибаемся. ПО и программисты — не исключение.
Иногда, непреднамеренно, разработчик делая исправление в коде может повлиять на части приложения, о которых он никогда не слышал и не представлял, что они существуют и связаны каким-то образом.
Особенно часто эта проблема проявляется в проектах с низким уровнем качества кода, плохой архитектурой и большим техническим долгом.
Фредерик Брукс в своей книге «Мифический человеко-месяц» (1975) писал: «Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20–50%) влечёт появление новой». [Куликов С., Базовый курс, 3-е издание]
Можно предположить, что в наше время вероятность появления ошибки — значительно меньше 20-50%, так как программы и среда разработки 1975 года сильно отличаются от современных.
Но, тем не менее, даже сегодня вероятность ошибки точно больше 0%.
Поэтому, регрессионное тестирование является ключевым инструментом обеспечения качества и должно использоваться практически на любом проекте.
Когда проводят регрессионное тестирование?
Регрессионное тестирование проводится после изменения кода программы (добавили / удалили / изменили) или изменения рабочего окружения (обновили версию PHP / Node JS / Java / Ubuntu / Windows / MySQL / MongoDB / переехали на новые сервера и т.п.)
Стоит отметить, что регрессионные тесты не нужно проводить после каждого изменения!
Например, вы изменили дату в футере сайта.
Нужно ли нам проходить 350 тест-кейсов и перепроверять весь сайт? — конечно же нет! Вы потратите свое время зря)
Такие исправления можно протестировать за 10 секунд используя самый простой чек-лист или сделав code review.
Если же такие исправления “ложат” / “ломают” сайт — вам срочно нужно задуматься о профессионализме разработчиков, это не нормально!
Или, другой пример. На одном из полей формы изменяется правило валидации: до этого максимальная длина строки равнялась 20 символам, а теперь нужно сделать 16.
Зачем после такой правки перепроверять весь сайт? (Вы не поверите, но существуют компании и команды, который до сих пор этим занимаются…)
Единственное, что нужно проверить — валидацию конкретно этого поля и, возможно, валидацию такого же поля на других формах (если они вообще существуют)
Если после изменения длины одного поля изменились правила валидации всех полей на сайте — поздравляю, у вас большие проблемы с профессионализмом разработчиков.
Вместо того, чтоб постоянно выполнять бесполезные проверки, лучше нанять более профессионального кодера. Через 2 месяца вы начнете экономить кучу денег.
При принятии решения о необходимости повторного тестирования вспоминаем принципы тестирования и задаем себе вопрос: ЧТО нам нужно проверять после этих изменений?
Какие плюсы регрессионного тестирования?
К плюсам можно отнести:
Выполнение повторного тестирования необходимо для анализа и улучшения качества продукта и рабочих процессов, чем, кстати, и занимаются настоящие QA Engineers.
Какие минусы регрессионного тестирования?
К минусам можно отнести:
Пытаясь бороться с описанными выше минусами многие компании автоматизируют регрессионные проверки 🙂
Но, решает ли автоматизация эти проблемы? Или только усугубляет? Давайте разбираться…
Автоматизация и regression testing
Регрессионные тесты выполняются много раз и обычно проходят медленно, поэтому такие тесты — это серьезный кандидат на автоматизацию. [ISTQB FL]
На первый взгляд — выглядит логично. Но давайте посмотрим немного “глубже”.
Предположим, у нас есть небольшой проект и 50 тест-кейсов. Мы, после очередного видео / доклада — “Автоматизируй все!” — решаем их автоматизировать 🙂
Через 2 недели все готово: тесты проходят, все зеленое — класс, у нас авто-тесты, Agile и CI! (в видео сказали, что будет так)
Проходит 2 года. Количество тест-кейсов увеличилось в 20 раз, до 1,000. Иии…
Сравнение теоретического “до” и “после”:
Решили ли мы проблемы, описанные выше? — нет.
Возможно, рутины стало чуть меньше. Но остальное — никуда не пропало + появилось новое:
Теоретически, мы можем уменьшить время прогона, купив более мощные сервера, или подняв кластер (привет новый DevOps), но это сделает затраты еще большими…
И здесь появиться финансовый вопрос — а не дешевле ли нам иметь 5 джунов, которые будут проходить регрессионные тест-кейсы изо дня в день, за те же 100 минут? (Знакомо, да? Мы вернулись туда, откуда начали)
Парадокс автоматизации? Наверное, можно так сказать 🙂
Пытаясь уменьшить затраты — мы сделали их еще больше!
Давайте вспомним, что регрессионные тесты — это серьезный кандидат на автоматизацию.
Поэтому, учитывая все, написанное выше, мы можем предложить решение проблем и сделать следующие выводы:
Все эти проблемы решаются только настоящими специалистами, включая QA лидов, автоматизаторов и DevOps инженеров.
Поэтому в следующий раз хорошенько подумай, перед тем, как “автоматизировать все”.
И помни, что работа любого специалиста должна быть направлена на повышение эффективности работы и качества продуктов компании, а не на увеличение ее финансовых затрат!
Псс.. Несколько инструментов тестировщика, которые точно помогут тебе стать более эффективными, без автоматизации)
Резюме
В статье мы детально ознакомились с одним из типов тестирования, связанного с изменениями, а именно регрессионным тестированием.
Мы узнали что это такое, зачем оно необходимо, какие у него «плюсы» и «минусы», и что нам “готовит” автоматизация таких тест-кейсов.
Если у тебя есть вопросы / предложения / замечания — пиши нам!)
Если тебе интересна эта тема, и ты хочешь получать актуальную информацию о тестировании — подписывайся на наш Телеграм канал, там интересно: статьи, тесты, опросы, нет спама! 🙂
Noveo
Оптимизация регрессионного тестирования в гибкой разработке
Спасибо тестировщику Noveo Анастасии за рубрику переводов о тестировании!
Регрессионное тестирование часто становится проблемным вопросом для менеджеров Agile-проектов. Этот вид тестирования несет в себе две основных трудности:
Чтобы решить эти проблемы, опытные продавцы услуг по тестированию ПО и QA-специалисты придерживаются определенных сбалансированных стратегий. Давайте исследуем некоторые из них.
Регрессионное тестирование в гибких проектах: как оптимизировать?
Существует три наиболее распространенных пути оптимизации регрессионного тестирования в гибкой разработке:
У каждого из них есть плюсы и минусы.
Двухуровневый подход
В соответствии с этим подходом команда тестировщиков делит регрессионные тесты на два цикла:
Тем не менее, этот подход не так прост, как кажется. Чтобы всё прошло успешно, требуется непрерывная коммуникация внутри команды. Общаясь с разработчиками, тестировщики получают полное представление о том, что было сделано в течение итерации, и обоснованно выбирают необходимый тип регрессионного тестирования. Еще один пункт, который следует учесть, это время, прошедшее с момента последней полной регрессии. Это может помочь в установлении графика регулярного полного регрессионного тестирования и проведении ряда тестов вне зависимости от изменений, которые были внесены в ходе итерации. Это поможет команде избежать утомительной полной регрессии после каждого спринта и сохранить приложение относительно “чистым” от багов в любой момент.
Приоритизация тестов: подход на основе оценки рисков
Согласно рискоориентированному подходу, команда тестировщиков выбирает тест-кейсы, покрывающие области приложения, в которые были внесены изменения в последних итерациях, и сортирует их по приоритету. Таким образом, время и силы на регрессию сокращаются.
В течение всего проекта подход, основанный на оценке рисков, может быть применен ко всему набору регрессионных тестов в гибком проекте. Тестировщики делят все тесты на три категории:
Таким образом, расстановка приоритетов помогает снизить время и усилия, затраченные на регрессионное тестирование, без ущерба качеству продукта. Однако этот подход может стать причиной некоторых проблем, так как команда тестировщиков ограничивается их собственными задачами и не видит всей картины. К счастью, есть еще одна стратегия, которая полностью соотносится с особенностями гибких проектов.
Приоритизация тестов: коллективный подход
Этот подход позволяет членам команды привнести свои знания и уникальный взгляд в регрессионное тестирование. В течение спринта команда разрабатывает т.н. “доску регрессии”, покрывающую все задачи, выполненные каждым ее членом. Каждый может внести небольшие изменения, основываясь на собственном опыте. Например, разработчик понимает, что недавно добавленная фича могла повлиять на профиль пользователя, и добавляет эту информацию на доску. Когда приходит время регрессионного тестирования, команда обращается к доске и распределяет время в соответствии с информацией на ней. Используя этот подход, команда применяет свои уникальные знания для формирования комплекта регрессионных проверок, что делает этот тип тестирования более эффективным и менее затратным по времени.
Кроме обоснованности и удобства, подходы с приоритизацией требуют внимания, так как они могут привести к техническим недоработкам, подрывающим реализацию проекта.
Осторожно: технические недоработки
Технические недостатки в гибкой разработке указывают на то, что нужно особенно постараться, чтобы закончить все незавершенные задачи, накопленные за спринт/спринты/жизненный цикл проекта. Как правило, недоработки возникают, когда команда решает починить баг “как-нибудь позже”. Иногда это имеет смысл: например, когда команда откладывает тестирование безопасности до момента, пока система не заработает более стабильно, возникает техническая недоработка. Но это обоснованный тактический шаг, продиктованный грамотным тайм-менеджментом.
Проблемы появляются, когда эти недостатки выходят из-под контроля. Дисциплинированная гибкая поставка (Disciplined Agile delivery, DAD) — фреймворк, который предлагает широкий диапазон шагов по эффективной работе с техническими недоработками. Удивительно, но постоянное гибкое регрессионное тестирование — один из них. Это возвращает нас к началу.
Итак, возможно ли оптимизировать гибкое регрессионное тестирование и в то же время контролировать техническую часть? Ответ на этот вопрос — автоматизация регрессионного тестирования, наша третья стратегия.
Автоматизированный подход
Автоматизированное регрессионное тестирование в гибкой среде — лучший способ разобраться с проблемами, которыми окружена регрессия. Автоматизация сокращает время на тестирование с дней до часов и избавляет инженера-тестировщика от утомительного прохождения одного теста снова и снова. Тем не менее, нужно с осторожностью подходить к внедрению регрессионных автотестов в гибкую разработку.
Правильно подобранный момент — первое, что нужно учесть при планировании автоматизации регрессионного тестирования. Лучше всего вводить автоматизацию на том этапе, когда проект уже достиг определенного уровня зрелости, и все главные изменения уже были внесены. На ранних итерациях в большинстве проектов происходят изменения в интерфейсе, пользовательских сценариях или логике, что увеличивает трудозатраты на тестирование (и ручное, и автоматизированное).
К тому же, автотесты, какими бы хорошими они ни были, не будут актуальными всегда. В гибкой разработке необходимо, чтобы наборы автоматизированных регрессионных тестов полностью отражали изменения и обновления в функциях приложения. Необходимо пересматривать тест-комплекты после каждого крупного релиза и удалять устаревшие кейсы, которые больше не помогают обеспечивать качество продукта.
Тем не менее, ручное тестирование должно сосуществовать даже с лучшими комплектами автотестов. Ручное регрессионное тестирование всегда проводится в первую очередь, так как автоматизированные тест-кейсы основываются на повторяющихся сценариях, которые стабильно выявляли баги в предыдущих итерациях. Эксперты рекомендуют проверять результаты регрессионных автотестов с помощью быстрого ручного смоук-тестирования, чтобы заблаговременно обнаружить ошибочные результаты.
Ориентированность на коммуникацию
Чтобы оптимизировать гибкое регрессионное тестирование, команде тестировщиков следует установить непрерывную коммуникацию с другими членами команды:
Это общепринятый фундамент для всех трех стратегий оптимизации регрессионного тестирования.
Подытоживая сказанное
Регрессионное тестирование в гибкой разработке напоминает горькую таблетку: неприятно, но необходимо для обеспечения качества продукта. К счастью, у команд тестировщиков Noveo в гибкой разработке есть множество стратегий, которые можно применить для оптимизации регрессии. Самые популярные из них — это двухуровневый подход, приоритизация тестов и автоматизация регрессии.
Команды обычно выбирают тот подход, что больше подходит им с точки зрения масштаба проекта, временных рамок, количества запланированных релизов и т.д. Тем не менее, у всех подходов есть общая основа — непрерывная коммуникация.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Немного о наших процессах
Итак, релиз приложений происходит раз в неделю. Один день закладывается на регрессионное тестирование, второй на smoke. Остальное время на разработку новых фич, исправление дефектов, написание и обновление документации, улучшение процессов.
Регрессионное тестирование — это набор тестов, направленных на обнаружение дефектов в уже протестированных, но затронутых изменениями, участках приложения.
Практически все позитивные сценарии проверки покрыты тест кейсами, которые ведутся в Allure TestOps.
У каждой платформы (я имею ввиду iOS, Android) своя документация и автотесты, но все хранится в одном месте. Любой QA из команды может посмотреть и отредактировать их. Если добавляются новые кейсы, то они обязательно проходят ревью. Тестировщик Android проводит ревью для iOS, и наоборот. Это актуально для ручных тестов.
Про тест план для регресса
Для проведения регрессионного тестирования, составляется тест план с ручными тест кейсами и автотестами, отдельно для Android и iOS. Тестировщик собирает лаунч (запуск тест плана), в котором указывает версию релизной сборки и платформу. После создания лаунча, запускаются автотесты с выбранными кейсами, а ответственный за ручное тестирование назначает мануальные тест кейсы на себя. Каждый проходимый кейс отмечается статусом: Passed, Failed или Skipped. В ходе проверки сразу отображаются результаты.
По окончании проверки лаунч закрывается. А на основании результов выносится решение о готовности к релизу. Вроде все классно и логично, но конечно же есть проблемы из-за которых грустят тестировщики
Определим проблему
Увеличение объема тестируемого функционала при проведении регресса, и выход из временных рамок.
Или — тест кейсов все больше и больше, а времени у нас только 8 часов максимум!
Раньше в тест план попадали все кейсы. А с добавлением нового функционала, тест план увеличился до 300 тестов и прохождение его стало занимать больше времени, чем было заложено. Мы перестали укладываться в рабочий день. В связи с этим было решено пересмотреть подход к тестированию, учитывая временные рамки и возможность сохранения качества.
Анализ и решение
Ручное тестирование перегружено из-за того, что с каждой новой фичей добавляются тест кейсы, они могут быть как простые, так и сложные (состоящие из переходов между экранами). Также приходилось проводить тестирование взаимодействия с бэкендом. Мы тратили много времени на такие проверки, особенно когда возникали баги и приходилось разбираться на чьей стороне проблемы.
Расписав слабые места, мы решили доработать подход к автоматизации, а еще воспользовались импакт-анализом для выделения методов решения.
Impact Analysis (импакт анализ) — это исследование, которое позволяет указать затронутые места в проекте при разработке новой или изменении старой функциональности.
Что же мы решили изменить, чтобы разгрузить ручное тестирование и сократить регресс:
Увеличение количества автотестов и разработка единого сценария перевода тест кейсов в автоматизацию
Разделение тестируемого функционала на фронтенд и бэкенд
Изменение подхода к формированию тест плана на регресс и смоук
Подключение автоматического анализа изменений, входящих в релизную сборку
Ниже я расскажу про каждый пункт более подробно и какие результаты были получены после введения.
Увеличение количества автотестов
Зачастую, когда в процессе тестирования хотят сократить время на регресс, начинают с автоматизации. Но у нас все этапы проходили параллельно. И естественно, часть проверок перешло в автоматизацию. Подробнее о том, как построен процесс автоматизации у нас в компании, будет расписано в другой статье.
Чтобы процесс был одинаковым для обеих платформ, была написана инструкция. В ней расписаны критерии перевода, шаги и инструменты. Я коротко распишу как происходит перевод тест кейсов в автоматизацию:
Определяется какие варианты проверок можно автоматизировать. Это делает ручной тестировщик самостоятельно, или обсудив с командой на митинге.
В Allure TestOps дорабатываются тест кейсы, например добавляется больше описания или json.
Переводятся соответствующие тест кейсы в статус need to automate (так же в Allure TestOps)
Создается задача в Youtrack. В ней описывается, что нужно автоматизировать. Прикладываются ссылки на тест кейсы из Allure TestOps. И назначается ответственный AQA.
Затем, задачи из Youtrack берутся в работу исходя из приоритетов. После того как изменения влиты в нужные ветки и прошли ревью, задачи закрываются, а тест кейсы в Allure переводятся в Automated со статусом Active. Ревью кода автотестов проводят разработчики.
Зачастую это происходит за несколько дней до следующего релиза, и ко дню проведения регресса, часть тест кейсов уже может быть автоматизирована.
Результаты:
Сокращение нагрузки на ручное тестирование.
Больше функционала покрыто автотестами, которые гоняются каждый день. Раньше обнаруживаются баги.
Backend и frontend отдельно
Автоматизация тестирования у нас разделена для backend и frontend.
Но есть E2E тесты, которые тестируют взаимодействие.
E2E (end-to-end) или сквозное тестирование — это когда тестируется вся система от начала до конца. Включает в себя обеспечение того, чтобы все интегрированные части приложения функционировали и работали вместе, как ожидалось.
Многие сквозные автотесты прогонялись со стороны мобильного тестирования, приходилось писать сложные тест кейсы. Зачастую они не проходили из-за проблем со стороны сервисов или на бэкенде.
Поработав в таком формате, мы решили, что много времени уходит на починку автотестов. И тогда E2E тесты приходится проходить вручную.
Было принято четко разделить функционал на модули с выделением логики на фронтенде и бэкенде. Оставить минимальное количество Е2Е тестов для ручного тестирования. Остальные сценарии упростить и автоматизировать. И так на бэкенде мы проверяем бизнес логику, а на клиенте корректное отображение данных от бэке и ui элементы.
Мы перестали запускать тесты на stable окружении и перевели их полностью на моки.
Это позволило нам определить области с наибольшей критичностью, сократить время ручного тестирования, сделать прогон автотестов более стабильным.
Для наглядности вот табличка:
Описание функционала
Локализация тестов
Простая валидация полей (например при смене пароля)
Размещение ui элементов на экране
Отрисовка ui элементов
Отображение информации от бэка
Навигация по экранам
Корректная обработка и отображение ошибок
Сложная валидация (например проверка формата TIN)
Сбор данных для профиля
Сбор и обработка данных по операциям
Создание и сохранение данных при работе с картами
Взаимодействие с БД
Результаты
Стало проще локализовать проблему
Раньше определяются проблемы и соответственно решаются быстрее
Есть четкое разграничение зон ответственности. Нет лишних проверок на клиенте.
Автотесты стали гораздо стабильнее, т.к. не завязаны на сервисы, которые могут отваливаться в любой момент. (А этот любой момент обычно самый неподходящий)
Сократилось время на реализацию автотестов, не нужно добавлять json в тест кейсы дополнительно при написании
Отфильтровали тест кейсы в тест плане на регресс
Тест план на регресс формируется исходя из того, в каких блоках были внесены изменения, а также из основных постоянных сценариев проверки.
Для того, чтобы проще было формировать план, мы стали использовать теги.
Пример: Regress_Deeplink, Regress_Profile, Regress_CommonMobile
Теперь, все тест кейсы у нас поделены на блоки, которые отмечены определённым тегом! Есть также обязательные кейсы, которые входят в каждый тест план на регресс и отдельные тест кейсы для smoke-тестирования на проде.
Это позволяет нам оперативно отфильтровать и быстро сформировать определённый план в соответствии с вносимыми изменениями, а не тратить время на проверку того, что не было затронуто.
Результаты
Введение дополнительного анализа, при формировании тест планов, помогло сократить общее время прохождения регрессионного тестирования всего до 2 часов с 8ми изначальных. У нас есть несколько тест планов — full и light. Обычно мы проходим light и он состоит из 98 кейсов (автотестов+ручных). Как видно на скрине, полный план регресса состоит из 297 тест кейсов!
Время на прохождение Regress iOS light в среднем составляет около 2 часов, но когда изменения были только в паре модулей, то можно провести регресс и за час. Это большой плюс, потому что остается запас на багофиксы (если понадобится что-то срочно исправить). Также, в будущем, всегда есть возможность посмотреть по отчетам, в какой сборке что проверялось.
Разработали скрипт с анализом изменений и оповещением через Slack
Качество продукта полностью зависит от всех участников команды. Поэтому, чтобы точно понимать какой модуль был затронут, мы обратились к разработчикам с предложением информировать нас о том, какие изменения были внесены в выпускаемую версию.
Первое время нам приходилось напоминать, уточнять и указывать в задачах затрагиваемые блоки. С одной стороны, мы смогли облегчить регресс, выбирая только необходимые кейсы. Но с другой стороны, тратилось достаточно много времени на коммуникацию, и постоянные уточнения. Пропадала ясность, и не было полной уверенности в том, что проверяется всё необходимое.
Был создан скрипт, который собирает информацию по коммитам. И далее, сформировав отчет о том, какие модули были затронуты, отправляет необходимую информацию в специальный канал Slack.
Скрипт работает просто:
После каждой сборки получает изменения между предыдущей версией приложения и коммитам, из которого собрался билд
Получает список файлов, которые отражают изменения в каком-то экране
Группирует эти изменения по фичам и командам, чтобы упростить жизнь тестировщикам
Посылаем сообщение в специальный Slack канал со всей информацией по изменениям
Результаты
Какие плюсы мы получили, подключив аналитику по сборкам:
Сократили время разработчиков на ручной анализ внесенных изменений
Снизили вероятность упустить из виду и недопроверить необходимый функционал
Упростили коммуникацию по данному вопросу
Естественно, было затрачено время на написание скрипта, и интеграцию его работы в Slack. Но, в дальнейшем, всем стало проще отслеживать вышеописанный процесс.
Коротко о главном
Использование тегов в тест кейсах и при формировании тест планов сократило объем тест плана, соответственно и время на тестирование.
Разработка и использование скрипта для оповещение об изменения дало возможность четко понимать какие модули были затронуты при разработке задач для релиза. Или при исправлении багов. Так же тестировщики перестали отвлекать разработчиков с такими вопросами.
Автоматизацией было покрыто около 46% тест кейсов, что сильно облегчило ручное тестирование. К тому же остается время на актуализацию кейсов и написание новых.
Разделение тестирования на backend и frontend помогло заранее определять локализацию проблем и своевременное исправление.