Этот дайджест создан совместно с телеграм-каналом QA Live ? тестирование ПО. Подпишитесь, чтобы получать дайджесты прямо в телеграм!
? Почитать:
Всего лишь одна строчка кода с ошибкой — и 60 тысяч человек оказались в XIX веке. Телефон молчит, аэропорты и отели закрыты, отменены 500 авиарейсов.
Какое соотношение dev/QA самое правильное? Это зависит от проекта: классический энтерпрайз-проект, эджайл-стартап, рисковый финтех или опенсорс.
Автор утверждает, что прокачанный скилл программирования «сыграл для меня большую роль и помог продвинуться в карьере. Не знаю, удалось ли бы мне так хорошо оптимизировать свои процессы, не умея программировать.»
Все-все-все собираются и тестируют новую функциональность, фиксят баги, usability issue, проблемы, вопросы и предложения.
Начинай сверху. Лучшие практики тестирования UI на фронтенде
Предлагается нестандартный подход к пирамиде тестирования на фронтенде: начинать тестирование с UI, и спускаться вниз, при обнаружении дефектов.
На других русскоязычных платформах:
Почти ничего не изменилось. Умеренный рост количества вакансий. Есть спрос на QA с опытом 1-3 года, 3-6 лет. Зарплаты джунов — «среднестатистические» по РФ.
В современных серверах устанавливается очень большой объем памяти. Иногда модули памяти ломаются и при ошибке сервер перезагружается. Если повезет, то умный системный контроллер подсветит неисправный модуль памяти, но может и не подсветить, тогда нужно искать, переустанавливая модули. Ситуация с перезагрузками сервера повторяется редко, но каждый раз это очень больно для бизнес-критичных приложений. Для диагностики модулей есть хорошая программа memtest86+, но если памяти у нас 1ТБ, то полное тестирование растягивается на несколько дней, а бизнес не может так долго ждать. Что делают в такой ситуации?
Речь идет об особой ОС «Нейтрино». Это защищенная операционная система реального времени, предназначена для отказоустойчивого и предсказуемого управления. Цель разработки — технологическая независимость, т.е. отсутствие зарубежного влияния на разработку и техническую поддержку. «Так как операционная система — очень обширное понятие и тестировать нужно много всего и сразу, для логического разделения используются модули и сабмодули. Тесты или пишутся с нуля, или портируются извне, в зависимости от конкретной задачи. Все тесты собираются с помощью рекурсивной сборочной системы.» Используется Jenkins.
Программный комплекс QUIK получает информацию из бирж и передает ее в систему брокера, в другом случае сам брокер идет в QUIK и получает биржевую информацию от него. Поскольку тестирование с полноценным QUIK проводить невозможно, мы сделали собственный эмулятор.
У нас в hh.ru более 370 микросвервисов. Классическая пирамида тестирования состоит из трех основных уровней: юнит-тесты, интеграционный слой, ui-тесты (e2e). Релизы сервисов проходят несколько раз в день. В вопросе интеграционных тестов было принято решение размещать их внутри сервиса отдельным модулем и запускать при очередных изменениях. При этом сами тесты проверяют эндпоинты тестируемого сервиса и иногда используют эндпоинты сервисов, которые с ним взаимодействуют. Для визуализации зависимостей между сервисами есть отдельная самописная утилита, показывающая связи и топологию, поэтому процесс определения смежных сервисов больших затруднений не вызывает. Но тут возникает следующий вопрос: как нам понять, все ли эндпоинты в сервисе проверяются и контролируют покрытие? Из этого вопроса выросла задача оценки тестового покрытия интеграционными тестами.
Спойлер: Соглашения о написании кода. Соглашения о разметке. Принцип DRY. Независимые тесты. Принцип единой ответственности. Ограничение количества проверок. Стратегия (правильных) локаторов. (Правильное) использование ожиданий. Объектная модель страницы. Скриншоты упавших шагов.
А было такое, когда снифаешь спокойно трафик через бесплатную версию Charles — а потом появляется окошко через час работы, и закрывает программу. А может видите, что переросли функционал. И хотите попробовать что-то новое. Или устали от грустного интерфейса «чайника».
Очень большой и подробный практикум.
Хотя уже есть немало статей, описывающих этот путь, я хочу поделиться с вами пятью шагами от ручного тестирования к веб-автоматизации, которые могут быть полезны другим QA. Что учить? 5 вещей: 1.Основное понимание веб‑приложений. 2.Элементы DOM и JS. 3.Механизм для связи рабочего стола и веб‑приложения. 4.Автотест-ранеры. 5.Паттерн объектов страницы (Page Object)
В мире QA на других платформах (англоязычных):
Большой подробный практикум.
Практикум с Mocking Authentication Flows, Handling Token-Based Authentication и пр. Примеры кода.
Следует уточнить, что «DoorDash — крупнейшая компания по доставке еды в США, занимающая 56% рынка. Соответствующая нагрузка. // «For testing, since it is impossible to do full regression testing in one week, says Sañudo, so-called component owners are responsible for testing all the components individually and tracking testing status using the mobile release management platform Runway. Each component owner has specific tests that they must run before approving the component. And every single component must be approved before the release can be submitted for review.
Автор пропагандирует активное совместное применение мутационного и стандартного («дифференциального») тестирования.
Абстрактные классы не могут быть инстанцированы напрямую, что создает проблемы при тестировании функциональности, реализованной в самом абстрактном классе. В этой статье я поделюсь своим подходом к решению этой проблемы.
«Одна из крупных компаний, из которой уволили 27 тыс. сотрудников, уже год не может закрыть 5,5 тысяч позиций миддлов и сеньоров».
«Даже если вы у себя в компании как-то научитесь использовать генеративный ИИ для создания кода — если вы сами не понимаете, что делает код, вы не никогда не будете уверены в нем. Оказалось, что это вообще не тот рынок, чтобы делать какие-либо реальные прогнозы.»
Еженедельное и ежедневное регрессионное тестирование. Охватываем критические пути, основные функции и сценарии. Активно применяем BDD.
Практикум по переходу от плохого старого к Vue2 к новому хорошему Vite+React. С примерами кода и дашбордами результатов.
Традиционно большой подробный практикум от ЛямбдаТест.
Testcontainers — открытая библиотека. Фреймворк с открытым исходным кодом абстрагирует API Docker, обеспечивая «практически нативную» работу с зависимостями из локального окружения.
Быстрое и, как утверждается, «фронтальное» тестирование доступности.
Вполне, утверждает автор, приводя множество примеров кода (в том числе сложных сценариев) и скринов.
Они делают акцент на правильной («идеальной») архитектуре, которая, собственно, и позволяет им достигать такого уровня.
С подробным описанием и примерами: Сложные зависимости. Увеличение времени выполнения тестов. Сложность обслуживания тестовых данных. Сложности с тест-дизайном. Невозможность полной изоляции тестов.
Простой базовый практикум для начинающих.
Достаточно подробно.
И возможных подходах, на которых мог бы быть построен подобный инструмент.
Блиц-практикум с кодом.
Автор исходит из того, что «… как широко известно, JMeter — изначально плохо оптимизированный инструмент». И предлагает свои небольшие (и судя по всему полезные) оптимизации.
? Посмотреть:
Дает советы и отвечает на вопросы.
- Сервис масштабирования Playwright-тестов от Microsoft (en) ⏱15 минут
«Рассказываем о новом сервисе Microsoft Playwright Testing, масштабируемом сервисе сквозного тестирования больших веб-приложений. Сотни тестов буквально за минуту.»
«Ядро нашей системы хранения данных, движок FrostFS, лежит в открытом доступе на гитхабе, поэтому мы тестируем два продукта с общим функционалом – публичный и коммерческий. В докладе Андрей рассказывает, как при таких условиях: Меньше дублировать код и автотесты, а также сохранять их читаемость; — Разделять и не показывать в паблике коммерческий функционал; — Гонять тесты в разных окружениях: докер, железный стенд, виртуальный стенд в облаке.» А также много других подробностей, интересных миддлам и сеньорам.
«В работе QA помимо технических скиллов очень важны софтскиллы, и умение поддерживать в том числе и качество коммуникации играет решающую роль. Однако, что происходит, когда переданное сообщение не равно принятому? Доклад исследует причины плохих ответов и как они могут быть связаны с неправильно заданными вопросами, важность контекста и как наши собственные предположения и убеждения могут влиять на нашу коммуникацию с коллегами. Вместе мы переосмыслим процесс коммуникации и узнаем, как задавать правильные вопросы для получения наиболее точных и полезных ответов.»
Хорошей недели!
