Home

Автор: Пол Гриззаффи (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. За семь лет существования компании накопилось много легаси в тестах, в какой-то момент был сделан акцент на увеличении покрытия и на скорости написания тестов. Необходимость рефакторинга назрела уже давно, и первыми звоночками стали увеличение времени поддержки тестов и неудобство прохождения код-ревью сценариев.

Статья взята из блога компании «НТЦ ПРОТЕЙ»

Наверное, где-то есть идеальная статья, сразу и полностью раскрывающая тему архитектуры тестов, легких и в написании, и в чтении, и в поддержке, и так, чтобы быть понятной начинающим, с примерами реализации и областей применения. Хочу предложить свое видение этой «идеальной статьи», в том формате, о котором мечтала, только получив первую задачу «напиши автотесты». Для этого расскажу о известных и не очень подходах к автотестам веба, зачем, как и когда их применять, а также про удачные решения хранения и создания данных.

Меня зовут Диана, я руководитель группы тестирования пользовательских интерфейсов, автоматизирую веб и десктоп тесты уже пять лет. Примеры кода будут на java и для web, но, на практике проверено, подходы применимы и к питону с десктопом.

Автор: Алан Ричардсон (Alan Richardson)
Оригинал статьи
Перевод: Ольга Алифанова

Краткое содержание: в мире множество хороших ресурсов для изучения JavaScript. Вам не нужно устанавливать IDE, вы можете научиться JS в консоли.

Для чего нужно учить JavaScript?

• Тестируя веб-приложение, вы можете смотреть на код.
• Для понимания кода.
• Для понимания ошибок в консоли разработчика.
• Для поиска обходных путей через дефекты приложения.
• Для автоматизации в браузере.
• Для создания вспомогательных инструментов вроде BookMarklets.
• Для улучшения использования WebDriver JavascriptExecutor.
• Для странных и загадочных открытый, которые вас поразят, когда вы выучите JavaScript.

Изучение JavaScript увеличивает площадь поверхности системы, с которой мы можем получать информацию (то есть моделировать систему), и мы сможем потенциально наблюдать за ней, опрашивать ее и манипулировать ей в большем количестве измерений.

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

Автор: Баз Дейкстра (Bas Djikstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой короткой серии статей я исследую библиотеку Python requests и ее использование для тестов REST API. Это четвертая статья в серии, и в ней мы разберемся с имитацией ответов для юнит-тестирования.