Я — Максим Цепков приветствую Вас на своем сайте
|
Я буду рад любым комментариям и обсуждениям. Авторизация для этого через регистрацию на сайте или OpenID. При желании, вы можете размещать здесь свои материалы по тематике сайта. MaksWiki содержит 623 статей. | |
|
Что нового
Коммуникация при различной структуре мышления - таксономия против фолксономии – СМД Process and Case Management - совмещай и властвуй! Действуй опираясь на ценности - Спиральная динамика и бирюзовые организации | |
|
Последний пост блога В Санкт-Петербурге прошла 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. Матерый. Группа проектов или ресурс-менеджер. Сам может выстроить путь развития, найти пространство работы. Цели ставить не нужно. Но он тоже может столкнуться с проблемами по зарплате, и она связана с тем, что руководитель может просто выпустить закрытый им сектор из поля зрения, полагая что там стабильная регулярная работа, в то время как у сотрудника там реальный рост сложности решаемых задач и достижения. И тут ему надо уметь показывать свои достижения, и рост ценности для компании. Подводя итоги, как действовать.
И замечания по проблемным кейсам.
Подводя итоги: говорите о своих изменениях через ценности для бизнеса. Вы сами управляете жизнью. Нет правильных и неправильных цифр. Управляйте своим путем. И будьте довольны окладами. В ответах на вопросы был разбор кейса, когда приходят дяденьки из бизнеса с якобы разовой задачей. А потом оно прилипает, ты не разговаривал, потому как разовое. Ответ Натальи: хотел бы такой оклад, за последний год стал делать вот это и получил ценность для бизнеса. Не копить обиду, а поговорить. И принять ответственность за то, что на входе не договаривался. Тут могут быть сложные переговоры, их надо уметь вести. Еще вопрос: стоит ли удерживать? Ответ: есть много разных факторов, были преображения для любого персонажа. Для руководителя идеальная ситуация, когда сотрудники сами приходят и обсуждают. Но практически руководителю часто приходится брать обсуждение на себя. У нее в практике были кейсы, когда по результатам обсуждений остаются, в том числе на меньшие оклады, чем был офер. Олег Королев и Анастасия Радужная из Ростелеком. Влияние QA сообществ на развитие ценностей в компанииРассказ - success-story о запуске сообщества тестировщиков. Это - не первая попытка, но 1.5 года назад сообщество запустилось, и за это время были успешные проекты:
К сожалению, в докладе не было анализа - почему сообщества не получалось раньше. Потому что рассказывали, в общем-то очевидные вещи: для сообщества нужны разные люди, которые готовы работать как двигатели при том, что формальных обязательств перед сообществом у них нет. Говорили, что если пробуешь сообщество ввести в формальные рамки, то воспринимается это как еще один кусок работы и отторгается. И тут возникает впечатление, что это - просто ламповый островок человеческих взаимоотношений в корпорации. Но вот истории говорят, что сообщество решает вполне рабочие задачи, и в рабочее время. Которые, наверное, почему-то не получалось в рамках рабочего процесса. Может быть, из-за его слишком большой организованности и формализованности, которая не дает пространства для инициативы. И тогда сообщество получается средством разморозки излишне жесткой корпоративной культуры. В общем, тут были бы интересен анализ. В рассказе были понятные организационные моменты: надо формировать повестку встреч, фасилитировать их и делать резюме по итогам встречи. Но, что тут интересно, резюме выполняют роль информации о том, что происходит в сообществе и привлечения интересующихся. Вообще сообщество - двухуровневое, есть широкий круг, который участвует в общем чате и есть ядро, которое участвует во встречах, делает задачи. QA - первое сообщество компании. Они катализировали появление сообществ - архитекторы, СУБД, Devops. Я тут хочу отметить, что в рамках компании воспроизводится ситуация с отрасли: сообщество тестировщиков было 10 лет назад одним из первых организовавшихся и самым активным, я это помню по истории конференции SQAdays. Нэлля Сердюк и Алексей Алешин из Ростелеком ИТ. Продукт, который можно "пить"Название - из метафоры очистки воды. А проект - про тестирование порталов видеонаблюдения за ЕГЭ и выборами. Но в рассказе специфики проекта не было, был рассказ про реорганизацию процесса и используемые практики. И я из их числа хочу отметить не очевидную реорганизацию: они откладывают описание тест-кейса до стабилизации задачи, а до этого работают по чек-листам. Это дает относительную легкость изменений и убирает фактор сроков - тест-кейс можно описать и после выкатки срочного функционала в прод, в режиме устранения тех.долга. При тестировании новой фичи чек-листа хватает, так как тестировщики в контексте: команда знакомится с задачей на груминге, и ее помнят, а вот при регрессе проверяют сделанное давно, и важно хорошее описание, чтобы регресс мог провести любой из тестировщиков. Это описание собирают на основе чек-листов и финальных комментариев тестировщика по каждому тестированию, которые тоже является обязательным для каждого такта тестирования и должен описывать - что было проверено с техникой. Груминг для знакомства с задачей был новой практикой, казалось бы, он дает накладные расходы, но реально он сокращает количество возвратов задач, когда ТЗ поняли неверно и делали не то. Я тут хочу заметить, что ненадежность передачи через артефакты из-за того, что тексты трактуют по-разному была осознана уже больше 20 лет назад, это - одна из предпосылок agile-методов, но те, кто создают процессы почему-то по-прежнему верят текстовым описаниям, практики коммуникации типа груминга появляются позднее и далеко не везде... Алексей Петров, Одноклассники. Индивидуальные планы развития на базе матрицы компетенцийЦели индивидуального развития: рост знаний и компетенций, карьерный рост, рост финансового вознаграждения, увеличение вариативности развития. Но! куда расти? Два пути: автоматизация тестирования и управление командой, еще в разработчика и смежные дисциплины. Это ограничивает. А реально путей больше: нагрузочное, мобильное, платформы, предметка (финтех или страховые) - вариаций много. Средство для вариации - матрица компетенций. У Алексея есть заготовка, ее можно дополнять, и точно надо добавить знание компонентов вашего продукта. В матрице ставим самооценку 0-3: 0 - ничего не слышал, 1 - что-то слышал, 2 - пользуюсь иногда с помощью других, 3 - пользуюсь регулярно. Это - самооценка, она не связана с зарплатой, обманываешь ты самого себя. Калибрация самооценки. Руководителем, наставником или кем-то еще. Помните про эффект Даннинга-Крюгера: компетентные недооценивают, а некомпетентные переоценивают. При калибровке - не устраивайте экзамен. Вы - наставник, ментор, а не судья. Дальше выберите области улучшений. Сотрудник - сам выбирает, не руководитель. И не обязательно от слабых областей, можно от сильных. Не выбирайте все, 3-6 на полгода - достаточно. А вот дальше руководитель сопоставляет выбранное с потребностями бизнеса - и тут обсуждаем. Дальше был проект прокачки с конкретным примером. Формат:
Важно, чтобы сотрудник сам заполнял, в частности описывал бизнес-ценность, а не получал готовое от руководителя. Точки контроля и артефакты позволяют сотруднику вести самоконтроль. В примере были цели - тест-дизайн, TMS, продуктовую компоненту, и проект включал разработку тест-кейсов для этой компоненты с использованием TMS. Реализуя проект мы приносим ценность для бизнеса - получаем больше тест-кейсов, и развиваем сотрудника. Делаем 2-3 проекта, чтобы была вариативность, и по внешним связям, и по своему драйву. Дальше plan-do-check-act - цикл Деминга. Если на промежуточных точках выясняется, что вы ничего не сделали - задайте вопрос, почему не пошли. 5 почему - может выбрали не то, может - другие причины, может стало не актуально. Корректируйте действия, при необходимости - меняйте план. Ситуация на проекте меняется, вы тоже узнаете о себе новое. Профит:
Объединяем матрицы и ИПР всех сотрудников - и видим компетенции команды в целом, взаимозаменяемость, узкие места и так далее. ИПР сотрудников можно объединять, чтобы была взаимная зависимость и перекрестный контроль. Например, один хочет расширить написание тест-кейсов, а второй - навыки руководства, и тогда второму ставим задачу обеспечить работу первого. Вопросы Алексею по докладу. Вопрос. Что делать, если все в команде хотят стать менеджерами? Или все хотят в автоматизацию, которой нет? При независимых консультациях можно предложить сменить место работы, внутри так не получится. Всегда выбираем релевантных, они могут стать замами. А остальных подруливаем в полезном направлении. Например, компетенция проведения собеседований, или каких-то коммуникаций: это полезно для управления, но может применяться и автономно. Вопрос. Есть тестировщик, который не хочет расти, ему нормально. Он написал ИПР, чтобы быть "как все". Поставил в пару, один зажигает, другой нет. Тут помогут ОКР: тебе может норм, бизнесу - нет. Можно сделать портрет идеального тестировщика вашего подразделения. Вопрос: надо ли вбирать свободно, или ограничить меню потребностями компании. Ответ: всегда двунаправленное движение, нужно дать поле выбора. Но для джунов, стажеров есть смысл подсказать. Связь с грейдами. Если вы самооценку связываете с грейдами - выше риск, что вы в самооценке обманываете себя. И там будет экзамен, контроль. Так что прямая завязка усложняет конструкцию. Вадим Лунин и Вадим Зубович, Альфа-Банк (Беларусь). ИИ в тестировании: помощник, или угрозаИИ уверенно переходит из фазы "посмотрим, что он может" в фазу "сделаем помощника и будем использовать". На Merge я неделю назад Газпромнефть рассказывал, как собрал ИИ-помощника для работы с вакансиями и подбор персонала, закрывающего полный цикл. А тут был рассказ об использовании ИИ для тестирования. Для начала - история. ИИ начал входить в тестирование для частных задач.
Каждый из инструментов - узкий и изолированный, он не встраивается. Подход - от инструмента. Приходит идея - и делаем нейросеть. Дальше все гиганты начали делать комплексные решения. Отдали спеку - она все сделает. Поскольку заменяем отдел тестировщиков, лицензия стоит как отдел - а результат сомнителен. Но появились большие языковые модели - универсальные инструменты. И тут получается история, аналогичная тому, что было 7 лет назад: был комплексный TestComplete для корпоратов за большие деньги, появился Selenium и сообщество быстро сделало инструменты. Так будет и здесь. По направлениям - есть еще IDE-ассистенты - автокомплит на стероидах, работает неплохо. Тут он бы выделил Tabnine: начинаешь писать название метода - он выдает реализацию. И работает без VPN. У банка ограничения - надо уметь развернуть локально. Они выбрали Llama, Mistral, Zephir. И еще Вихрь - русифицированный Mistral. Направления
Идея - порождать тесткейсы по спекам. Для начала ui-тест, по flow для мобилки. Ни одна из моделей результата не дала. Порождали обобщенные сценарии, не понимали язык. Но появилась saiga - русифицированная Llama-3, ей скормили спеку, где картинки описали текстом - и получили приемлемый результат. Еще UI запилили, куда кидаем спеку, из нее промпт идет Бэкэнд-тесты - они проще UI, картинок нет.
Планы: проработать спеки для 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 с фиксированной привязкой процентов, так что, померив их, дескать можно понимать где сейчас тренд. А Руслан в своем докладе просто собрал несколько отчетов о трендах воедино. В презентации довольно много данных и есть ссылки, где выложены исходные материалы. Если вам интересно - смотрите. Пересказывать это содержательно - сложно. |
Я в сети http://www.facebook.com/mtsepkov http://www.linkedin.com/in/mtsepkov http://www.slideshare.net/mtsepkov/ e_mail M.Tsepkov@custis.ru
|
|
Обо мне Моя основная работа — проектирование корпоративных и банковских систем. Я верю, что автоматизация открывает новые возможности развития, поэтому создавая ИТ-системы мы открываем путь прогрессу и делаем мир лучше. Я делаю это, работая главным архитектором дирекции развития решений компании CUSTIS. Я верю в эффективность командной работы и профессиональных сообществ, и в развитие организаций и всего человечества на новых ценностных уровнях. Я вхожу в программные комитеты конференций SECR и AnalystDays, и открыт к общению с коллегами по ИТ на различных площадках и в соц.сетях. А еще я люблю путешествовать, об этом и о других идеях вне профессиональной деятельности я пишу в своем ЖЖ. |
Блоги друзей |
