Home

Оригинальная публикация

Кажется, уже сложно представить себе веб-приложение, которое не использует микрофронтендную архитектуру для возможности реализовать гибкое и функциональное приложение. И как в любом архитектурном подходе, в микрофронтенде необходимо обеспечивать качественное тестирование разрабатываемых компонентов.

Но с чего стоит начать и что ждет каждого, кто вступит на путь автоматизации микрофронтенда, когда многие привыкли тестировать уже собранные из кусочков приложения?

Привет. Меня зовут Александр Воробей, я ведущий специалист по автоматизации тестирования в Тинькофф. В этой статье я постараюсь вкратце рассказать, с чего мы начинали автоматизацию микрофронтенда, с какими проблемами встретились и какие результаты получили.

Оригинальная публикация

Меня зовут Иван Сидоренко, я инженер по тестированию в компании Digital Design.

Передо мной стояла задача разработки авто-тестов для одного из наших проектов с помощью инструмента Selenium WebDriver на языке Java. Подробнее про это вы можете прочитать в моей прошлой статье

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

В ходе поисков выбор пал на AutoIT. Этот инструмент разработан для автоматизации задач в Microsoft Windows, что и было необходимо. В этой статье я опишу работу с AutoIT для решения поставленной задачи. Предполагается, что у вас уже развернута среда разработки с подключенным Selenium WebDriver. В качестве примера будет использоваться окно для загрузки фотографий на одном из сайтов по редактированию фото. Итак, приступим.

Оригинальная публикация

Нет, конечно же ручники будут нужны. Но с каждым годом потребностей в них будет все меньше. Уровень зарплаты быстро упрется в потолок, а от монотонных задач будет тошнить. Если у вас есть желание оставаться в QA и вырасти в автоматизатора (разработчика?), то текст ниже для вас.

Автор

Предисловие

Модульное тестирование (unit testing) применяется повсеместно. Кажется, уже никто без него не обходится, все пишут тесты, а их отсутствие в сколь-нибудь серьёзном проекте вызывает, как минимум, непонимание. Однако, многие воспринимают тестирование как некий ритуал, совершаемый для того, чтобы не разгневать "бога программирования". Мол, так надо. Почему? Потому что.

Буду говорить страшные вещи.

Не важно, что брать за единицу тестирования. Не важно, как сгруппированы тесты. Не важно, пишутся ли они до кода или после. TDD или не TDD? Всё равно. Доля покрытия? Наплевать. В конце концов, тестов может совсем не быть. Всё это совершенно не важно. Важно, чтобы выполнялись требования, предъявляемые к ПО.

Модульные тесты — это не ритуал, а хороший, рабочий инструмент, позволяющий приблизиться к выполнению этих требований. И этот инструмент нужно уметь правильно использовать.

Постойте, причём же тут наука с математикой?

Автор: Жданов Илья Владимирович, ЛАНИТ, Тест-менеджер (15 лет в IT, за первые 10 лет прошел путь от эникейщика до руководителя направления системных аналитиков, последние 5 лет занимаюсь созданием команд и практик по тестированию на проектах от 5 до 60 QA)

В последнее время автоматизацию тестирования называют «серебряной пулей» от всех проблем проекта. Многие приступают к автоматизации очень спонтанно и лайтово, не просчитав все «за» и «против», плюсы и минусы, сопровождение и окупаемость. 

А вообще автоматизация тестирования – очень дорогой и специфический инструмент. Поэтому к ней нужно подходить с должным уровнем зрелости кода и самого проекта. Иначе можно потратить миллионы часов и денег, а эффект получить микроскопический или не получить его вообще.

В этой статье я постарался:

• осветить «детские болячки» тест-менеджмента, стремящегося автоматизировать все, что не приколочено,
• пояснить, какую пользу может нанести бюджету проекта автоматизация тестирования без детального анализа ее скоупа и должной подготовки,
• составить Roadmap для подготовки к автоматизации проекта.

Источник 

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

Ранее я приводил примеры базовых тестов на C# для REST API с использованием NUnit и библиотеки RestSharp. В этой статье я хочу поговорить об этом подробнее, показав, как сделать эти тесты управляемыми через данные.

Если вы не знаете, что имеется в виду под "управлением через данные": если я хочу запускать тесты, использующие одинаковую логику или поток в тестируемом приложении несколько раз с различными комбинациями входных значений и соответствующими ожидаемыми результатами, я называю это тестированием, управляемым через данными.

Это особенно полезно при тестировании REST API, так как в их основе лежит отправка и получение данных, а также открытие бизнес-логики другим уровням архитектуры приложения (например, графическому интерфейсу пользователя) или другим приложениям (пользователям API).

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

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

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

Френд в Twitter недавно задал мне вопрос:

"Я работаю в команде Microsoft. У нас 40 разработчиков, использующих .NET (C#). У нас также несколько ручных тестировщиков и 5 автоматизаторов, которые разработали нашу тест-автоматизацию на Python. Однако руководство хочет полностью перенести все на C#.

Что лучше, а) научить 40 .NET-разработчиков Пайтону, чтобы пользоваться имеющимся решением, или б) научить тестировщиков .NET и портировать тесты на C#?"

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

Автор: Джош Грант (Josh Grant)
Оригинал статьи
Перевод: Ольга Алифанова

Продолжая исследовать Pytest и его замечательные возможности, хочу рассказать о плагине pytest, который по сути представляет из себя полноценный инструмент тест-автоматизации. Это pytest-bdd.

Pytest-bdd – это вариация более распространенных фреймворков вроде Cucumber или Behave, который сам по себе – по сути Python Cucumber. BDD – популярный подход, распространенный среди команд – как работающих с автоматизированным тестированием впервые, так и опытных, ищущих зрелую методологию для внедрения. Ключевая особенность BDD – это создание фича-файлов с применением специального неспециализированного синтаксиса, Gherkin. Это позволяет описывать фичи вначале в таком формате:

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

Эта статья покажет вам наилучший способ обращения с Python-функциями "main".

Python похож на скриптовый язык: все строки в "модуле" Python (файле .py) выполняются всегда, когда этот файл запускается. Модулям не нужна функция main. Допустим, у нас есть модуль по имени stuff.py вот с каким кодом: