Этот дайджест создан совместно с телеграм-каналом QA Live | тестирование ПО. Подпишитесь, чтобы получать дайджесты прямо в телеграм!
Почитать:
Как ускорить разработку фронтенда сайта? Устранить “медленные” части на этапе разработки «код -> тест», где важнее всего быстрая обратная связь. Именно поэтому в каждом современном фреймворке есть режим «горячей замены модулей» для ускорения процесса компоновки; благодаря ему изменения в приложении мгновенно отображаются в браузере.
Рассмотрим параллельный запуск в TestING на симуляторах и эмуляторах, также и на реальных девайсах. Используется Java + TestNG.
— Как анализировать логи в DevTools Console, Postman, Fiddler, Charles Proxy;
— Какие команды помогут быстро найти ошибку в логах сервера;
— Как фильтровать логи с помощью grep, journalctl, ELK Stack;
— Какие ошибки тестировщик должен фиксировать и как их правильно описывать.
В пирамиде тестирования КТ стоит сразу после модульного. И если модульное тестирование это задача разработчиков, то компонентное тестирование это уже, якобы, зона ответственности тестировщиков — отсюда необходимость в этом разобраться.
Итак, unit-тест — это технический тест, а тест компонента — функциональный тест. Если рассуждать так, то вроде вполне логично, что за тесты компонентов должны отвечать тестировщики. Юрий Чернов в книге так и обозначает зоны ответственности. Но я с этим не согласен с точки зрения компетенций тестировщика. Модульное тестирование — это про изоляцию, а значит нужны либо замоканые данные, либо драйверы. Это нетривиальная задача для QA. Выше мы рассмотрели пример ближе к бэковой части, но ведь у фронтенд разработчиков тоже есть МТ, а значит есть и КТ. Тут выделять компоненты мне кажется чуть проще, ну чем вам какая-нибудь отдельная форма не компонент. А отдельное поле, вполне себе модуль. Но на сколько часто QA клепают какие-то тесты на уровне модульного тестирования? С проверками именно корректной работы формы, как отдельной сущности в контексте DOM веб страницы. Напоминаю, это уровень МТ, данные тут изолированы. Это не совсем те ui тесты, которые вы привыкли клепать на Cypress/Selenide.
Нередко тестировщики сталкиваются с ситуациями, когда стандартные методы и подходы оказываются недостаточно эффективными или когда временные и ресурсные ограничения не позволяют провести полноценное тестирование. В таких условиях на помощь приходят эвристики — практичные и быстрые способы принятия решений, основанные на опыте и интуиции.
Иногда приходится делать выбор не только в пользу одной утилиты. Например, мы используем две: Gatling и K6. Это позволяет закрыть 95% нужд наших команд по разработке скриптов нагрузочных тестов. Данные утилиты можно быстро расширять необходимой для нас функциональностью через разработку новых плагинов.
Не всегда следует слепо полагаться на то, что выбирает большинство, и там, где сообщество большое.
Будучи совсем малышариком (стажёром/джуном) я попал в относительно небольшую компанию, которая занималась автоматизацией налоговых и бухгалтерских процессов для среднего и малого бизнеса. Это был классный и разносторонний опыт: микросервисная архитектура, сложная бизнес логика приложений, задачи на тестирование фронта и бэка, автоматизация и много других активностей. Расстраивал только один факт — тестовая документация в google таблицах.
Почему то первая мысль, которая пришла в голову — ввести правило, встретил неактуальный тест во время тестирования — сразу исправь его. Да, зачастую опытные тестировщики помнят по памяти тест-рейсы и не открывают их при каждом прогоне, но тут другой вариант.
Если фича изменяется, ее необходимо тестировать, так же как и новые фичи. Вот если под новые фичи выделяется время на написание тест-кейсов, то для измененных фич нужно доп время на актуализацию тест кейсов.
Отличительной чертой инструмента Keploy является подход к захвату трафика и генерации тестовых примеров, позволяющий проводить сквозное тестирование, имитацию и генерацию тестов с минимальным вмешательством человека.
Когда приложение взаимодействует с API, Keploy записывает эти взаимодействия и преобразует их в повторяющиеся тестовые примеры. Это избавляет разработчиков и команды QA от необходимости создавать тестовые кейсы вручную, экономя время и силы.
Keploy автоматически генерирует утверждения на основе записанного трафика, гарантируя, что фактические ответы API соответствуют ожидаемым результатам. Эта функция обеспечивает надёжные механизмы проверки, помогающие разработчикам выявить любые отклонения или ошибки в поведении API.
В процессе работы нужно было работать со сторонними сайтами – в нашем случае это были VK, Telegram, Yandex Messenger, Whatsapp.
Кстати быстрый гайд по Xpath для новичков:
Весь процесс внедрения от идеи до запуска первого теста на проде занял у нас чуть меньше полутора месяцев. Первые 1,5 недели собирали гипотезы и описывали стабильное состояние системы. Следующие 4 недели три разработчика писали тесты, вспомогательные уведомления и отображения прохождений для них. Написали тесты отказа брокера Kafka и ноды Cassandra, смены мастера Redis, перезапуска подов приложения, деградации Cassandra и общей проверки инфраструктуры.
Можно использовать интеллект-карты для первичной визуализации требований, а затем экспортировать карты в другие форматы (например, PDF, HTML) для использования в документации, презентациях или в качестве основы для более детальной проработки в других инструментах для разработки (например, в Jira или Trello).
Но вот первый рабочий день, и внезапно выясняется, что большая часть вашего рабочего времени уйдёт на тестирование UI-форм. Да, именно такое тестирование, где большинство ваших знаний и навыков будут сидеть без дела. И это не шутка и не тест на прочность, это ваша новая рабочая реальность.
За первые две недели на проекте проверила качество функционала более 60 задач и составила около 500 тестов. Коллеги заваливали сообщениями о новых тасках, ожидающих проверки качества. Рабочее время увеличивалось до 16 часов в будний день. А окончание итерации (спринта) заставило смеяться смехом Джокера (Хоакин Феникс) — последняя таска оказалась медным тазом из-за её особенности — девелопер закомментировал блок кода, в который и входил весь протестированный мною функционал New CJM… Впоследствии разработка нового UI и микросервиса не тестировалась на предпродакшн среде и ушла в релиз в виде комментария.
Как говорит пословица: Ездят на тех, кто возит. Из-за низкой самооценки и небольшого опыта на вас было проще всего ездить, что менеджеры и делали.
Второй момент. Для тех, кто не умеет говорить “нет”, как автор статьи. Говорите: «Да, хорошо. Создай в Jira задачу и напиши там подробно, что тебе необходимо. Когда задача пройдёт все этапы согласования и будет назначена на меня, то я её обязательно посмотрю.»
В этом случае мы не говорим человеку прямое нет, а посылаем его по процессам, т.е. через внутреннюю бюрократию компании. Как итог, лишь 40% людей в реальности создадут для вас тикеты. Срочность задача тоже куда-то исчезнет, ведь ждать 3 дня согласований это норма в текущей компании. А торопить высокостоящих начальников менеджеры боятся, так что будут ждать сколько понадобится. Так что со временем вас станут больше ценить и перестанут на вас ездить. А олени, которые хотят протестировать функционал за 10 минут до релиза, будут его сами тестировать, т.к. сами просрали все сроки.
С чего мы начинали
Три года назад у нас была похожая ситуация: регресс и смоук нашего приложения занимали 3-4 дня, автотесты только зарождались, а вся команда QA была в районе 10 человек, 6 из которых были задействованы в релизном процессе. Релизы выпускались каждые 2 недели, ну и ещё иногда хотфиксы, куда же без них.
Итого на тот момент наши трудозатраты составляли по 9-12MD (человеко-дней) на каждую платформу (iOS/Android) или в среднем 21MD суммарно на всю команду. Запомним это число как точку отсчёта.
Примите как данность — тестировать визуальную составляющую придется на костылях
При тестировании нативных мобильных приложений часто возникает забавная, но очень важная проблема: невозможно определить, что кнопка действительно имеет нужный оттенок красного или что обводка элемента соответствует требованиям дизайна. Получить значение класса элемента или определенного атрибута здесь не получится, мир нативного приложения работает по своим правилам.
Освойте базовый инструмент для автотестов — Appium Inspector
Appium Inspector -один из ключевых инструмент, помогающий в написании автотестов. Это графическая среда, которая взаимодействует с мобильным приложением в режиме реального времени через Appium-сервер. В ней визуально представлена иерархия элементов приложения, их атрибутов и свойств, что делает процесс создания и отладки тестовых сценариев гораздо удобнее. По сути это аналог вкладки Elements, привычной для веб-тестировщиков.
Кстати, ознакомительный гайд по Inspector:
- ОБЩЕЕ КОЛИЧЕСТВО ДЕФЕКТОВ ПО ПРИОРИТЕТУ И СТАТУСУ
- ТЕХНИЧЕСКИЙ ДОЛГ ПО КАЧЕСТВУ
- ИНДЕКС СЕРЬЕЗНОСТИ ДЕФЕКТОВ (DEFECTS SEVERITY INDEX)
В большом мире QA (англоязычное):
Огромный обзор инструментов (Lambdatest).
+ практикум Lambdatest по Cypress.
Cypress automatically logs the commands you use in your tests, showing you what happens during test runs. However, when you create custom commands, Cypress only tells you when those commands are used, not what happens inside them. It can make it tough to figure out what’s going wrong if something doesn’t work. To solve this, you can add your own Cypress logs to custom commands.
You can have your cake and eat it, as long as you bake it carefully.
While integration tests are crucial for service quality, evolving them into “Service Tests” can address their limitations.
Component tests should be cheap to write without having to lean on snapshots (if they’re not you should strongly think about refactoring). In fact in the current AI climate, tools such as copilot mean you don’t even have to write them yourself! Theres no excuse.
There will be valid points raised from others that snapshots can pick up on subtle regressions in your DOM that your alternative tests might miss. But in my opinion they are a half hearted attempt of test coverage in this area. Contrasted to something like visual regression tests which test from the users perspective, they provide limited confidence and do more harm than good.
This blog post explores strategies like parameterized tests, feature logic handlers, subclassing, and leveraging pytest fixtures to optimize test execution and design for feature flags.
In one of my previous organizations, we used to inform in organization’s official group two weeks before the event, that we were organizing the event. It was open for all except the QA & PMs of the project. We usually start it on Friday evening and would close it on Monday evening.
There were 4 categories of issues reported by users — improvement, bugs, and rejected and need to be discussed.
All the improvements were forwarded to PM so that they could review and create a ticket for it, valid bugs were further categorized according to priority and severity, and then some were rejected which were not valid, lastly “needs to be discussed” which include the issues to be discussed with those people who raise.
There were points for improvements and valid bugs (in case of bugs, like critical bugs were given the highest point then so on. ). If any bugs of “Needs to be discussed” turn out to be valid bugs, it was also considered in points.
The prize was given as an Amazon gift voucher for the top 3 persons.
Prioritizing Verb-Driven Descriptions и подобное.
I speak, write and teach about the importance of testing your tests on a regular basis, so it makes sense to start walking the talk and get more insight into the quality of the RestAssured.Net test suite. One approach to learning more about the quality of your tests is through a technique called mutation testing.
With the latest 1.50 Playwright release, there was a really nice feature that was released that will help speed up test automation api requests. The feature is found on the Playwright Trace Viewer which is found in Playwright UI mode or the HTML test report.
Timeouts are one of the vital parts of UI end-to-end testing. When testing user interfaces, we often need to deal with various forms of randomness (or apparent randomness) in how elements appear and interact.
WebdriverIO handles this by having commands that run in a loop, trying to locate elements or make assertions until they either succeed or eventually fail.
Посмотреть:
- Поиграть в игру != протестировать игру ⏱️45 минут
Многие считают, что тестировщик игр — это благо и лучшая работа на свете: играешь в игру, а тебе за это еще и деньги платят, особенно когда работаешь с такими компаниями, как Electronic Arts, Square Enix и другими. Однако реальность намного более сурова. Речь в докладе будет о настоящих активностях Game QA! Зачем тестировать Game Design документацию и инструменты? Как тестировать объемные игровые уровни (стадии Level Design и Level Art)? Какие подходы помогут сократить время тестирования в разы (чит-коды, создание gym-комнат и т. д.)?
A typical day for a junior tester involves reviewing requirements, creating and executing test cases based on those requirements, identifying and reporting bugs, collaborating with developers to fix issues, and performing regression testing to ensure fixes don’t introduce new problems; common QA responsibilities include thorough documentation of test cases, defect tracking, analyzing test results, and communicating findings to the team to maintain software quality.
Дэбби Брайан, руководитель проекта. We’ll cover the latest news, community highlights, exciting projects, and answer your questions.
Хорошей недели!
