2018-10-07: COMAQA — конференция минского сообщества тестировщиков

Из ленты: MaksWiki — Блог:Максима Цепкова [ru]

Съездил в Минск на осеннюю конференцию COMAQA минского сообщества тестировщиков. Два дня, в пятницу — мастер-классы, в субботу — сама конференция, я был только в субботу. Оплата за каждый из дней — отдельная, день мастер-классов 6000 рублей (200 белорусских), а за конференцию 4500 (150 белорусских). И это — за позднюю регистрацию. Если сравнивать с ранней регистрацией на SQAdays дешевле в полтора раза, а вот если с поздней — то в три раза за два дня.

При этом доклады — достаточно хорошие. Конференцию организует Антон Семенченко, и он ищет докладчиков, а еще — тренирует молодых и растущих ребят, коорые с ним работают, делать совместные доклады. Вот и получается наплохо. Идет три параллельных потока, можно выбрать интересное. Идет запись, она выкладывается через пару месяцев, на сайте можно посмотреть прошлые записи. На конференции было 100+ учатников, и, что интересно — с достаточно широкой географией. Помимо Минска и Белоруссии — хорошо представлены Москва и Питер, хотя, казалось бы, в них проходят и крупные конференции, и собственные встречи сообществ тестировщиков несколько раз в год. Участники из Киева и Украины. Участники из российских регионов — быстро вспоминаю Рязань и Ростов-на-Дону, возможно, были и из других регионов.

В целом надо отметить, что виден устойчивый тренд развития таких небольших конференций, не только в тех регионах, куда «не доезжают» крупные конференции, такие как SQAdays или AnalystDays, но и в тех городах, где такие конференции проходят. COMAQA проходит с 2014 года, с 2016 — дважды в год в Минске, в прошлом году начали проводить в областных центрах и в Петербурге, и не только по тестированию, есть линейка конференций по C++ corehard.by, и в Питере они участвовали совместно. А питерское сообщество аналитиков год назад организовало свою конференцию Точка сборки, которая уже третий раз собирает сильно больше 100 человек и развивается, и тоже бюджетная по стоимости (2500-3500 за день в зависимости от времени регистрации). Лично мне такое развитие разнообразных конференций очень нравится, потмоу что предоставляют IT-шникам много разных возможностей для своего развития.

Большое спасибо Антону за то, что позвал на конференцию!

Мои доклады

Я выступал на конференции с двумя докладами Роли в команде — модель Белбина и Как строить свой профессиональный путь — схемы самоопределения в QA-контексте. Они — не новые, и, казалось бы, можно посмотреть записи. Но, с другой стороны, у участников конференции они вызвали явный отклик, и побудили дальше интересоваться этими и другими темами, и донесли, думаю, главную мысль: для человека и социальных системам тоже есть модели, и их можно использовать так же, как мы используем архитектурные модели для софта. Доклад про самоопределение был еще и пересобран к конференции — логику изложения я взял с весенней TeamLeadConf, а примеры — для аудитории тестировщиков.

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

Заметки с докладов

Я, естественно, не только рассказывал, но и слушал чужие доклады, и публиковал заметки в ходе конференции. Собираю их вместе.

Пост на FB Алиса Бойко (Alla Ambrazhevich). Программисты считают себя гениальными. Индия и ты — два разных полюса. Но вот в отделе тестирования видно, насколько Индия близка к тебе :)

А в целом про IT-отделы средних компаний. Потому что заказчик — не где-то далеко, он рядом, и всегда знает, что и как надо. Аутсорс-компании стараются процессы строить и выдерживать. В inhouse оно не так. И особенно про тестирование всегда забывают.

Особенно интересно, когда приходишь на вакансию, где просят построить процесс тестирования. Вроде они это хотят. Но! реально система-то сложилась, стремиться к гомеостазу и это надо менять. Надо искать точки соприкосновения, вписываться…

И описано окружение — вертикаль, конкуренция, первая проверка любых твоих инициатив на то, не пытаешься ли ты с их помощью получить кусочек власти…

Пост на FB Anton Semenchenko и Вадим Зубович. Продажа автоматизации — переводим аргументы в плоскость бизнеса. Но доводить до конца, «ручного тестирования станет меньше» — недостаточно: «И что, у них будет больше кофе-пауз? А платить буду столько же, да еще и на кофе больше будет уходить?» Надо довести до быстрой выкатки релизов и других профитов.

Пост на FB Alexei Vinogradov автоматизация тестирования UI. Live coding на примере CRUD операций в таблице контактов в публичном сервисе. Фишка именно в live coding, в ходе которого разные полезные приемы. Например, первый шаг наполнения метода для теста — это пройти интерфейс вручную и записать шаги в виде комментариев в теле метода, а потом наполнять кодом. assume — сообщения-лога о том, какие шаги прошли, а не только про ошибки. Из нетривиального — асинхронность, после создания контакта — надо проверить, что он появился в таблице. Мы вводим в поле поиска, он работает асинхронно. Как различить ситуацию ошибки теста, когда новый контакт не создали от ситуации, когда поиск еще не успел отработать. В общем случае, решения не существует, вернее, нужны точки, когда ты вмешиваешься в код, а они не всегда есть. Sleep — плохо, но на реальном тесте он не везде смог избавиться. И так далее. В конце — код на github полного примера, можно посмотреть, попробовать запустить, попробовать доработать…

Пост на FB Запомню формулировку. Теоретизирование — обоснование сомнительных вещей, в которые веришь интуитивно. Вадим Винник.

А в целом доклад был через проверку правильности программ через наложение предусловий и пост-условий на данные. И сопутствующие механизмы, такие как инварианты классов.

Источник