Этот дайджест создан совместно с телеграм-каналом QA Live | тестирование ПО. Подпишитесь, чтобы получать дайджесты прямо в телеграм!
Почитать:
Больше всего автотестировщиков беспокоит нехватка времени, жесткие ограничения, устанавливаемые произвольно, а также нехватка ресурсов. 80% QA-команд указали проблему нехватки времени (и ресурсов) как главную.
«Одно могу сказать точно – гарантированно будут расти люди с уникальными навыками и особенным рвением, то есть, те, кто готов на начальных этапах довольствоваться «миской риса» и «веткой». Но по моему опыту в преподавании, большинство будущих IT-специалистов понятия не имеют, как работает сфера и какие там ожидания. Когда приходит осознание – многие отваливаются, только 30% находят в себе силы хотя бы закончить курсы.»
Ознакомительный гайд, с примерами в Playwright.

Проблемы в новых фичах, о которых сообщили пользователи, стабильность критически важных пользовательских путей, и время, потраченное на исследовательское тестирование.
Эти метрики связаны с DORA — популярной методикой оценки эффективности членов команды:
На других платформах:
Большинство тестировщиков в курсе, что Postman – один из самых популярных инструментов тестирования API. Я пользовалась им больше, нежели иными аналогичными инструментами, и просто без ума от его интерфейса. По моему опыту, наиболее популярные возможности Postman – это предварительные скрипты, методы авторизации, интеграция библиотеки Faker для случайных тестовых данных, и та, которую я намерена изучить и исследовать – Flows.

Большинство тестировщиков в курсе, что Postman – один из самых популярных инструментов тестирования API. Я пользовалась им больше, нежели иными аналогичными инструментами, и просто без ума от его интерфейса. По моему опыту, наиболее популярные возможности Postman – это предварительные скрипты, методы авторизации, интеграция библиотеки Faker для случайных тестовых данных, и та, которую я намерена изучить и исследовать – Flows.


Чаще всего аргументы используются в запросах и мутациях. Тем не менее, они могут быть и внутри простого объекта, если это нужно по бизнес-логике.


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


Метод критического пути тестирования помогает компаниям лучше использовать ресурсы через определение самых важных задач, влияющих на общее время разработки. С помощью этого метода специалистам также легче находить места в системе, которые могут негативно сказываться на его релизе.
Слышали о землетрясениях, которые происходят каждый день по всему миру? Как правило, если вы не сейсмолог или не живёте рядом с тектоническим разломом, то вам всё равно. Но информировать людей о реальных катастрофах в их регионе очень важно, покажем пример такой системы оповещения через SMS.
Сегодня мы построим небольшой центр уведомлений. За основу возьмем GeoJSON Earthquake API для получения данных о землетрясениях, подключим Exolve API, чтобы рассылать SMS, а для хранения данных используем PostgreSQL.

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


NeoNN: Вообще в тестах принято прописать стандартный комментарий AAA — arrange, act, assert, чтобы разделить секции с разными операциями. Ну и часто тесты действительно могут копипаститься и писаться гораздо менее продуманно, чем основной код, но у них чисто утилитарная цель, непонятны цели инвестиций в код, кроме тех, где они реально оправданы.

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

Pytest — это первое, с чем сталкивается любой тестировщик, который хочет начать автоматизировать и развиваться в этой области. Многие компании строят автоматизацию на Pytest, и на собеседованиях требуют его понимания. Поэтому, чтобы устроиться в такую компанию, нужно изучить Pytest.
Давайте разберёмся, что умеет этот фреймворк, на примере простых конструкций, которые часто советуют тестировщикам.

Денис Хахалкин, QA Lead — Wallarm, ex. Ozon. Поговорили с ним о том, как подготовить резюме для прохождения первичного отбора ресёрчерами и HR‑специалистами на российском рынке труда. Обсудили, как правильно выбрать опыт для включения в резюме, чтобы он был актуален для желаемой должности, почему не стоит врать в резюме и как и когда стоит упоминать о пройденных курсах и полученных сертификатах, чтобы не отпугнуть потенциальных работодателей.


После долгих праздников и рабочего разгона в задачи самое время вспомнить азы, проиллюстрированные мемами, и порадоваться, что санитары в начале года нужны не вам и вашему проду.
Сегодня поговорим о не особо упоминаемом, но одном из самых популярных видов тестирования – санитарном тестировании. О том, когда важно к нему прибегать, кто должен им заниматься, почему его часто путают со смок-тестированием, можно ли полностью его автоматизировать и как правильно его организовать.
End-to-end тесты обеспечивают надёжность приложения, но сами они часто превращаются в боль при поддержке. Даже небольшие изменения в UI могут их ломать, и в результате команда тратит много времени на отладку.
Ниже поделюсь способом, как можно оптимизировать процесс исправления Playwright тестов с помощью AI, добавив прямо в HTML-отчёт вот такую кнопку.



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


Локаторы — важная часть автоматизации тестирования. Они позволяют находить элементы на странице для взаимодействия с ними в тестах. Но что делать, если стандартные методы, такие как CSS-селекторы и XPath, становятся громоздкими, ломаются при изменении структуры страницы или не поддерживают уникальные особенности элементов? Решение — кастомные локаторы.

В большом мире QA (англоязычное):
- Chrome DevTools support is now: v132, v131, and v130 (Firefox still uses v85 for all versions)
- Expanded nullability annotations for better type safety in .NET and Java.
- Refinements to Selenium Grid, including more efficient session handling and node management.
- Packaging and installation enhancements across Python and Ruby for smoother integration.
- Documentation improvements across Python and .NET libraries, ensuring clearer developer guidance.
- Updated language-specific implementations for modern development standards.
New option timeout allows specifying a maximum run time for an individual test step. A timed-out step will fail the execution of the test.
In this post, we’ll cover how to best organize your Playwright tests, from folder structures to using hooks, annotations and tags.

Today, we’re going to dive deeper into how E2E testing with Appium works on iOS.


Being a test engineer (QA) for a decade, I’ve collected over a hundred notes related only to API testing.
In the Dev-in-Test team, we use the “Scorecard” method to ensure we make the right decisions quickly. This approach helps us evaluate options based on predetermined criteria, making our choices more objective.


Building OneXerp, Applying It to HiiBo, & Lessons Learned


At Vestiaire Collective, our monolith application underpins essential features such as Login, Listing Form, and Checkout, which are vital to our business operations. With numerous engineers contributing to this repository, deploying changes can pose risks to the reliability of the entire system. To mitigate these risks and accelerate the deployment of smaller amounts of changes, we embarked on a journey to optimize our end-to-end (E2E) test suites.

Confusing terminology contributes to misperceptions of testing and testers. And it often makes it even harder for people to understand the value off professional testers. For example: describing someone as a “manual tester” may create a perception of someone who’s not adding a lot of value. There is nothing intrinsically wrong with the term “manual”, but culturally, at least here in the U.S., the term implies someone who doesn’t have valuable skills but can be given straightforward, well-defined tasks to do.
Does 2025 Maaike agree with what 2021 Maaike wrote? I found the following in my Apple Notes just now. Read it, and then I’ll tell you whether I still agree with my thoughts from 4 years prior. Spoiler: it gets very real! Lots of curse words! I’m not sparing anyone, including myself.
We currently execute close to 10,000 tests for our monolithic application. We split our tests amongst many machines to perform these tests in a reasonable timeframe.
According to CI, our workflow takes about 13–16 minutes, with testing taking up about 9–11 minutes of this whole workflow.

In this blog post series, I’m going to explain 2 things:
- How to use mocking tools to create simple, expressive, and powerful mocking interfaces
- How to type-check those interfaces to make them effortless to use

From here on, I will use the term “tester” because I agree with the opinion expressed in the book Agile Testing that the effort to label specialists as QC or QA often stems more from a desire to escape negative associations with low-skilled positions than from actual competency expansion. Nevertheless, testers in Agile are generally more T-shaped and influence the entire software development process. We will not discuss dedicated QC and QA roles that do not directly engage in testing.

Посмотреть:
- Ускоряем Allure TestOps ⏱️45 минут
Если Allure TestOps понравится команде, а это очень вероятно, то скоро в нем появятся гигабайты результатов тестов и запусков. И возникнет задача ускорения работы с наиболее популярными проектами тестов: как сделать так, чтобы самый популярный отчет работал быстрее. Такие оптимизации несложно добавить, но добавлять их логичнее всего каждому SDET-инженеру самостоятельно под текущую конфигурацию данных.
This comprehensive tutorial covers the fundamentals of web tables, including their structure, elements like thead, tbody, tr, and td, and the DOM inspection process to validate table elements. You’ll learn how to identify rows and columns programmatically, perform filtering operations based on specific criteria like tasks, assignees, and statuses, and write advanced assertions to verify test outcomes accurately.
- From network tab to automated API test ⏱️15 минут
Creating API tests under tight deadlines can be overwhelming for backend developers. What if there was a way to automate test generation directly from network traffic?
- The State of Cypress | Founder of Cypress.io ⏱️35 минут
Join Brian Mann, Founder of Cypress.io, and Senior Product Manager Peter Stakoun as they reveal the latest innovations in application testing with Cypress. In this session, they unveil two powerful tools, UI Coverage and Cypress Accessibility, that are set to transform how teams test and maintain their applications.
Хорошей недели!
