Автор: Жданов Илья Владимирович, ЛАНИТ, Тест-менеджер (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 вот с каким кодом:
Автор: Энджи Джонс (Angie Jones) Оригинал статьи Перевод: Ольга Алифанова
Большинство людей тестируют API спустя рукава. В своем воркшопе "Азбука API" я прошу людей вручную протестировать API. Получая ответ, они, как правило, бросают на него взгляд и, возможно, тщательно проверяют некоторые ключевые поля. То же верно и для автотестов – обычно проверяются только ключевые поля.
Напомним, что XSS-атака – это тип инъекции кода: вредоносный код ошибочно интерпретируется как пользовательский ввод. Чтобы предотвратить этот тип инъекций, необходимо безопасно обращаться с вводом. Для веб-разработки существует два фундаментально разных подхода к безопасной обработке вводимой информации:
Шифрование, когда браузер интерпретирует пользовательский ввод только как данные, а не как код.
Валидация, фильтрующая пользовательский ввод – браузер интерпретирует его как код, игнорируя вредоносные команды.
Непрерывная интеграция – основная цель внедрения автоматизации тестирования на проекте, без нее смысл автоматизации меркнет. Однако единственно верного рецепта построения CI на проекте не существует, т.к. CI это практика и глобальный подход, который строится на конкретных технических решениях, коих сегодня великое множество. На прошлой конференции Вадим Зубович рассмотрел различные подходы к организации процесса непрерывной интеграции и показал множество «подводных камней», с которыми можно столкнуться при применении тех или иных инструментов и подходов
С 31 марта по 2 апреля ждем вас на четвертом выпуске конференции TestCon Moscow 2020. Уже составлена программа конференции.
А всем подписчикам портала мы предлагаем дополнительную скидку в 10% по промо коду SOFTWARE10.
Автор: Филип Рик (Pilip Hric) Оригинал статьи Перевод: Ольга Алифанова
Принцип DRY = Don’t repeat yourself (не повторяйтесь).
End-to-end тесты иногда начинают повторять сами себя. Вы можете делать все, что в ваших силах, чтобы удерживать количество тестов на оптимальном уровне, но в некоторых случаях избежать повторяемости просто невозможно.
Приведу пример. Мы будем тестировать админ-интерфейс Slido. Slido дает пользователям возможность модерировать вопросы участников в ходе события. Одобренные вопросы отображаются для аудитории. В приложении есть различные фильтры вопросов, и у всех из них своя сортировка.
Пользователям по разным причинам может понадобиться сортировать входящие вопросы, а также живые, отмеченные звездой и архивированные.
