Приглашаем на открытый урок.
🗓 29 сентября в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «ИИ в тестировании: ускорение процессов и проверка ИИ-функций».
Программа вебинара
После урока сможете:
- Формулировать критерии приёмки для ответа ИИ-фичи
- Собирать golden dataset и гонять на нём регрессию
- Отличать галлюцинацию от допустимого разброса ответов
Кому будет интересно:
- QA-инженерам, в чей продукт уже приехала ИИ-фича
- Тест-лидам, которым нужно защитить критерии качества перед бизнесом
- Аналитикам и разработчикам, отвечающим за приёмку ИИ-функциональности
🔗 Ссылка на регистрацию: https://vk.cc/d21X3X
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👍2🔥1
Как правильно отчитываться на дейли-митингах / стендапах / летучках?
Источник: Максим Азаров, Software Testing QA Lead в SAM Solutions
За много лет работы я заметил одну и ту же особенность в командах.
Есть категория людей, которые не любят долго распинаться, предпочитают говорить минимум и в общем предпочитают не отсвечивать. От них обычно слышно что-то типа «Я на автоматизации», или «Я баг проверяю», или «Я стори делаю» и всё. Ни рассказа о находках и преодолённых трудностях, ни эстимейтов, когда закончит, ни любых других интересных или познавательных деталей. Всю остальную информацию приходится вытягивать клещами и наводящими вопросами.
Есть другая категория людей, которые, наоборот, любят говорить долго, погружают всех окружающих в кучу технических деталей, рассказывают свои мысли, о том, как они думали, какие решения принимали, где ошиблись, а где, наоборот, придумали гениальные решения. Так минут на 10–15. Эти товарищи часто очень обижаются, если их прерывают и просят сформулировать статус в 2–3 предложениях. И тут обратная ситуация: идёт перегруз информацией, и человек вне контекста очень быстро теряет смысл происходящего, а у человека, собирающего статус и оценивающего общую ситуацию на проекте, начинает кипеть мозг от лишней информации.
Так нужен ли на самом деле алгоритм? И для кого на самом деле эти митинги? Для менеджера, чтобы собрать статус, или для членов команды, чтобы понимать, что вообще происходит и кто что делает на проекте?
Короткий ответ: Митинг этот для всей команды, но с разными целями для разных ролей.
Для команды (разработчиков, тестировщиков, дизайнеров и т.д.) это синхронизация:
а) Узнать, что сделали другие, чтобы не работать в вакууме.
б) Обнаружение блокеров: услышать, у кого возникли проблемы, и предложить помощь («Я сталкивался с такой ошибкой, посмотри вот в этот конфиг»).
в) Понимание контекста: увидеть общую картину движения к цели спринта.
г) Обмен знаниями: узнать о новых подходах, технологиях или проблемах, с которыми столкнулись коллеги.
Для менеджера / тимлида / скрам-мастера это:
а) Сбор статуса: получить общее представление о прогрессе.
б) Выявление рисков: увидеть препятствия, которые мешают команде, и оперативно их устранить.
в) Оценка нагрузки: понять, всё ли по плану или нужны корректировки.
Главная ошибка здесь - считать, что дейли - это просто отчёт менеджеру. Это время синхронизации команды, которую организует менеджер / скрам-мастер.
Предположительно правильный алгоритм отчёта должен укладываться в 3-4 предложения и длиться не более 1-2 минут. Он должен содержать ответы на три ключевых вопроса:
1. Что я сделал вчера? (По отношению к цели спринта)
2. Что я планирую сделать сегодня? (Опять же, для движения по задачам)
3. С какими трудностями столкнулся? (Блокеры, риски, вопросы)
Плохо: «Я кодил, потом тестил, потом ещё покодил».
Хорошо: «Вчера я завершил разработку API для модуля платежей и написал для него юнит-тесты. Сегодня планирую начать интеграцию с банковским шлюзом. Пока блокеров нет».
А как это работает в ваших командах ?
Источник: Максим Азаров, Software Testing QA Lead в SAM Solutions
За много лет работы я заметил одну и ту же особенность в командах.
Есть категория людей, которые не любят долго распинаться, предпочитают говорить минимум и в общем предпочитают не отсвечивать. От них обычно слышно что-то типа «Я на автоматизации», или «Я баг проверяю», или «Я стори делаю» и всё. Ни рассказа о находках и преодолённых трудностях, ни эстимейтов, когда закончит, ни любых других интересных или познавательных деталей. Всю остальную информацию приходится вытягивать клещами и наводящими вопросами.
Есть другая категория людей, которые, наоборот, любят говорить долго, погружают всех окружающих в кучу технических деталей, рассказывают свои мысли, о том, как они думали, какие решения принимали, где ошиблись, а где, наоборот, придумали гениальные решения. Так минут на 10–15. Эти товарищи часто очень обижаются, если их прерывают и просят сформулировать статус в 2–3 предложениях. И тут обратная ситуация: идёт перегруз информацией, и человек вне контекста очень быстро теряет смысл происходящего, а у человека, собирающего статус и оценивающего общую ситуацию на проекте, начинает кипеть мозг от лишней информации.
Так нужен ли на самом деле алгоритм? И для кого на самом деле эти митинги? Для менеджера, чтобы собрать статус, или для членов команды, чтобы понимать, что вообще происходит и кто что делает на проекте?
Короткий ответ: Митинг этот для всей команды, но с разными целями для разных ролей.
Для команды (разработчиков, тестировщиков, дизайнеров и т.д.) это синхронизация:
а) Узнать, что сделали другие, чтобы не работать в вакууме.
б) Обнаружение блокеров: услышать, у кого возникли проблемы, и предложить помощь («Я сталкивался с такой ошибкой, посмотри вот в этот конфиг»).
в) Понимание контекста: увидеть общую картину движения к цели спринта.
г) Обмен знаниями: узнать о новых подходах, технологиях или проблемах, с которыми столкнулись коллеги.
Для менеджера / тимлида / скрам-мастера это:
а) Сбор статуса: получить общее представление о прогрессе.
б) Выявление рисков: увидеть препятствия, которые мешают команде, и оперативно их устранить.
в) Оценка нагрузки: понять, всё ли по плану или нужны корректировки.
Главная ошибка здесь - считать, что дейли - это просто отчёт менеджеру. Это время синхронизации команды, которую организует менеджер / скрам-мастер.
Предположительно правильный алгоритм отчёта должен укладываться в 3-4 предложения и длиться не более 1-2 минут. Он должен содержать ответы на три ключевых вопроса:
1. Что я сделал вчера? (По отношению к цели спринта)
2. Что я планирую сделать сегодня? (Опять же, для движения по задачам)
3. С какими трудностями столкнулся? (Блокеры, риски, вопросы)
Плохо: «Я кодил, потом тестил, потом ещё покодил».
Хорошо: «Вчера я завершил разработку API для модуля платежей и написал для него юнит-тесты. Сегодня планирую начать интеграцию с банковским шлюзом. Пока блокеров нет».
А как это работает в ваших командах ?
👍18❤2
#посмотреть #middle #senior
▫️Fundamentals of Testing
▫️Testing Throughout the Software Development Lifecycle | часть 1
▫️Testing Throughout the Software Development Lifecycle | часть 2
▫️Static Testing | часть 1
▫️Static Testing | часть 2
▫️Test Design Techniques | часть 1
▫️Test Design Techniques | часть 2
▫️Test Management | часть 1
▫️Test Management | часть 2
▫️Tool Support for Testing
Please open Telegram to view this post
VIEW IN TELEGRAM
❤16🔥1😴1
Как перейти от монолита к микросервисам без лишнего риска?
🎥 6 октября в 20:00 МСК на открытом уроке разберём практические подходы к переходу от монолита на микросервисы: как определить границы сервисов, выбрать стратегию миграции и не остановить разработку.
На примере покажем, как работать со strangler pattern, декомпозировать систему по доменам, организовать работу с данными и транзакциями и избежать главной ловушки «распределённого монолита».
🔔 Урок проходит в преддверии старта курса «Микросервисная архитектура» и будет полезен backend-разработчикам, архитекторам, техлидам и DevOps-инженерам, которые работают с большими системами и планируют их эволюцию.
Зарегистрируйтесь и разберитесь, как переходить от монолита к микросервисам поэтапно без остановки бизнеса и дорогих архитектурных ошибок: https://vk.cc/d2ezcC
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
🎥 6 октября в 20:00 МСК на открытом уроке разберём практические подходы к переходу от монолита на микросервисы: как определить границы сервисов, выбрать стратегию миграции и не остановить разработку.
На примере покажем, как работать со strangler pattern, декомпозировать систему по доменам, организовать работу с данными и транзакциями и избежать главной ловушки «распределённого монолита».
🔔 Урок проходит в преддверии старта курса «Микросервисная архитектура» и будет полезен backend-разработчикам, архитекторам, техлидам и DevOps-инженерам, которые работают с большими системами и планируют их эволюцию.
Зарегистрируйтесь и разберитесь, как переходить от монолита к микросервисам поэтапно без остановки бизнеса и дорогих архитектурных ошибок: https://vk.cc/d2ezcC
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
❤2🌚2👍1🎉1
Это база! Рассказываю о бесплатных функциях Google Календаря, которые упростят вашу жизнь
Google-календарь — это не просто место, где удобно записывать личные и рабочие дела. А ещё и мощный инструмент, который упростит вашу жизнь. Поделюсь моими любимыми функциями.
Читать
Google-календарь — это не просто место, где удобно записывать личные и рабочие дела. А ещё и мощный инструмент, который упростит вашу жизнь. Поделюсь моими любимыми функциями.
Читать
❤2👍2🎉1
Heisenbug 2026 Autumn: тестирование, практика и живое общение
16–17 октября в Санкт-Петербурге пройдет Heisenbug 2026 Autumn — конференция по тестированию не только для тестировщиков.
В программе есть форматы, которые рассчитаны именно на живое участие: воркшопы, где можно самостоятельно поработать с ИИ-агентами, дискуссии с коллегами и экспертами, разбор рабочих проблем и Fail Talks с историями о реальных провалах.
Эти форматы не будут записываться и не входят в онлайн-билет. Поэтому если хочется не только послушать доклады, но и попробовать инструменты руками, разобрать свой кейс и пообщаться с коллегами — будем ждать вас на конференции лично.
Подробнее о программе и форматах — в карточках.
Также приглашаем принять участие в опросе State of Testing — масштабном исследовании о том, что тормозит развитие QA и как индустрия использует ИИ. Первые результаты представят на открытии конференции, а затем пришлют подробный отчет с графиками всем участникам на email.
Среди участников опроса пройдёт розыгрыш билетов на Heisenbug 2026 Autumn.
🌟А если вы хотите приобрести персональный билет уже сейчас, то по промокоду
Изучить расписание
Купить билет
Реклама. ООО «Джуг Ру Груп». ИНН 7801341446
16–17 октября в Санкт-Петербурге пройдет Heisenbug 2026 Autumn — конференция по тестированию не только для тестировщиков.
В программе есть форматы, которые рассчитаны именно на живое участие: воркшопы, где можно самостоятельно поработать с ИИ-агентами, дискуссии с коллегами и экспертами, разбор рабочих проблем и Fail Talks с историями о реальных провалах.
Эти форматы не будут записываться и не входят в онлайн-билет. Поэтому если хочется не только послушать доклады, но и попробовать инструменты руками, разобрать свой кейс и пообщаться с коллегами — будем ждать вас на конференции лично.
Подробнее о программе и форматах — в карточках.
Также приглашаем принять участие в опросе State of Testing — масштабном исследовании о том, что тормозит развитие QA и как индустрия использует ИИ. Первые результаты представят на открытии конференции, а затем пришлют подробный отчет с графиками всем участникам на email.
Среди участников опроса пройдёт розыгрыш билетов на Heisenbug 2026 Autumn.
🌟А если вы хотите приобрести персональный билет уже сейчас, то по промокоду
godoftesting можно его купить со скидкойИзучить расписание
Купить билет
Реклама. ООО «Джуг Ру Груп». ИНН 7801341446
👍4❤2🤔1