Этот дайджест создан совместно с телеграм-каналом QA Live | тестирование ПО. Подпишитесь, чтобы получать дайджесты прямо в телеграм!
Почитать:
Инструмент малоизвестный, но, говорят, эффективно решающий простые задачи.
Как интегрировать MSW и конструкторы данных в функциональные тесты, чтобы они точнее отражали продакшен-окружения и поведение
Тщательное тестирование поведения выпадающих списков в различных интерфейсах позволяет эффективно выявлять дефекты до релиза.
Тестируйте состояние UI, а не детали реализации, используя автоожидания. Избегайте жестко закодированных таймаутов.
Playwright – это не только сквозное тестирование и headless-браузеры, но и тестирование API.
Моками можно заменять любые внешние зависимости – API, базу данных, Redis или другой пакет внутри приложения.
В своей книге про тест-дизайн я написала ряд чит-листов, которыми и хочу теперь поделиться. Сегодня поговорим про очень важную тему — одновременное использование. Если говорить про веб-приложение, то это одновременная работа в двух вкладках браузера.
Если в приложении есть возможность открыть одну и ту же форму несколько раз — это обязательно надо проверить:
- Веб — открыть форму в нескольких вкладках браузера.
- Десктоп — там тоже иногда можно открыть в отдельной вкладке форму. Или запустить приложение несколько раз (имитируя разных пользователей).
- Мобилки — открыть с разных устройств.
Параллельное выполнение одинаковых действий часто ломает систему. Поэтому обязательно проверяем. Тем более что совместная работа — вполне распространенный кейс работы с программой. Те же гуглодоки для того и нужны, чтобы работать с ними вместе или самому с разных компьютеров.
Где должен жить код тестов проекта? Старый, как мир, спор.
Как только инженерное сообщество начало включать тестирование в жизненный цикл разработки ПО, мы спорим о подходящем доме для кода тест-автоматизации. Должен ли он жить в том же репозитории, что и код тестируемого приложения? Может, лучше выделить его в отдельный репозиторий, подальше от основной базы кода? Этот спор почти так же горяч, как противостояние «табуляция или пробелы».
В этой статье изложены аргументы обеих сторон, а также плюсы и минусы каждого подхода. Она предлагает гибридное решение на основании опыта автора и обсуждений с командой разработки. Статья делает акцент на важности «культуры качества» и роли адвокатов качества, которую играют инженеры по обеспечению качества. Также будет обсуждаться внедрение прекоммитных хуков и использование тегов в pytest для создания быстрой петли обратной связи и повышения эффективности непрерывной интеграции и поставки/разработки (CI/CD). В заключении говорится о том, что для улучшения QA-практик необходимы масштабные исследования.
Оркестрация безопасности — это новый подход, который превращает разрозненные инструменты в единую систему управления безопасностью. Раньше проблемы чаще возникали на финальных этапах разработки, когда исправлять ошибки дорого и сложно. Сегодня оркестрация позволяет управлять безопасностью на всех этапах жизненного цикла продукта — от проектирования до эксплуатации.
Как это работает?
Опять что-то куда-то интегрируется. На этот раз – тестирование безопасности в процесс разработки. Очень просто и для многих уже привычно – разработчики и тестировщики работают вместе, чтобы выявлять уязвимости до того, как код попадет в production. Например, инструменты статического анализа кода могут проверять его на наличие ошибок прямо во время написания.
Петля обратной связи- это описание процесса взаимодействия, при котором результат выполнения какого-либо действия влияет на последующее поведение системы или пользователя
Она состоит из трех ключевых этапов:
- Действие: Пользователь или система совершает действие
- Результат: Система предоставляет обратную связь о результате этого действия
- Коррекция: На основе полученной обратной связи пользователь или система вносят изменения в свои действия (Или не вносят, если коррекция не потребовалась)
Также ПОС можно обозначить временем между выполнением какой либо работы и получением обратной связи по результатам ее обработки
Selenium, Cypress, Playwright для автоматизированного тестирования UI. Postman, Rest Assured для тестирования API.
Давайте представим обычного работягу – Олега, который работает на заводе, и приходя домой, открывает соцсети, чтобы немного отвлечься и отдохнуть. И вот однажды его внимание привлекает реклама: «Стань тестировщиком 1С за неделю и зарабатывай от 100 000 рублей».
— Так-так, — думает Олег. — А что, если попробовать?
Олег решает купить ноутбук и параллельно начать обучаться. Однако спустя пару дней становится ясно, что стать тестировщиком — это не так уж просто. Нужно разобраться во множестве вещей, о которых он даже не слышал.
Последние 3 года я не интересовалась рынком труда, на собеседования соответственно тоже не ходила, по этому, когда я начала их проходить, меня ждало много открытий и удивлений.
При развитии UX‑экспертизы в продукте обязательно наступает момент, когда продуктовую команду нужно научить самостоятельно проверять простые интерфейсные гипотезы. С одной стороны, это помогает команде лучше понимать пользователей, качественнее закрывать свои задачи и ускорять проверку интерфейсных гипотез. С другой стороны — даёт возможность самим исследователям взять на себя больше сложных запросов, так как мелкие переходят в руки продуктовой команды.
Давайте на примере конкретной задачи разберем, как работает наша пирамида тестирования. В работу берется фича «Разработать новую шторку смены тарифа для OpenStack». Производится вычитка документации, после которой тестировщик накидывает в тикет чек-лист с проверками. На общем созвоне с разработчиками эти проверки распределяются по уровням в этом же тикете.
В микросервисной архитектуре есть множество зависимостей от других сервисов и инфраструктуры. В результате чего возникают проблемы, которые съедают большое количество сил и времени. Приходит, например, тестировщик с описанием воспроизведения бага — а чтобы его воспроизвести, надо долго готовить данные, а потом еще дольше поднимать фронт… После N-й итерации повторять такое вы, конечно, не будете это, мягко говоря, утомляет. Так интеграционные тесты становятся определенным оверхедом вместо того, чтобы упрощать жизнь разработчикам.
Привет, меня зовут Наталья, я мобильный QA Engineer вот уже более 6 лет. Занимаюсь как мануальным, так и авто-тестированием, успела поработать в стартапах и в крупных компаниях. Однако везде, где мне доводилось работать, была одна и та же боль – документация. А если быть точнее, ее скупость или отсутствие как таковой. И на каждом новом месте мне приходилось быть тем, кто ее пишет.
В большом мире QA (англоязычное):
JSON is easy to read, write, and language-independent, supporting data structures like arrays and objects for flexible organization. It is widely used by software teams and is a common choice for storing and transferring data. The RESTful APIs generally rely on JSON files to exchange data over HTTP.
Automated tests in CI/CD pipelines rely on consistent and predictable test data. However, without proper cleanup and management, test data can become unstable, leading to unreliable test results and deployment delays.
But now, with the AI-crap at everyone’s fingertips, we all are becoming lazy fucks. Too accustomed to getting fast answers, speed running ourselves to be even more enslaved to big tech solutions.
This is only possible because people gobble up the big tech «solutions» without question. You could stop and slow down, you know? I know many people out there are fearmongering «use AI or get left behind!», but just ignore them. Perhaps….they are not telling the truth. Perhaps, they just want to sell you something? And perhaps….the cost is too high. I don’t mean the cost of the product, but the cost for humanity.
It will only stop if we stop using these tools. If my blog offended you, good! Use your brain, and think long and hard about the LONG TERM effects of where this is all headed.
While I am generally of the opinion that we don’t need injected problems on applications that are already target rich enough as is, today I went for three versions of a well-known test target problem, namely the ToDo MVC app. Theoretically this is where a group of developers show how great they are at using modern javascript frameworks. There is a spec defining the scope, and the scope includes requirement for having this work on Modern browser (latest: Chrome, Firefox, Opera, Safari, IE11/Edge).
Software testers’ role is often misunderstood in agile teams. Unlike developers, product managers, or designers, whose responsibilities are widely recognized, testers frequently struggle with a lack of clarity and visibility in their contributions. This misunderstanding leads to the assumption that testing is merely a supporting function rather than a specialized discipline requiring expertise.
As part of my exploratory testing task for the HNG Internship, I conducted an in-depth usability and functionality test on Cars.ng. The goal was to evaluate the core user flows, identify bugs and inconsistencies, and suggest improvements to enhance the overall user experience.
Testers and developers work on the same artifacts but have different contexts. Automating rules and hiding unnecessary context can help move past the differences.
- Use cy.should() for UI-related assertions.
- Use expect() only for non-Cypress elements (API responses, variables).
- Don’t mix both styles for the same purpose to keep the framework clean and maintainable.
The motivation behind introducing a new native way of writing tests in Swift is to overcome limitations of XCTest.
Manually adding items to the cart, entering shipping details, selecting payment methods, and verifying confirmation pages is tedious. Any change in the checkout flow necessitates retesting everything from scratch.
This blog explains how to use Pytest fixtures for initializing and cleaning up Selenium WebDriver, with a practical example using the Sauce Labs Demo website.
In the Foundation Level ISQTB certification we can find five different test levels.
I’ve created a Jenkins pipeline that automates the entire process using Newman (Postman’s command-line collection runner).
Playwright has emerged as one of the leading tools in this domain.
Godoc examples are snippets of Go code that are displayed as package documentation and that are verified by running them as tests. They can also be run by a user visiting the godoc web page for the package and clicking the associated “Run” button.
Having executable documentation for a package guarantees that the information will not go out of date as the API changes.
The standard library includes many such examples (see the strings package, for instance).
This article explains how to write your own example functions.
Storybook 8.5 includes:
- ♿️ Realtime accessibility tests to help build UIs for everybody
- 🛡️ Project code coverage to measure the completeness of your tests
- 🎯 Focused tests for faster test feedback
- ⚛️ React Native Web Vite framework for testing mobile UI
- 🎁 Storybook test bootcamp to level up your testing game
currently work as a Product Engineer focusing on Software Quality at Waitrose Digital, part of the John Lewis Partnership. With 13 years of experience in Quality Engineering across multiple projects — and six of those years within the Partnership — I’ve had the opportunity to lead and innovate in various quality-focused initiatives. Over the past two years, I’ve been involved in an exciting migration project: moving from a monolithic architecture to a Micro Frontend (MFE) architecture for Waitrose — starting with the Product Details Page (PDP).
I have an unapologetic and, I’d like to think, pragmatic take on testing. I want tests to run fast, not be flaky and not be brittle. By «flaky», I mean tests that randomly fail. By «brittle», I mean tests that break due to seemingly unrelated changes in the code. I’m happy that the definition of «unit tests» has broadened over the years: it’s now acceptable to have «unit tests» do more, i.e. hitting a database. I call the period of time where I (we?) over-relied on dependency injection and mocking frameworks, the «dark ages». Still, I do believe that stubs and similar testing tools can be useful in specific cases. One pattern that I’ve recently leveraged is using a generic to inject a stub for testing.
Imagine you’re playing with a remote-controlled car. The remote sends signals to the car, and the car understands what you want it to do. APIs (Application Programming Interfaces) are like those remotes or APIs are similar to waiters in a restaurant. As a client, you simply place your order from the menu, and the waiter brings it to you from the kitchen (the back-end). It acts as a bridge between two components to do a particular task.
Parameterized tests allow you to run a single test with multiple input parameters without adding much boilerplate code. For example, you might want to run a unit test for all cases of an enum. You can specify a collection of elements to use as input for the unit test, after which the test will run for each individual argument.
Mutation testing, where faults (mutants) are deliberately introduced into source code (using version control to keep them away from production) to assess how well an existing testing framework can detect these changes, has been researched for decades. But, despite this, mutation testing has remained difficult to deploy. In earlier approaches, mutants themselves would be automatically generated (most often using a rule-based approach). But this method would result in mutants that weren’t particularly realistic in terms of how much of a concern they actually represent.
Посмотреть:
Akamai reports that 83% of traffic on their Akamai network is API hits, which is more than HTML traffic. Our discussion focuses on the API First strategy, which places API design and planning at the forefront of project development, enhancing collaboration, scalability and integration.
Ваша консоль вам не помогает и не подсказывает? Она бесцветная и грустная? Вы забываете команды и не любите много печатать?
- Как стать тестировщиком в 2025 | Артём Русов ⏱️40 минут
Про нетворкинг, накрутку опыта, стажировки и гибкость.
𝐄𝐥𝐞𝐦𝐞𝐧𝐭𝐂𝐥𝐢𝐜𝐤𝐈𝐧𝐭𝐞𝐫𝐜𝐞𝐩𝐭𝐞𝐝𝐄𝐱𝐜𝐞𝐩𝐭𝐢𝐨𝐧 и прочее.
- How ProductSquads Redefined QE ⏱️40 минут
From shorter release cycles to complex tech stacks, AI-driven test automation, and integrating QE into CI/CD, teams face new challenges every day.
okey — on top of the job market being so tough this video came out and made things even more scary
На уроке мы рассмотрим требования для валидации запросов и ответов API. Также разберем JSON Schema и автоматизируем процесс валидации JSON
Хорошей недели!
