В телеграме QA Live | тестирование ПО
Дайджесты + 🔥 Вакансии QA 🔥
Почитать:
Тестирование доступности в Slack: интеграция Axe в Playwright
Axe — неформальный стандарт индустрии, многие инструменты основаны на этой библиотеке. Несмотря обилие инструментов и их гибкость, они определяют не более 30-70% имеющихся проблем.
Краткое объяснение и код реализации этих подходов в Playwright.
На других площадках:
Качество ПО и простота разработки: почему тестировщикам стоит об этом позаботиться
Простота разработки связана с вопросом, насколько легко или сложно разработчику выполнять задачи, необходимые для процесса разработки. Положительный опыт разработчика означает, что эти задачи довольно легко выполнимы командой, потому что для поддержки процесса разработки существуют необходимые системы, технологии, процессы и культура. Короче говоря, хороший DX важен, так как позволяет разработчиком писать код с уверенностью, приносить больше пользы и повышать производительность, затрачивая меньше сил.
На самом деле я айтишник, а доставка — это для души
Я системный аналитик в компании «Автомакон», где занимаюсь разработкой мобильного приложения «ВкусВилл:Курьер». Но почему я решил на время сменить профессию? Мне нужно было понять, как работает наш продукт в реальной жизни — не через отчёты или звонки с курьерами, а своими руками, ногами и велосипедом.
Как писать визуальные автотесты UI при помощи графики, а не сложных локаторов
Представьте на минутку, что вы тест-робот, задача которого – тщательно следовать тест-скрипту. Ваша ключевая проблема – это выполнить текстовую инструкцию в графическом интерфейсе пользователя. Если вы тестируете веб-приложения, то ваши инструкции могут выглядеть, как строка CSS – нечто вроде «.posts:n-th(3) button:has(.pencil).» Это можно интерпретировать, как кнопку редактирования третьей записи, но в структуре приложения зависимость более глубокая.
В ходе этого процесса небольшая группа специально отобранных пользователей проверяет программное обеспечение или его отдельные компоненты в реальных условиях.
Примеры тест кейсов
Техники тест-дизайна: теория против реальности
За 17 лет в QA я не раз сталкивался с тем, что на курсах, тренингах дают десяток техник тест-дизайна. Всё красиво: классификация, схемы, примеры. А потом ты приходишь на проект — и релизы каждую неделю, десятки тикетов, ручная регрессия, звонки, встречи… И времени на всё это просто нет.
Тестирование в процессе разработки MVP
MVP создается не для того, чтобы впечатлить инвесторов или захватить рынок, а чтобы проверить гипотезы.
Методологии разработки ПО: классика глазами тестировщика
Если вы тестировщик, важно понимать, на каком этапе вы подключаетесь к работе, будет ли у вас документация и как строится процесс в целом.
Нюансы тестирования десктоп-приложений
Во-первых, такие приложения тесно интегрируются с операционной системой и оборудованием компьютера, что требует проверки множества аспектов, таких как установка, удаление, совместимость с разными версиями ОС и конфигурациями устройств.
Нельзя прийти к своему руководителю и на вопрос: «Что там с проектом?» ответить: «Всё отлично, проект качественный, зуб даю!» Невозможно повысить зарплату, обосновывая, что тестировщик Ваня — отличный парень и чётко работает, а наш проект — лучший по обеспечению качества, потому что я в этом уверен!
Чтобы упростить тестирование, используют заглушки — это упрощенные версии реальных компонентов, которые помогают проверить работу системы без необходимости запускать всё «по-настоящему». Моки (Mocks), стабы (Stubs) и фейки (Fakes) — это разновидности заглушек, которые заменяют реальные компоненты системы в тестировании. Разница между ними заключается в том, насколько они реалистичны и что именно позволяют протестировать.
Приоритизация регрессных тест-кейсов
Если уйти от идеализации, то обычно в начале регрессионного тестирования мы видим огромное количество тест-кейсов в виде большого списка, который, как правило, структурировано выделен по папкам и разбит на модули, связанные между собой.
Также мы помним, что одна из задач тестирования — предоставление информации о качестве системы и обеспечение этого самого качества на определённом уровне. А о каком качестве можно говорить, если при тестировании мы осознанно не рассматриваем часть кейсов?
Ответ на этот вопрос вытекает из эмпирических исследований, которые выявили, например, что для приложения NASA: 67% ошибок были спровоцированы одним параметром, 93% проблем были вызваны одним параметром или взаимодействием двух параметров, 98% — одним параметром, взаимодействием двух параметров или взаимодействием трёх параметров.
Измерение покрытия API тестами на основе Swagger для Python
Основная цель инструмента — определить, насколько полно тесты покрывают API-контракт, представленный в формате Swagger (OpenAPI). Здесь ключевые слова — «автоматически» и «на основе бизнес-требований». Ведь если измерить покрытие кода — задача давно решённая (во многих языках такие инструменты встроены из коробки), то вот получить представление о бизнес-покрытии (что именно из спецификации API проверено) — задача куда менее тривиальная.
Regexp -> Regular expression -> регулярное выражение – это строчное значение, которое описывает шаблон поиска подстрок в заданной строке.
Как мы тестируем дизайн внутренних продуктов
Наш продукт не увидит внешний пользователь, но он напрямую влияет на скорость, точность и удобство работы с ипотекой. Если что-то в интерфейсе неудобно, то это отражается не только на работе специалиста, но и на том, как быстро клиент получит одобрение, подпишет договор и купит квартиру.
Пишем тесты в транзакциях MySQL
Я люблю писать тесты для своего кода, но при этом не люблю писать моки и всю необходимую для них обвязку. Особенно это касается базы данных, ибо если замокать вызовы внешних сервисов и очереди сообщений еще не так сложно, то с БД все гораздо сложнее. Взаимодействие с базой данных обычно довольно «богатое», это ведет к тому, что приходится писать много хрупких и утомительных моков/стабов, и при этом сами запросы к БД не покрываются тестами (а там зачастую могут таиться ошибки, связанные с некорректными запросами или ошибками миграции схемы).
Контроль времени в Python-тестах: freeze, mock и архитектура Clock
Время — это одна из самых нестабильных переменных в коде (и не только). Оно безжалостно к CI, случайным багам и здравому смыслу. Особенно если вы пишете логику, где участвует datetime.now(), time.time() или utcnow(): TTL, крон-задачи, дедлайны, отложенные события, idempotency-окна, подписки, отложенная отправка писем, повторная авторизация — всё это работает с временными сдвигами. И всё это будет ломаться, если не заморозить время в тестах.
Англоязычное:
Cutting Through the Noise — The Case Against Gherkin in Automation
In practice, I’ve seen plenty of teams start out with good intentions, embedding Gherkin scenarios into user stories and automation suites. But that’s usually where it ends. Non-technical stakeholders rarely engage with the feature files, so Gherkin just becomes an extra layer of abstraction and maintenance. Ultimately, it is left to the automation engineers to pick up the slack.
Scaling Strategies for Parallel Test Execution
You may not be familiar with scaling strategy types for parallel test execution, but 99% of you use them in practice. I want to enlighten you about three scaling strategies to expand your knowledge base.
In Cypress, cy.session is a command that caches and restores certain session data (like cookies, localStorage, and sessionStorage) between tests. This helps you maintain a consistent context between tests, ensuring that your tests are faster and more reliable by avoiding the need for redundant login steps or setup procedures.
Creating a Cypress project from scratch using TypeScript + Cucumber
I went with Cypress since it runs directly in the browser making it very fast and reliable, it is also very easy to install and configure as we will see and it provides a nice interactive runner that allows you to inspect elements and debug your test cases.
Visual Regresion Testing: Implementing Snapshot test on iOS
Implementing snapshot tests alongside regular unit tests is valuable because it addresses an often-overlooked aspect of testing: UI consistency.
Everyone who’s written a bit of code, knows we shouldn’t duplicate code. It’s like the opening session of day 2 of software school.
Building and improving Page Objects, one step at a time | Bas Dijkstra
As the tests were using Playwright in TypeScript, and were heavily oriented towards using the graphical user interface, we decided to start building a Page Object-based structure for a key component in their application. This component was a UI component that enabled an end user to create a report in the system.
Those pesky “non-functional” requirements
We talk about and plan testing for all the quality attributes that may be important in the context of our team’s products. These mostly fall into the right side of the quadrants, test activities that critique the product. That doesn’t mean teams won’t start testing for them even before the production code is written. For example, a team may do a spike, write throw-away code that is unsupported by tests. They may do this to run load tests against it and verify that the architecture scales appropriately for the expected number of users.
To paraphrase Ben Thompson, the #1 feature of any network is the people already on it. Accordingly, the power of any new protocol derives from its adoption (aka ecosystem), and it’s fair to say that MCP has captured enough critical mass and momentum right now that it is already the presumptive winner of the 2023-2025 “agent open standard” wars. At current pace, MCP will overtake OpenAPI in July.
Have you ever heard of Goodhart’s Law? British economist Charles Goodhart once stated: “When a measure becomes a target, it ceases to be a good measure.”
Посмотреть:
Integrate Playwright with Claude AI from Scratch | Full Setup & Demo ⏱️10 минут
A live demo of Claude using Playwright to navigate and generate test automation scripts.
Web 3.0: куда двигается IT ⏱️45 минут
В современном интернете существует проблема капитализма наблюдения, которая возникает из-за владения информацией большими корпорациями. Концептуально эту проблему можно решить с помощью Web 3.0. На основе блок-схем спикер рассказал, как построить архитектуру современного приложения с помощью блокчейна. Кроме того, он рассмотрел отличия от клиент-серверных приложений и показал, какие инструменты нужно изучить для тестирования и аудита.
Эпизод 3: Новые горизонты ⏱️45 минут
Захватывающее космическое путешествие в докладе «Эпизод 3: Новые горизонты». Мы отправляемся в далекую галактику тестирования, где все начиналось с первых контактов с «дроидами» — автотестами. Эти ранние «голографические» отчеты стали нашим окном в мир автоматизации, помогая установить связь между человеком и машиной. С течением времени мы столкнулись с новыми вызовами: объемы данных стремительно росли, и нам пришлось искать способы преодоления этих препятствий. Вместе мы исследуем, как «Сила» современных технологий и инноваций изменила наше представление о тестировании.
Готовим красиво между митингами ⏱️2 часа
Обсуждаем что такое “лего-подход” к готовке, и как один кусок тыквы превращается в три разных блюда; как сделать еду красивой, не используя трюфели и золото; как собрать удобную и рабочую кладовую, которая сэкономит деньги, время и нервные клетки; почему планеры питания не работают и как сделать, чтобы заработали; какой минимум посуды нужен, чтобы вы не бросили готовить через неделю. Этот выпуск для всех, кто хочет начать готовить вкусно, красиво и просто и готовить чаще, но тратить на это меньше сил.
⬅️ Предыдущий QA-дайджест — c 31 марта по 6 апреля
