в программе тестирования уже участвует максимальное количество человек как исправить
7 шагов к отличному результату – пользовательское тестирование
Главная идея тестирования состоит в том, чтобы показать проект пользователю на раннем этапе. Это позволит оценить будущие итерации и проверить предположения.
Что такое пользовательское тестирование
Пользовательское тестирование (или тестирование юзабилити) является процессом, который идентифицирует проблемы продукта. Вы находите реальных пользователей, желательно из вашей целевой аудитории, и просите их попробовать ваше детище. История этого вида тестирования началась во время второй мировой войны, когда тестировали удобство использования военной техники.
Стив Круг в книге «Не заставляйте меня думать» популяризировал юзабилити тестирование. В наше время методы тестирования стали общедоступны, выйдя за рамки военных исследований и научных лабораторий.
Зачем нужно ранее тестирование
Намного дешевле найти потенциальные проблемы на ранних этапах жизненного цикла нового продукта. Технические компании, как правило, следуют за производственным процессом, который выглядит примерно так:
Этот график представляет, как проект передается через команды по всей компании. Менеджеры по продукции определяют требования к продукту и передают их команде UX. После окончания проектирования продукт перемещается к разработчикам. Этот цикл повторяется итеративным способом, пока конечный продукт не завершен.
Разработчики, которые полагаются на интуицию и одни только предположения, должны ждать выпуска каждого цикла, чтобы измерить обратную связь, потенциально тратя впустую много ресурсов. Как только создан образец продукта, нужно получить доказательства плохого юзабилити и изменять проект. Это оказывается слишком дорого и неэффективно.
«Если вы думаете, что хороший дизайн дорого стоит, посмотрите счет за плохой» Ralf Speth
Тестирование юзабилити на прототипах было разработано как быстрое и недорогое решение для снижения некоторых из этих рисков. Вы можете проверить предположения, регулировать разработку продукта и определить направление его развития. Скрытые проблемы продукта раскрываются с использованием фактических отзывов пользователей. Тестирование юзабилити может ограничиваться искусственной тестовой средой и небольшой выборкой, но это никогда не даст тех же результатов, какие дает обратная связь с массовым пользователем. От них мы получаем реальные данные.
Используйте бесплатные инструменты
Разрабатываем программу тестирования
Шаг 1 — Определите цели тестирования
Самое важное – определить на какие вопросы вы должны получить ответы в ходе тестирования. Ищите слабые места вашего продукта, тестируйте сложные действия пользователя и другие идеи, которые могут оказаться критичными. Наличие таких вопросов поможет подобрать наиболее подходящий метод тестирования и создать план. При недостатке средств можно использовать метод тестирования под названием «Мысли вслух».
«В тесте «Мысли вслух», вы просите участников непрерывно размышлять вслух, просто выражая словами их мысли, когда они пользуются интерфейсом» — Jakob Nielsen
Шаг 2 — Создайте сценарий
Здравствуйте! Меня зовут Алексей, и я буду сопровождать ваше тестирование. Спасибо за то, что нашли время поучаствовать в тестировании, Ваш отзыв очень ценен. Прежде чем мы начнем, я хотел бы прояснить несколько пунктов.
После идентификации целей исследования, определенных на предыдущем этапе, я проведу обсуждение некоторых вопросов по темам:
Фон/Контекст — «Как обычно вы создаете сайты? Вы используете приложения или сервисы?»
Ожидания — «Прежде, чем нажать кнопку поиска, чего вы ожидаете, что должно произойти?»
Юзабилити — «Как эту область лучше всего использовать?»
Шкала оценки — «Как сложно(1) или легко(5) создать форму в редакторе?»
Если ваш продукт сложен, расставьте приоритеты в вопросах и проведите многократные сеансы тестирования. Рассчитывайте, что для сеанса 20–30 минут используется 1–2 вопроса и 3–5 задач. Обращайте внимание на формулировки и избегайте наводящих вопросов, чтобы исключить влияние на поведение пользователя. Например, «Как вы прокручиваете страницу, чтобы видеть больше контента?» предполагает, что можно прокрутить. Лучше спросить «На странице есть еще контент? Как его можно увидеть?»
Шаг 3 — Создайте каркас и прототип
Каркас должен фокусироваться в меньшей степени на зрительном ряде и в большей на расположении элементов. Если вы используете программу для создания прототипа на основании визуальных каркасов, используйте их. С помощью платформы PIXLI можно пропустить этот шаг и сразу создать интерактивный прототип с визуализацией элементов. Общее правило состоит в том, чтобы создать высокоточные мокапы после проверки корректности основных пользовательских потоков, а не до них.
На этом этапе ваш прототип должен соответствовать вопросам, которые вы поставили. Если первая задача звучит как «Как вы авторизуетесь в системе?», то прототип должен демонстрировать доступ к форме и саму форму авторизации.
Если вторая задача – «Как вы создаете сайт на основании шаблона в редакторе», то где-то должен присутствовать переход к созданию сайта на основе шаблонов и возможность их выбора. Обратите внимание, где пользователи ищут путь решения задачи. Это и есть цель тестирования.
Шаг 4 — Поиск пользователей
Определитесь с целевой аудиторией. Если на тестирование выделили бюджет, обеспечьте стимулы для пользователей. Например, Google или Airbnb обычно стимулируют пользователей, предлагают подарочную карту. Если бюджет отсутствует, воспользуйтесь следующими подсказками.
Если у вас уже есть пользователи
Идентифицируйте людей, которые активно используют ваш продукт и отправьте сообщение по электронной почте. Предложите им поучаствовать с целью дальнейшего развития продукта. Сообщите, что будете учитывать все мнения и результаты тестирования. Легкий подхалимаж не помешает. Пользователь даст обратную связь, если он лично заинтересован в вашем продукте – ваш успех это его успех. Если пользователь не заинтересован, объясните, какую продукт приносит пользу или как решает его проблему.
Если у вас нет пользователей
Найдите места, где собирается ваша целевая аудитория лично или онлайн. Ищите форумы, группы в соцсетях, клубы и т.д. И отправьте сообщение, например:
«Здравствуйте, Андрей! Я разработчик платформы для web-дизайна PIXLI. По сообщениям на форуме я обратил внимание, что вы активно используете конструкторы для создания сайтов. Не могли бы Вы уделить полчаса на тестирование нашего продукта? Если да, то сообщите о наиболее удобном для Вас времени».
Если это не работает, расширьте зону поиска пользователей или обеспечьте маленькие стимулы. Например, можно предложить увеличить тестовый период пользования платформой, или расширить бесплатный функционал. Искать пользователей для тестирования трудно, если бюджет отсутствует.
Сколько пользователей должны участвовать в тестировании?
3–5 пользователей за один сеанс достаточно, чтобы увидеть большинство проблем. Если вам необходимо большее число пользователей, увеличьте количество сеансов.
Шаг 5 — Создайте подходящую обстановку для тестирования
Личные сеансы тестирования лучше проводить в тишине. Например, выделите комнату в своем офисе. Кафе тоже является неплохим вариантом, но там может быть шумно – это мешает. Следите за отсутствием отвлекающих факторов. Или постарайтесь их минимизировать. Если вы назначили встречу в кафе, лучше выбрать время, когда там не собирается полсотни служащих соседнего офисного центра на обед.
Удаленные сеансы проще организовать – пользователь находится в комфортной и привычной обстановке. Однако могут происходить технические сбои и надо иметь запасные возможности. Например, быстро сменить клиента для связи.
Всегда проводите пробный прогон!
Как следует проверьте свой прототип, доступ к нему. Прогоните сначала свой сценарий сами, чтобы еще раз все детализировать и уточнить.
Шаг 6 — Подготовка сеанса
Электронные письма-напоминания полезны, чтобы уменьшить неявки. Сообщите, в течение какого времени вы будете ожидать пользователя.
Записывайте высказывания пользователя на аудио, а потом их анализируйте. Видео и аудио позволят увидеть все действия и услышать «мысли вслух» по поводу их выполнения. Особенно те, которые отклоняются от заданного поведения. Обязательно предупредите пользователя, что его действия будут фиксироваться.
Шаг 7 — Анализируйте ключевые результаты
Пересмотрите, протестируйте, повторитесь
Пользовательское тестирование даст вам направление для движения дальше. Продукт запускается в разработку, когда решены проблемы юзабилити и общая обратная связь положительна. Если обратная связь нейтральна или отрицательна, или УТП для пользователя не определено четко, следует пересмотреть прототип и выполнить тестирование еще раз.
____________________ __________ __________ __________ __________ __________
Материал создан агентством контент-маркетинга Текстотека.
Хотите самостоятельно внедрить контент-маркетинг в свой бизнес? Подписывайтесь на наше сообщество ВКонтакте, там много бесплатного обучающего материала.
Как работать тестировщику: выстраиваем планирование, общаемся с командой разработки и проверяем сайты на безопасность
Мы собрали митап, где трое экспертов по QA рассказали, о чем тестировщику нужно говорить с командой разработки, какими инструментами пользоваться для планирования и тестирования, а также что нужно учесть, чтобы сделать сайты безопасными. Внутри есть видео и текстовая выжимка по каждому докладу.
Современные паттерны тестирования
Рассказывает директор по развитию бизнеса в IT-компании @BSL_Dev и ex-руководитель отдела обеспечения качества Redmadrobot Марина Куликова @Marishunya_QA.
Коротко в чем суть.
Бывает, что в командах разработки забывают о принципе раннего тестирования. Существует миф, что тестирование продукта должно проходить в конце спринта или разработки. При такой организации процесса проекта могут возникать ошибки (как процессные, так и технические).
Чтобы такого не случалось, тестирование продукта должно быть в самом начале разработки. Кроме того, тестовые активности должны идти параллельно с ней. Это помогает тестировщикам оповещать команду о рисках заранее и давать обратную связь на каждом этапе, начиная от анализа требований до финальных релизных отчетов и поддержки.
Основная цель тестирования — своевременно оповещать команду о реальном состоянии системы или продукта
Основные точки опоры для построения тестирования
Анализ требований или технического задания.
Инфраструктура — важно настроить окружение, выбрать целевые устройства, какие тестовые данные потребуются.
Процесс коммуникации — нужно договориться, в каком формате мы выстраиваем обратную связь с командой (например, делаем отчеты о тестировании в Jira).
Разбираемся, как именно организовываем тестирование: какие виды тестирования, на каких этапах применяем, как распределяем ресурсы, планирование и так далее.
Уделяем время написанию отчетности и договариваемся, какая отчетность и в каком виде нужна.
Постоянно внедряем улучшения и анализируем изменения.
О чем тестировщик должен сообщать команде
Что нужно автоматизировать. В процессе коммуникации с разработчиками и менеджерами тестировщику нужно определить и рассказать, какие тесты должны быть автоматизированы и на каком уровне.
Как оптимизировать работу. Нужно делать постоянную оптимизацию тестов, чтобы они затрачивали меньше времени. Задача тестировщика — минимизировать время выполнения тестов, оптимизировать фича тесты и регресс. Это нужно, для того чтобы быстро получать информацию о состоянии продукта.
Обеспечить полезные метрики для бизнеса. Например, количество багов на продакшене, количество активностей, как двигается процесс написания документации, время, затраченное на тестирование и т.д. Такие метрики будут сигнализировать, всё ли у проекта хорошо. Кроме того, с помощью них тестировщик может показать результаты работы всей команды. Но стоит помнить, что не стоит закапываться в метриках, а нужно использовать скорее их как опорные точки. Ведь, помимо метрик, есть и другие системы отчетности.
Напоминать о новых инструментах. Важно говорить об инструментах тестирования, потому что сейчас они постоянно меняются. Стоит постоянно мониторить, как изменяются инструменты, и добавлять себе самые лучшие.
Тестирование — это как круговая оборона. Весь продукт «охранять» очень сложно, поэтому тестировщики создают «датчики» (некие красные флажки), которые в нужный момент сообщают: alarm! И подобные «датчики» — это метрики, а также автотесты, различные приемы и т.д. Задача команды тестирования выстроить многослойную систему защиты, состоящую из нужных «датчиков». Также стоит помнить, что помимо того, что QA тестирует, команда ещё сообщает реальное состояние системы, где все окей, где начинает «рваться», а где все плохо и нужно срочно исправлять.
Как тестировщику обеспечивать обратную связь для команды
С помощью парного тестирования или программирования. Автоматизацию тестирования полезно делать при поддержке разработчиков. На этом этапе должно происходить взаимное ревью, это помогает тестировщику глубже узнать систему и уже на этом этапе обнаружить какие-то проблемы.
С помощью Code Reviews. Это не совсем работа тестировщика, но в проекте через Code Reviews можно получить обратную связь. Например, если у нас фича автоматизации типовая, и она долго ревьюится на разных проектах, то нужно выяснить причину.
Через модульные тесты (Unit tests).
С помощью автоматизированных интеграционных тестов (Automated Integration Test).
С помощью автоматизированных Acceptance Tests. Эту активность можно разделить с продакт-менеджерами.
По возможности следует автоматизировать Regression Test.
Постоянный Exploratory Testing.
Обратная связь от пользователей или бизнес-юзеров.
Постоянное UAT-тестирование + DEMO-сессии.
Через что тестировщик может организовать обратную связь с командой
С помощью работы с дефектами (багами) — нужно определить формат их заведения и оповещения о них, например, делать это в Jira или другом удобном инструменте. Разработчикам не всегда хватает информации в дефекте, чтобы приступить к фиксу, поэтому иногда требуется дополнительная коммуникация с багрепортером.
Организовать коммуникацию по сборкам и состояниям тестовых сред. Это понадобится, если вдруг с ними что-то пойдет не так или они задерживаются.
Кросс-обучение внутри тестирования. Все специалисты разные, они могут учиться друг у друга, поэтому важно иногда собираться и обсуждать результаты работы и делиться лайфхаками и знаниями продукта. Это некий knowledge transfer.
Тест-документация — собирать отчетность по фичам, сборкам и по приемке. Для составления отчетности поможет изучение ГОСТов: в них описаны градации дефектов, как с ними быть и так далее. Для проектов, связанных с государственным подрядом, поможет изучение ГОСТ 34.603-92.
Как тестировщикам работать с Google-таблицами (и зачем)
Руководитель отдела тестирования Redmadrobot Саша Строкин собрал собственные Google-таблицы, с помощью которых он выстраивает работу, начиная от планирования и заканчивая аналитикой для тестировщиков.
На нескольких примерах Саша рассказал об инструментах и формулах, которые он использует в работе.
Google-таблицы при планировании — подготовка к процессу тестирования
В тестировании есть четыре главных процесса:
Планирование — подготовка к самим работам по тестированию,
Test development — крафтинг артефактов, разработка сценариев тестирования,
Test execution — само выполнение тестирования,
Test analysis — оценка результатов тестирования, выделение процессов, которые нужно улучшать или, наоборот, не стоит менять.
Планирование в Google-таблицах — это инструмент, необходимый в первую очередь для лидов, чтобы вовремя подключать и отключать нужных людей, проводить ротации, отслеживать нагрузку сотрудников.
Чтобы облегчить процесс планирования, в Sheets можно создать вкладку Dictionary, где описываются все существующие проекты для работы, список участников, роль инженера на проекте и так далее.
Стоит отметить, что Google Sheet позволяет добавлять отдельные срезы, если мы говорим про фильтрацию данных, ее можно делать как на уровне всей таблицы, так и по отдельным критериям. Например, если нажать на вкладку с указанием определенного проекта, то увидим, сколько инженеров на данный момент в нём задействовано и процент их загрузки.
Интеграция Google-таблиц с Jira
Интеграция Excel c рабочим инструментом большинства команд разработки и тестирования — Jira — возможна через специальный плагин — Jira Cloud of Sheets.
C помощью этого плагина можно «вытаскивать» любые данные из бэклога Jira по тому же фильтру, по которому обычно тестировщики фильтруют дефекты, только с переводом не на графическое изображение, а на JQL.
На примере Саша показал, как решил проверить все свои дефекты и собрать на этом фоне статистику. За время работы над проектом в общей сложности было заведено 1500 дефектов и по ним была сформирована статистика. Можно посмотреть, например, какие из них обладают уровнем приоритетности. Также можно в виде графиков формировать статистику по практически любым показателям.
Кроме того, с помощью плагина можно выгрузить статистику по отдельным проектам и посмотреть статистику по нему. Можно проанализировать, как проекты обрастают дефектами в динамике и увидеть, что, например, в июне и июле на проекте было заведено больше всего багов.
Для формирования такой статистики нужно воспользоваться вкладкой MounthStat (она вытягивает данные о дате создания из общей выгрузки, где мы можем выбрать дату создания дефекта). С помощью функции Trim даты можно рассортировать по месяцам.
Тестирование и безопасность web-сайтов для начинающих тестировщиков
Рассказала и показала QA-инженер Redmadrobot Вика Бегенчева @vikusti.
Основные уловки мошенников, как они могут навредить пользователям или системам:
С помощью cookies
Вика рассказала, что такое cookies на примере интернет-магазина. Допустим, мы открываем браузер, заходим на сайт и кладем в корзину печеньки, которые нам понравились. Если мы закроем окно браузера, а затем откроем заново, то вся информация про начавшиеся покупки сохранится. Это происходит с помощью cookies — различной информации о пользователе, которая хранится в браузере локально.
Эта информация нужна для удобства пользователя, чтобы сайт «запоминал» определенные данные и нам не приходилось постоянно их указывать. Cookies бывают двух видов: временные (cookies-сессии) и постоянные. Cookies-сессии хранятся определенное ограниченное время и могут меняться, когда пользователь перелогинился. Постоянные сookies хранятся всегда, пока вы их не сотрете.
Как хакеры могут использовать cookies
Хакер может «угнать» ваши cookies и с помощью этого «доказать» системе, что он — это вы. Тогда он сможет переиспользовать их и продолжить сессию. Это происходит так:
Через протоколы: HTTP и HTTPS
Копаясь на просторах интернета, мы до сих пор можем попадать на сайты, о небезопасности которых нас предупреждает браузер.
Почему так? Потому что браузер умный, и он считает ненадежным сайты, в которых происходит соединение по HTTP, а не HTTPS. В протоколе HTTPS есть последняя буква S, это значит, что добавляются повышенные требования к безопасности. В этом протоколе при общении браузера с сервером по протоколу https добавляется сертификат безопасности: если хакер попробует перехватить такие запросы, он получит лишь набор символов и не сможет их расшифровать.
Подбор пароля — Brute force
Это атака перебора — мошенник может знать логин и с помощью специального скрипта подбирать пароль. Обычно подбор пароля с помощью скрипта занимает около 10 часов.
Как проверять сайты на безопасность
Посмотреть, как устроена безопасность хранения cookies: открываем «Инспектор» в браузере, заходим в вкладку application и видим свои cookies для сайта. Для проверки безопасности нужно обратить внимание на столбцы под названием httpOnly и secure. Если галочки стоят, то на сайте предусмотрена защита от угона cookies.
Нужно проверять, чтобы все запросы шли через протокол HTTPS. Например, работаем с сайтом диванынадом.ру. Нужно убрать букву S из протокола и проверить, можно ли зайти только по ссылке с HTTP. Если да, то это плохо, мошенник может создать такую ссылку и перехватывать запросы пользователей. Чтобы этого избежать, нужно создать редирект — автоматически перебрасывать пользователей на безопасную страницу.
При введении логина/пароля нужно использовать ограничение на количество неправильных попыток, а также использовать таймаут, например, после трех неудачных попыток введения пароля попробовать ввести пароль в четвертый раз можно лишь через час. Это поможет избежать взлома с помощью автоматического подбора паролей.
Вика написала отдельную статью, где подробно рассказала про все пункты и дала еще больше советов для начинающих тестировщиков.
Полезные ссылки
Telegram-канал «Google Таблицы»: много информации о фишках Google Sheets;
YouTube STM Solutions: видеоуроки Google Docs, Google Sheets, Google Apps Script;
Jira Cloud for Sheets: плагин для интеграции Google Sheets с основным рабочим инструментом большинства команд — Jira;
owasp.org: некоммерческий фонд, который работает над повышением уровня безопасности ПО;
hackthebox.eu: тренировочная онлайн-платформа, на которой можно проверить навыки тестирования в сфере безопасности сайтов;
xss-game.appspot.com: тренировочная игра для обнаружения и устранения ошибок XSS.
Кстати, мы ищем QA-специалистов в команду, залетайте посмотреть.
Как сохранить нервы тестировщика или ускорить регресс с 8 до 2 часов
Меня зовут Юля, и я Mobile QA в компании Vivid Money.
В тестировании уже давно — столько всего интересного видела. Но как показывает практика, проблемы и заботы у всех одинаковые. Разница только в анализе, подходах и реализации решений.
В этой статье я расскажу, КАК ОБЛЕГЧИТЬ ЖИЗНЬ ТЕСТИРОВЩИКУ ВО ВРЕМЯ РЕГРЕССА!
Расскажу по порядку:
Наши процессы (для полноты картины)
Методы решения, с полученными результатами
Немного о наших процессах
Итак, релиз приложений происходит раз в неделю. Один день закладывается на регрессионное тестирование, второй на 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 помогло заранее определять локализацию проблем и своевременное исправление.