В одном из старых проектов в кучу были навалены ассерты из JUnit, kotlin.test и AssertJ. Это было не единственной его проблемой: его вообще писали как письмо Дяди Федора, а времени остановиться и привести к единому виду не было. И вот это время пришло.
В статье будет мини-исследование про то, какие ассерты лучше по субъективным критериям. Хотел сначала сделать что-то простое: накидать набор тестов, чтобы быстренько копипастом клепать варианты. Потом выделил общие тестовые данные, некоторые проверки автоматизировал, и как поехало все… В результате получился небольшой розеттский камень и эта статья может пригодится вам для того, чтобы выбрать библиотеку ассертов, которая подойдет под ваши реалии.
Сразу оговорюсь, что в статье не будет сравнения фреймворков для тестирования, подходов к тестированию и каких-то хитрых подходов к проверке данных. Речь будет идти про несложные ассерты.
Автор: Баз Дейкстра (Bas Djikstra) Оригинал статьи Перевод: Ольга Алифанова
Недавно я провел свой первый трехдневный курс "Python для тестировщиков". В нем я, в частности, раскрывал тему создания тестов REST API с использованием Python-библиотеки requests и фреймворка pytest для юнит-тестирования.
В этой короткой серии статей я хочу показать, как можно использовать Python-библиотеку запросов для создания тестов REST API. Это третья часть серии, и в ней мы рассмотрим работу с XML-телами запросов и ответов. В предыдущих частях рассказывалось, как приступить к работе с requests и pytest, а также о создании тестов, управляемых через данные.
Загрузить через любой сервис конвертирования изображения в base64 строку, например, https://www.base64-image.de/
Скопировать полученную строку целиком, включая начало: «data:image/png;base64,iVBORw0KG...»
Вставить в параметр для передачи фото в формате base64
Профит! Инструкция одинаковая для REST и SOAP.
Но смысл этого поста, разумеется, не в инструкции. А в том, чтобы сразу ее применить! Попробовать пощупать самостоятельно. Сделать это можно в API бесплатной системы Shop, метод create или update.
Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
Теперь WebDriver готов к работе – давайте напишем наш первый web-тест! Это будет простой поиск DuckDuckGo. DuckDuckGo – это поисковик, который не отслеживает пользовательские данные. Пользователи могут вводить запросы и получать ссылки на соответствующие сайты, как и в любой другой поисковой системе.
По моему наблюдению довольно много тестировщиков когда-либо слышали такое понятие, как XSS-уязвимость. Но мало кто может просто и на пальцах рассказать на собеседовании про нее. Или эффективно проверить веб-сайт на наличие этой уязвимости. Давайте вместе разберемся со всем этим подробнее и попробуем сами найти XSS-уязвимость на демо-странице, которую я специально подготовил к этой статье. :)
Автор: Роберт Сабурин (Robert Sabourin). Оригинал статьи Перевод: Ольга Алифанова
Я нахожусь в постоянном поиске новых идей для тестирования. Некоторые из наиболее ценных идей приходят в голову непосредственно в ходе тестирования. Вот список из десяти источников тест-идей, которыми я пользуюсь при тестировании динамических тест-проектов:
Привет, меня зовут Лилия, я QA TeamLead в финансовом маркетплейсе Одобрим.ру.
У нашей команды нет разделения на разработку и поддержку, и мы работаем по Kanban. Данная методология позволяет нам совмещать поддержку (т.е. задачи, которые появляются неожиданно и которые нужно выполнить срочно) и задачи из бэклога, которые запланированы заранее.
Процесс тестирования является частью процесса разработки. Он должен быть эффективен для того, чтобы не задерживать выпуск готового функционала в продуктивную среду. Для этого мы стремимся его постоянно совершенствовать.
Автор: Джош Грант (Josh Grant) Оригинал статьи Перевод: Ольга Алифанова
В своей последней статье о прелестях Pytest я бы хотел немного изменить правила и поговорить о достоинствах такой библиотеки Python, как requests. Requests – несомненно, один из моих любимых программных продуктов. Как и говорится на его домашней страницы, Requests – это HTTP, сделанное для людей.
Наш текущий QA-процесс мы прорабатывали порядка двух лет и он продолжает активно развиваться. Он может казаться очевидным, но когда мы начали внедрять его в новой команде, которая полностью состояла из новых разработчиков, то поняли, что сразу внедрить его сложно. Многие привыкли работать иначе и для переключения им требуется сделать единовременно много изменений — это сложно. Однако внедрять такой процесс частями тоже нельзя, потому что это может негативно сказаться на качестве.
Что делать? Нужна предварительная подготовка по каждому из блоков процесса разработки: декомпозиция задачи, оценка и планирование, непосредственно разработка, исследовательское тестирование, релиз. Подготовка заключается не в простом выбрасывании старых частей из процесса, а в их адекватной замене, которая даёт прирост в качестве.
В статье расскажу подробно о нашем процессе тестирования на каждом этапе создания новой фичи и о внедрённых изменениях, которые повысили качество и скорость разработки.
