Помоги отловить техтренды тестирования и проверь актуальность своего стека

😀 Организаторы Heisenbug, JUG Ru Group, запустили TechRadar — исследование тенденций российского IT-рынка. Помоги составить актуальную картину индустрии с точки зрения тестирования — расскажи о своих рабочих инструментах в опросе.

😀 Результаты исследования представят на осеннем Heisenbug 2025, а затем опубликуют в открытом доступе.

😀 Участие займет не больше 30 минут, но польза для QA-сообщества огромная!

🎁 Среди участников опроса разыграют 5 офлайн- и 10 онлайн-билетов на любые конференции JUG Ru Group по выбору победителей.

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

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

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

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

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

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

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

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

Очередная подборка "если вы случайно пропустили"
(пока меня завалило работкой, давайте хоть так)

Посмотреть
📎 опубликованы вапще все доклады Heisenbug 2024 Autumn
📎 выпуск Подкаста на кухне про развитие в ИТ компании
📎 доклад Анны Куреновой с SafeCode "Посторонним вход воспрещен: ошибки аутентификации и авторизации"

Почитать
📎 Плагины для IDE для сканирование кода на предмет безопасности
📎Питонистам: Не позволяйте словарям портить ваш код
📎Снова про гит для самых маленьких

Потыкать
📎 Очередная игра для изучения SQL -- SQL Noir

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

Посмотреть
📎 Data Quality: что за зверь и как обучиться - Тоня Безгина
📎 Все доклады про информационную безопасность с Heisenbug 2024 Autumn

Почитать
📎 Тестирование больших данных: руководство для начинающих
📎 (уникальная) Дока про безопасность Chromium extensions
📎 (для способных кекать) Болезнь «ООП головного мозга»
📎 Как работают хэш-функции
📎 Прямое и обратное геокодирование – тестирование популярных решений
📎 The State of Python 2024

Потыкать
📎 flpc (rust-based regex for Python)

Традиционная рекомендация: Podlodka QA Crew: с 24 по 28 февраля сезон про Quality Gates!

Расскажут про то:
▶️Как выстраивать Quality Gates на всех этапах разработки
▶️К чему приводит жизнь без QG и как избежать хаоса
▶️Где провести черту между «релизить» и «тестировать»?
▶️Как DoR и DoD помогают команде говорить на одном языке

Спикеры из Точки, Островка, Яндекса, Devexperts и других компаний поделятся реальными кейсами.

Формат, как всегда, удобный: утренние и вечерние сессии, минимум теории, максимум практики.

Не пропустите: https://podlodka.io/qacrew (с промокодом short_qa13 билет ещё выгоднее)

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

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