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

Привет! На связи Никита, QA Surf! И я три или четыре раза сталкивался с мнением, что навыки программирования опциональны для QA. Но работа QA — это не просто тестирование, это полноценное обеспечение качества продукта. И умение писать код — мощный инструмент для совершенствования и автоматизации процессов тестирования.

Разберёмся, как автоматизация помогает решать проблемы QA, на примере матрицы покрытия устройств для конфигурационного тестирования. Звучит непросто, но нас не испугать сложными задачами!

Автор: Шрай Шарма (Shray Sharma)
Оригинал статьи
Перевод: Ольга Алифанова

Введение

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

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

Возможно ли это? Да, возможно! Эта статья о том, как совместить Playwright, библиотеку тест-автоматизации с открытым исходным кодом, с языковыми моделями ИИ вроде Groq, Llama и Mistral, чтобы:

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

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

Меня зовут Николай Борисенко. Я специалист по автоматизации тестирования в ОК, и я продолжаю наш рассказ о генерации тестов на основе спецификации API.

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

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

Меня зовут Михаил Палыга, я инженер в Блоке обеспечения и контроля качества выпуска изменений ПО в РСХБ‑Интех. Разработчик я начинающий, в компании работаю около года, плюс 6 лет обучения в профильном вузе. В данной статье хочу рассказать, как мы в нашем проекте проводим проверки данных в наших тестах.

Мы занимаемся разработкой автотестов для АБС ЦФТ‑Банк — автоматизированной банковской системы (АБС), разработанной ООО «Центр финансовых технологий». Это ядро IT‑экосистемы банка. Тесты состоят из трех этапов: формирование условий, воздействие и проверка результата. Кстати, о том как и каким инструментом мы подбираем тестовые данные, мы писали ранее в этой статье, а об особенностях перехода с Oracle на PostgreSQL мы писали тут.

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

Далее в статье я опишу, как со временем менялся наш подход к проведению проверок данных и как менялись сами классы проверок. А чтобы было чуть проще и интересней — займемся тестированием чего‑нибудь из вселенной Звездных Войн. Например, протестируем имперский бронированный транспортный вездеход AT‑AT.

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

Тестирование API — неизменная задача при разработке продуктов. Проблема, с которой сталкиваются многие компании, — большой ручной регресс. Появляется автоматизация, но покрытие огромного количества API‑методов требует ресурсов, которых часто нет. Кроме того, в большинстве случаев написание API‑тестов — монотонная работа, которой никто не любит заниматься. Как решить эти проблемы?

Меня зовут Елизавета Андреева. Я инженер по автоматизации тестирования в ОК.Tech. Мы с коллегами в ОК разработали и внедрили автогенерацию API‑тестов, благодаря которой мы сокращаем ручную работу и время на написание однотипных автотестов, оставляем QA‑инженерам для покрытия только кейсы на бизнес логику. И в этой статье (которая станет первой в серии из двух частей) я начну рассказ о том, как мы реализовали наш генератор и каких результатов нам удалось достичь.

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

Всем привет! Я старший преподаватель направления функционального тестирования в «ЛАНИТ Экспертиза». К нам в штат приходят люди из разных профессий и с разным уровнем знаний. Поэтому в компании организованы курсы обучения практикам тестирования, которые уже стали базовыми. Одной из них является тестирование с помощью API запросов, или, как его еще называют, тестирование API. И сегодня для тех, кто этим занимается, я постараюсь доступным языком рассказать, как использовать этот формат для описания тестовых данных, подключаемых к прогонам коллекций в Postman.

Автор: Пронин Дмитрий, Иви (AQA-lead клиентского тестирования)

Привет! Мы в онлайн-кинотеатре Иви любим писать автотесты, особенно клиентские (Потому-что клиентские приложения - это первое, а иногда и единственное, что видят наши пользователи). У нас 4 основных платформы - Android, Web, Smarttv, iOS (Android и iOS - еще подразделяются на мобильную и tv версии).

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

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

Терминатор 2: Судный День, наверное, самый лучший из всех фильмов про Терминатора. Он по большей части сохранил дух оригинального Терминатора, но добавил более качественные спецэффекты и шикарную песню Guns ‘N Roses. ПО, о котором я буду говорить, Mailinator, всегда напоминает мне одну из самых запоминающихся фраз из Т2: «Идем со мной, если хочешь жить». Но для начала немного контекста.

В моей прошлой компании нам нужно было создать «достаточно уникальную» учетную запи сь, чтобы автоматизированное создание учетки не требовало вмешательства человека; на проде «вмешательство человека» требовалось для предотвращения мошенничества и работы со сценарием «тот же человек, другая информация». Для завершения автоматизированного тестирования создания учетной записи процесс требовал получения письма о создании учетки. В то время Google Mail, то есть Gmail, позволял это через синтаксис «емейл-адрес с плюсом».

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

Конечно, нет! Наша автоматизация должна прогоняться за секунды, или хотя бы менее, чем за десять минут. Ведь верно? Ведь правильно? Вставьте сюда мем с Падме и Анакином. 45 минут – это явно антипаттерн и всегда плохая идея, правда же?

Все вы знаете, не так ли, что бывает, когда я задаю подобные абсолютные вопросы, да?

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Мы дошли до L в SOLID! Принцип замещения Лисков назван в честь Барбары Лисков, специалистки по информатике, которая ввела эту концепцию в 1987 году. Принцип гласит, что вы должны иметь возможность заменять объекты суперкласса объектами подкласса, не изменяя программу.