Home

Автор: компания Simbirsoft

Ранее мы уже писали о том, когда бывает нужна автоматизация тестирования и какие проверки при этом используют. Сегодня предлагаем обсудить использование инструментов на практике и оценить их производительность. С разрешения Giovanni Rago – автора серии полезных материалов о тестировании – мы перевели его статью «Puppeteer vs Selenium vs Playwright: сравнение скорости» (Puppeteer vs Selenium vs Playwright, a speed comparison). Статья будет интересна тем, кто задумывается о выборе подходящего инструмента автоматизации в своих проектах.

Автор: Ольга Назина (Киселёва)

Введение

Сегодня я расскажу про плагины браузера, которые помогают быстро заполнить поля тестируемой формы. Рассказ также доступен в виде видео. Мой топ-3:

• 3 место — Bug magnet

  • О плагине

  • Как использовать

  • Плюсы

  • Минусы

• 2 место — Web developer toolbar

  • О плагине

  • Как использовать

  • Плюсы

  • Минусы

• 1 место — Fake Filler

  • О плагине

  • Как использовать

  • Плюсы

  • Минусы

• Итого

Применять плагины мы будем на бесплатной системе Users. 

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Python – потрясающий язык программирования. Его любят и новички, и эксперты, и он регулярно оценивается как язык с самым высоким спросом. На конференции PyData Carolinas 2016 Джош Хоус, старший менеджер управления данными в MaxPoint, описал Python примерно так:

Python – магический инструмент, который позволяет легко решать самые сложные мировые проблемы.

Я впервые столкнулся с Python в старшей школе более десяти лет назад, но начал по-настоящему пользоваться им и полюбил только недавно, используя его для тест-автоматизации. Эта серия статей научит вас тестировать на Python. Эта вводная статья даст вам базовые ориентиры, а каждая последующая подробно разберет один из фреймворков Python.

Автор: Пол Гриззаффи (PaulGrizzaffi)
Оригинал статьи
Перевод: ОльгаАлифанова

Вперед, к поиску по сети! В ней больше постов и статей про "десять заповедей тест-автоматизации", чем вы кейсов в жизни написали. Вперед! Я подожду.

Добро пожаловать назад!

Внесу ясность – я не читал ни одну из этих статей. Точнее, недавно я не читал ни одной из них, а большую часть не читал никогда. Возможно, я просматривал одну или две давным-давно, но не могу вспомнить ни одной конкретной заповедей. Все то, что я еще не знал и счел разумным, я, скорее всего, давным-давно применил в своей практике. Говорю это не чтобы принизить другие статьи, а чтобы сослаться на них в том высоко вероятном случае, если некоторые из моих "заповедей" уже озвучивались до меня; я не копировал чужое, и если я повторяюсь, то надеюсь улучшить их. Я также хочу поделиться идеями, о которых вы раньше не задумывались.

Поэтому я не пишу о "ДЕСЯТИ заповедях тест-автоматизации". Вместо этого я расскажу о ЕЩЕ десяти заповедях тест-автоматизации. Поехали!

Автор: Даниил Тимашов
Оригинальная публикация

Привет, Хабр. Я работаю QA Automation инженером в компании Wrike и хотел бы поговорить о том, как нам удалось оптимизировать процесс код-ревью для репозитория с 30 000+ автотестов при помощи IntelliJ IDEA плагина. Я расскажу о внутреннем устройстве плагина и о том, какие проблемы он решает в нашей компании. А еще в конце статьи будет ссылка на Github репозиторий с кодом плагина, с помощью которого вы сможете попробовать встроить плагин в ваши процессы.

Автор: Тоби Стид (TobySteed)
Оригинал статьи
Перевод: Ольга Алифанова

Представьте – у вас есть команда высокопрофессиональных автоматизаторов, отличные девопсы, инфраструктура и лицензии, о которых можно только мечтать – и, что самое главное, вы убедили высший менеджмент, что автоматизации надо дать дорогу. Что же может пойти не так? Ваш новый план автотестов прямо-таки обречен на успех.

К сожалению, такие компании – редкость, поэтому, обнаружив себя в такой ситуации, легко испытать головокружение от всего, что вы хотите сделать и чего достичь. Однако куда меньшая редкость – это в один прекрасный день открыть бэклог или доску JIRA (или того инструмента, которым вы пользуетесь), и увидеть, что все сложности по запуску новой тест-автоматизации, все ее проблемы и задачи дистиллированы в один-единственный тикет – зачастую с расплывчатым именем вроде "Создание автотестов".

Автор: Энди Найт (Andy Knignt)
Оригинал статьи
Перевод: Ольга Алифанова

Разработка через реализацию поведения (BDD) может помочь команде создавать хорошее ПО через скрупулезную спецификацию поведения продукта на простом языке. Неважно, хотите ли вы улучшить сотрудничество через встречу "трех друзей", или повысить качество автоматизации при помощи фреймворка вроде Cucumber – в центре BDD стоит один язык: Gherkin.

С первого взгляда Gherkin выглядит простым – просто напишите ряд шагов, описывающих желаемое поведение. Однако я сталкивался с командами, которым очень трудно хорошо писать на Gherkin. Начинающие часто страдают от писательского ступора, или же пишут сценарии, которые сложно автоматизировать. Иногда противоречивость заставляет людей по-разному интерпретировать шаги. Еще, бывает, люди слишком детализируют шаги, делая сценарии сложными для понимания. Раздражение от Gherkin даже выливается в плохую репутацию BDD.

Хорошо писать на Gherkin, возможно, сложно, но это не невозможная задача. Вот четыре правила, которые помогут вам писать на Gherkin читабельно, автоматизируемо, и масштабируемо.

Оригинальная публикация
Автор: Ксения Якиль

Привет! Меня зовут Ксения Якиль. Я пишу core-сервисы на C и Go в бэкенд-отделе Badoo и Bumble. Наш бэкенд — это высоконагруженная распределённая система, обслуживающая пользователей по всему миру. Она оперирует большими массивами данных и делает всю ту магию, благодаря которой люди находят друг друга. 

В этой статье я не буду концентрироваться на специфике наших сервисов, а расскажу, как мы реализовали автоматизированные интеграционные тесты в распределённой системе, поделюсь общими принципами и нюансами создания фреймворка для них. В тексте будут встречаться отсылки к реализации на Go, так как мы использовали именно этот язык, но понять основную мысль это не помешает.

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Современные команды разработки ПО размывают традиционные границы между разработчиком и тестировщиком. Это означает, что разработчики все сильнее вовлекаются в тест-автоматизацию на всех уровнях пирамиды, а тестировщики все глубже погружаются во внутреннюю механику приложения. Разве не здорово бы было найти причины багов JavaScript, а не просто сообщать о них? Это можно сделать при помощи брейкпойнтов инструментов разработчика Chrome!

В этой статье я шаг за шагом проведу вас по использованию Chrome Dev Tools для дебага. Я узнала об этом из этой полезной статьи в блоге Google, но я буду использовать пример приложения, чтобы вы смогли попробовать различные методы самостоятельно.

Важно отметить, что для использования брейкпойнтов вам понадобится локальная установка приложения. Нельзя просто взять релизную версию и дебажить ее. Статья покажет вам, как запустить React-приложение локально, и вы можете уточнить у своих разработчиков, как сделать это с вашим рабочим приложением.

Оригинальная публикация
Автор: Евгения Шереметова (телеграмм канал автора @bel-qa)

Фреймворк Cucumber используют как часть bdd-подхода к разработке, так и как отдельный инструмент для автотестов. 40+ млн скачиваний обеспечили фреймворку богатый опыт использования, но актуализировали поверхностное отношение к этому инструменту. Разбираем популярные огуречные антипаттерны и учимся писать действительно выразительные сценарии.

Я Женя Шереметова, работаю в группе автоматизированного тестирования МойОфис. В своей работе мы используем инструмент Cucumber. За семь лет существования компании накопилось много легаси в тестах, в какой-то момент был сделан акцент на увеличении покрытия и на скорости написания тестов. Необходимость рефакторинга назрела уже давно, и первыми звоночками стали увеличение времени поддержки тестов и неудобство прохождения код-ревью сценариев.