Home

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

Статьи об инструментах, которые я писал ранее, в основном концентрировались на Java или C#. Однако недавно меня попросили о тренинге по тест-автоматизации для группы инженеров по Data Science, с явным требованием использовать инструменты на основе Python для примеров и упражнений.

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

Tavern – это фреймворк тестирования API, работающий на основе pytest, одного из наиболее популярных Python-фреймворков для юнит-тестирования. Он предлагает целый ряд возможностей для создания и запуска API-тестов, а если что-то нельзя сделать через Tavern, то его можно легко расширить через возможности Python или pytest. Не могу поручиться за эту расширяемость, потому что пока что я пользовался исключительно встроенными в Tavern возможностями. У Tavern также хорошая документация, и это очень приятно.

Предлагаем вам подборку наиболее интересных докладов по Автоматизации тестирования, прозвучавших на QA конференции COMAQA Spring Minsk 2019.

«Selenide 2019 - Quo vadis? Новинки и малоизвестные функции библиотеки» Алексей Виноградов

«Архитектура решений автоматизации Back-End на пальцах» Антон Семенченко

«Путь автоматизатора к непрерывной интеграции» Вадим Зубович

«Автоматизация инфраструктурного тестирования» Андрей Ю

«Spock в Автоматизации тестирования» Тимур Гарафутдинов

«JDI tools: быстро стартуем автоматизацию тестирования» Роман Иовлев

«JDI light - как писать автотесты быстро, легко и непринужденно» Роман Иовлев

«Вхождение Функциональщиков в Автоматизацию» Станислав Бадов

«Если UI / API автоматизация уже не штырит» Алексей Калашников

«Тестирование безопасности - как базово проверить проект» Евгений Толчинский

«Инструменты нагрузочного тестирования в процессе разработки» Сергей Зименко

«Процесс тестирования производительности на проекте "с нуля"» Антон Серпутько

«Сказ об автоматизации тестирования» Александр Пушкарев

«Тестирование по-космически» Алексей Ткаченко

Видео докладов можно посмотреть нажав на ссылку Подробнее

Обратите внимание, что 24-26 октября, менее чем через две недели в Минске состоится Международная конференция по тестированию Comaqa Autumn Minsk 2019. 

У ВАС ЕСТЬ ВОЗМОЖНОСТЬ КУПИТЬ БИЛЕТ СО СКИДКОЙ 20% ПО ПРОМОКОДУ COMAQA-ST-2019. Купить билет со скидкой

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

В давние времена у нас было всего несколько сервисов, и выложить за сутки обновление более чем одного из них на production — было большой удачей работой. Потом мир ускорился, система усложнилась, а мы трансформировались в организацию с микросервисной архитектурой. Теперь у нас около сотни сервисов, и вместе с ростом их числа увеличивается и частота релизов — их более 250 в неделю.

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

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

Про изменения в релизном цикле и развитие механизма выкладки рассказывали со стороны ops и dev в одной из прошлых статей. Я же расскажу про историю изменения процессов тестирования в ходе этой трансформации. 

Сейчас у нас около 30 команд разработки. В команду обычно входят руководитель продукта, менеджер проекта, фронтенд- и бэкенд-разработчики и тестировщики. Их объединяет работа над задачами по конкретному продукту. За сервис, как правило, отвечает команда, которая чаще всего вносит в него изменения. 

Автор: Дэн Эшби (Dan Ashby)
Оригинал статьи
Перевод: Ольга Алифанова

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

У моего сына Ангуса довольно давно есть игрушка-ходилка. Она помогла ему удерживать равновесие – сейчас, в возрасте 17 месяцев, он носится очень шустро, и нет сомнений, что в том есть заслуга игрушки.

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

Автор: Сунагатов Ильдар, Юшкова Юлия (Haulmont)

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

Автор: Владимир Янц (Badoo)
Оригинальная публикация

Как оценивать качество тестов? Многие полагаются на самый популярный показатель, известный всем, — code coverage. Но это количественная, а не качественная метрика. Она показывает, какой объём вашего кода покрыт тестами, но не то, как хорошо эти тесты написаны. 

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

На Badoo PHP Meetup в марте я рассказывал, как организовать мутационное тестирование для PHP-кода и с какими проблемами можно столкнуться. Видео доступно по ссылке, а за текстовой версией добро пожаловать под кат.

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

Практически каждый крупный язык программирования имеет тест-фреймворки BDD, и Python – не исключение. На самом деле у Python их даже несколько? Как их сравнивать, какой из них лучше? Давайте разберемся.

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

Недавно я имел счастье делать доклад на конференции UKStar 2019 в Лондоне, и говорил о том, как задавание правильных вопросов (подсказка – сначала спрашивайте "зачем", а потом "как") помогает командам и организациям предотвратить "автоматизацию ради автоматизации" и повысить шансы на то, что тест-автоматизация станет важной и значимой частью жизненного цикла разработки и тестирования.

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

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

Автоматизация тестирования – это краеугольный камень непрерывного процесса поставки программного обеспечения. Автоматизация постоянно держит новые фичи под огнем тестов, которые никогда не будут вовремя завершены, если мы начнем выполнять их вручную. Однако по моему опыту код тест-автоматизации – это иногда худший код в мире разработки. Команды зачастую не придают значения его важности, объему требуемой работы и его уникальным техническим трудностям. В результате выходит не код, а громоздкая куча мусора! Его даже можно назвать "банкротом".

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

Публикуем доклады с конференции SQA Days 25, посвященные вопросам автоматизированного тестирования.

• Тестируем SQL Server код с tSQLt – Никита Белковский, АО "Аркадия" (Таганрог).
• Ведущие разработчики учат меня писать автотесты – Виталий Рощупкин, ЗАО "ПФ "СКБ Контур" (Екатеринбург).
• От Page Object к MVC с использованием .NET – Игорь Ершов, АО "Калуга Астрал" (Калуга).
• Tips and tricks: упрощение синтаксиса тестов и multi-environment тестирование – Лилия Сапурина, Deutsche Bank (Санкт-Петербург).
• Специфика разработки и тестирования статического анализатора – Сергей Хренов, PVS-Studio (Тула).
• Швейцарский нож тестировщика или Jmeter не только для нагрузки – Сергей Махетов, СКБ Контур (Екатеринбург).
• Хочешь написать фреймворк для автоматизации тестирования бэкенда? Спроси меня как! – Людмила Михейцева, OOO "БСЦ Мск" (Нижний Новгород).
• Автоматическое регрессионное тестирование с помощью AET при непрерывном развёртывании ПО – Радек Логмин, Cognifide (Познань).

 Видео докладов ниже.