Этот дайджест создан совместно с телеграм-каналом QA Live ? тестирование ПО. Подпишитесь, чтобы получать дайджесты прямо в телеграм!
? Почитать:
Зарплаты, можно сказать, вполне себе среднеевропейские. Примерно как в промышленности. Никакой «айтишной исключительности» уже нет и в помине. А с учетом постоянного роста требований …

В небольшом гайде — часто задаваемые вопросы поведенческой части QA-интервью; и какими должны быть ответы (по методике STAR).

Каноничная скрам-команда состоит из разработчиков, скрам-мастера и владельца продукта. Стоп, а тестировщик?

TDD, BDD и ATDD — это не о предпочтении одной из этих методик, а о понимании, какое их сочетание лучше подходит для проекта и конкретных задач.

Серьезный гайд по интеграционному тестированию
Проблемы и паттерны, Docker, Vagrant и Testcontainers.

На других русскоязычных платформах:
«У меня 15 лет опыта в разработке, всегда так работали, и ты сможешь!» — подбодрил руководитель и отключился. А я призадумался.»
Автор сначала спросила у ChatGPT. Ответ был очень структурированным, правдоподобным и наукообразным, как всегда у ChatGPT, но мы же понимаем. Затем провела опрос у соответствующей аудитории. Результат: «В результате исследования я для себя сделала вывод, что нет какого-то стандарта относительно ролей руководителей QA.»
Кратко: ‘Непонимание концепции инструктивной речи. Неумение демонстрировать доказательства некорректной работы ПО. Путаница в показаниях при непонимании устройства системы. Акцент на второстепенном. Нежелание самостоятельно разбираться.»
Очередной хит Антона QAsmoke, соавтора Манифеста Профессионального IT-образования Manifestus.Pro. Пересказывать нет смысла, надо читать (плюс коменты). И делать выводы.
«Сейчас я Head of QA продуктов BI‑аналитики, ML и EPM Polymatica в компании SL Soft. Работал в разных командах величиной от 2-х до 20-ти человек как в коммерческих организациях, где не было документации, так и в серьезных государственных компаниях. Также довелось побывать единственным QA на проекте. Получил большой опыт: от тестирования баз данных, брокеров сообщений и различных интеграций до тестирования UX, производительности и написания сквозных автотестов. Начинал с позиции джуна, вырос до лида с собственной командой и своими процессами — сейчас являюсь servant leader отдела QA.»
«Данный регламент я написал на основании опыта работы лидом в IT компании с веб-приложением. Пункты из него прошли проверку практикой. Изначальные версии были (естественно) основаны на best practice из интернета, agile и опыта предыдущих и текущих руководителей. Стоит отметить, что я хоть и находился в какой-то момент в роли QA-лида, но не имею соответствующей подготовки, но имею много знакомых QA-инженеров и лидов. От себя рекомендую следующий алгоритм: копипаст, корректирование под свою специфику, практика использования. Важно обращать внимание на потребности разработчиков, ПМов, системных аналитиков и других участников команды, которые будут анализировать баги. Данный регламент не ориентируется на какую-то определенную систему трекинга задач. Использование возможно как для JIRA, Kaiten, GitLab, Trello, так и для excel-таблиц.»
«В своей книге «Методы тестирования программного обеспечения» Борис Бейзер описывает парадокс пестицидов. В контексте тестирования программного обеспечения — независимо от того, какой метод тестирования вы выберете, вы все равно пропустите более незаметных “вредителей”, то есть баги. Объяснение Бейзера заключается в том, что вредители больше не будут находиться в тех местах, где был применен пестицид; они будут только там, где его не применяли. Аналогия с тестированием заключается в том, что со временем все меньше и меньше ошибок будут находиться в тех частях кода, которые были тщательно протестированы, а ошибки, которые обнаружат пользователи, будут в областях, которые были протестированы менее тщательно. Как же с этим справиться? Расширить охват тестирования, добавив в свой процесс фаззинг.»
В мире QA на других платформах (англоязычных):
Если лень смотреть видеопрактикум целых 12 минут.

Сравнение архитектурных стилей, гибкости, производительности, и типичные юзкейсы.

Неплохой гайд для трейни. Но очень большой.
Практикум по настройке визуального тестирования в связке Github + Argos CI + Playwright.
Самая правильное соотношение: Features/QAs. А не Devs/QAs, это невозможно знать заранее и все зависит от проекта. Плюс PRISMA-подход (Product RISk MAnagement).
О соотношении Devs/QAs в разных проектах — отдельный материал на TestEngineer.
Рассуждения о любимой фразе лидов общепризнанного QA-авторитета.
Андрей Енин объясняет преимущества: 1. Наглядное подтверждение выполнения задачи. 2. Команда лучше синхронизируется. 3. Эти репорты пригодятся в будущем.
Не иссякает фантазия авторов Медиума.
Очень подробно обосновал (для девопсов).
‘В 2018 году Instagram случайно выпустил функцию, которая позволяла пользователям переходить между постами, проводя пальцем по горизонтали, а не по вертикали, как обычно. Хотя первоначально эта функция вызвала негатив, некоторые пользователи нашли новую навигацию интуитивно понятной и требовали сделать баг фичей.»
С примерами кода.
Небольшой «поддерживающий» практикум на Green Report.
Генерация юзкейсов из спецификаций.
Советы по промптам для тестеров + репозиторий готовых
Помимо этих — главный совет такой: вводить все промпты только и исключительно на английском. Пусть даже с ошибками — ИИ не обращает на это внимания. Потому то с русскими промптами ИИ галлюцинирует слишком уж часто, иногда до полной неработоспособности.
А здесь небольшой репозиторий готовых рабочих промптов.
? Посмотреть:
Обещают «non-flaky» assertions. Новый синтаксис тегов и аннотаций, благодаря которому можно использовать теги вне тайтлов и аннотировать пропущенные тесты. Также теперь можно стилизовать скриншоты с помощью stylePath. И новая экспериментальная функция Locator Handler, «позволяет избавиться от случайных наложений».
- Краткий обзор CI/CD-систем (en) ⏱20 минут
CI/CD это то, с чем вынужден работать уже даже стажер, не только джун. Так что…
- «Написал веб-приложение в ChatGPT за неделю» (Артем Русов) ⏱50 минут
«Я написал веб-приложение в ChatGPT за неделю, которое буду использовать для обучения других тестировщиков в реальной среде: frontend, backend и база данных. Все это без глубоких знаний программирования, но с бэкграундом в ручном тестировании приложении.»
- Валидация данных (форм/полей) на фронтенде и бэкенде (ProTestingInfo) ⏱45 минут
«Частый вопрос на собесе: А как понять, где ошибка на фронте или на бэке? Вот постараемся рассказать».
- Не все ошибки одинаково полезны (Heisenbug) ⏱45 минут
«Ввели невалидное значение в API – получили текст ошибки или необработанное исключение. Текст ошибки помогает пользователям ввести и отправить правильные значения, а QA проверяют это в автотестах.»
- QA — стеклянный потолок (нет) SQA Days ⏱40 минут
СРО в Test IT опровергает.
Хорошей недели!
