QA ИНЖЕНЕРАМ-АВТОМАТИЗАТОРАМ И ВСЕМ-ВСЕМ-ВСЕМ!

Уже на текущей неделе (а именно 25–26 октября) команда Ozon Банка проводит Weekend Offer.

Ищем:
- QA Backend (Python)
- QA Frontend (TypeScript)
- QA 1C\Go
- SDET (Go+PostgreSQL)

Пишете на другом языке, но готовы перейти на наш стэк? Тоже приходите!

ЧТО ПОТРЕБУЕТСЯ

1.а. Поревьюить код, который мы специально для вас заботливо наполнили ошиками и антипаттернами (у меня решение заняло около часа, но я люблю всё 100 раз перепроверить)
или
1.б. Можно прислать ссылку на свой гитхаб с проектами

2. Пройти техническое интервью (всего одно!)

МИТАП

Для заполнивших форму мы подготовили закрытый митап с новыми (!) докладами про нашу внутрянку. Там же будет возможность познакомиться с лидами разных команд и позадавать им вопросы.

ПРО НАС

Уверена, что вы уже про нас слышали и/или пользуетесь нашими продуктами. Лучше и то, и другое)

Но если коротко, то мы делаем всё, чтобы новые фичи Банка релизились часто, хорошо протестированными и сразу с автотестами.

А если не коротко, то вот плейлист с нашими докладами (и тут далеко не всё).


До встречи на Weekend Offer!

"Мы перестали лазить в окна к любимым женщинам" и читатать State of the API Report, что очень зря.

Давайте для начала в общих чертах посмотрим на тренды. Если вам будет интересно, то после вернёмся к отдельным проблемам и тому, что они значат для QA-процессов и команд.

А между тем, по итогам 2024 года:

* значимость API продолжает расти (это снова про API-first, повышенные требования к качеству и дизайну API). Как следствие, ускоряется разработка API, ускоряется failure recovery (тут наверняка подтянутся и ожидания бизнеса);

* разрабатывать API по-прежнему сложно (проблемы всё те же: слабая коллаборация между командами, отсутствующая или противоречивая документация);

* настаёт время multiple-gateways (одновременно надо поддерживать разные типы API — private/partner/public/etc);

* API приносит всё больше прибыли (это продолжение тренда API as a product);

* AI-тулзы пришли в сферу разработки API ;

* безопасность — по-прежнему слабое место API (почти треть опрошенных не используют API Key Vault security tools).

Это я всё к чему?
- тестировать API становится сложнее, но потребность в качественном API растёт с каждым годом;
- разработка (в широком смысле) API приносит всё больше денег, то есть компании могут позволить себе платить за обеспечение качества, скорости и отказоустойчивости;
- у API много проблем, а значит и направлений для развития, в том числе в части QA.

Найти сам репорт и красивые графики в нём можно здесь.

В прошлом году про тренды апи мы с вами тоже вспоминали — тут.

Больше итогов 2024

Мы ещё вернёмся к API репорту, как к более интересному для QA, но тут подоспел 2024 Year in Review от Cloudflare, а они кое-что знают про эти ваши интернеты...

Итоги, которые показались мне наиболее полезными в быту в работе:
- около 50% всех запросов в 2024 использовали HTTP/2, 20.5% — HTTP/3 (незначительно отличается от 2023);
- 1/3 мобильного трафика приходила от Apple iOS. В 29 странах доля мобильного трафика от Android-устройств составила больше 90%;
- Go обогнал NodeJS как язык для автоматизированных запросов API, Python на почётном 3-ьем месте;
- Google Chrome всё ещё самый популярный браузер. Safari и Edge по-прежнему крайне популярны на своих родных девайсах;
- 41.3% трафика приходится на мобильные устройства. В примерно 100 странах/регионах бо́льшая часть трафика приходится на мобилки.

Вчитаться во все подробности можно тут.

Нет времени объяснять, стартует Route 256 для QA (middle) на Go и QA (middle) на Python!

Почему в Руте стоит поучаствовать, уже рассказывала здесь.

Чтобы попасть на курс, нужно пройти отборочный контест 26 января.
Регистрация туть до 23 января (!).

Обратите внимание, потребуется:
– владение Go (возможен переход с Java/C#/другого ЯП) или Python;
– минимум 2 года опыта в ручном тестировании;
– минимум 1 год в автотестах.

Курс длится 2 месяца, состоит из вебинаров, воркшопов и домашней работы. Лучшие студенты получают оффер в Ozon Tech.

Удачи!

5 ценных скиллов для обеспечения качества продукта

Это не то, что легко проверить на собеседовании или можно коротко описать в резюме.
Но часто именно эти навыки помогают инженеру достичь существенного повышения качества конечного продукта относительно небольшими трудозатратами.

Все выводы сделаны по результатам наблюдений за живыми людьми, реальными процессами и крутыми, но сложными продуктами.

Итак, что в моём списке крайне ценных навыков:

1. Умение использовать в работе инструменты observability.
Зачем? Чтобы не делать выводы на основании отрывочных данных или разовых проявлений проблемы.
Неплохая обзорная статья на тему лежит тут.

2. Big picture thinking/view. Способность посмотреть на систему/процесс в целом, не утопая в мелких деталях реализации. Не скажу лучше, чем "big-picture thinking involves being goal-oriented, rather than task-oriented".
Зачем? Позволит обнаружить критичные проблемы на максимально ранних этапах работы над проектом. Часто именно QA инженер обладает знаниями обо всех частях системы, в то время как разработчики отдельных частей могут быть раскоординированы (типичная история про то, что фронт не знает об изменениях на бэке).

3. Problem solving или навык решения вопросиков.
Зачем? Чтобы а) решать действительно критичные проблемы и не тратить время на незначительные неудобства б) находить первопричину проблемы и устранять её вместо бесконечных последствий.
Если у клуба проблем-солверов есть первое правило, то там точно что-то про "какую проблему мы решаем".

4. Инцидент менеджент. В случае наступления критической ситуации определить как минимум свой план действий и следовать ему.
Зачем? Чтобы не паниковать, когда "у вас баг в проде". Чтобы совершать минимум новых ошибок, устраняя последствия уже совершенных ошибок.
Вот тут занятно расписано.

5. Опыт анализа и выявления уязвимостей (и в целом навыки в области информационной безопасности).
Зачем? Чтобы совместить полезное с полезным, а именно: в ходе тестирования мы уже владеем достаточными знаниями о системе и инструментарием, чтобы выявить отдельные уязвимости, странно этим не воспользоваться.

Это я всё к чему?
Если вы искали (и не находили), в каком направлении можно прокачаться даже без смены проекта, то вот оно.
Если вы уже применяете вышеназванные навыки в работе, то моё почтение, и не принимайте это как должное.

Код, но не тот
или на что обратить внимание в вашем тестовом задании, пет-проекте или любом другом фрагменте кода

У меня нет цели пересказать вам SOLID, ООП, внушить что-то про чистый код и тд. Просто вот 5 довольно критичных недостатков, исправив которые, вы можете сделать свой код заметно лучше.
Написано по итогам проверки десятков тестовых заданий.

1. Поддерживаемость кода.
Часто можно встретить спагетти-код, который является решением вот этого (и только этого) конкретного задания и совсем не универсален. В таком случае его сложно переиспользовать и поддерживать, его сложно понять, что на реальном проекте станет существеной проблемой.
Иными словами, хорошо бы показать, что вы умеете писать код, с которым будет удобно работать и вам, и остальным в долгосрочной перспективе.

2. Нейминг.
Тут про нейминг файлов, тестов, функций и переменных. Наименования всех этих сущностей должны быть однозначными, понятными, конкретными и тд. С примерами об этом хорошо написано, например, тут.

3. Тестирование.
Если вам требуется написать тесты на функцию, точно не стоит пренебрегать тест-дизайном и особенностями вашего фреймворка тестирования.
Лучше сначала сформулировать интересующие вас проверки и только потом написать код.

4. Переусложнение.
Задайтесь вопросом, все ли методы и конструкции, использованные в вашем коде, действительно необходимы. Нельзя ли добиться ровно той же цели встроенными методами языка или, просто убрав лишний блок кода?

5. Документация к проекту, аннотации и понятность кода.
README с минимальным описанием проекта и его особенностей точно не повредит.
А что касается аннотаций методов и переменных, в том же Python у вас есть богатый арсенал средств для повышения читабельности кода -- неплохие примеры можно найти здесь.

Замечено, что в большинство из этих пунктов не умеет ИИ, но умеет человек, который понимает зачем и что он пишет в своём коде. Think about it

Что-то на лидском

Не буду утомлять вас нравоучениями и банальностями, которых уже слишком много в материалах про лидство, а просто поделюсь своим топом за последнее время:

1. Канал В IT чудес не бывает

2. Канал Yandex for Teamleads

3. Доклады с Teamlead Conf

4. Статья Развитие инженеров от Senior до Principal с точки зрения руководителя

И всё же… Старо как мир, но по-прежнему актуально: Евгений Кот про лидство и страдания

DevOps в каждый дом

Наверняка и ваш день не проходит без девопсов и их помощи. Чтобы чуть лучше понимать этих ребят, ловите анонс.

У конференции DevOops 3 сентября будет community day, то есть доклады этого дня будут доступны сразу и бесплатно, нужно только зарегистрироваться туть.

Очередная подборка "если вы случайно пропустили"

Почитать
🐍 исследование руководителей разработки

Каждый пятый руководитель разработки работает в финтехе

🐍 мартовское, но слишком интересное исследование обсервабилити от графаны: The state of observability in 2025

Organizations have been slower to take the leap into traces, which are often considered the third pillar of observability. Traces are critical for end-to-end visibility into today’s modern, distributed systems, so it’s encouraging to see more than half (57%) of all companies use them.

Потыкать и отпраздновать
🐍 релиз Python 3.14 (сейчас только и разговоров повсюду что о t-стрингах...)

Template strings are a new mechanism for custom string processing. They share the familiar syntax of f-strings but, unlike f-strings, return an object representing the static and interpolated parts of the string, instead of a simple

str

.

Скорость. Стабильность. Безопасность — в докладах Heisenbug 2025 Autumn, крупнейшей в России конференции по тестированию

📍 19–20 октября, Санкт-Петербург + онлайн-трансляция.

Вместе с другими участниками Программного комитета мы собрали программу из 30 выступлений. Вот что вас ждет:

«State of Testing 2025» — способ сверить свои практики с актуальными на рынке.

Нестандартные и редкие для QA-ивентов темы. От взлома и инлайн-тестирования железа на конвейере до тестирования лекарств и QA в геймдеве.

Инженерия — можно брать и внедрять. Среди тем: Test Impact Analysis «по-взрослому», test cases as code, Env-тесты для Kubernetes-операторов, борьба с flaky в Python/pytest.

QA ↔️ AppSec без стен. Доклады, где безопасность строится на артефактах QA: nuclei, IDOR-поиск из E2E-трафика и переосмысление DAST.

С промокодом Romanova2025PC персональный билет стоит на 25% дешевле.

Подробности и билеты

Реклама. ООО «Джуг Ру Груп». ИНН 7801341446