Автор: Энджи Джонс (Angie Jones) Оригинал статьи Перевод: Ольга Алифанова
Большинство людей тестируют API спустя рукава. В своем воркшопе "Азбука API" я прошу людей вручную протестировать API. Получая ответ, они, как правило, бросают на него взгляд и, возможно, тщательно проверяют некоторые ключевые поля. То же верно и для автотестов – обычно проверяются только ключевые поля.
Напомним, что XSS-атака – это тип инъекции кода: вредоносный код ошибочно интерпретируется как пользовательский ввод. Чтобы предотвратить этот тип инъекций, необходимо безопасно обращаться с вводом. Для веб-разработки существует два фундаментально разных подхода к безопасной обработке вводимой информации:
Шифрование, когда браузер интерпретирует пользовательский ввод только как данные, а не как код.
Валидация, фильтрующая пользовательский ввод – браузер интерпретирует его как код, игнорируя вредоносные команды.
Непрерывная интеграция – основная цель внедрения автоматизации тестирования на проекте, без нее смысл автоматизации меркнет. Однако единственно верного рецепта построения CI на проекте не существует, т.к. CI это практика и глобальный подход, который строится на конкретных технических решениях, коих сегодня великое множество. На прошлой конференции Вадим Зубович рассмотрел различные подходы к организации процесса непрерывной интеграции и показал множество «подводных камней», с которыми можно столкнуться при применении тех или иных инструментов и подходов
С 31 марта по 2 апреля ждем вас на четвертом выпуске конференции TestCon Moscow 2020. Уже составлена программа конференции.
А всем подписчикам портала мы предлагаем дополнительную скидку в 10% по промо коду SOFTWARE10.
Автор: Филип Рик (Pilip Hric) Оригинал статьи Перевод: Ольга Алифанова
Принцип DRY = Don’t repeat yourself (не повторяйтесь).
End-to-end тесты иногда начинают повторять сами себя. Вы можете делать все, что в ваших силах, чтобы удерживать количество тестов на оптимальном уровне, но в некоторых случаях избежать повторяемости просто невозможно.
Приведу пример. Мы будем тестировать админ-интерфейс Slido. Slido дает пользователям возможность модерировать вопросы участников в ходе события. Одобренные вопросы отображаются для аудитории. В приложении есть различные фильтры вопросов, и у всех из них своя сортировка.
Пользователям по разным причинам может понадобиться сортировать входящие вопросы, а также живые, отмеченные звездой и архивированные.
Всем привет! Меня зовут Артём Соковец. Хочу поделиться переводом своей статьи об Atlas: реинкарнации фреймворка HTML Elements, где представлен совершенно иной подход работы с Page Object.
Перед тем, как перейти к деталям, хочу спросить: сколько обёрток для Page Object вы знаете? Page Element, ScreenPlay, Loadable Component, Chain of invocations…
А что будет, если взять Page Object с реализацией на интерфейсе, прикрутить Proxy Pattern и добавить немного функциональности Java 8?
Недавно я сменил проект — пришел в новую разработку, где до меня не было никакого тестирования, ни ручного, ни автоматического. Условий на инструментарий (за исключением того, что это Python) заказчик не накладывал, так что я сделал собственный выбор. В этой статье я расскажу, почему в таких условиях предпочел Robot Framework. А в конце будет немного специально написанных под статью примеров, иллюстрирующих, о чем речь.
Автоматизацией тестирования я занимаюсь уже более 10 лет, а с Robot Framework взаимодействовал порядка трех из них.
Как я отметил выше, не так давно я пришел на новый проект, где начал автоматизацию тестирования с нуля. Подробностей о проекте рассказать не могу — NDA. Отмечу лишь, что это крутой инструмент автоматизации, который в перспективе должен сэкономить массу человеческих ресурсов. Построен он из микросервисов. Пока что моя работа касается четырех из них, но в будущем я расширю свою деятельность и на другие — все упирается в то, что у меня лишь 8 рабочих часов в сутки. На все нужно время.
Отсутствие тестирования в случае этого проекта было тождественно отсутствию рекомендуемого инструментария. В рамках стека Python у меня была свобода выбора. И я ей воспользовался.
Читая статьи на тему web-тестирования, вырисовываются условно две темы: 1) ручное тестирование вымирает, автотесты (здесь и далее под автотестами имеются в виду Selenium UI и REST-тесты) – наше все; 2) автоматическое тестирование – не панацея, без ручного тестирования не обойтись. При этом из статей намечается тенденция на рост требований к качеству программного обеспечения и скорости развития продукта. Wrike — это как раз тот случай, когда эти требования критически важны.
Продукту уже 12 лет, но он до сих пор активно разрастается. Деплои происходят раз в день, а иногда и два. Поэтому нам критически важно, чтобы регрессия проводилась исключительно на автотестах. Однако в Wrike (в компании) свыше 30-ти scrum-команд, а штат команды автоматизаторов не резиновый. В таких условиях ожидать автоматизации ручных сценариев в лучшем случае один-два спринта – не вариант. Опыт нашей компании говорит, что ручной тестировщик может самостоятельно писать автотесты, при соблюдении некоторых нюансов. В статье расскажу о них и почему, на мой взгляд, это умение не только помогает соответствовать тенденциям, но и будет полезно для самого тестировщика.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Автоматизировать CRUD-тестирование можно несколькими способами. Как минимум нужно проверить по одной операции из каждого раздела: создание, чтение, обновление и удаление. Для удобства давайте предположим, что:
Мы тестируем простое текстовое поле, которое использовали раньше.
Мы автоматизируем на уровне UI (автоматизацию API я буду обсуждать в других статьях).
Привет, я Андрей Шальнев, QA Automation Lead в проекте Skyeng Vimbox. В течение года мы с командой занимались оптимизацией процессов автоматического тестирования и сейчас вплотную подошли к ее финальной стадии. А это хороший повод выдохнуть, пересмотреть бэклог и подвести какие-то промежуточные итоги. Для Хабры я решил сделать подборку из десяти наиболее полезных и при этом простых вещей, которые помогли нам справиться с задачей оптимизации автотестов. Надеюсь, статья пригодится QA-командам в растущих компаниях, где старые процессы тестирования уже не справляются с нагрузкой, и вопрос реорганизации встает ребром.
Некоторое время назад я написала статью о своем опыте организации работы QA Инженера на проекте. Сейчас хочу продолжить эту тему, но уже в более узком ее направлении — автоматизации тестирования. Речь пойдет о том же самом проекте, он небольшой, но развивающийся под запросы постоянных клиентов. Быть может мой подход не очень подойдет командам, где работают много десятков сотрудников и каждый отвечает за свою часть (по-моему, в таких проектах работа каждого должна быть строго регламентирована, иначе такой махиной управлять просто невозможно, хотя и они найдут здравое зерно), но он точно будет интересен тем, кто, как и я, однажды пришел на новую работу, и встал на перепутье как самому организовывать свое место под новым солнцем.
