Home

Автор: Бенджамин Бишофф (Benjamin Bischoff)
Оригинал статьи
Перевод: Ольга Алифанова

Разработка и тестирование ПО на первый взгляд сильно отличаются друг от друга, но некоторые аспекты важны для обеих дисциплин.

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

Пожалуйста, обратите внимание, что это не полноценные примеры, а урезанные образцы кода, иллюстрирующие суть подхода. Так как я в основном пишу на Java, то примеры тоже написаны на нем. Я старался сделать их как можно более простыми и доступными для понимания.

Автор: Ананд Багмар (Anand Bagmar)
Оригинал статьи
Перевод: Ольга Алифанова

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

Если вы используете инструменты с открытым исходным кодом, то есть несколько способов приступить к делу.

1. Сделай сам: создайте собственный фреймворк, напишите скрипты на основе документации.
2. Используйте Selenium IDE для быстрой записи и воспроизведения.
3. Используйте TestProject Recorder для быстрой записи и воспроизведения.
4. Используйте TestProject SDK для создания собственных кастомных скриптов автоматизации тестов.

У каждого из этих подходов есть достоинства и недостатки. Рассмотрим их подробно.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Вместо того, чтобы спрашивать, какие тесты вам автоматизировать, задавайте более точные вопросы.

Если вы подразумеваете "Как мне расценивать использование инструментов в тестировании", прочитайте статьи "Контекстно-ориентированный подход к автоматизации в тестировании", и "Тестирование и проверки".

Если вы спрашиваете о проверке результата или других фактов о состоянии продукта, продолжайте чтение.

Автор: Деннис Мартинез (Dennis Martinez)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

Автор: Игорь Любин

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

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

Если события приходят некорректно, отчёт будет недостоверным.

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

Автор: Поздняков Антон Игоревич (Инженер по автоматизированному тестированию), ООО "Хоппер ИТ"

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

Мы постоянно работаем с большими объемами тестов, и по мере роста количества заказов в команду приходят новые инженеры. Именно обучение стало поводом для размышлений над тем, что такое “хороший XPath”, а что такое “плохой XPath”. 

На первый взгляд может показаться, что в этом вопросе нет ничего сложного: просто берете общепринятый стандарт для селекторов, сверху кладете документацию по XPath и отдаете все это новому сотруднику со словами: “Знакомься товарищ!”. Но практика показала, что просто знаний синтаксиса недостаточно. И в работе встречаются как хорошие, так и плохие практики написания селекторов. Именно исходя из этого опыта и родился этот пост. А ниже вы найдете те принципы и практики, которые мы выработали сами для себя, набив несколько шишек, потратив часы лишнего времени на исправления и так далее. 

Автор: Поздняков Антон Игоревич (Инженер по автоматизированному тестированию), ООО "Хоппер ИТ"

Сегодня хочется поговорить про XPath — мощный и гибкий инструмент для работы с веб-интерфейсами, который при этом почему-то остается не особенно популярным. Статей и мануалов по XPath очень много, и в этом посте я постараюсь рассказать, как мы применяем данный инструмент и почему считаем его более эффективным, чем другие подходы. Если вам знаком термин “селектор”, а тем более — если вы слышали про XPath, добро пожаловать под кат, там много полезного!

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

Примерно месяц назад я получил сообщение от контакта в LinkedIn со ссылкой на статью Forbes и вопросом:

“Как вы думаете, codeless - хорошая штука, или нет?”

Я отправил подробный рассказ о своем мнении про статью и ‘codeless’ (позже вы поймете, почему здесь и далее я пользуюсь кавычками) как феномене автоматизации. По какой-то причине мне пока не ответили, и, дабы мои усилия не пропали зря, я превратил свой ответ в статью, которую вы сейчас читаете.

Итак, считаю я codeless хорошей штукой или нет?

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

Недавно я опубликовал пост в LinkedIn и Twitter:

“Упоминал ли я, что разработка автоматизации - это разработка ПО? Нет? Считайте, что теперь упомянул”.

Как это часто бывает, ответил Майкл Болтон:

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

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

Автор: Корина Пип (Corina Pip)
Оригинал статьи
Перевод: Ольга Алифанова

Мы запускаем наши автотесты или на локальных машинах, или в CI-системах. В некоторых случаях мы неспособны наблюдать, что делают наши тесты. Если это API-тест, то если он не дает результат в консоли, мы не можем узнать, что он делает, пока тест не закончится. Если это UI-тест, то пока мы не увидим, что происходит в браузере, мы не поймем, что там творится. Поэтому в некоторых случаях нам нужно выводить информацию в консоль. Эта информация даст нам понять состояние теста или данные, используемые тестом. Одна из возможностей записывать ход теста в консоль предоставлена библиотекойApache Log4j.