QA Сhannel

Баттл «Проактивный и реактивный подходы к развитию QA-специалиста» Попытаемся понять на основе наших подписчиков какая модель развития сотрудника в компании лучше: 👍 - если считаете, что надо развиваться самому по своему плану 🙌 - если очевидно, что компания должна выстраивать процесс обучения сотрудников 🤔 - если в целом не понимаете зачем что-то изучать, и так некогда задачи текущие решать

Новые подходы в Swift для тестирования: разбор технологии Swift Testing

Тестирование на Swift долгие годы держалось на трех китах: XCTest, сторонние библиотеки и собственная смекалка. Но на WWDC 24 Apple представила новый, современный фреймворк — Swift Testing, который предлагает концептуально новый подход к тестированию.

Давайте рассмотрим основные отличия при использовании Swift Testing: - Поддержка аннотации @Test. Благодаря этому, для определения теста теперь не обязательно создавать класс. - Поддержка аннотации @Suite - Expectation и require для проверки условий - Логирование ошибок при помощи Issue.record() - Появилась возможность использования тегов - Механизм добавления связи упавшего теста с багом - Возможность создания параметризорованных тестов

Эффективное тестирование ETL-процессов в Data Warehouse

7 бед - flywave migrate

Процесс тестирования встречается в разных частях компании. Сегодня поговорим про тестирование данных. А точнее о процессах проверки больших хранилищ с данными о пользователях для аналитики. Эти данные позволяют компаниям принимать более взвешенные решения о рекламным акциях, отправке грузов или построении трендов спроса на отдельные виды товаров.

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

Как конвертировать mind map в чек лист В продолжении темы про визуализацию в тестировании. Эта статья поможет тем, кто пользуется TestOps и TestRail как хранилищем для своих чек-листов и тест-кейсов. Для каждого из продуктов есть свои особенности реализации, но схема работы совпадает. Автор показал как за три шага сделать конвертацию из визуального представления данных (в данном случае mind map) в список проверок. Правда данный вариант лучше работает для чек-листов, так как для полноценных тест-кейсов в mind map не хватает описания шагов и ожидаемого результата. Но, возможно, с помощью ИИ вы найдете способ, как обогатить список проверок для следующего шага оптимизации процесса.

Gradle для QA-инженера В процессе внедрения автотестирования в проект есть несколько шагов, где надо сделать выбор в пользу того или иного инструмента. Одна из таких развилок происходит при выборе между Gradle и Maven. У каждого из них есть свои плюсы и минусы. Пару примеров приемуществ Gradle:

Сегодня Gradle — это выбор по умолчанию для Kotlin, активно используется в крупных Java-проектах и продолжает отбирать долю у Maven благодаря своей производительности.

В отличие от Maven, Gradle выполняет только те задачи, которые необходимы. Если код не менялся, Gradle не будет перекомпилировать его повторно, что и дает огромный прирост скорости.

Gradle использует язык программирования (Groovy или Kotlin) для файлов конфигурации, а не статический XML, как Maven. Это дает широкие возможности для создания сложных и гибких сценариев сборки, что особенно полезно в больших проектах с автотестами.

Как Flakyzavr съел наши проблемы Разбор падений в прогонах автотестов - утренняя рутина для многих специалистов по тестированию. Но отдельное удовольствие - пытаться понять, почему определенный тест сегодня упал, хотя до этого неделю с ним все было нормально, а при новом прогоне он становится «зеленым». Что это: - баг, который воспроизводится в определенных условиях? - ошибка вызвана инфраструктурными изменениями? - просто тест с нестабильным поведением? Чтобы упростить работу с такими тестами, ребята сделали отдельный плагин, который может: - собрать всю нужную информацию об упавшем тесте - проверить, есть ли в Jira уже тикет на эту проблему - если нет, создать новую задачу по шаблону

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

Тестировали, тестировали, тестировали, тестировали и наконец ПРОТЕСТИРОВАЛИ! Как сэкономить нервы тестировщиков? Нужно автоматизировать большинство процессов и научиться выявлять ошибки на ранних этапах разработки 😎 С этим помогают инструменты Платформы Сефера. Сфера.Тестирование — это бандл инструментов в рамках российского DevOps-конвейера: 🛑позволяет создать систему автоматизированного тестирования; 🛑обеспечивает качество продуктов на всех этапах разработки; 🛑 сокращает затрачиваемое время и ресурсы. Кроме функционального, нагрузочного, веб-тестирования, а также генерации и обезличивания данных, в бандл входит мобильная ферма. Сервис позволяет командам тестировщиков получить удаленный доступ к множеству смартфонов и планшетов, чтобы проверять работу продуктов в условиях, максимально приближенных к реальным. 📤 Подробнее о всех инструментах Платформы Сфера. Информация о рекламодателе.

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

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

Топ-10 полезных расширений для браузера в арсенале QA-инженера

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

А какие вы используете браузерные расширения для работы? Пишите в комментарии к посту.

Применение структурно-логических схем в организации тестирования

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

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

Давайте потестируем Webview Если вы тестируете мобильные приложения, то скорее всего, сталкивались с Webview. Эта технология используется для вставки определенного веб-контента внутри: от показа рекламы до формы оплаты банковской картой. У нее есть ряд особенностей, о которых лучше знать заранее, чтобы не получать потом лишние негативные отзывы от пользователей. Также в докладе рассматривается несколько подходов к автоматизации тестирования для таких компонентов систем.

Как запускать 100k+ браузеров в день и спать спокойно Работа с UI-автотестами - отдельный вид удовольствия. Особенно если у вас много таких тестов и нужно запускать их параллельно в нескольких браузерах. Все это относительно долго и не очень стабильно. Всегда хочется иметь больше потоков для запуска, чтобы быстрее проверять функциональность или производить отладку текущего кода. Обычно вопрос параллельного запуска решают с помощью Selenoid. Но у него есть две проблемы: - Он не совместим с Playwright - Проект Selenoid был заархивирован и больше не развивается с конца 2024 года Поэтому авторы статьи создали свое решение, которое сейчас опубликовали в виде open source проекта. И теперь в день пиковый объем составляет до 500к открытых браузеров.

В продолжении темы тестирования процесса доступа пользователей в приложение. От Basic Auth до OIDC: тестирование аутентификации и авторизации для QA-инженеров Повторим базовые знания, которые иногда спрашивают на собеседованиях:

Идентификация — вы вводите логин (сообщаете, кто вы). В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд. Аутентификация — вы вводите пароль или код из SMS (доказываете, что это вы). Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

Краеугольные камни нагрузочного тестирования В беседе специалистов из Dodo и VK рассматриваются основные аспекты нагрузочного тестирования: - какой инструмент выбрать - от кого приходят целевые показатели для данного вида тестирования - кто проводит нагрузочное тестирование сервиса - тестируем на продакшене или на отдельном стенде - когда надо запускать нагрузочное тестирование - по каким критериям определять завершение нагрузочного тестирования

gRPC для тестировщика: быстрый старт после REST

REST API уже давно стал стандартом, но у него есть ограничения. Когда нагрузка растет, появляются потоковые сценарии или бизнес требует ускорения работы внутри сервисов, REST перестает быть ультимативным решением. gRPC решает то, с чем REST не справляется: обеспечивает высокую скорость передачи данных, поддерживает стриминг и дает строгую структуру взаимодействия. Его удобно использовать в микросервисах, мобильных и IoT-приложениях. Для тестировщика это значит одно: умение работать с gRPC превращается из «будет плюсом» в обязательный навык. Если вы еще не работали с этим протоколом, то статья поможет понять его основы, отличие от REST, как устроены .proto-файлы, и самое главное – как тестировать gRPC-сервисы с помощью Postman.

Давайте посмотрим на мир общения между частями приложения чуть шире. Если раньше REST часто сравнивали с SOAP, а потом был краткосрочный период популярности GraphQL, то сейчас еще одним активным игроком на этом рынке является gRPC.

Как измерять техническое качество и SLA, чтобы команда работала стабильно

Предположим, у нас есть сервис, у которого есть три ручки: первая отдает что-то по ID, вторая проводит транзакцию, третья пачкой загружает сущности. Как мы можем охарактеризовать эти ручки в рамках ожиданий? - Ручка 1 используется часто и должна быстро отдавать ответ.  - Ручка 2 используется реже, но должна быть максимально надежной и стабильной. При этом, конечно, мы не хотим, чтобы оплаты проходили долго. - Ручка 3 не требует моментального отклика. 

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

Про тестирование «в право» Многие из нас слышали понятие «Тестирование влево» (Shift-left testing). Оно говорит нам о том, что мы должны начинать осуществлять проверки как можно раньше в процессе разработки ПО для минимизации общих рисков. В данной статье рассматривается еще один похожий подход - Тестирование вправо (shift-right testing). Вот как описывает его автор:

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