Home

Автор: Дейв Вестервельд (DaveWesterveld)
Оригинал статьи
Перевод: Ольга Алифанова

API - отличная штука. Это мощный способ заставить разные приложения работать вместе. API позволяют легко интегрировать приложения, и на них основана львиная доля современного Интернета. Они прекрасны.

Но.

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

Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

К статьям вроде "Принцип трех А" я часто получаю комментарии вроде таких: "у нас проблемы с пересечением пользовательских данных в тестах", или "как бы вы управились с Х тестами, каждому из которых нужно наполнение данными".

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

Автор: компания 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, так как мы использовали именно этот язык, но понять основную мысль это не помешает.