Как работать тестировщику: выстраиваем планирование, общаемся с разработкой и проверяем сайты на безопасность
Мы собрали митап, где трое экспертов по QA рассказали, о чём тестировщику нужно говорить с командой разработки, какими инструментами пользоваться, а также что нужно учесть, чтобы сделать сайты безопасными. Внутри есть видео и текстовая выжимка по каждому докладу.
Современные паттерны тестирования
Рассказывает директор по развитию бизнеса в IT-компании BSL и ex-руководитель отдела обеспечения качества red_mad_robot Марина Куликова.
Коротко в чем суть.
Бывает, что в командах разработки забывают о принципе раннего тестирования. Существует миф, что тестирование продукта должно проходить в конце спринта или разработки. При такой организации процесса проекта могут возникать ошибки (как процессные, так и технические).
Чтобы такого не случалось, тестирование продукта должно быть в самом начале разработки. Кроме того, тестовые активности должны идти параллельно с ней. Это помогает тестировщикам оповещать команду о рисках заранее и давать обратную связь на каждом этапе, начиная от анализа требований до финальных релизных отчетов и поддержки.
Основные точки опоры для построения тестирования
- Анализ требований или технического задания.
- Инфраструктура — важно настроить окружение, выбрать целевые устройства, какие тестовые данные потребуются.
- Процесс коммуникации — нужно договориться, в каком формате мы выстраиваем обратную связь с командой (например, делаем отчеты о тестировании в Jira).
- Разбираемся, как именно организовываем тестирование: какие виды тестирования, на каких этапах применяем, как распределяем ресурсы, планирование и так далее.
- Уделяем время написанию отчетности и договариваемся, какая отчетность и в каком виде нужна.
- Постоянно внедряем улучшения и анализируем изменения.
О чем тестировщик должен сообщать команде
- Что нужно автоматизировать. В процессе коммуникации с разработчиками и менеджерами тестировщику нужно определить и рассказать, какие тесты должны быть автоматизированы и на каком уровне.
- Как оптимизировать работу. Нужно делать постоянную оптимизацию тестов, чтобы они затрачивали меньше времени. Задача тестировщика — минимизировать время выполнения тестов, оптимизировать фича тесты и регресс. Это нужно, для того чтобы быстро получать информацию о состоянии продукта.
- Напоминать о новых инструментах. Важно говорить об инструментах тестирования, потому что сейчас они постоянно меняются. Стоит постоянно мониторить, как изменяются инструменты, и добавлять себе самые лучшие.
- Тестировщик должен обеспечить полезные метрики для бизнеса. Например, количество багов на продакшене, количество активностей, как двигается процесс написания документации, время, затраченное на тестирование и т.д. Такие метрики будут сигнализировать, всё ли у проекта хорошо. Кроме того, с помощью них тестировщик может показать результаты работы всей команды. Но стоит помнить, что не стоит закапываться в метриках, а нужно использовать скорее их как опорные точки. Ведь, помимо метрик, есть и другие системы отчетности.
Как тестировщику обеспечивать обратную связь для команды
- С помощью парного тестирования или программирования. Автоматизацию тестирования полезно делать при поддержке разработчиков. На этом этапе должно происходить взаимное ревью, это помогает тестировщику глубже узнать систему и уже на этом этапе обнаружить какие-то проблемы.
- С помощью Code Reviews. Это не совсем работа тестировщика, но в проекте через Code Reviews можно получить обратную связь. Например, если у нас фича автоматизации типовая, и она долго ревьюится на разных проектах, то нужно выяснить причину.
- Через модульные тесты (Unit tests).
- С помощью автоматизированных интеграционных тестов (Automated Integration Test).
- С помощью автоматизированных Acceptance Tests. Эту активность можно разделить с продакт-менеджерами.
- По возможности следует автоматизировать Regression Test.
- Постоянный Exploratory Testing.
- Обратная связь от пользователей или бизнес-юзеров.
- Постоянное UAT-тестирование + DEMO-сессии.
Через что тестировщик может организовать обратную связь с командой
- С помощью работы с дефектами (багами) — нужно определить формат их заведения и оповещения о них, например, делать это в Jira или другом удобном инструменте. Разработчикам не всегда хватает информации в дефекте, чтобы приступить к фиксу, поэтому иногда требуется дополнительная коммуникация с багрепортером.
- Организовать коммуникацию по сборкам и состояниям тестовых сред. Это понадобится, если вдруг с ними что-то пойдет не так или они задерживаются.
- Кросс-обучение внутри тестирования. Все специалисты разные, они могут учиться друг у друга, поэтому важно иногда собираться и обсуждать результаты работы и делиться лайфхаками и знаниями продукта. Это некий knowledge transfer.
- Тест-документация — собирать отчетность по фичам, сборкам и по приемке. Для составления отчетности поможет изучение ГОСТов: в них описаны градации дефектов, как с ними быть и так далее. Для проектов, связанных с государственным подрядом, поможет изучение ГОСТ 34.603-92.
Как тестировщикам работать с Google-таблицами (и зачем)
Руководитель отдела тестирования red_mad_robot Саша Строкин собрал собственные 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-инженер red_mad_robot Вика Бегенчева.
Основные уловки мошенников, как они могут навредить пользователям или системам:
С помощью 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.