в программе тестирования уже участвует максимальное количество человек что делать
Как работать тестировщику: выстраиваем планирование, общаемся с командой разработки и проверяем сайты на безопасность
Мы собрали митап, где трое экспертов по 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-специалистов в команду, залетайте посмотреть.
Меньше, чем пара. Еще один способ сокращения количества тестов
Любому QA известен такой метод минимизации тест-кейсов, как Pairwise Testing — попарное тестирование. Метод отличный, достаточно простой и проверенный множеством команд. Но что делать, если после его применения кейсов остается слишком много?
Именно так произошло в моем проекте, и сегодня я расскажу, как можно еще сильнее сократить количество тест-кейсов, не теряя при этом в качестве.
Тестируемый объект
Для начала расскажу немного о продукте. В Тинькофф наша команда разрабатывала блоки — это React-компоненты, состоящие из реализации и конфигурации. Реализация — это непосредственно сам компонент, который мы разработали и который видит пользователь в браузере. Конфигурация — это JSON, который задает параметры и наполнение этого объекта.
Главная задача блоков — быть красивыми и одинаково отображаться у разных пользователей. При этом от конфигурации и контента блок может очень значительно меняться.
Например, блок может быть таким — без фона, с кнопкой и картинкой справа:
Или вот таким — с фоном, без кнопки и с картинкой слева:
Или вообще вот таким — со ссылкой вместо кнопки и без списка в тексте:
Все примеры выше — это один и тот же блок, который имеет одну версию конфигурации (структура JSON, которую умеет обрабатывать конкретно этот React-компонент), но разное ее наполнение.
Кейсы из сочетания параметров
В этой статье я не буду касаться вопросов версионирования схемы блоков, правил наполнения контентом или того, откуда в блок приходят данные. Все это — отдельные темы, которые никак не влияют на составление набора тест-кейсов. Главное, знать: у нас есть много параметров, влияющих на наш компонент, и каждый из них может принимать свой набор значений.
Для примера выше я выбрала блок с достаточно простой конфигурацией. Но даже в нем проверка всех сочетаний значений всех параметров займет непозволительно много времени, особенно если придется учитывать кроссбраузерность. Обычно здесь на помощь приходит Pairwise Testing, или попарное тестирование. Про него уже написаны тонны статей и есть даже обучения. Если вдруг не сталкивались — обязательно почитайте.
Давайте прикинем, сколько тест-кейсов у нас получится при его применении. Мы имеем больше 25 параметров, и некоторые из них принимают аж 7 и 9 вариантов значений. Да, можно чем-то пренебречь: например, если вы проверяете верстку, guid вам не важен. Но при применении Pairwise Testing все равно получится больше 80 тест-кейсов. И это, как я уже писала, для не самого сложного блока и без учета кроссбраузерности. Блоков у нас сейчас больше 150, и их количество растет, так что позволить себе столько кейсов мы не можем, если хотим сохранить скорость тестирования и выпуска новых версий.
Кейсы из одного параметра
Метод попарного тестирования основан на утверждении о том, что большинство дефектов вызвано взаимодействием не более двух факторов. То есть большинство багов проявляются либо на одном значении какого-то параметра, либо на сочетании значений двух параметров. Мы решили пренебречь второй частью этого утверждения и предположили, что при проверке одного параметра все равно будет найдено большинство багов.
Тогда получается, что для тестирования нам нужно проверить каждое значение каждого параметра хотя бы один раз. Но при этом каждый блок несет в себе всю конфигурацию. Тогда можно в каждом новом кейсе проверять максимум еще не проверенных значений, чтобы минимизировать количество кейсов.
Разберем алгоритм построения кейсов на упрощенном примере. Возьмем из нашей схемы компонент button и составим для него тест-кейсы:
Шаг 1. Составляем варианты контента для каждого поля
Здесь, на мой взгляд, важно очень четко определить границы и функциональность своей системы и не проверять лишнее. То есть если проверка на обязательность ключей или валидация значения реализованы в сторонней системе, то и проверять эту функциональность нужно в сторонней системе. А мы должны в качестве кейсов использовать только «правильные» данные.
По большому счету этот же принцип используется в пирамиде тестирования. При желании самые критичные интеграционные тесты можно добавить к нам — например, проверять обработку не пришедшего ключа. Но таких тестов должно быть минимальное количество. Иной подход — стремление к исчерпывающему тестированию, которое, как всем известно, невозможно.
Итак, мы определили варианты контента для каждого поля и составили такую таблицу:
В эту таблицу входит каждый класс эквивалентности каждого параметра, но только один раз.
Вот такие классы значений в нашем случае классы:
Шаг 2. Обогащаем таблицу данными
Поскольку каждый блок несет в себе полную конфигурацию, нам нужно добавить какие-нибудь релевантные данные в пустые ячейки:
Теперь каждый столбец — это один кейс.
При этом, поскольку недостающие данные мы выбираем сами, мы можем генерировать кейсы исходя из приоритета. Например, если мы знаем, что в кнопке короткий текст используется чаще, чем текст средней длины, то и проверять его стоит чаще.
В примере выше также можно обратить внимание на «выпавшие» кейсы — кейсы, в которых какой-то параметр вообще не проверяется, хотя и присутствует в таблице. В данном случае button.color.style: secondary не будет проверен на внешний вид, потому что неважно, какой стиль у отключенной кнопки.
Чтобы «выпавшие» кейсы не привели к багам, раньше мы анализировали полученные наборы значений. Анализ происходил один раз при генерации тестовых наборов, и все «выпавшие» кейсы добавлялись вручную в итоговый тестовый набор. Такое решение проблемы достаточно топорное, но дешевое (если, конечно, у вас редко меняются конфигурации тестируемых объектов).
Более универсальное решение — разделить все значения на две группы:
Шаг 3. Уточняем значения
Теперь осталось только сгенерировать конкретные значения вместо классов эквивалентности.
Здесь каждому проекту придется подобрать свои варианты значений, опираясь на особенности тестируемого объекта. Некоторые значения генерировать очень просто. Например, цвет для большинства полей можно просто брать любой. Для некоторых блоков при проверке цвета приходится добавлять градиент, но он вынесен в отдельный класс эквивалентности.
С текстом чуть сложнее: если сгенерировать строку из случайных символов, то не будут протестированы переносы, списки, теги, неразрывные пробелы. Мы генерируем короткие и средней длины строки из реального текста, обрезая его до нужного количества символов. А в длинном тексте проверяем:
Получается, что для каждого проекта нужно составить свой актуальный набор контента исходя из реализации тестируемого объекта.
Алгоритм
Конечно, на первый взгляд может показаться, что алгоритм сложный и не стоит потраченных усилий. Но если опустить все детали и исключения, которые я постаралась описать в каждом пункте выше, получается достаточно просто.
Шаг 1. Добавляем в таблицу параметров все возможные значения:
Шаг 2. Дублируем значения в пустые ячейки:
Шаг 3. Превращаем абстрактные значения в конкретные и получаем кейсы:
Каждый столбец таблицы — это один кейс.
Преимущества подхода
Такой способ генерации тест-кейсов имеет несколько важных преимуществ.
Меньше кейсов
Первое и очевидное — кейсов значительно меньше, чем в попарном тестировании. Если брать упрощенный пример с кнопкой — у нас получилось 4 кейса вместо 8 в попарном тестировании.
Чем больше параметров в тестируемом объекте, тем значительнее будет экономия кейсов. Например, для полного блока, представленного в начале статьи, у нас получается 11 кейсов, а с помощью попарного — 260.
Не раздувается количество кейсов при усложнении функциональности
Второй плюс — при появлении новых параметров, учитывающихся при тестировании, количество кейсов увеличивается далеко не всегда.
Количество кейсов увеличится только в том случае, если у какого-то параметра станет больше значений, чем было кейсов.
Можно чаще проверять важное
За счет обогащения значениями (шаг 2 в алгоритме) можно чаще проверять более приоритетные или более рискованные значения.
Например, если мы знаем, что раньше пользователи чаще использовали короткий текст, а теперь — более длинный, мы можем обогащать кейсы более длинным текстом и чаще попадать в реальные пользовательские кейсы.
Можно автоматизировать
Алгоритм, приведенный выше, вполне поддается автоматизации. Конечно, сгенерированные алгоритмом кейсы будут меньше походить на реальные, чем сгенерированные человеком. Хотя бы за счет подбора цветов и обрезания текста.
Но зато уже в процессе разработки без участия тестировщика появляются кейсы, что очень сильно сокращает петлю обратной связи.
Недостатки
Естественно, такая генерация кейсов — далеко не серебряная пуля и имеет свои недостатки.
Сложно анализировать результат
Думаю, вы обратили внимание, что в процессе генерации кейсов происходит смешивание тестовых данных друг с другом. Из-за этого при падении кейса усложняется процесс выявления причины падения. Ведь часть параметров, задействованных в кейсе, никак не влияет на результат теста.
Это правда затрудняет разбор результатов тестов, с одной стороны. Но, с другой стороны, если тестируемый объект требует большой объем обязательных параметров, это тоже затрудняет нахождение причины бага.
Могут быть пропущены баги
Возвращаясь к самому началу статьи: при применении этого метода мы допускаем возможность пропуска багов, вызванных сочетанием двух и более параметров. Зато выигрываем в скорости, так что только вам решать, что важнее на каждом конкретном проекте.
Чтобы не пропускать баги дважды, мы ввели Zero Bug Policy и стали закрывать каждый пропущенный баг дополнительным тест-кейсом — уже не автоматически сгенерированным, а написанным вручную. Это дало отличные результаты: сейчас у нас более 150 блоков (тестируемых объектов), несколько релизов в день и от 0 до 3 пропущенных некритичных багов в месяц.
Выводы
Если в вашем тестируемом объекте широкий набор входных параметров и вы хотите попробовать сократить количество кейсов и, как следствие, время на тестирование, я рекомендую попробовать приведенный выше метод генерации кейсов через один параметр.
На мой взгляд, для фронтовых компонентов он подходит идеально: можно более чем в три раза сократить время, например, на проверку внешнего вида через скриншот-тестирование. Да и разработка пойдет быстрее за счет появления кейсов на самых ранних этапах.
Конечно, если вы тестируете автопилот новой «Теслы» — нельзя пренебрегать даже малой вероятностью пропуска бага. Но в большинстве случаев не стоит забывать, что скорость в современном мире — это весьма важный критерий качества. А прирост скорости дает больше положительного результата, чем пара найденных минорных проблем.
А для самых ответственных в следующей статье я расскажу, как можно дополнительно предохраниться от хитрых багов, вызванных сочетанием параметров, при помощи пользовательских кейсов и StoryBook.