Home

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Привет, и с вами снова цикл статей по основам Cypress!

Получение текста элемента

Чтобы получить правильные атрибуты элемента, хорошо бы понимать основы различных HTML-элементов. Приведу пример. Допустим, у нас два элемента:

<div>Пожалуйста, введите имя:</div>
<input type="text"></input>

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Автор оригинала: Uladzislau Ramanenka

Меня зовут Владислав Романенко, я старший iOS QA Engineer в Badoo и Bumble. Несколько лет назад мы начали активнее использовать автотесты в разработке, но столкнулись с некоторыми трудностями. 

Логичный вопрос: почему мы занялись автоматизацией тестирования? Ответ кроется в еженедельном выпуске новых версий наших мобильных приложений. QA-отделу приходится тестировать новые фичи, их интеграцию в сервисы и заниматься регрессионным тестированием. За неделю комплексное регрессионное тестирование нужно проводить как минимум один раз, что довольно утомительно. Автоматизация помогла нам выпускать новые версии быстрее и без потери качества. Подробнее об автоматизации мобильного тестирования — в докладе моих коллег. 

В разработке проблемы часто решаются с помощью паттернов — обобщённых решений для часто возникающих проблем в заданном контексте. То же и с автоматизацией тестирования, есть даже хорошее wiki-описание. В этой статье мы поговорим о паттернах процессов (Process Patterns). Они помогают организовать и улучшить процесс автоматизации тестирования. 

Без дальнейших предисловий перейдём к трудностям, с которыми мы боролись, и рекомендациям по их преодолению с помощью тех самых паттернов. Замечу, что это не единственные проблемы, которые у нас были и есть. Но в рамках данной статьи я решил остановиться именно на них.

Автор: Руслан Ахметзянов, Qameta Software

Обеспечить представление данных из любой большой системы так, чтобы человек мог спокойно с этими данными работать — задача нетривиальная, но давно решенная. В этой гонке уже давно победило "дерево". Папочные структуры в операционных системах знакомы всем и каждому и исторически простое дерево в UI/UX становится первым решением для упорядочивания и хранения данных. Сегодня поговорим о тестировании, так что в нашем случае объектами хранения будут выступать тест-кейсы. Как их хранят чаще всего? Верно, в папочках!

Привычно? Да. Но так ли это решение хорошо и универсально? Вопрос подкрепляется существованием исключений: почта, JIRA-тикеты и много чего другого хранится не в папках. Давайте разбираться, почему.

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

Краткое содержание: покрытие требует моделирования. Мы можем организовать код так, чтобы его можно было оценить на основании ментальной модели, и некоторые из моделей исполнимы. Другие модели мы сравниваем с результатами прогона тестов.

Мне задали ряд вопросов: как задокументировать, что делает и что покрывает автотест, не затрачивая кучу времени и сил? Как узнать, что не покрыто автоматизацией?

Автор: Роман Буданов, тренер курса “Первый Онлайн ИНститут Тестировщиков” (компания “Лаборатория Качества”)

Всем доброго времени суток, мои маленькие (и не очень) любители (и не очень) SQL! На курсе ПОИНТ мы с нуля разбираем построение запросов, обучаемся основным операторам, работе с разными типами данных, но сейчас я хочу с вами поговорить про один из полезных инструментов, увы, оставшихся  за рамками ПОИНТ — сегодня я хочу рассказать вам про такую полезную штуку, как подзапросы и показать несколько вариантов их приготовления.

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

Обзор

unittest – это стандартный Python-фреймворк для юнит-тестов. Создатели вдохновлялись JUnit, и он включается в стандартный дистрибутив CPython. unittest содержит базовый класс TestCase, дающий методы для утверждений и рутин настройки и очистки. Все классы тест-кейсов должны наследоваться от TestCase. Каждый метод в подклассе TestCase, чье имя начинается с "test", будет прогоняться как тест-кейс. Тесты можно группировать и загружать с использованием класса TestSuite и методов загрузки – используя их совместно, можно создавать свои собственные тест-загрузчики. unittest также может генерировать XML-отчеты (как и JUnit), используя unittest-xml-reporting.

unittest поддерживается и в Python 2, и в Python 3. Однако для версий старше Python 2.7 нужно пользоваться портированием unittest2.

Автор: Бет Маршалл (Beth Marshall)
Оригинал статьи
Перевод: Ольга Алифанова

• Язык: VB.Net / UiPath
• IDE: UiPath Studio
• Инструмент управления исходным кодом: Github через Github Desktop
• Тип тестов: UiPath
• Тестируемый сайт: сайт моего спортзала

В этой статье я бы хотела поговорить про свой опыт создания тест-фреймворка роботизированной автоматизации процессов (RPA) с использованием ведущего поставщика на рынке UiPath.

Я познакомилась с UiPath в этом году, когда одной из первых сдавала их новый базовый экзамен – UiRPAv1. Я официально сертифицирована, но почти не работала с этим инструментом после сдачи экзамена, поэтому это показалось хорошей идеей для обучения на ходу.

Я очень довольна тем, как продвигается работа над моим портфолио, учитывая, с чего я начинала, но не думайте, что этот код занял у меня пару минут. Я потратила несколько дней, и много времени ушло на Google. Но все мы с чего-то начинаем, и я уверена, что кривая обучения ускорит работу в следующий раз. Еще один дополнительный бонус – симпатичный шаблон, с которого я смогу начать в следующий раз.

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

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

Но.

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

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

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

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