Home

Автор: Яковлев Станислав — Team Lead команды тестирования сервиса Юла, телеграмм канал t.me/qa_chillout

Привет! После знакомства с Charles Proxy большинство из читателей захотело узнать больше про инструменты мониторинга и анализа HTTP/HTTPS трафика. Расскажем про популярный у многих тестировщиков Fiddler. Описать все возможности Fiddler в одной статье вряд ли получится, поэтому давайте рассмотрим базовые возможности, которыми мы пользуемся каждый день.

Fiddler это:

Кроссплатформенное приложение прокси-сервера для отладки HTTP. Он позволяет пользователю просматривать HTTP, HTTPS и активированный трафик TCP-порта, доступ к которому осуществляется с локального компьютера, на него или через него. Сюда входят запросы и ответы, включая HTTP-заголовки и метаданные (например, файлы cookie, кэширование и кодирование информации), с функциями, предназначенными для помощи разработчикам и тестировщикам в анализе соединений и обмене сообщениями.

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

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

Хотя в ряде случаев тестировщики пользуются методами ожидания Selenium WebDriver, чтобы условия выполнились до начала взаимодействия, тесты все равно могут продолжать падать. Как же добиться надежных тестов? Читайте дальше, чтобы узнать, как создавать агрегированные методы ожидания, позволяющие заново создавать сложные условия.

Автор: Сумон Дей (Sumon Dey)
Оригинал статьи
Перевод: Ольга Алифанова

Честно говоря, стоит мне столкнуться с новым инструментом тест-автоматизации – неважно, коммерческим или открытым – как я сразу отношусь к нему скептически. Не потому, что я сомневаюсь в функциональности, возможностях или (сверкающих) новых фичах, которые дает этот инструмент – я сомневаюсь, будет ли от него толк как для тестирования, так и для тест-инженеров. Выбор неверного инструмента может повлечь за собой нежелательную потерю денег, времени и сил. Нам это не нужно. Инструмент, как минимум, должен быть достаточно гибким для кастомизации под наши нужды, бесшовно масштабироваться для Web, мобильных устройств и API, генерировать хорошие информативные отчеты или поддерживать их генерацию, интегрироваться с CI-серверами или другими инструментами для запуска в CI/CD, предоставлять функции повторного использования, поддерживать кросс-браузерность, запускаться на любой ОС, и требовать минимальной поддержки.

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

За несколько лет многое может измениться – взглянуть хоть на состояние дел с тест-автоматизацией на JavaScript (JS).

Если бы вы спросили о моем мнении по поводу JS и браузерного тестирования в 2015 году, я бы сказал "избегайте JS как только можете, но если уж вам необходимо использовать JS – применяйте Protractor".

Теперь моя позиция поменялась на 180 градусов: "WebdriverIO – наилучший выбор для браузерной (и мобильной) тест-автоматизации UI, и я настоятельно рекомендую инструменты на основе JS, а не инструменты на основе Java".

(если вы думаете "А где, по вашему мнению, JS-инструменты автоматизации окажутся к 2026 году?", то мой ответ – "Ни малейшего понятия").

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

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

За Allure TestOps с самого начала тянется немало мифов. В некоторые из которых в начале пути мы верили и сами (например, в пятый!). В этой статье мы поделимся наиболее частыми заблуждениями и постараемся развеять их.

Оригинальная публикация
Автор: Уханов Максим

На рынке так много программных продуктов для тестирования, что может показаться, будто для всего найдется готовое решение и нет необходимости тратить время и усилия на разработку инструментов тестирования. На самом деле это не так. Мы в «ЛАНИТ Экспертизе» убедились в этом, когда появилась задача тестирования Desktop-приложений, и теперь делимся с вами опытом. 

Источник: kotomatrix.ru

Автор: Джоеп Шууркс (Joep Shuurkes)
Оригинал статьи
Перевод: Ольга Алифанова

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

Прежде чем я перейду к сути, отмечу, чего эта статья не касается. Я не буду вдаваться в то, как тест-кейсы влияют на выполнение тестов, и хороши ли кейсы для применения в тестировании. Лично я не думаю, что они несут пользу, и писал о своей неспособности ими пользоваться в июле 2013 года. Если вы хотите глубже изучить вопрос, рекомендую статью Джеймса Баха и Аарона Ходдера "Тест-кейсы – это не тестирование" (часть 1, часть 2).

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

Если вы когда-либо работали в команде, практикующей BDD и использующей Cucumber или SpecFlow для создания исполняемых спецификаций, то вы знаете, как тяжело писать читабельные сценарии. Очень, очень тяжело!

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

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

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

Оригинальная публикация
Автор: Водянчук Михаил, QA-специалист в компании adcombo

Всем привет! Меня зовут Миша, я работаю на позиции ручного тестировщика, или Manual QA - кому как удобно. В связи с тем, что в моей работе преобладает ручное тестирование -  я часто сталкиваюсь с консолью разработчика в браузере (думаю как и 99.9% web-тестировщиков). 

В интернете огромное количество источников, в которых можно найти информацию про DevTools, как для разработчиков, так и для тестировщиков. Конечно, наполнение таких статей очень сильно разнится в зависимости от ее направленности. Изучив большое количество подобного материала и поняв, что нас (тестировщиков) обделяют информацией :), решил залезть в первоисточник для изучения инструментов разработчика в полном объеме. Пройдясь по всем пунктам огромного меню, выписал для себя порядка 20 пунктов, которые были бы интересны (читай полезны) для тестировщиков. Сразу скажу, что в статье я не буду рассказывать, как пользоваться тем или иным инструментом, так как это подробно описано в статьях, которые будут прикреплены к каждому из пунктов. Цель моего повествования - скорее вычленить из огромного списка возможностей DevTools, именно те, которые были бы полезны для QA-специалистов. Не претендую на объективность и полную раскрытость темы, но постараюсь это сделать. 

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

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