Home

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

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

И у каждой ошибки есть своя цена. Было бы здорово, если бы о них можно было узнать:

• на этапе локальной отладки и, соответственно, быстрее (например, запустив одну команду и получив отчёт) — движение в сторону Fail Fast и сокращения Feedback Loop;

• не занимая ресурсы CI сборкой кода, который заведомо придётся исправлять, — Quality Gates;

• снимая часть нагрузки с ревьюера и меньше переключая контекст специалистов;

• работая с унифицированным кодом и не тратя время на обсуждение мелочей.

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

Меня зовут Николай, и я инженер в мобильной платформенной команде Яндекс Еды. В этой статье я расскажу, как мы повышаем качество кода автотестов Android-приложения. И в этом нам помогает статический анализ.

Автор: Мануэль Матузович (Manuel Matuzović)
Оригинал статьи
Перевод: Ольга Алифанова

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

Встроенный в Google инструмент тестирования Lighthouse оценивает доступность наших сайтов по шкале от 0 до 100. Похвально иметь высокий рейтинг, однако то, что вы набрали 100, не значит, что у сайта прекрасная доступность. Чтобы это доказать, я провел небольшой эксперимент.

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

Автор: Субботин Юрий

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

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

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

Я, как профессионал: Почему так много людей начинают автоматизировать с UI-автоматизации?

Я, как тренер: Почему так много курсов автоматизации начинает с UI-автоматизации?

Автор: Куо Динг (Kwo Ding)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Катерина Верхошинская (инженер по автотестированию в Газпром-Медиа Холдинг)
Оригинальная публикация

Меня зовут Катерина, я инженер по автотестированию в команде онлайн-кинотеатра PREMIER и сегодня я хотела бы поделиться с вами своим опытом в написании API автотестов на Python. Я работаю в сфере автотестирования уже довольно давно и на практике встречаю проекты из разных сфер деятельности (банкинг, ритейл, телекоммуникации, строительство, развлечения и др.) зачастую, работая над ними, я сталкивалась с одной общей проблемой - код автотестов был тяжелым в понимании и плохо масштабируемым. Приходилось его капитально рефакторить, а это совсем невесело;) В этой статье  я хочу поделиться советами, как сделать ваш код более «чистым», легким в понимании и расширении. Мне всегда хочется думать, что тот, кто будет работать с моим кодом в будущем, будет думать обо мне и моём коде в положительном ключе, а не ругаться на него. Если вы разделяете мою философию, прошу под кат.

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

Несколько недель назад в моей LinkedIn-ленте появился пост от коллеги-автоматизатора Куо Динга. В нем Куо предлагает использование того, что он называет моделью «клиент – тест», для улучшения разделения ответственности при создании тестов API на основе HTTP в REST Assured.

Блог компании YADRO

Полезный контент для всех, кто пишет автотесты на Python. В подборке — видео докладов с последнего AQA‑митапа: о плагинах Pytest, архитектуре автотестов для продукта на open source-движке, а также о критериях понятных тестов (и как их соблюдать на практике). Материалы будут полезны как начинающим, так и опытным AQA-инженерам. Под катом — все видео и ответ на вопрос, зачем это смотреть, от гостей митапа.

Автор статьи: Глеб Саркисов (Gleb Sarkisov)
Оригинал статьи

Бэклог багов: делаем понятную организацию и держим всегда актуальным

Всем привет, я Глеб, работаю хедом QA в Mayflower.

Сегодня поговорим про такую важную штуку как бэклог багов. Представьте: вы выходите на новую работу (тестлидом, менеджером тестирования, а, может тестировщиком или даже продактом/проджектом), начинаете знакомиться с людьми и процессами, открываете Jira, а там бэклог из 300 открытых багов! Ваша реакция логична: недоумение, отчаяние и боль от увиденного.

Автор: Артем Сидорук

Вы пишете автотесты? Ваш проект с автотестами огромен и монструозен, и добавление каждого нового сервиса в него приносит нестерпимое желание все удалить и написать заново? У вас есть базовый класс на 3000+ строк с методами на все случаи жизни? Или, возможно, вам приходилось исправлять множество тестов, чтобы добавить одну и ту же строчку в каждом из них?



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