Еще обо мне…
Мои доклады
Мои статьи

В Санкт-Петербурге прошла SQAdays-34. Как всегда, хорошие доклады и много общения, тестировщики продолжают быть одним из самых активно общающихся сообществ. И вот несколько лет назад на конференциях было ощущения определенной стабилизации профессии. А сейчас его нет, есть атмосфера движения. Хотя, если смотреть по докладам - изменений немного. Может, это просто возрос поток молодежи, а может - изменения пока не проявились в докладах.

Из докладов я хочу отметить Вадима Лунина из белорусского Альфа-Банка про ИИ в тестировании: пока теоретики спорят, о том, что он может, а что не может, практики - используют. Кстати, на MergeConf неделю назад тоже был доклад от практиков из Газпромнефти - они создали ИИ-ассистента для поиска и найма сотрудников, и еще несколько. При этом методы аналогичные: берем GPT, над ним делаем систему, которая его правильно спрашивает о задачах, давая большой контекст информации, а потом - обрабатывает ответ. Модели GPT использовали разные, но стандартные, без доработки под задачу - они уже достаточно много знают, понимают и могут ответить, если правильно их спросить.

Еще хочу отметить Ольгу Ерину про SEMAT, Андрея Мясникова про чуткое отношение к признакам возможного выгорания и Алексея Петрова про индивидуальные планы развития, где была ссылка на заготовку матрицы компетенций для тестировщика (есть в конспекте).

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

Мой доклад Модели softskill - способ понимать людей и строить путь развития был дальнейшим развитием серии докладов, начатых на Teamlead-2019. Однако, доклад был существенно переработан: на него повлияло развитие серии по самоопределению, о котором я делал доклад [[Самоопределение: чего я хочу от жизни и работы (SQAdays-2023)|на прошлой SQAdays] и по инженерной модели личности, по которой вышла серия статей и готовится книга. Поэтому в докладе изменились представление взаимосвязей моделей, появились новые модели. А еще, по сравнению с Teamlead, существенно изменился фокус рассмотрения: там он был на использование моделей для работы с командой, что логично для конференции, а здесь, совместно с ПК, мы решили, что логичным будет использование моделей для качественной коммуникации и определения пути личного развития, продолжая этим тему самоопределения. Обсуждение после доклада продолжалось два слота и проходило на barcamp, поэтому, я надеюсь, от него тоже будет опубликована запись.

А тепепрь - про другие доклады.

Ольга Ерина из red_mad_robot. Техника SEMAT в управлении качеством ПО

У меня очень интересное впечатления от доклада. С одной стороны, было впечатление поверхностного изложения. Но в конце как раз получается, что SEMAT был использован именно так, как сейчас позиционируют авторы: как легкая система поверх существующих процессов, которая наводит фокус на продвижение по проекту. При том, что применять можно поверх любой методологии, и не только в профессиональной работе, но и для личных проектов.

Да, для тех, кто не в курсе, SEMAT - это название рабочей группы во главе с Иваром Якобсоном, которая начала делать эту конструкцию, а позднее они пришли под крышу OMG (Object Management Group), и более известен как OMG Essence или полностью The Essence of software engineering, есть книга Ивара, стандарт OMG и большая библиотека практик на сайте Ивара, доступная при регистрации.

В рассказе Ольга пробежалась по конструкции SEMAT - 7 альф, параллельное движение их по состояниям в ходе проекта, и интегральное измерение продвижения проекта в целом, исходя из каждой альфы. На слайдах были конкретные таблицы workflow, при чем не для программной системы целиком, а отдельно для тестировщиков, когда есть отдельная команда тестирования, которая, получается, делает автономный проект, включенный в более крупный, при том что спринты у них общие. Конструкцию с автономным тестированием рассматривают редко. И там отдельно был фокус на альфу технологий, которую разбирают редко.

Кроме того, были примеры применения SEMAT для личных проектов, причем в двух вариантах: небольшой локальный проект, например, сдачи для сертификатов, и к жизни в целом, где в качестве альф выбираешь направления колеса worklife balance. И это - интересно.

Что я бы полагал важным. Ольга советовала не рассматривать альфы, на которые нет влияния. Я бы полагал, что их тоже имеет смысл включать в рассмотрения. Дело в том, что исследования SEMAT выделили этот набор альф по принципу минимальной необходимости: провал по одной из них приводит к провалу проекта. И даже если у вас нет прямого влияния, вы будете видеть, где именно проект поджидают нежданчики. И, по принципу системного подхода, стоит смотреть альфы для системы и для ее надсистемы, в данном случае - для проекта в целом и для тестирования в проекте. А для жизни - смотреть на конкретный проект и на его включения в жизнь в целом. Что было, но явно не акцентировано и без показа связи.

Еще интересно, что хотя OMG Essence появился давно, и Ивар дважды приезжал на SECR в Россию, рассказывал про конструкцию, тема для участников - новая, и из зала было много вопросов. Я надеюсь, что это может привести к новой волне интереса. Я сам использовал ее в докладах примерно с 2015 года, можно посмотреть доклад Развитие управления проектами и критериев качества в ИТ (Максим Цепков на AgileDays-2015), статью OMG Essence и OKR — многофокусное ведение проектов и бизнеса в целом и другие материалы на моем сайте, включая конспекты докладов Ивара.

Андрей Мясников. Я люблю свою работу, я приду туда в субботу!

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

Начался с личной истории. Однажды проснулся и понял, что не хочет на работу. Позвонил начальнику, он разрешил не выходить. И еще день. Не на помогло. И начальник сказал: или выходишь на работу, или отпуск за свой счет. И он вышел и провел анализ ощущений: его удобный бардак на столе уборщица трансформирует в удобный ей, солнце отсвечивает в монитор после обеда, оттягиваешь взять задачу в работе. На следующий день вышел бодрячком, потому что увидел - это все мелочи, а значит их можно побороть: энергия приходит во время работы, поэтому просто действуй. И дальше - разные техники.

Типы задач. Тоже история от знакомого лида, пришел - говорит: сотрудник увядает, вроде все хорошо, но положил заявление со словами "все достало". А там классный лид, менеджер-зонтик: прикрывает команду, гнев начальства не долетает. Андрей спрашивает: а какой тип задач сотруднику нравится? Пришлось рассказать, что это.

У Андрея есть своя классификация, он рассказывал на SQAdays-13 (я нашел по конспекту https://mtsepkov.org/SQAdays-2013a):

• одноразовые: прогнал ПМИ, посетил конфу.
• итеративные, регулярные - чистить зубы,
• внезапные - прилетают вдруг.
• волшебные - они любимые.

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

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

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

Рефлексия проблем. Он это не сделал сразу и потерял несколько дней и душевное спокойствие. 5 почему и другие техники. Почему вчера было хорошо, а сегодня - не очень? Что изменилось? Как прошел денек? Если остался осадок - то от чего?

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

Найдите общее хобби с коллегами. Была коллега, с которой тяжело общаться, а потом узнал, что общая онлайн-игра. С ПМ - играть в шашки, и рабочие вопросы пошли лучше

Съешь лягушку. Сделайте самое плохое дело первым. Если вы пробежали несколько километров, хуже не будет.

Отдых - часть работы. Восстановление. 8-часовой рабочий день не просто так придуман. Если у вас выходной и вы вызываетесь помочь - не надо. Если инструмент затупился - его выбрасывают. Точите себя как инструмент, отдых - это такое время.

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

Екатерина Глушанина из 2ГИС. Как внутренние активности помогают расти и поддерживать бодрость духа

С моей точки зрения, этот доклад - очень хорошая иллюстрация того, как одни и те же события приводят к совершенно разным последствиям. У всех был ковид и переход на удаленку. У очень многих при этом появилось больше чатов, например, общий чат в дополнение к командным. Но вот то, что из общего чата, на основе анализа общения там, проросло много различных активностей: литклуб, докладо-клуб, митапы, мастер-классы - это исключение. Хотя, казалось бы: если люди задают вопросы, то обобщить и попробовать эти проблемы порешать - вполне понятная штука. Рассказ был как раз о том, как прорастали разные активности. Литклуб - из обсуждений книг, которые были на слуху, он хорошо стартовал, а потом общие книги кончились. Доклад-клуб - из обсуждения докладов на конференциях, они не кончаются. Типовые проблемы команд породили митапы по обмену опытом их решения. Мастер-классы - из проблем, по которым есть эксперты являются узким горлом. Пошло очень хорошо, и даже календарь оказался перенапряжен - они сделали опрос от чего отказаться, общее мнение было, что встречи полезны, но как урок - они начали делать регулярный дайджест, выявлять проблемные точки, и делать мероприятия только по реальным причинам. В целом - хорошо.

Дмитрий Щербаков из BelkaCar. За кулисами каршеринга: тестирование автомобилей

В докладе был рассказ, как устроено тестирование управлением автомобиля в каршеринге. Я лично услышал из доклада, что тестирование автомобиля ничем принципиально не отличается от тестирования другой работы с интеграции с оборудованием, которое, в свою очередь, близко к тестированию интеграции. Может, это субъективно. Тестирование работы с оборудованием я представляю, мы делали работу с оборудованием для розничным магазинов, там на кассе до пяти разных внешних устройств, с разными протоколами, а важно, чтобы все работало. А интеграция тоже похожа, особенно когда там внешняя система, которую иногда сложнее подключить в тестовом контуре, чем внешнее оборудование. И да, используем эмуляторы, иногда с обеих сторон.

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

Тестирование прошивки на машине занимает примерно день, за которые проходит около 300 проверок. При этом иногда проверяют несколько: один рулит, второй с ноута следит на автомобилем, а третий - за сервером. Это - особенность реального времени, но все эти части и для интеграции надо проходить. И оптимизация тестирования с эмуляторами автомобиля или ноутом вместо реального сервера эту финальный тест не отменяет, хотя и позволяет уменьшить их количество. Что интересно, они практически не обновляют прошивки в автомобилях. Потому что срок службы автомобиля относительно невелик, и целесообразно держать обратную совместимость со старыми версиями прошивок, а не обновлять с тестированием.

Наталья Савостюк. Как экологично влиять на изменение своего оклада?

У Натальи 90 человек в отделе, и большой опыт разбора ситуаций с окладами. На основе опыта - пять обобщенных персонажей, типичных представителей у которых есть проблемы с окладами. И особенности ситуаций с каждым.

1. Недооцененный. Мидл+, хорошо работает для своих задач. Не имеет целей развития, когда говорит - потому что так принято, плана развития нет, либо по нему не идет. Закрыт эмоционально, на разговорах 1:1 - все хорошо. А потом уходит, а в кулуарах оказывается, что он считает, что он недооценен, успехи не замечают. А вопрос: как замечать, если ты об этом не говорит.

У нее психологическое образование, она может раскрутить, но это много сил и она спец, у других - такого нет. Если руководитель через кулуарные разговоры узнает проблемы, зовет поговорить про план развития - а тот говорит "на работе времени нет, а потом - домашние дела." План развития договоренность, если сотрудник нарушает - почему руководитель должен стараться? Тут надо отметить, что обычно те, кто хотят развиваться - находят время. Мидл+ с высокой вероятностью сам достаточно свободен в распределении своего времени. Он его не выделяет, и обижается на компанию, что времени не дают.

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

2. Амбициозный. Junior+ поработал год-полтора, был интенсивный рост и оно породил завышенные ожидания. На собеседовании просит оклад в 1.5-2 раза текущего, и хочет повышение на 20-30% каждые полгода. Через 2-3 года человек приходит к тупику - такого темпа роста точно не будет. Тут контрольные вопросы: а что ты сделал за последнее время, что нового принес - если ответа нет - то какие основания? Часто ответы: "я ответственный, внимательный, развивающийся", но это же характеристика любого хорошего сотрудника, почему это стоит +20-30% в полгода? Амбициозный персонаж часто берется за много дел, но вот доводит до конца - мало.

3. Рисковый. Он сходил и принес офер, говорит что хочет остаться. Делают контрофер. Но дальше будет релиз - и его уволят. В процессе релиза бизнесу надо закрыть задачи. И работают на удержание. А вот после релиза есть фаза маркетинга, и раскрутки. Бизнес начинает экономить - и увольняет таких дорогих.

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

4. Сеньор. Ответственный, у него большой и относительно круг обязанностей, которые он хорошо выполняет. И тут могут быть сложности, если он хочет роста оклада и готов расширить круг ответственности: чем именно расширить, и получится ли это не в ущерб тому, что он выполняет, а если он одно возьмет, а другое перестанет делать - то не очень понятно, почему взятое должно больше стоить. Это предмет переговоров. В любом случае, новые обязанности надо брать на регулярной основе, расширяя круг ответственности, например, если онбординг - то не разово, а как зону ответственности, а если выступление, то опять-таки не разово, а стать регулярным спикером.

5. Матерый. Группа проектов или ресурс-менеджер. Сам может выстроить путь развития, найти пространство работы. Цели ставить не нужно. Но он тоже может столкнуться с проблемами по зарплате, и она связана с тем, что руководитель может просто выпустить закрытый им сектор из поля зрения, полагая что там стабильная регулярная работа, в то время как у сотрудника там реальный рост сложности решаемых задач и достижения. И тут ему надо уметь показывать свои достижения, и рост ценности для компании.

Подводя итоги, как действовать.

1. Сформулируйте ожидания: какой доклад хочу, когда я его хочу? Какой разрыв? Что я готов сделать ради этого?
2. Подумайте, насколько реалистична такая разница в заданный срок с учетом обстановки в стране, ИТ, вашей отрасли, вашей компании - может, надо менять? При этом у любой компании есть периоды сложностей и хорошие. Осознали - скорректируйте ожидания.
3. Сходите к руководителю и озвучьте спокойным текстом все, что обдумали. И обсудите - может что еще надо.

И замечания по проблемным кейсам.

• Надо понимать, что если был план, вы его игнорили, а в конце года начали делать - будут вопросы. Оклад - за изменения в работе, а вы просто доделали план, изменений не было. Разовая работа, например, конфа - премия. Чтобы оклад - можно стать амбассадором. Изменение - на постоянной основе. Не один онбординг, а обязанность.
• Есть кейс, когда тебя взяли на оклад с ожиданиями, ты не умел, наконец обучился - это не повод повышать, ты просто наконец-то делать то, для чего брали.
• Изучил новое, но ненужное для проекту - неясно, профита-то нет.

Подводя итоги: говорите о своих изменениях через ценности для бизнеса. Вы сами управляете жизнью. Нет правильных и неправильных цифр. Управляйте своим путем. И будьте довольны окладами.

В ответах на вопросы был разбор кейса, когда приходят дяденьки из бизнеса с якобы разовой задачей. А потом оно прилипает, ты не разговаривал, потому как разовое. Ответ Натальи: хотел бы такой оклад, за последний год стал делать вот это и получил ценность для бизнеса. Не копить обиду, а поговорить. И принять ответственность за то, что на входе не договаривался. Тут могут быть сложные переговоры, их надо уметь вести.

Еще вопрос: стоит ли удерживать? Ответ: есть много разных факторов, были преображения для любого персонажа. Для руководителя идеальная ситуация, когда сотрудники сами приходят и обсуждают. Но практически руководителю часто приходится брать обсуждение на себя. У нее в практике были кейсы, когда по результатам обсуждений остаются, в том числе на меньшие оклады, чем был офер.

Олег Королев и Анастасия Радужная из Ростелеком. Влияние QA сообществ на развитие ценностей в компании

Рассказ - success-story о запуске сообщества тестировщиков. Это - не первая попытка, но 1.5 года назад сообщество запустилось, и за это время были успешные проекты:

• единая методология
• единый базовый онбординг
• школа тестеров - для внешних, рост джунов и 3 месяца стажировки, ребята сами вызвались быть менторами: 280 заявок, 35 взяли, 22 дошли до финала, 10 человек на стажировки и их берут работать
• экспертная группа, готовая выступать на конференциях
• внутренние продукты - разработка в рамках импортозамещения инструментов для тестирования, сообщество дает фидбэк

К сожалению, в докладе не было анализа - почему сообщества не получалось раньше. Потому что рассказывали, в общем-то очевидные вещи: для сообщества нужны разные люди, которые готовы работать как двигатели при том, что формальных обязательств перед сообществом у них нет. Говорили, что если пробуешь сообщество ввести в формальные рамки, то воспринимается это как еще один кусок работы и отторгается. И тут возникает впечатление, что это - просто ламповый островок человеческих взаимоотношений в корпорации. Но вот истории говорят, что сообщество решает вполне рабочие задачи, и в рабочее время. Которые, наверное, почему-то не получалось в рамках рабочего процесса. Может быть, из-за его слишком большой организованности и формализованности, которая не дает пространства для инициативы. И тогда сообщество получается средством разморозки излишне жесткой корпоративной культуры. В общем, тут были бы интересен анализ.

В рассказе были понятные организационные моменты: надо формировать повестку встреч, фасилитировать их и делать резюме по итогам встречи. Но, что тут интересно, резюме выполняют роль информации о том, что происходит в сообществе и привлечения интересующихся. Вообще сообщество - двухуровневое, есть широкий круг, который участвует в общем чате и есть ядро, которое участвует во встречах, делает задачи.

QA - первое сообщество компании. Они катализировали появление сообществ - архитекторы, СУБД, Devops. Я тут хочу отметить, что в рамках компании воспроизводится ситуация с отрасли: сообщество тестировщиков было 10 лет назад одним из первых организовавшихся и самым активным, я это помню по истории конференции SQAdays.

Нэлля Сердюк и Алексей Алешин из Ростелеком ИТ. Продукт, который можно "пить"

Название - из метафоры очистки воды. А проект - про тестирование порталов видеонаблюдения за ЕГЭ и выборами. Но в рассказе специфики проекта не было, был рассказ про реорганизацию процесса и используемые практики. И я из их числа хочу отметить не очевидную реорганизацию: они откладывают описание тест-кейса до стабилизации задачи, а до этого работают по чек-листам. Это дает относительную легкость изменений и убирает фактор сроков - тест-кейс можно описать и после выкатки срочного функционала в прод, в режиме устранения тех.долга. При тестировании новой фичи чек-листа хватает, так как тестировщики в контексте: команда знакомится с задачей на груминге, и ее помнят, а вот при регрессе проверяют сделанное давно, и важно хорошее описание, чтобы регресс мог провести любой из тестировщиков. Это описание собирают на основе чек-листов и финальных комментариев тестировщика по каждому тестированию, которые тоже является обязательным для каждого такта тестирования и должен описывать - что было проверено с техникой. Груминг для знакомства с задачей был новой практикой, казалось бы, он дает накладные расходы, но реально он сокращает количество возвратов задач, когда ТЗ поняли неверно и делали не то. Я тут хочу заметить, что ненадежность передачи через артефакты из-за того, что тексты трактуют по-разному была осознана уже больше 20 лет назад, это - одна из предпосылок agile-методов, но те, кто создают процессы почему-то по-прежнему верят текстовым описаниям, практики коммуникации типа груминга появляются позднее и далеко не везде...

Алексей Петров, Одноклассники. Индивидуальные планы развития на базе матрицы компетенций

Цели индивидуального развития: рост знаний и компетенций, карьерный рост, рост финансового вознаграждения, увеличение вариативности развития. Но! куда расти?

Два пути: автоматизация тестирования и управление командой, еще в разработчика и смежные дисциплины. Это ограничивает. А реально путей больше: нагрузочное, мобильное, платформы, предметка (финтех или страховые) - вариаций много.

Средство для вариации - матрица компетенций. У Алексея есть заготовка, ее можно дополнять, и точно надо добавить знание компонентов вашего продукта.

В матрице ставим самооценку 0-3: 0 - ничего не слышал, 1 - что-то слышал, 2 - пользуюсь иногда с помощью других, 3 - пользуюсь регулярно. Это - самооценка, она не связана с зарплатой, обманываешь ты самого себя.

Калибрация самооценки. Руководителем, наставником или кем-то еще. Помните про эффект Даннинга-Крюгера: компетентные недооценивают, а некомпетентные переоценивают. При калибровке - не устраивайте экзамен. Вы - наставник, ментор, а не судья.

Дальше выберите области улучшений. Сотрудник - сам выбирает, не руководитель. И не обязательно от слабых областей, можно от сильных. Не выбирайте все, 3-6 на полгода - достаточно. А вот дальше руководитель сопоставляет выбранное с потребностями бизнеса - и тут обсуждаем.

Дальше был проект прокачки с конкретным примером. Формат:

• прокачиваемые компетенции,
• описание проекта,
• пользовательские сценарии,
• бизнес-ценность
• точки поэтапного контроля (вехи)
• DoD
• артефакт
• в какую цель бьет

Важно, чтобы сотрудник сам заполнял, в частности описывал бизнес-ценность, а не получал готовое от руководителя. Точки контроля и артефакты позволяют сотруднику вести самоконтроль.

В примере были цели - тест-дизайн, TMS, продуктовую компоненту, и проект включал разработку тест-кейсов для этой компоненты с использованием TMS. Реализуя проект мы приносим ценность для бизнеса - получаем больше тест-кейсов, и развиваем сотрудника.

Делаем 2-3 проекта, чтобы была вариативность, и по внешним связям, и по своему драйву.

Дальше plan-do-check-act - цикл Деминга. Если на промежуточных точках выясняется, что вы ничего не сделали - задайте вопрос, почему не пошли. 5 почему - может выбрали не то, может - другие причины, может стало не актуально. Корректируйте действия, при необходимости - меняйте план. Ситуация на проекте меняется, вы тоже узнаете о себе новое.

Профит:

• сотрудник понимает кто он и куда идет
• руководитель тоже понимает это про сотрудника
• есть цели на год и квартал - можно сопоставлять с ИПР
• обоснование роста зарплаты - связь косвенная, но она есть, нужно и сотруднику и руководителю. Но проекты - они разовые, поэтому рост зп - не автоматический

Объединяем матрицы и ИПР всех сотрудников - и видим компетенции команды в целом, взаимозаменяемость, узкие места и так далее.

ИПР сотрудников можно объединять, чтобы была взаимная зависимость и перекрестный контроль. Например, один хочет расширить написание тест-кейсов, а второй - навыки руководства, и тогда второму ставим задачу обеспечить работу первого.

Вопросы Алексею по докладу.

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

Вопрос. Есть тестировщик, который не хочет расти, ему нормально. Он написал ИПР, чтобы быть "как все". Поставил в пару, один зажигает, другой нет. Тут помогут ОКР: тебе может норм, бизнесу - нет. Можно сделать портрет идеального тестировщика вашего подразделения.

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

Связь с грейдами. Если вы самооценку связываете с грейдами - выше риск, что вы в самооценке обманываете себя. И там будет экзамен, контроль. Так что прямая завязка усложняет конструкцию.

Вадим Лунин и Вадим Зубович, Альфа-Банк (Беларусь). ИИ в тестировании: помощник, или угроза

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

Для начала - история. ИИ начал входить в тестирование для частных задач.

• Автомат результата автотестов - Report portal - анализировал причины падений
• Self healing automation - чтобы тестовые скрипты проходили. Helenium и еще несколько
• Автоматические анализаторы performance. Yslow, PageSpeed - рекомендации по ускорению
• Обнаружение визуальной регрессии - наложение текста и картинок.

Каждый из инструментов - узкий и изолированный, он не встраивается. Подход - от инструмента. Приходит идея - и делаем нейросеть.

Дальше все гиганты начали делать комплексные решения. Отдали спеку - она все сделает. Поскольку заменяем отдел тестировщиков, лицензия стоит как отдел - а результат сомнителен.

Но появились большие языковые модели - универсальные инструменты. И тут получается история, аналогичная тому, что было 7 лет назад: был комплексный TestComplete для корпоратов за большие деньги, появился Selenium и сообщество быстро сделало инструменты. Так будет и здесь.

По направлениям - есть еще IDE-ассистенты - автокомплит на стероидах, работает неплохо. Тут он бы выделил Tabnine: начинаешь писать название метода - он выдает реализацию. И работает без VPN.

У банка ограничения - надо уметь развернуть локально. Они выбрали Llama, Mistral, Zephir. И еще Вихрь - русифицированный Mistral.

Направления

• генерация тестовой документации
• ревью кода автотестов (и вообще всех кодов)
• фазз-тестирование

Идея - порождать тесткейсы по спекам. Для начала ui-тест, по flow для мобилки. Ни одна из моделей результата не дала. Порождали обобщенные сценарии, не понимали язык. Но появилась saiga - русифицированная Llama-3, ей скормили спеку, где картинки описали текстом - и получили приемлемый результат. Еще UI запилили, куда кидаем спеку, из нее промпт идет

Бэкэнд-тесты - они проще UI, картинок нет.

• Llame-2 что-то сгенерировала, но по-английски, и там не тестовый сценарий, а какой-то ответ. И не учтен весь пользовательский путь.
• Zephir - получилось получше, похоже на описание шагов, по английски. И дописал сценарии, которые в спеке нет
• Mistral - лучше всех, по-русски, опознал полный путь. Но с промптами пришлось поиграться серьезно.
• Развернули Вихрь - тоже хорошо.

Планы: проработать спеки для UI, и еще чтобы alure, API - проработать интеграцию с инструментами типа swagger

Код-ревью. Просто попробовали отдать порцию кода и pull request. Появился проект Alt-man review. дает pull request, пишет ответ комментарием в git. Но не взлетело - галлюцинации, неверный язык программирования

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

Фаззинг - шумовые данные, бомбардировка приложения чтобы найти утечки данных и крэши. Вышел OSS-fuzz от google - заточен на это, по задумке он сам все сделает. По факту - сам не может, тесты надо написать самим. oss-fuzz-gen - сморит коды и порождает, только для с++ - поэтому они пока не копали. И им им еще надо развернуть свой кластер, и обучить работать с их моделями GPT, а не с google. Это - в планах.

Сергей Атрощенков. Будущее 2040+: Тестирование в эпоху Трансгуманизма

Доклад предварял дисклеймер: это не позиция компании, а личное мнение.

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

Помимо этого в докладе была интересная вводная часть, где Сергей вспомнил прошлые тренды: тотальная автоматизация и отказ от ручного тестирования, API first, TestOPS-культура, тестирование в проде, краудсорс-тестирование. Предложил залу вспомнить те образы будущего, которые в связи с ними рисовали и соотнести с реальностью. По всем трендам реализация много скромнее прогнозов. По той же автоматизации тестирования, когда ковид в 2020 дале резкий импульс потребности в новом софте, тут же обнаружили, что автоматизация - дольше и дороже ручного тестирования.

Значит, можно ожидать, что с современнымии трендами - nocode автоматизация, self-healing инструменты, квантовые компьютеры, Security first, устойчивое тестирование (минимизация влияния на окружающую среду), Cloud-Native подход, shift-left testing - будет примерно так же.

А в конце была интересная схема, попытка совместить HADI-цикл проверки гипотез и цикл Колба обучения. В результате получилось 4 фазы, каждая из двух шагов: (Опыт -> Гипотеза) -> (Действие -> Рефлексия) -> (Данные -> Теория) -> (Выводы -> Эксперимент). Любопытно.

Руслан Остропольский. Тренды QA 2024

Слово "тренд" предполагает динамику изменения. И хорошо, если еще есть объяснения причин. Но уже давно аналитики этим не парятся, и под вывеской трендов публикуют просто срез статического состояния отрасли: сколько процентов используют agile, а сколько devops, сколько делают автоматизацию и так далее. Это я не про Руслана, это я про авторов отчетов. И чтобы не парится, они еще подвели под это теоретическую базы: объявили, что любой тренд развивается одинаково, нарисовали кривую Innovation model: innovators -> early adopters -> early majority -> later majority -> laggards с фиксированной привязкой процентов, так что, померив их, дескать можно понимать где сейчас тренд. А Руслан в своем докладе просто собрал несколько отчетов о трендах воедино. В презентации довольно много данных и есть ссылки, где выложены исходные материалы. Если вам интересно - смотрите. Пересказывать это содержательно - сложно.