Как обычно тестировщик ищет границы в поле? Если в ТЗ есть ограничения, то тестирует их. А если их нет? С нижней границей все понятно — это пустое поле. А как найти верхнюю? Вставляем большую строку и смотрим, сколько символов сохранится. И всё…
И тестировщик должен проверить их все. Почему? Потому что когда мы одно значение дублируем несколько раз в разных местах, велик шанс ошибиться. При этом границу на клиенте очень легко снять. Что будет, если пользователь обойдет границу на клиенте? Не сломает ли он нам сайт большой строкой?
В этой статье я расскажу, как искать границы для поля в веб-формочке. Возьмем для примера форму редактирования пользователя в бесплатной системе Users.
Автор: Пол Симан (Paul Seaman) в соавторстве с Ли Хокинсом (Lee Hawkins) Оригинал статьи Перевод: Ольга Алифанова
Недавно мы прочитали статью на сайте QA Revolution под названием "7 веских причин для создания детальных тест-кейсов". Статья утверждает, что дает "значимое обоснование для создания детальных тест-кейсов", и идет дальше, пытаясь "вдохновить вас писать более детализированные кейсы в будущем". Мы категорически не согласны как с предпосылкой, так и с "вескими причинами", и в этой серии статей мы обоснуем свою точку зрения.
В одном из старых проектов в кучу были навалены ассерты из 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. Данная методология позволяет нам совмещать поддержку (т.е. задачи, которые появляются неожиданно и которые нужно выполнить срочно) и задачи из бэклога, которые запланированы заранее.
Процесс тестирования является частью процесса разработки. Он должен быть эффективен для того, чтобы не задерживать выпуск готового функционала в продуктивную среду. Для этого мы стремимся его постоянно совершенствовать.
