Изменения

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

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

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

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

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

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

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

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

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

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

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

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

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

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