Home

Автор: Ирина Соколова, Senior QA Engineer, qualsolife.ru
Оригинальная публикация

Некоторое время назад я написала статью о своем опыте организации работы QA Инженера на проекте. Сейчас хочу продолжить эту тему, но уже в более узком ее направлении — автоматизации тестирования. Речь пойдет о том же самом проекте, он небольшой, но развивающийся под запросы постоянных клиентов. Быть может мой подход не очень подойдет командам, где работают много десятков сотрудников и каждый отвечает за свою часть (по-моему, в таких проектах работа каждого должна быть строго регламентирована, иначе такой махиной управлять просто невозможно, хотя и они найдут здравое зерно), но он точно будет интересен тем, кто, как и я, однажды пришел на новую работу, и встал на перепутье как самому организовывать свое место под новым солнцем.

Автор: Баз Дейкстра (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)
Оригинал статьи
Перевод: Ольга Алифанова

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

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