#git
Git всемогущий

Нет времени объяснять. Вот 2 команды гита, которые сэкономили мне кучу времени:

git checkout -b имя_ветки

создаст новую ветку и переключит на неё

git checkout -

вернёт на предыдущую ветку (с учётом необходимости периодически переключаться между мастером и веткой это бесценно)

Если вас волнует и интересует git, жамкайте на хэштег, там много интересного.

Ленивый пентестинг или Как сделать приложение безопаснее, имея только веб, девтулзы и немного времени

Как появится запись выступления, обязательно принесу сюда, а пока, как обещала, делюсь презентацией.

Запись доклада "Ленивый пентестинг или Как сделать приложение безопаснее, имея только веб, девтулзы и немного времени"

Без лишних слов, как обещала: запись доклада про ленивый пентестинг. Презентация вот.

А вот тут вы сможете найти все доклады GigaConf 2024.

IT-пикник 17 августа

Если планируете завтра быть на IT-пикнике, приходите к стенду Ozon к 17:00, расскажу "Чем мы заняты, когда не пишем автотесты".
Инсайты на тему интересных задач и отсылки к What We Do in the Shadows гарантируются.

Приходите или смотрите в онлайне

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