В этой статье — без прикрас и маркетинговой мишуры. Жестко, честно и по фактам рассказываю, как устроены мошеннические курсы в тестировании (и не только), как вас обманывают, и на что стоит обращать внимание, чтобы не слить деньги впустую.

В статье разбираем современный подход к автоматизации тестирования — от требований до продакшена. Как писать автотесты ещё до выката фичи, запускать их в изоляции, работать в одной ветке с разработчиком и ловить баги раньше, чем они попадут на стенд. Реальные практики, понятные схемы и причины, почему "автоматизация после релиза" — путь в никуда.

Если загуглить «Бирюзовые компании в РФ», первые вкладки будут мало чем отличаться друг от друга по содержанию, в том числе и по списку компаний. Все дело в том, что такое словосочетание не то что в России, в мире возникло относительно недавно. Его предложил Фредерик Лалу в своей книге «Открывая организации будущего» в 2014 году, обобщив уже тогда имеющиеся кейсы «дебюрократизации» в менеджменте на западе. Это при том, что модный сегодня «тойотовский» Kanban на 10 лет старше полета на Луну.

Тем не менее, в России уже есть несколько крупных IT и не только компаний, строящихся как бирюзовых. В том или ином виде декларируются следующие принципы:

Началось все с того, что при проектировании своего устройства на микроконтроллере ATtiny 85, которое должно было работать от встроенного li‑ion аккумулятора, я изначально не задавался целью измерения заряда АКБ, поскольку в этом не было необходимости. Однако, собрав все устройство на печатной плате, я подумал над тем, почему бы не добавить такую возможность.

Прочитав в Интернете, как это можно было реализовать, стало ясно, что сделать это вряд ли удастся, поскольку все порты PB[0:5] уже были заняты и, следовательно, не было возможности применения АЦП с аналогового пина (при чем порт PB0 я не мог настроить на вход опорного напряжения AREF - он должен был использоваться как управляющий выход).

Долгое изучение состояния регистров АЦП в datasheet на ATTiny 85 привело меня к следующей идее: в качестве опорного напряжения может быть выбрано само напряжение питания VCC (биты REFS [0:2] регистра ADMUX установлены в 0), а в качестве измеряемого ‑ напряжение VBG с внутреннего стабилизатора в 1.1В (биты MUX [3:0] регистра ADMUX установлены соответственно в 1100). То есть, для измерения напряжения питания не нужно ничего, кроме, собственно, самого питания VCC!

Алгоритм сортировочной станции (Shunting Yard) был предложен Дейкстрой ещё в 1961 году и служит для преобразования математических выражений из привычной всем инфиксной записи (где операторы стоят между операндами, как в 1 + 2 * 3) в постфиксную (обратную польскую нотацию, 1 2 3 * +), удобную для дальнейшего вычисления. Однако есть один важный момент, который почти всегда упускается или замалчивается: алгоритм предполагает, что входное выражение уже синтаксически корректно.

Ни в Википедии, ни в большинстве обучающих статей вы не встретите слов о том, что выражения вроде + (1 2, 3 * 4 + ) или sin(+) должны вызывать ошибку. В лучшем случае они просто не вычисляются (что будет понятно лишь на этапе обработки в обратной польской записи), в худшем – дают бессмысленный результат. Алгоритм продолжает работать, даже если выражение изначально некорректно – и мало кто задумывается, почему это плохо.

Эта статья – попытка исправить эту несправедливую ситуацию, в которой мы не только реализуем алгоритм сортировочной станции «на максималках» с поддержкой констант, переменных, функций, унарных операторов, приоритетов и ассоциативности, но и добавим полноценную проверку корректности выражения по ходу разбора.

Мэтт Годболт, знаменитый разработчик Compiler Explorer — потрясающий человек, вам стоит найти в вебе и изучить весь созданный им контент. Именно этим и занимался, просматривая Correct by Construction: APIs That Are Easy to Use and Hard to Misuse. Я уже больше двадцати лет работаю с C/C++, поэтому эта тема была мне близка.

Когда я смотрел его доклад, ко мне постоянно приходила мысль: «Да! И именно поэтому в Rust это делается так». После просмотра видео я подумал, что этот доклад — отличный способ понять, как Rust помогает разработчикам не только в безопасности по памяти, и в своей статье я расскажу об этом.

Но прежде нам следует поговорить о поднятых Мэттом проблемах и о том, как он предлагает решать их в C++. Сделайте себе одолжение и посмотрите доклад целиком, а я разберу один из его пунктов.

Покрытие UI-тестами — вещь, о которой все говорят, но почти никто не измеряет. А если и измеряет, то по старинке, через Excel, TMS или на глаз. Это как считать шаги, не надевая шагомер.

ui-coverage-scenario-tool — это как шагомер, но для UI-тестов. Он показывает, с чем именно взаимодействуют ваши тесты, что осталось в тени, и главное — делает это автоматически. Без ручного труда, без вымышленных цифр, без «по ощущениям».

Это не очередной инструмент ради красивого дашборда. Это инструмент, который ставит зеркало перед вашим UI-покрытием — и показывает, есть ли там что-то, кроме отражения.

Как понять, что реально делают ваши UI автотесты?

ui-coverage-tool — это инновационный инструмент нового поколения, не имеющий аналогов. Он визуализирует покрытие прямо в браузере, работая с реальным приложением. История по каждому элементу, фильтры по действиям, динамика и полная наглядность — всё, чтобы не просто тестировать, а понимать и улучшать.

Разбираем, как писать масштабируемые и читаемые UI автотесты на Python с использованием паттернов PageObject, PageFactory и PageComponent. Разберем на атомы как устроены эти подходы, когда их применять и чем они отличаются. Всё это — на примере тестового проекта UI Course с CI/CD и наглядными отчетами в Allure.

Почему в вакансиях для джунов требуют 3 года опыта? Как неадекватные требования, массовые курсы и бюрократия убивают рынок найма? Личный опыт, наблюдения и немного сарказма о том, как не попасть в ловушку сомнительных вакансий.

Load-testing-hub: эволюция сервиса аналитики нагрузочного тестирования

Ранее я рассказывал о load-testing-hub, инструменте для аналитики и агрегации данных по нагрузочным тестам. Тогда он находился в стадии MVP, а теперь прошел значительные улучшения.

Что изменилось?

— Добавлено больше информации и гибкости в настройках.
— Расширены возможности сравнения результатов.
— Реализованы детальные графики и аналитика по методам.
— Оптимизирован процесс выявления аномалий в производительности сервисов.

Один из практических кейсов — поиск по банковским операциям среди сотен миллионов записей. Load-testing-hub помог протестировать производительность, выявить узкие места и оптимизировать решение.

Изменений настолько много, что проще рассказать о сервисе заново. В статье подробно разберу его новые возможности и кейсы использования.

Как провалить собеседование в IT? Легко!

Провел больше сотни интервью и заметил закономерности, из-за которых кандидаты получают отказы. В этой статье — субъективные, но проверенные советы для опытных специалистов, которые хотят проходить собесы легче. Даже если у вас "богатый" бэкграунд, вопросы к вашему опыту могут появиться внезапно и поставить в тупик. Делюсь наблюдениями, разбором типичных ошибок и рекомендациями, которые помогут взглянуть на процесс глазами собеседующего.

В этой статье разберём процесс написания API автотестов на Python, используя современные best practices. Кроме того, мы настроим их запуск в CI/CD с помощью GitHub Actions и сформируем Allure-отчёт с историей запусков. Цель статьи — не только показать, как писать качественные API автотесты, но и научить запускать их в CI/CD, получая удобные отчёты о результатах.

В этой статье я расскажу про swagger-coverage-tool — инструмент, который показывает, насколько полно ваши тесты покрывают API по спецификации Swagger (OpenAPI). Всё работает автоматически, без изменений в логике тестов. Поддерживаются httpx и requests, отчёт генерируется в один клик. Идеально, если вы хотите объективно видеть, что действительно проверяют ваши API автотесты.