2025-10-28: SQAdays - про ИИ и не только

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

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

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

Прошла очередная конференция SQAdays. Для меня основной темой конференции был ИИ, что достаточно логично. Я уже отмечал в отчетах с весенних конференций, что во многих командах ИИ становится рабочим инструментом повседневного использования. Более того, сейчас ставят вопрос о том, как надо перестроить традиционный процесс разработки с учетом инструментов ИИ, что изменится? Будут ли изменения столь же радикальны, как, например, переход к конвейеру поставки и continous delivery?

Вместе с тем, сохраняется позиция скептиков, которые смотрят на происходящее, и говорят «ну, ИИ же ошибается», или «ну, ИИ же глупый» (недостаточно умный) или даже «это все хорошо, но интеллекта там нет». Как будто люди не ошибаются и все обладают высококачественным интеллектом. Меня это задело на первом круглом столе с Александром Александровым, а во второй день мы обсудили с ним это на баркемпе, который шел в трансляцию его запись тоже будет. Каждый остался при своем мнении, при том, что факты мы все представляем корректно, различаются именно оценки.

И тут важно отметить, что истина -- не по середине, истина всегда на стороне тех, кто делает, а не тех, кто просто критикует. Александров - делает, несмотря на скептицизм, это звучало, хотя и в фоне.

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

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

Александр Александров, Антон Киселев. ИИ или не ИИ — вот в чем вопрос

ИИ или не ИИ — вот в чем вопрос

Отношение к ИИ у Александрова — очень человеческое, как у гуру к новичку: ты сначала подрасти, тогда я начну воспринимать себя всерьез. Может быть. И в репликах прямо звучат придирки: не всегда выделяет важное, не всегда точно формулирует. Как будто существуют люди, которые всегда все делают идеально.

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

Различие ИИ и множества предыдущих программ, которые Александров многократно упоминал — в принципиальном подходе. ИИ, включая LLM — учатся. Так, как учится человек.

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

Так что работайте в паре, как с помощником. А сэкономленное время тратьте на другие активности. И есть данные, что эффективность повышается кратно. Об этом в зале говорили.

Не только в разработке, но и в такой интеллектуальной работе, как разработка следующей версии системного подхода, применимого для личности и сообществ. Анатолий Левенчук начал этим заниматься с июня, Начиналась у него эта работа в июне, вот его пост, в этом посте он разбирает бригаду ИИ, с которой работает и метод работы, а вообще можно следить по блогу как оно развивалось, там интересно. В этом посте — свежий статус, и там есть ссылка на сам фреймворк на Яндекс-диске, можно использовать. Это ЖЖ и историю можно смотреть по его постам, это работа этого лета. А это один из последних постов Анатолия, где он показывает работу с примером реального промпта.

И еще один совершенно прекрасный пример начинается здесь — профессиональный филолог попросила ИИ перевоплотиться в Грибоедова и прокомментировать роман Тынянова о Грибоедове. Результат потрясающий, и дальше у нее серия разговоров с Радищевым и многими другими, читайте.

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

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

• Под интеллектом понимают способность решать задачи, для которой нет инструкции. Если человек выучил таблицу умножения и правила перемножения или делания в столбик, то никакого интеллекта в этих действиях нет. А вот чтобы придумать эти методы интеллект нужен. Но есть и другая точка зрения: интеллект — это способность вести коммуникацию на относительно произвольную тему.
• Тьюринг ставил критерии успеха развития ИИ в виде решения частной задачи на коммуникацию, в ходе которой ИИ должен был вводить человека в заблуждение (это — важная часть задачи), так что человек-наблюдатель, с которым ведут коммуникацию, не сможет отличить коммуникацию ИИ и другого человека. Критерий понятен, но принадлежит историческому прошлому. Хотя для тех, кто любит докапываться к букве, не так давно был проведен тест Тьюринга, и ИИ его прошел.
• Когда задумались о том, как сделать ИИ, встал вопрос: а как человек решает задачи, что в этом главное. Было два кандидатных ответа: умение рассуждать, которое имеет длинную историю, начиная с Аристотеля, и умение обучаться на опыте, которое дает способы решения для таких задач, которые ранее не встречались. И решили, что умение обучаться — главное: во-первых, само умение рассуждать еще надо было придумать, во-вторых, когда ученый решает проблему, то гипотеза не выводится аналитическими рассуждениями, она ученый ее берет «ниоткуда», а затем проверяет — это дуга Эйнштейна.
• Исходя из этого, начали с распознавания речи и изображений, отработали алгоритмы обучения, а уже потом — начали их применять для речи и рассуждений, сделав LLM (там по пути надо было придумать алгоритм-трансформер, но это — детали). То есть к работе с речью пошли не прямым путем, а окольным. Что нормально в науке. Поэтому все это логично относят к ИИ — компьютер обучается на опыте решать задачи. А программы, которые работают по алгоритмам, к ИИ не относят.

Иван Степнов из Test AI. Автоматизация регресса без стресса: от классики и BDD до ИИ-агентов под контролем QA

Автоматизация регресса без стресса: от классики и BDD до ИИ-агентов под контролем QA

Резкий контраст с предыдущим круглым столом. Люди настроены конструктивно. Они видят в ИИ потенциал и делают средства на основе ИИ. Создатели автотестов — узкое место, их всегда не хватает. И они сделали продукт, который решает эту проблему: он берет тест-кейс для UI E2E тестирования, написанный на естественном языке, и ИИ-агент превращает его в автотест. И этим агентом могут пользоваться люди, которые знают продукт, и умеют тестировать вручную.

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

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

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

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

Юлия Кнац и Анна Ставцева. Мастерская дизайна команды

Мастерская дизайна команды

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

Я с моделью Белбина знаком давно, рассказывал о ней на SQA еще в 2012 году, а в 2020 у меня был доклад на Teamlead с кейсами. Поэтому я прокомментирую отличия. Авторы сократили модель до 7 ролей: Координатор, Генератор, Аналитик, Исполнитель, Исследователь, Эксперт, Душа команды. У Исполнителя (он же Реализатор) есть важное отличие от Эксперта (Специалиста) — он закрывает серые зоны, если это нужно для проекта, даже если этого не очень умеет. Надо поднять стенд — поднимет. Надо с кем-то договориться — попробует. Не будет говорить «это не мое дело». И в этом его основная ценность. Авторы исключили Шейпера — вторая руководящая роль, человек, который ведет команду к результату на своей энергии. Думаю, это уместно, потому что тестировщики не делают независимых проектов, Шейперы в ИТ нужны на внедрении или в авральных проектах, когда надо личной энергией обеспечить продвижение. А вот исключение Педанта — любопытно. Педант — это человек, который помнит про хвосты и качество, и обеспечивает их достижение. Если он в команде — об этом не надо помнить, а иначе надо решать административно. Но, наверное, если команда работает по таск-трекеру и снабжена чек-листами тестирования, то Педант действительно перестает быть необходимым.

Кстати, отмечу, что Белбин создавал свою модель для команд менеджеров, но для ИТ она применялась очень давно, я в свое время с удивлением опознал ее изложение в книге «Смертельный марш» Йордана, который ссылался на американского последователя Белбина. Кстати, книга — актуальна до сих пор, как перечнем причин, по которым проваливаются ИТ-проекты, так и рекомендациям — как в таком проекте работать.

Екатерина Глушанина из 2ГИС. Помогите, Flaky!

Помогите, Flaky!

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

Для решения этой задачи сделали много workaround, реализованных через плагины в Allure, они выложены в open source — можно использовать. Самое простое — reruns, если 2 из 3 прошло — считаем ок. Но бывает, что падение стабильно, и ждет тикета на исправления. Есть плагин, который игнорирует конкретную причину падения, указываемую в параметрах, делает тест хорошим.

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

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

Vadim Nikitenko из Райффайзен. Генерация автотестов с помощью MCP + LLM

Генерация автотестов с помощью MCP + LLM

Доклад показывает механику создания тестов с помощью LLM. Для этого используется MCP-протокол, обеспечивающий взаимодействие LLM с внешними тулами, возвращающими динамический контекст. Работает так: сначала запрос пользователя обогащается список доступных тулов с описанием. LLM возвращает, что вызвать, выполняется вызов и результат добавляют к следующему запросу LLM как контекст. LLM может запросить несколько вызовов. Таким образом можно получить прогноз погоды. MCP-клиент и MCP-сервер легко написать самим, в докладе были примеры. И есть много готовых, в частности, для целей тестирования есть mcp playwriter, который умеет показывать структуру интерфейса приложения. В нем есть агенты (специально настроенные промпты), которые умеют создавать планы тестирования, создавать код по этому плану, а если тест упал и вы видите, что это ошибка в тесте — есть хелпер, который может предложить исправления.

Можно использовать локально развернутую LLM, даже очень слабые (Llama8b) хорошо определяют, что для какой-то информации надо запросить контекст у mcp. Но LLM требовательны к ресурсам, поэтому лучше использовать корпоративную — это будет быстрее. Кроме того, сильная может обрабатывать более сложные тест-кейсы, строить более длинные цепочки обращений, лучше строит обработку ошибок, добавляя вызов снапшотов и так далее. Естественно, можно использовать внешние LLM.

Светлана Кочнева. «Жалоба как подарок» или системный подход к разбору претензий по качеству тестирования

«Жалоба как подарок» или системный подход к разбору претензий по качеству тестирования К тестировщикам вечные претензии о том, что протестировано плохо. Это сильно огорчает. И периодически приходят мысли «что ж за дурацкую профессию я выбрала». В какой-то момент вспомнила свое детство. Когда была с бабушкой, которая работала продавцом в магазине, и ей говорили «хлеб черствый», «мармелада нет». Бабушка не переживала и говорила «напиши в жалобную книгу». Она вспомнила и вдохновилась.

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

Но появились проблемы. Тестировщик по задаче «проведи анализ и предложи решения» — они не могут, два вердикта «виноват, больше не буду» или «не виноват, вы придираетесь».

Придумали список вопросов, и пока он отвечает — проводит анализ.

• Время обнаружения на проде. Если инциденты пошли сразу после нового релиза — значит тестирование недостаточно качественное. А если уже после релиза создали много заказов, и потом ошибка — значит относительно качественное.
• Что могло побудить тестировать? Описано в регрессе, есть требованиях, есть анализ кода или взаимосвязей, или из опыта знают, что объект проблемный, и если тронул — проверяем тщательно.
• Сложности с трактовкой требований. «Если согласование документа не выполнено в течении 7 дней, то отправлять уведомление…» — дни календарные или рабочие? Инициатор думал про календарные, а команда — про рабочие, как в других задачах.
• Категория ошибок: 0 — не могло быть найдено (невероятный ответ из внешней системы), 1- низкая вероятность (на определенном наборе данных и т. п.), 2 — можно было найти, популярная ситуация, 3 — должна быть найдена (это было в регрессе или тест-кейсах, но пропустили).
• Пути решения. Чтобы предложить эффективные пути, нужно найти пути решения проблемы. Они рекомендуют пять почему. Не приходят уведомления — потому что логика на рабочие дни — это предположение команды — в требованиях не указали — почему взяли в работу, посчитали очевидным — был упор на скорость работы. Проблема не в тестировании и в согласовании требований.
• Действия по результатам анализа: дописываем регресс; актуализируем тестовое окружение или делаем это чаще (например, эмулятор вместо реальной интеграции); работа с требованиями (доработка шаблона, мастер-классы и семинары, база хороших и плохих требований); использование ИИ (спросить его, пусть ревью сделает); создание базы пропущенных ошибок; доработка системы взаимосвязи между объектами (если меняется длина реквизита — проверь печатные формы).

И дальше — заполнение шаблона.

Проблемы.

• Бывает, что инициатор не согласен с результатом анализа. Перепиской не ограничиваемся — обсуждаем.
• Бывает, претензия в смежных областях — двое проводят анализ.
• Первый анализ — с наставником
• Качественный анализ требует времени, его откладывают. Есть соглашение, что 7 дней, по относительно свежим следам.

За 6 месяцев 150 претензий, только 39 (26 %) обоснованных. И это нормальное число, можно работать. По обоснованным — разбор полетов, не поиск виноватого. По не обоснованным — это все равно не оправданные ожидания — надо смотреть, это может быть в смежных процессах, которые стоит улучшить.

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

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

Марина Куликова и Павел Голяков. Конец эпохи QС: что будет с процессами, когда разработчики начнут тестировать сами?

Конец эпохи QС: что будет с процессами, когда разработчики начнут тестировать сами?

Марина и Павел задались вопросом о том, как изменит процесс разработки появление ИИ, и, в частности, как это повлияет на обеспечение качества (QA). Пока участники процесса (аналитики, разработчики, тестировщики) просто используют инструменты ИИ, выполняя те же самые задачи. Но, возможно, будут принципиальные изменения.

Авторы выдают интересную версию: тестировщиков не станет, будет один специалист по QA, а задачи по контролю качества (QC) возьмут на себя разработчики, которых он будет тренировать, совместно с ИИ. Мысль интересная, но рассмотрена чисто теоретически. Вот если бы авторы попробовали так организовать, было бы интересно.

Кстати, нельзя сказать, чтобы таких процессов не было вообще, доклады об организации тестирования, которое полностью возложено на разработчиков, а тестировщики лишь организуют процесс и проговаривают с разработчиками, как те будут проверять фичи, я слышал уже лет десять назад на SQA. Там на 20+ разработчиков было 3 тестировщика, при этом это был GameDev или что-то подобное, где ошибка проявляется немедленно и массово. Там у такой конструкции были основания: ускорялся TTM, а разработчик, понимая реализацию, мог лучше проверить стремные моменты. Но в основном предпочитают выделять отдельную команду тестирования, ибо дешевле. Оснащение ИИ ускоряет и разработку и тестирование — принципиальных отличий не будет.

У авторов тоже были ссылки на известный опыт, но конкретика только одна: Atlassian QA, где нет тестировщиков, разработчиков коуч учит тестировать. И что в стандарте Agile тестировщиков нет, а есть кроссфункциональная команда, но это очень общая ссылка. Стандарт истоком из нулевых, тогда тестировщики встречались значительно реже, как и аналитики, а была единая компетенция программиста вообще.

Подробно пересказывать доклад я не буду, смотрите запись — там много деталей, с одними тезисами авторов я согласен, с другими — нет, а вы можете составить свое мнение.

Ольга Артемьева. Между техникой и людьми: невидимая сторона тестирования

Между техникой и людьми: невидимая сторона тестирования

Великолепный доклад о переживаниях тестировщика, которые обусловлены профессией тестировщика и носят системный характер, и о способах их решения. Дальше — конспект.

1. Мы приносим плохие вести.

Индустрия прописана оптимизмом — выпустим продукт, он принесет кучу денег. Не думают о рисках и провалах. В культуре, где нет невозможного управление рисков становится преступлением. А тестировщики — они об этом думают.

Как проявлется в работе? «Мы обязаны успеть всроки», «Почему так много багов». И даже когда понимающая команда, багам не радуются. Тестировщики не радуются багам, особенно перед релизом.

Мы начинаем совмневаться в знаниям. Может, я излишне драматизирую. Был кейс, когда надо сказать менеджеру о задержке релиза. И менеджер говорит «а почему ты говоришь, ты что, в этом разбираешься?» Надо выдерживать свои и чужие эмоции, не выгорать.

Что делать?

• Аргументировать позицию на знаниях и опыте. Не просто «две недели», а «требует полного регресса, он занимает две недели, можно сократить, но риски»
• Искать поддержку. На сех действует групповая динамика.
• Брать паузу. Это дает время успокоиться и подготовиться, перевести эмоциональное в рациональное.

2. Невидимая работа в голове.

Превосходное и посредственное тестирование отличается тем, как вы это спроектировали. Это — в голове, не видимо. Часто кажется, что тестирование — среднее между магией и удачей, но это не так. «Просто потыкай», «посмотри аккуратно». В свое время пришла на вакансию «девочка с красным дипломом» — чтобы была скурпулезна и усидчива, и не больше. А реально кроме внимательности и усидчивости нужно мышление. Его не видят. И это — блоки. «Оля, ты умная, что делаешь в ручном тестировании?» И невидимая работа сложно планируется, поэтому многие тестировщики хронически перегружены, да еще говорят, что самое узкое звено. И не дают признания — ведь работа простая.

Что делать?

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

3. Ответственность без власти.

Тестировщик как бы отвечает за качество, но он не имеет право исправить код. Он может лишь содействовать. Слова «за качества отвечает команда» — красивые, но за баги на продакшене прилетает тестировщику, ответственности от тестировщика ждут «чтобы багов не было». А гарантировать, что багов не будет — невозможно. А еще тестировщику отдают все не-техническое: написать release notes, подготовить материалы для продукта, проставить селекторы ко всем элементам — для вас будет развитие.

В результате тестировщик — мини-менеджер, но без власти менеджера. С непонятным кругом ответственности. А еще мы тревожимся пытаемся постоянно перепроверить.

Что делать?

• Согласовывать ожидания с командой. Баги — будут
• Делегировать задачи назад в команду, release notes напишет любой
• Определить зону контроля
• Системный подход к работе с рисками: не только предотвращение, но и снижение вреда, что будем делать, если риск реализуется

4. Какую работу я приношу?

Часто говорят, что «когда разработчики делают работу хорошо, тестировщики не нужны». Но это не так, сложные баги — все равно находят.

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

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

Что делать?

• Записывать достижения — мы забываем
• Провести мысленный эксперимент «а что если без тестирования», или даже уйти в отпуск.
• Право на уважение

Все это — системный вызовы профессии.

Что сделать завтра?

• Достижение результата снова и снова. Запишите результаты за последние три месяца, и дальше ведите такой список. Можно посмотреть таск-трекер, мессенджер и другие артефакты. Или вспомните.
• Запишите в формате STAR(R): situation, task, action (что сделал), result, reflection (не обязательно). Например, приходит «будем сокращать TTM», вы сократили, багов больше, не улучшилось. Вы сделали чек-лист для отправки на тестирования, разработчики проходят — сокращаются возвраты. Я тут замечу, что это похоже на протокол авторизации результата, о котором рассказывает Анна Обухова, и там есть две важные части: как достигнутый результат связан с крупными целями, и как я могу рассказать это другим — это фиксирует историю в долговременной памяти как часть личной истории. Возможно, это входит в result и reflection, но тут важные акценты. И у авторизации результата есть негативный вариант, чтобы отпустить неудачу.
• Нарисуйте круги влияния. Контролирую то, что делаю сам, например, как заполняю баг-репорты. А если решение о допустимости выпуска принимаете не вы, то вы влияете, но не решаете. Внешние обстоятельства — не них не влияешь.
• Запланируете способ, как сделаете работу видимой — на доске, в виде артефактов и так далее. Сделайте презентацию для коллег: что входит в тестирование, почему занимает столько времени, что даст автоматизация.

Алина Иванычева (Райффайзен). Avro и Kafka: испытания тестировщика в мире Big Data

Avro и Kafka: испытания тестировщика в мире Big Data

Avro — бинарный формат, проще, чем Json. Но для тестирования в этом проблемы: вам надо уметь декодировать конкретные сообщения, а еще уметь найти сообщения, относящиеся к конкретному документу по его номеру или другим реквизитам, которые указал пользователь. И Алина в деталях рассказывала про конкретные средства, с помощью которых это обеспечивается. Основное — Fast Avro и Trino для поиска. Если вы начинаете использовать Avro — то смотрите доклад.

Анастасия Кононова. И чтец, и жнец… как совмещать две роли в проекте и не сойти с ума

И чтец, и жнец… как совмещать две роли в проекте и не сойти с ума

Анастасия совмещала роль тестировщика и scrum-мастера в своей команде. У них классический скрам со всеми ритуалами (а говорят, что его не бывает — врут), в командах разработчики, тестировщики, дизайнеры. И выделенной роли скрам-мастера не было, все совмещали.

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

А год назад ей предложили взять роль скрам-мастера у 4 команд, в которых 50 челвоек, на продукте (как я понимаю, там команды iPhone, Android, веб и бэк для одного продукта, но могу ошибаться). И это резко увеличило нагрузку на роль скрам-мастера, до 80 % на начальном этапе, при этом обязанности тестировщика никуда не ушли, ей по-прежнему, надо было обеспечивать выпуск релизов.

В целом справилась. Что помогло? Тайм-менеджмент, помодоро 15 минут без прерывание. Приоритеты важное-срочное. И делегирование — не впихивайте 24 часа в рабочий день, отдавайте. Многое было сделано за счет взамодействия и коррекции процессов. В частности, квоту на роль скрам-мастера надо было учитывать явно, и если в результате получался перегруз — то думать о том, кому передавать тестирование и по каким задачам, на часть задач можно было привлечь тестировщика из другой команды.

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

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

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

А роль фасилитации они перенесли внутрь команды. Сначала была идея, что это полезно сеньорам для performance review, а потом — вообще для всех. Так что передается.

Главное — доверие команды, в обе стороны: ты мог подойти с любым вопросом, к тебе подходили. И все мы идеалисты, но главное — не падать духом.

И в ответах на вопросы.

• Как повысить эффективность встреч? Ограничение по времени, дейлик 15 минут стоя, вопросы — на отдельные встречи. Груминг — инструмент и подготовка. В середине спринта синк с распределением задач следующего спринта, и люди готовят, ко встрече приходят подготовленные. В ретро — элемент игры, фан-вопросы или викторина, проходит лучше. Все техники есть в интернете, пробуйте новое.
• Как быть объективным, не продавливать позицию тестировщика? Это сложно, этого дзена достигла через год, это работа над собой.
• При сопротивлении изменениям — «давайте попробуем». Бывают неудачи, это тоже хорошо.

Сергей Атрощенков. Нейроохота на баги: что происходит в мозге тестировщика?

Нейроохота на баги: что происходит в мозге тестировщика?

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

Тестирование — сложная когнитивная деятельность. Оно посложнее многих других дисциплин в ИТ.

• В нем много анализа — работа с требованиями, проектирование сценариев, предсказание работы системы.
• Тестирование — под постоянным давлением
• Много коммуникаций
• Абстрагирование — в ширь, вглубь, в стороны
• Мозг — чтобы выживать, а не тестировать софт.

Зачем нейрофизиология? Тестирование — не чтение кода, не только на уровне логики. Читая код, задействуем левое полушарие, при тестировании — задействуем правое. Задействуется нейронная сеть, которая работает для логики и математики. Мозг работает так. То есть при тестировании мы решаем задачи.

• Мозг имеет свойство уставать, это нормально. И он устает от тестирования.
• Рабочая память ограничена.
• Вовлечены сознательные и бессознательные процессы.

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

Когнитивный цикл тестирования.

• Планирование — фронтальная кора
• Теменная доля — внимание и рабочая память
• Понимание контекста — височная доля
• Обнаружение аномалий — передняя островковая доля

Когнитивная нагрузка. Память занята: система, ожидаемый результат, возможные креш-кейсы, часть архитектуры системы, бизнес-поведение системы. Минимум 5-6 элементов. Детальные тесты разгружают память — но увеличивают ttm, нужен баланс. Если вы решаете задачу, а вас грузит менеджер — печалька, перегруз.

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

Как прокачивать опыт. Можно поучаствовать в теневом режиме как разработчик или аналитик. Разработчик дает задачу тестировщику и они в паре делают, потом тестировщик полностью делает, только результат. И в продуктом — бегать по всем встречам, и расширяет познание. Если такого нет — то хотя бы из другого домена. Это позволит превратить интуицию во что-то осознанное.

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

Ага-момент. Мы получаем озарение. Моменты, когда ищешь-ищешь, проблема не находится. А через некоторое время, на обеде — приходит озарение. Это происходит из-за туннельного эффекта, мы погружаемся, а потом оно всплывает. И когда решили — выброс дофамина. Это помогает развиваться, и развивать мозг как орган. Если не брать дешевый дофамин, пролистывая ленту, а погружаемся.

Когнитивные ловушки. Докладов — множество, и их 200+. Он выбрал три, которые редко упоминают.

• Ловушка подтверждения. Проверяем только happy path — хотим подтвердить, что работает. Особенно в ограниченном времени.
• Доступность. Полагаемся на баги, которые нашли, и смотрим в эту область. Не обращаем внимания на другое. Например, на тестирование формы, при том, что перепутали логотип.
• Якорение. Фиксируемся на первой проблеме. Нашли баг, не понимаем с чем связано, идем к разработчику, в чем причина — исследуем, долго, не находим проблемы — потому что проблема в другом месте.

Что с ними делать? Якорение — строим равномерное покрытие, структурирование подхода, кросс-ревью тестов. Ловушка подтверждения — шесть шляп, меняем позицию. Доступность — чек-листы и все то, что делает тестирование скучным.

Ловушки не приговор. Мозг может обучаться. Проводили МРТ студентов, обучение программированию увеличивает количество серого вещества.

Мы приходим к опыту работы. Работаешь год, и казалось бы все знает. Нет, мозг не развился настолько, сколько у сеньора за три года. Даже если он может решать задачи — он это делает тяжелее. И дайте время мозгу развиться, зафиксировать достижения, а потом увеличивайте сложность. Есть статья — число лет от новичка до эксперта. Новичок — полгода, продвинутый год-полтора, эксперт — три. Нейропластичность качают, беря разнообразные задачи. Что-то узнали — попробуйте сразу, через три часа, через день, через 10 дней. А еще — спите, отдыхайте, люди плохо умеют это делать.

Различие мозга между разработчиками и тестировщиками — есть исследование. В частности — разработчики менее дисциплинированы, чем тестировщики. Там интересный слайд, надо будет посмотреть.

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

И в заключении — маленькое дополнение. Мозг не устает таким же образом, каким устают мышцы, которым после тяжелой работы нужно питание, еда. Мы воспринимаем как усталость мозга отсутствие подкрепления. Потому что разработчик (или тестировщик) устает делать задачи и идет играть в Warcraft, где когнитивная нагрузка выше, но есть эмоции. Подкрепление можно научиться выдавать себе самостоятельно, или получать через похвалу.

Спасибо Сергею! А нейрофизиология — очень интересно, и психологам пора бы пересобрать свои модели на их основе. Но они не торопятся, так что мне пришлось самому, получилась книга «Инженерная модель личности».

Дмитрий Воробьев. Захватывающая история Пейджамена Паттерна

Захватывающая история Пейджамена Паттерна

Это действительно интересная история — о том, как герой доклада пришел на новое место работы, чтобы сделать автоматизацию тестирования. При этом опыта автоматизации у него не было, хотя знание python, на котором писали тесты — было. В докладе рассказ был очень подробный, со скринами a фрагментами кода, и они реально показывали, как после применения конкретных шаблонов код становится понятным и читаемым. На мой взгляд, это — очень важная иллюстрация.

Дальше — шаги работы.

• Первое задание — сделать приемочные тесты на продукт: авторизация, переход между страницам и верстка.
  • Авторизация — playwrite и плугин для выбора стендов. Есть проблема: не все селекторы библиотеки срабатывают в браузере, и он формирует правила использования селекторов, и проверяет их при написании.
  • Переходы между страницами. Несколько тестов — дубли селекторов и кода. Вынос повторяющихся действий. Тест короче, патерн Steps.
  • Скрины страниц, сравнивает библиотека. Проблема — динамические данные. Надо дождаться загрузки и надо подменять данные — затемнять или подменять ответы, есть средства.
• Тестирование админки. Пользователи и роли. Данные рандомизирует, однако взаимодействие через UI требует предварительной подготовки данных — это долго. И переходит для подготовки и очистки на использование API. Модуль подготовки, fixture для авторизации и куки, очистка окружения. В тесте API остается только для UI.
• Модули растут. Дублирование селекторов и проверок, слишком много настроек — хаос. Идея — изучить и посмотреть доклады. И хотя он считал неплохим автоматизатором, а самооценка проседает. И тут он решает сделать план по проверенным подходам.
  1. Конфигурация — основные настройки. Singleton, чтобы был единственный экземпляр. Модули в python — singleton, это можно использовать.
  2. Работа со страницами. Модули UI-действий — большие, и приходится передавать Page. Использует PageObject — классы с методами — атомарными действиями.
  3. Есть набор общих действий — открытие, скриншоты, базовые проверки и другие — выносит в класс PageBase. Умное открытие — чтобы не открывать повторно, но с возможностью обновить, и дожидаться загрузки объекта до взаимодействия.
  4. В PageObject — проверки, а в методы называть по результату. Результат — нет объекта Page, действия структурированы, ожидание — автоматическое.
  5. Тесты плохо читаются — паттерн 3a: структура подготовка-действие-проверка. Проще всего — комментарии. Но тут уже надо использовать тулы, Allure позволяет размечать тест шагами и фазами.
  6. Разметку — в лог — делает собственные функции разметки, которые логируют, а потом пишет в Allure. И для каждого названия шага делает отдельную функцию, чтобы IDE подсказывала.
  7. UI — сложный, и работать сложно. Используем PageElements и отдельные классы примитивов с базовыми наборами взаимодействия. И есть базовый набор примитива, от которого наследуются, и конкретные над ним.
  8. Как добраться до примитива? Они далеко не сразу появляются. И Chain Of Information — метод возвращает контекст, например, если нажатии на кнопку появляется меню — метод возвращает объект, в котором содержимое дает набор действий. И тут пример — как идет открытие, выбирается элемент и что делаем.
  9. Улучшение API — тоже большой модуль. Делают классы для каждого end point. Литералы заменяем на константы и их — в модуль конфигурации. Многие методы требуют набор связанных параметров — их лучше заменить на объект Value Object.
  10. Привязка к библиотеки, и импорт приходится тащить в тестовые модули, чтобы были подсказки. Можно использовать кастомный модуль ответов, работать в ней.
  11. Стандартная библиотека requests поднимает соединение для каждого запроса — это долго. Нужны сессии. Но отдельная сессия для каждого клиента даст слишком много соединение. Dependency Injection, соединения передаем.
  12. Объект-валидатор, чтобы не использовать констант, использование Strategy. И шаблоны валидаторов для повторяющихся проверок. Дает возможность отключения проверок.
  13. Для тестов много объектов взаимодействия. И он объединяет объекты в один Facade для api и ui.
• e2e тесты. Большой сценарий действий. Идея — steps, объединение связанных действий, технические детали скрываются. Делает шаги UI и api и делает фасады. Тест получился большой 100+ ожиданий и проверок.
  • Авторизация — сложно хранить, и она отдельная для UI и api. Screen play — требует отдельных фреймворков, это неудобно. Поэтому он делает упрощенный вариант — объект-пользователь, которому можно задавать данные авторизации и другие вспомогательные действия, и который выполняет шаги.
    

• Отчет. Decorator — reporter Allure предлагает готовый, и его можно навесить на классы шагов. И еще свой decorator для записи в лог. Но проставлять вручную декораторы тяжело, можно забыть. Поэтому используем метаклассы, они позволяют навесить декораторы на все методы. Делаем базовый класс, от него наследуем. В логе — все детали, а в отчете — верхний уровень.

В целом — получился зрелый проект.

Вывод. Изучайте паттерны — они всегда пригодятся.

Наталья Руколь. Тотальный контроль тестирования

Тотальный контроль тестирования

Наталья всегда прекрасна, помню ее выступления уже больше десяти лет, и она продолжает быть такой же энергичной и искрометной. У нее — своя компания, которая выполняет аутсорсинг тестирования.

У рассказа было замечательное начало. Наталья ненавидит контроль, потому что сама — раздолбай. Но уверена, что без него — никуда, потому что все сыплется. Поэтому надо строить систему, которая обеспечит контроль.

Что дает тестирование?

• Субъективность: ошибки нечаянно, нарочно неосознанно и нарочно осознанно. Человек себя обманывает, видит лучше, чем мы есть.
• Своевременность. Мы оцениваем какой-то показатель, должно быть не ниже 4. И мы смотрим метрику, все зеленое, но есть тренд на снижение. И можно во-время заметить. Тлеющая тряпка, дымок — индикатор возможного пожара, надо обращать внимание, и у них есть индикатор с таким названием.
• Корректировка маршрута. Хочешь сократить срок выпуска — и смотришь на индикатор. В одной крупной компании сделали отдел автоматизаторов, которые пилили фреймворк и так далее — в результате после двух лет ROI отрицательное, время автоматизации увеличилось. А люди гордятся — классный фреймворк. Понять можно было сразу. А еще метрики дают «ты умничка» — и это тоже важно. .

Не путаем метрики.

• Контроль продукта. Например, контроль принятых требований.
• Контроль процесса. Тестировщики нашли 100 багов — это много или мало? Если видно покрытие требований — то можно понимать, сколько еще будет.
• Контроль проекта — сроки, прохождение людей.
• Контроль людей

Метрики — на слайдах ссылки на каналы, там 200+ метрик, накануне об этом был круглый стол.

Ее компания занимается аутсорсингом тестирования. Она все контролирует, и еще за отдельные проекты отвечает. Еще HR — менеджер счастья. Она хочет знать, как работают процессы в отделе в целом. Общие процессы отдела, статусы процессов, статусы команд, статусы сотрудников, инциденты и проблемы — и там много чеклистов. Контроль повторяющихся процессов. По всем ним есть регламенты: шаг, роль, что надо сделать. И во всех них — как считать метрики.

У каждого проекта — свои метрики. Два скрина, на проектах даже один тест-менеджер — метрики не повторяются. Метрики в динамике и целевые показатели. Метрики подбирают под условия.

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

Ведем все проблемы. Инцидент — однократен. А проблема — когда сотрудник считает, что что-то работает неправильно. Сотрудники их пишут. Например «слишком ограниченное время на оценку компредов», созвон показывает: «рынок требует быстро оценить», и проблема меняется: «мы не умеем быстро готовить компреды».

И множество табличек. Менеджер принимая сотрудника, смотрит развивать или нет, и из базовых шаблонов делает ИПР, это быстро. А еще — по команде, есть набор компетенций команды — и смотрят, что не хватает.

Сотруднику говорят «прочитай статью», приходит тест-менеджер и говорит «докажи, что прочел». Они все каждый месяц друг друга оценивают по шкале.

Итак, внедрили. Там 100500 табличек. Открывает 50 — а там много разного. И много красного. А еще все на удаленке, и когда она в 6 утра пишет вопросы — никто не может ответить. И вообще, может понять, что красное хорошее, а то зеленое — проблема. Можно потратить день.

Что сделали?

• Агрегировать так, чтобы все можно контролировать. Табло компании — все повторяющие процессы в департаментах, 150 строчек, там есть ответственные и статус выполнения. Табличку нельзя держать актуальным вручную. Есть специальный человек, он заходит в последний день месяца. Столбец «статус выполнения» ставится красным — и у каждого есть несколько дней актуализировать. А дальше он должен придти на созвон и отчитаться.
• Фокус-созвоны по каждой теме. Топы, статус проекта-сводка и каждую неделю пишут комментарии и все пометки — здесь, статус каждого проекта (тест-менеджер), статус процессов компании, статус резерва сотрудников, 1:1 сотрудников ИПР. Правила созвонов: регулярность, дисциплина. Не пропускаем, часто менеджер переносит в пользу рабочих задач. Готовность к созвону — за несколько часов, не смотреть материалы в моменте. Чат под каждый созвон — он группирует процессы. Если созваниваемся, и есть что-то красное — выписываем решение, и не может быть ситуации «решим потом», может быть ситуация «пока нет времени, займемся в феврале» — и ставим задачу на февраль. Чат: General, рабочее, всякая фигня. И нужен фан на созвонах! Позитивные и веселые. И есть созвоны в пятницу в 5 вечера (это рабочее время) с алкоголем.
• Ответственный за показатель. Может ответить на любой вопрос посреди ночи, всегда готов к созвону. И люди стараются зайти пораньше, за день, узнать контекст, а иногда и сразу исправить.
• Ведение задач по созвонам, а не по проектам. Своя доска по каждому созвону. И каждый созвон начинается с отчета по доске. Если есть красный показатель — должна быть задача с дедлайном.
• Есть человек, Наташа с должностью дрючер (официально), которая все контролирует. Она боялась, что возненавидят — ее обожают, она помогает. Но на внутрипроектные — не ходит, только общие, их около 20 в месяц.

Вопрос. Применяете ли KPI для тестировщиков? Ответ — нет, они для сейлов. Есть метрики проектов, а как только ставишь для тестировщика — он начинает работать на метрику, заводит баги или что-то еще. Бывает, когда мы учим чему-то, и тогда меряем изменение того, чему учим.

Она не работала в компании несколько лет, год назад вернулась. Начала с проблемника. Проблем с отсутствием контроля есть всегда. Озвучивают, дальше «давайте подумаем, что делать» — они предлагают метрики. Таблички вводили по чуть-чуть, и мягко. Сначала созвоны — хрень, а потом видят, что удовлетворенность заказчика улучшилась — внедрили процесс, начали фиксировать проблемы. И оно идет.

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

Павел Кузнецов. Как одним курсом решить проблему онбординга и развития сотрудников (ну или почти решить)

Как одним курсом решить проблему онбординга и развития сотрудников(ну или почти решить)

В компании был онбординг с наставником на задачах. Но задачи разные, а ментор далеко не все знает. За 3 месяца человек мог не познакомиться с базовым функционалом — он устойчив, изменения редки, поэтому задач мало, а вот знать его надо. Получается, что погружение зависит от вдохновения ментора, и непонятны ожидания на конце испытательного срока.

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

И он решил написать курс «как писать автотесты в компании», чтобы те, кто погружаются, знали особенности сайта, авторизации, стиля оформления текстов (есть особенности). И чтобы компетенции джуна покрыть.

План, о каких технологиях надо рассказать. Новые проекты без исторических наслоений. И пришлось написать много документации. Курс поделен на задания: раздел сайта, команда поддержки, задание на автотесты и ссылки на док. Рассмотрим, как описывается фирма, как добавлять реквизиты, какие использовать хелперы. Кейсы простые 10-15 строк. И сдача задания — в флоу, приближенной к реальностью. 8 заданий и дипломный проект — реальная задача. Создание курса 1.5 месяца чистого, астрономически 4 месяца. Прохождение — 3 недели, минимально была — 1 неделя, если у человека хороший бэкграунд.

В результате: знакомство с базовым функционалом, информация задокументирована, есть ожидания по результатам. И по старой формулы затраты сотрудника + ментора, в сравнении с новым — сокращение вдвое. В первый месяц человек работает менее эффективно, зато во второй-третий — работает эффективные, реальные задачи.

И можно не только онбордить, но и обучать ручных тестировщиков. На группу из 2 человек — 1 ментор, время выполнения больше (10 недель), так как они проходят параллельно с работой. 4 человека: один прошел, второй на половину, а еще двое — даже не поставили окружение. Обратная связь — у них нет свободного времени. А одна — договорилась с лидом в рабочее время, при том, что задачи проходятся. Для второй группы уже попросил согласовывать, но там не получалось. Третья итерация — заявка в тимлидов, если он посылает тестировщику — то соглашается на рабочее время. 4 группы, 10+ человек прошли, одна команда закрывает потребности в автотестах, в одной — появились автотесты, один уволился, остальные — неясно. Курс — компактный, дает нужное в компании. И поддерживать курс недорого.

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

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

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

— Максим Цепков • 16:27, 28 октября 2025 • нет комментариев