2023-12-07: SQAdays-33 - качественные доклады и хорошая атмосфера

Короткая ссылка: SQAdays-2023b

Ссылки сюда (3) →

О других конференциях

Впечатления от SQAdays-33, на которой я был в конце ноября, уже смазаны следующими конференциями: Highload и Teamlead. Однако, я помню что на SQAdays, как обычно, была очень качественная атмосфера, много общения и качественные доклады. Собственно, именно атмосферой мне более 10 лет назад понравился SQAdays, и меня очень радует что она по-прежнему хороша. Это не только мое мнение, я слышал и отзывы других участников. А вау-докладом конференции был доклад Алексея Пименова о работе с противодействием изменений. Он, кстати, был признан лучшим докладом конференции. А меня впечатлило хорошее сочетание в одном докладе довольно широкого теоретического изложения и практических приемов, я тоже так хочу и буду стараться.

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

А теперь - про другие доклады. Начну я с доклада Алексея Пименова, а дальше пойду по порядку.

Алексей Пименов. Я предлагаю - они отказываются!

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

Распространенная реакция на предложение нового - отказ, ответ "нам будет неудобно", или тихий саботаж или итальянская забастовка. Есть методология Prosci (prosci.com) для работы с сопротивлением, там разные причины систематизированы, есть очень большой справочник и методики работы. Однако, можно поднять уровень рассмотрения.

Питер Сенге писал: "люди любят изменения, люди не любят меняться самим. И если понять как мыслят люди - можно увидеть природу сопротивления. Для этого Алексей опирается на модель Канемана Думай медленно, решай быстро, Канеман выделил в мозгу две системы: быстрых решений и реакций, которую навал Система-1 и медленных размышлений, которую навал Система-2.

Система-1 обучается многократным повторением, на личном опыте, поэтому обучается медленно, зато реагирует быстро и не энергозатратна. Система-1 работает при процессах, которые выполняются автоматически: при вождении автомобиля, у боксеров в бою, а достигается это повторением, но для мыслительных процессов эти механизмы тоже работают, мы можем отвечать или писать код тоже на автомате.

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

Как сказал Леша, Канеман за свои исследования получил нобелевку, потом эти системы попробовали приземлить на механизмы работы мозга, это получилось не слишком хорошо, в результате вся теория сейчас под сомнением. Но она практична, поэтому ее стоит использовать. Я тут хочу дать развернутый комментарий, потому что сейчас готовлю доклад про по модель личности на Teamlead и детально разбираюсь с вопросами работы мозга. Дело в том, что когда модель Канемана приземляли на модель работы мозга, то использовали триединую модель Маклина, система-1 была локализована в рептильном мозге и лимбической системе, а система-2 - в неокортексе. С тех пор Маклин умер, а его модель объявили ненаучной. Но вся критика, которую я читал, сводится к нескольким пунктам (1) эти части мозга работают совместно, (2) модель - большое упрощение, а реально все устроено сложнее. Но про независимость Маклин не утверждал, не даром модель триединая, это уже упрощающие интерпретации типа "укроти своего внутреннего зверя", а то, что сложнее, так любая модель - упрощение, покажи, где она не работает, предложи альтернативу - а альтернатив не предлагают. При этом нейрохирурги продолжают эту модель использовать, и, более того, сами психологи продолжают использовать анатомические модели мозга на зоны следующего уровня детальности, то есть получается, что части - есть, а против агрегатов - возражают. В целом сама критика несет отчетливый отпечаток социальных, а не научных аспектов.

Если говорить в позитиве, то и модель Маклина - вполне рабочая модель, если рассматривать ее как выделение логических уровней, подобно к тому, как мы выделяем логические уровни приложения (фронт-бэк-БД), при этом каждый уровень не просто обрабатывает запросы другого, а имеет собственные активные процессы, обращающиеся к другим. Схемы работы мозга, которые получаются на их основы, вполне совместимы с современными моделями работы мозга. Если интересует - я готов обсуждать подробнее. И модель Канемана тоже рабочая, она - функциональная, описываемые ей эффекты есть, а уж как она локализована в мозгу - вопрос отдельный, не следует путать функциональное и модельное деление системы, они отличаются. Когда нейрофизиологи предложат иную локализацию систем Канемана и уточнят их - будем ей пользоваться.

И отдельное замечание про энергозатратность. Нейрон - это клетка, и как клетка он обладает постоянным потреблением АТФ, описываемое циклом Кребса, вариации в пределах 5%, тепловые карты возбуждения мозга показывают именно такие вариации. Но вот для взаимодействия с другими нейронами, размышления ему нужен дофамин, ресурс которого ограничен и в лимбической системе есть регулятор, направляющий его в части, управляющие движением, если ситуация предполагает, что организму придется драться или убегать, то есть в стрессе, или в неокортекс для спокойных размышлений. А так мозг не устает. Разработчик "устал" писать код и пошле "отдыхать" в Warcraft - мыслительных ресурсов эта игра требует не меньше, а иногда - больше. Просто система подкрепления перестала воспринимать написание кода как полезную деятельность и выдавать дофамин под нее.

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

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

Как это работает с изменениями? Вы приходите в команду, готовите логичные аргументы, рассчитываете на систему-2 - а они влетают в систему-1 и получаете фабрику гнилых отмазок. Почему? Любые новые роли атакуют идентичность человека. "Некогда объяснять, ты scrum-мастер" - а он PM, он знает кто оно такой, перспективы и так далее - много вопросов. Новая ответственность атакует чувство собственного достоинства и так далее. Люди чувствуют, что получат гораздо меньше, чем потеряют. Есть люди, которые за любой кипеж кроме голодовки - их 15-20% они всегда за. А остальные - видят проблемы и угрозы и консервативны.

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

Принцип дзю-до: не спорим, а присоединяемся и ведем. "Так не работает, мы делали" - присоединяемся "да, не работает, я тоже пробовал, давай обсудим как у вас не работало и у меня, подумаем можно ли что сделать". Обсуждение переводит в логику, и потом уже выводим на конструктив. Когда проектируете изменения - попробуйте предсказать аргументы и понять, как будете присоединиться.

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

Дальше - ответы на вопросы.

Вопрос. Если команда против и выходит в саботаж, что делать? Ответ - можно, но другим инструментом. В лекции инструмент из психологии, а есть еще социология. Надо разобраться с кланом саботажников, и как-то убедить их присоединиться. Для этого ответить на вопрос - как вы соотноситесь с кланом саботажников? Вы вместе, или отдельно? Если вместе - то рассмотреть риски. Если отдельно - есть способ понижения социальной значимости группы возражающих. Объединившись - вы защищаете безопасность социальной группы и повышаете значимость. Если вы офигенные - нет стимула к развитию, важно удержать статус-кво, и изгонять лидера, который хочет изменения. "Вы все профи, но вместе - говно, потому что результат не поставляете". Нельзя, чтобы вас сделали общим врагом: не они против вас, а вы вместе борете агрессивное окружение, не PVP (player versus player) , а PVE (player versus environment). При этом важно снизить значимость племени, не снижая значимость индивида, со снижением значимости индивида начинается треш.

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

Вопрос. Я рядовой участник команды изменений, но рядовой. Как работать, если опытный человек говорит "это не будет работать". Ответ: ты присоединяешься "давайте обсудим почему".

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

Вопрос. Есть системные администраторы на площадках "я не буду делать - не знаю", хотя на собеседованиях показывали. А другие - сидят в кабинеты и не выходят в поле. Что делать? Ответ: дело в авторитете руководителя, как его поднимать, если технических скилов недостаточно. Лайфхак: собрать группу, и сказать "такая задача - ваши предложения". У него есть игра: 3 стикера, довольная, нейтральная, недовольная. Выигрышная стратегия: хорошие расхватали, потом даешь недовольную, не доволен - какие предложения, и так далее - требуешь договариваться. Чтобы не выходить впозицию "я начальник - ты дурак", а это - не перспективно.

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

Марина Тарасова из SimbirSoft: Индивидуальный план развития

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

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

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

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

Планы развития всегда включают soft skill, а не только hard. Не должно быть много: 1-2 hard + 1 soft. Откуда брать: из задач проекта, существующих проблем и потребностей улучшения, обратная связь от команды, будущие задачи - тренды и бизнес-цели проекта, опыт других, карьерное консультирование. Цели встраивают личное развитие в развитие проекта.

Развитие soft skill можно делать через доп.активности на проекте: демо, ретро, лидство (наставничество, кураторство), ревью и внепроектные активности - митапы, конференции, статьи.

Вопросы-помощники: зачем, хватает ли навыков для выполнения задачи, какие проблемы есть на проекте, какие задачи интересны?

После целей: декомпозиция цели на задачи - как с user story, критерии успеха и сроки и контролируем процесс.

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

Цикл контроля общий: Цель - План и параметры - Мониторинг в точках контроля - Коррекция по результатам мониторинга.

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

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

Про мотивацию есть книга Светлана Иванова "Мотивация на 100% - где у нее кнопка". Преподнесение информации - идеальна. Я, правда, тут хочу предостеречь: есть другая книга Шпренгер "Мифы мотивации", где автор разбирает все известные схемы мотивации и показывает, что они ведут к деградации в долгую. Книга - старая, но я критикуемые методы видел и в свежих, люди работают в короткую. Так что полезно самим соотнести перед применением.

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

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

Виталий Старостин из ПСБ. В чём измеряются инженеры по тестированию

Хороший доклад о том, как мониторинг сам по себе улучшает ситуацию, потому что проблемы становятся явными. У них количество людей сильно возросло, и они решили ввести метрики, чтобы понимать, кто и что делает, работы нет или ее не видно, опасения, что метрики покажут не адекватную картину, понятное отношение сотрудников, которые не хотят чтобы их мерили, потому что и так работают хорошо. И они решили двигаться, не смотря на опасения. В презентации был чек-лист идеальной метрики и полный набор метрик, который они используют. И подробно раздирались метрики для ручного регресса, который является дорогим процессом - 27 тестировщиков + капитан + команда разработки 3.5 дня на первую итерацию. Тест кейсы распределялись по тестировщикам автоматически равномерно по оценке трудоемкости, дальше тестировщики их выполняли, если кто-то не успевал - товарищи ему помогали, а выполнение тест-кейсов фиксировалось. Метрики позволили увидеть, кто именно из тестировщиков столкнулся с наибольшими проблемами и дальше поговорить, чтобы эти проблемы увидеть и решить. Из интересного: выяснилось, что алгоритм распределения тест-кейсов реально распределяет их неравномерно, выявились тест-кейсы с неверной оценкой, увидели, что процесс актуализации тест-кейса не работает, а он - дорогой. В целом был получен результат, время первой итерации сократилось в 1.5 раза, с 28 до 19 часов, и дальше это было стабильно. Они продолжают работать по выявленным проблемам. А потом будет следующий такт.

Таисия Толстунова и Елена Коренева из VK Tech. Преодоление трудностей кросс-продуктового тестирования: подходы, лайфхаки и инструменты

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

Для координации:

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

А дальше следующий уровень, различие ценностей, процессов и ожиданий.

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

Казалось бы, все понятно, но далеко не всегда это делают и это - боль. Это было видно по реакции зала.

Иван Железков и Алексей Кожин из ПСБ. В стране невыученных уроков, или как создавалась школа тестирования ПСБ

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

1. Надо найти заказчика, который заинтересован в специалистах и скажет, кто и сколько нужен.
2. Как будем обучать? Внутренняя экспертиза, ее распространяем на студентов - готовим для себя. Выбрать экспертов
3. Опишите роль - кто должен получиться.
4. Разработайте контент.
5. Запустите обучение.

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

Весь набор знаний разбит на микрокурсы, каждый из 4 этапов.

1. . Первичная оценка и передача знаний
2. Создание рабочего артефакта
3. peer2peer - студенты обмениваются артефактами и снимают ошибки друг у друга
4. Оценка экспертами результата

Этап peer2peer оказался очень ценным, студенты снимают большое количество ошибок, и еще закрепляют знания, что сильно разгруает экспертов на следующем этапе.

По результатам микрокурсов и оценке артефактов получается розочка компетенций: тест-дизайн, чек-листы и так далее.

Результаты:

• частичное решение проблемы подбора через обучения молодых - джун+, подтверждено
• снижение текучки - эксперты смогли проявить себя по-другому
• сокращение затрат на обучение за счет привлечения внутренних экспертов

В презентации было два ценных слайда: (1) фреймворк разработки, который применяет банк, со всеми артефактами и другими подробностями (2) розочка компетенций тестировщика, которая получается по результатам обучения.

Анастасия Золотых из 2GIS. Тестирование на лету: новый подход к визуальному тестированию

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

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

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

Эмиль Барлыбаев из Doubletapp. На старт... Внимание... Нагружаем!

Короткий рассказ про организацию нагрузочного тестирования. Потому что важно не просто дать нагрузку - надо дать разную нагрузку для определения разных характеристик. Для начала надо понять, какие запросы будут давать основную нагрузку, обычно они составляют малое количество функционала, и тестировать надо именно их, а не по площади. Далее даем нагрузку и делим три зоны: слабую, когда потребляемые ресурсы постоянны, а время отклика около нуля и не растет, основную, в которой ресурсы растут линейно и рост времени отклика примерно линеен по нагрузки, и стрессовую, когда мы постепенно приближаемся к максимуму нагрузки. В целом у нас - образная кривая, и эти зоны - ее деление. В примере пределом было 100 rps, слабая дона 0-40, рабочая 40-80 и стрессовая от 80. Дальше сравниваем вычисленную нагрузку с ожидаемой. Если ожидаемая ниже - то можно сокращать ресурсы. Если больше - нужно масштабирование, горизонтальное (больше нод) или вертикальная (мощность ноды). И делаем три вида тестов: под рабочей нагрузкой проверяем стабильность работы, стрессовое для проверки работоспособности под большой нагрузкой и долгое (8+ часов) тестирование под низкой нагрузкой, чтобы увидеть, что ресурсы сервиса не текут. Еще нужно тестирование всплеска, обычно есть события, когда ожидается всплеск нагрузки, вплоть до перегрузки, и надо проверить, что когда оно проходит, сервис возвращается к рабочим параметрам. Помимо этого нужно тестирование объема, что накопление данных не повышает время отклика. И в конце доклада - оформление отчета и рекомендации lzk начинающего, но это - стандартно.

Анфиса Лаврова. Проектирование процесса тестирования по проблемам

Любопытный доклад об успешном сокращении регресса от 6 недель до 2, а далее до одной, с уменьшением числа занятых тестировщиков с 5 до 3, то есть трудоемкость уменьшилась в 10 раз. Что важно - были разобраны неверные шаги, которые предприняли сначала. А также показано применение различных методов - организации процессов, анализ причин на простых примерах. Так что в целом - успех. А сами неверные шаги служат хорошей иллюстрацией того, как применение стереотипных ответов может оказаться неверным в конкретной ситуации.

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

Есть два способа проектирования процессов: от целей, например "уменьшить трудоемкость регресса", или от проблем "долгий регресс" Проектирование от целей начинается с модели to be и применяется для новых процессов, а также при существенных изменениях условий и ресурсов для существующих, а проектирование от проблем - с анализа as is и применяется для улучшения существующих процессов.

Теперь про регресс. Исторически регресс включал 5000+ кейсов, которые вручную прогоняли на 3 платформах с различными базами данных, на которых работал продукт. И это требовало 6 недель при команде тестирования в 5 человек. Это было долго и трудоемко. Когда Анфиса пришла как руководитель отдела, то перед ней была поставлена задача сокращения времени регресса. Вторую задачу, которую она видела, было увеличение мотивации самих тестировщиков. Но оценив задачи по степени влияния, она решила сфокусироваться на регрессе. Идея о том, что регресс можно ускорить, увеличив мотивацию, в докладе рассмотрена не была, по-видимому, было очевидно, что объем работ носит объективный характер, и если его делать быстрее - просто увеличится число ошибок.

Очевидное решение - автоматизация. Теестировщики в команде умели писать код, и попробовали писать автотесты. Эксперимент был 2 спринта, и в конце собрали статистику: за это время разработано 50 новых тест-кейсов, а автоматизировали всего 20 тест-кейсов. Процесс явно не сходится. Кроме того, выполнение этих тест-кейсов - не более часа, а на разработку потратили 6 человеко-недель, то есть срок окупаемости получается большой, 250 прогонов. Впрочем, для этого анализа надо было отделить построение инфраструктуры автотестов, которое явно было внутри, и посмотреть динамику с учетом обучения. Но в целом было видно, что метод при нынешних ресурсах команды - не перспективный.

Вторая попытка - увеличить ресурсы. Временно добавили тестировщика из соседней команды, это 20% мощности. Регресс сделали быстрее на 10% - 5.5 недель. Но суммарная трудоемкость при этом увеличилась на 10%, 30 -> 33, что логично. Я отмечу, что результат - предсказуем.

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

Кроме того, продукт состоит из модулей, новые фичи трогают не все модули, и, хотя вероятность затронуть соседние модули существует, она не слишком велика. Поэтому тест-кейсы разделили по приоритетам в зависимости от важности проверяемого функционала, и для тех модулей, которые не менялись в релизе, решили прогонять только приоритетные тест-кейсы. Наконец, часть функционала продукта клиентами не используется, и для него тоже проверяют только приоритетные тест-кейсы. В результате регресс сократили до 2 недель с 6, в три раза, а потом еще до 1 недели и его делают 3 тестировщика вместо 5. Остальных не уволили, они занялись автоматизацией и другими вопросами. При этом качество релизов не ухудшилось.

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

Андрей Бровко из Авито. Оценка рисков в разрезе модели качества продукта

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

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

Уровень риска: вероятность * влияние, оцениваем по трем градациям низкий-средний-высокий по каждой оси. Для программы надо описать требуемый профиль риска, стандартного нет, и это понятно: для медицинских программ одни требования, для информационных сайтов - другие, для систем, от которых зависит исполнение бизнес-процесса - третьи и так далее.

Схема планирования тестирования с учетом рисков из стандарта, на ней много блоков, в простом случае часть из них становятся тривиальными, но где именно - зависит от проекта. Фазы: определить контекст -> организовать разработку плана тестирования -> определить и изучить риски -> определить подходы к обработке рисков -> разрабатываем стратегию тестирования (ресурсы и инструменты) -> определить персонал и график -> оформить план -> согласовать план.

Виды риска:

• риск проекта: персонал, поставщики, организация, лицензии, техника
• Риск продукта - опыт пользователя: функциональность, ошибки и та далее.

Параметры для оценки риска продукта ISO 25010, оценка качества системы: Функциональность, Производительность, Совместимость, Удобство использования, Сопровождаемость, Надежность, защищенность, Переносимость. В стандарте идет детализация, но практически это редко не требуется. К каждой характеристике добавляем "риск" - получаем 8 рисков. Оцениваем влияние на пользователя и на обслуживание системы.

Качество системы - качество ПО (качество ресурсов + качество ворклфлоу) + качество смежных компонентов.

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

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

Антон Семенченко. Чистая архитектура в контексте Автоматизации тестирования

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

Смысл Архитектуры - снижение стоимости продукта на всех этапах, включая тестирование и эксплуатация.

Отделить архитектуру от дизайна невозможно ни в строительстве, ни в ИТ. Дверная ручка - - дизайн, фундамент здания - архитектура, а декоративные колонны - что? В ИТ тоже самое, есть design pattern и architecture pattern, но многое на стыке. К архитектуре точно относится принципы деления на компоненты и организации взаимодействия между ними, к дизайну - детали внутреннее устройство компонент, а вот выделение отдельных компонент или принципы проектирования компонент - на стыке.

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

Роберт Мартин. Clear Architecture. В одной из глав он приводит 4 варианта архитектуры: трехкомпонентная, функционально-разделенная, сущность-плагины и еще один. При этом в коде - одинаковое количество классов и интерфейсов. Получается, что логически ошибки везде одинаковы - раз речь идет о коде. Но раз они одинаковы, то архитектура не влияет на тестируемость? Но опыт говорит о другом. Проверки в коде - разработчиками в unit-test, и если это делают - то ошибки должны быть найдены. Тогда где влияние архитектуры?

Юнит-тесты, code review и многие другие практики. И QA должны понимать эти аспекты и участвовать в проработке, вписывать их в свою стратегию тестирования. И дальше фокусироваться на пересечения границ.

Автотесты - куда встраивать: есть unit, api, есть функциональные. Куда ставить? Автотесты - тоже часть архитектуры системы в целом. Чтобы тестировать слои изолировано, полезно встраивать промежуточные слои: command-line, api для тестирования. Это позволяет статьи независимым от того, что тестируешь на этапе подготовки данных для конкретного теста, сделать тесты более изолированными. Если в приложении часто возникают проблемы безопасности - давайте вынесем их за скобки функциональных тестов и будем проверять их отдельно, а для этого сделаем способ работы, при котором "все позволено" - но отдельным модулем, который точно не выкатим на прод.

Design pattern humble object. Скромный объект. Разобьем сложный объект на два, разделим сложность. Так в свое время появился MVC: разделим на клиенте визуальное представление (View) и бизнес-логику (Controller). Потом еще был Module-View-Presenter, MVVM - они тоже делили сложность. Декомпозиция уменьшает сложность разработки, обеспечивает независимое тестирование и локализации ошибки. База данных. СУБД - plugin для приложения. ORM - плугин для плугина.

Разрабатывали монолит, стал монстром, решили декомпозировать - куча проблем с тестированием. Это проблема архитектуры, но в других терминах. Потому сделали два шага в одном: изменили архитектуру и поменяли реализацию. Если монолит внутри структурирован - разбит на компоненты, используется dependency rules и разные методы пересечения границ - фабрики, IoC и другие то он потом хорошо развалится на микросервисы. А если микросервисы декомпозированы неверно, то ошибки и не кончатся.

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 17:38, 7 декабря 2023 • нет комментариев