Всем привет! Я продолжаю цикл статей про применение ИИ в тестировании. Мы уже разобрали shift-left: контекст, тестирование требований, генерацию тестовой документации, автотесты и оптимизацию тестовой модели. Но даже когда кейсы написаны, а автотесты готовы, остаётся задача, на которую может уходить довольно много времени — это подготовка тестовых данных для ручного тестирования.

Всем привет! Я продолжаю цикл статей про применение ИИ в тестировании. Мы уже успели поговорить про анализ требований, создание тестовой документации и автотесты, т.е. разобрали весь shift-left с ИИ. Но у QA-инженера есть много других задач, с которыми ИИ также может помочь.

И одной из таких задач является актуализация тестовой модели. Когда она может потребоваться? Когда продукт существует уже не первый год, тест-кейсов накопилось много, они написаны разными людьми в разное время по разным шаблонам, а требования к продукту успели поменяться. В TMS накапливаются дубликаты, устаревшие шаги и кейсы, которые логичнее было бы объединить. Разбирать всё это вручную долго и дорого, и редко когда у команды есть ресурс на такой разбор. Вот тут-то вам может пригодится ИИ.

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

Всем привет! Меня зовут Алена, и я продолжаю свой цикл статей про применение ИИ в тестировании. Следующий этап в shift-left подходе — это автоматизация. А в нашем случае — генерация автотестов с помощью ИИ.

После успехов с требованиями и тестовой документацией мне казалось, что дальше всё будет ещё проще. Однако первый pull request оказался настолько «удачным», что его разбор занял почти две недели.

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

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

Привет, Хабр! Меня зовут Дмитрий, я руководитель проектов в РГС. И я решил рассказать, как я собирал свою умную дачу в лучших традициях, то есть «от балды». Вот здесь можно прочитать первую часть про, с чего вообще все началось и почему я взялся за модернизацию своего дома из 80-х.

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

Привет, Хабр! Меня зовут Алена Метенева, я руководитель направления по тестированию в Росгосстрахе. А это третья статья цикла про внедрение ИИ в тестирование.

В первой статье я рассказывала, зачем мы вообще пошли в пилот и почему начали с ручного режима в Cursor. Во второй разбирала подготовку контекста: от простого кейса до больших ТЗ с PDF, диаграммами и макетами.

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

Всем привет! Продолжаю цикл статей про применение ИИ в тестирование. Сегодня поговорим про тестирование требований, а именно про первый и самый важный этап — подготовку контекста. 

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

Всем привет! Меня зовут Алена Метенева, я руководитель направления по тестированию в Росгосстрахе. Я специализируюсь на внедрении ИИ-инструментов в процессы тестирования. И сегодня хочу рассказать вам о том, как мы в Росгосстрахе провели пилот по внедрению нейросетей в тестирование и как сейчас масштабируем результаты на другие команды.

Привет, Хабр! Недавно я писала о том, как понять, что ваш IT-проект летит в тартарары, и что делать, если это уже случилось, и в комментариях мне задали резонный вопрос: «А что делать руководителю, чтобы проект в принципе не пришлось "спасать"?».

Панацеи тут нет. Но давайте разберемся.

В мире есть два типа руководителей проектов: те, у кого всё горит, и те, у кого всё горит, но они умеют это скрывать :)

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

Я побывала в обеих ипостасях. В этой статье собрала выжимку из граблей, на которые я наступала, и перил, за которые успевала схватиться.

Меня зовут Полина, я 9 лет работаю в РГС, и почти два года из них вожу настольно-ролевые игры в нашей компании. За это время мы успели побывать волшебными котятами в Хогвартсе, американцами 20-х годов, расследующими мистические происшествия, персонажами фентези в Забытых Королевствах и даже воскресили Ильича (что, кстати, довольно символично).

Казалось бы, чем занимаются серьезные люди? Но между тем НРИ — это отличный способ отдохнуть после работы, завести новые связи и развить свои софтовые навыки.

Привет, Хабр! Меня зовут Сергей, я руковожу управлением операционных технологий в РГС. Недавно мы с командой обсуждали вопрос: «А что эффективнее сегодня: робот или AI-агент?».

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

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

Поэтому в этой статье я хочу рассмотреть актуальность RPA сегодня, плюсы и ограничения каждой технологии, взаимодополняющие архитектурные паттерны и разобрать реальный кейс РГС (как и зачем мы объединили роботов и ИИ).

Понедельник, 09:00. У вас есть четкий план на неделю, вы спокойно допиваете свой кофе
и планируете начать работу, как вдруг:

Вариант А: Прилетает рассылка, которая перечеркивает все планы. Ваш начальник решил, что «с сегодняшнего дня мы работаем по-новому». Зачем и почему, кончено же, никто объяснять не станет. Просто так надо, так сейчас «все работают, и мы тоже будем».

Вариант Б: Руководитель пишет, что ваша идея гениальна. И больше на этой неделе вы его не увидите, обсудить процесс реализации «гениальной идеи» тоже не получится. Зато
в пятницу он ловит вас в коридоре, выдает еще три новых идеи и исчезает в лифте.

Вариант В: Вы предлагаете крутую идею. Руководитель молчит, смотрит сквозь очки, задает три вопроса по цифрам и сухо резюмирует: «Жду расчетов».

Если хотя бы один вариант отозвался холодком в спине — поздравляю, вы работаете не просто с менеджером. Вы работаете с олимпийским божеством.

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

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

Живой пример

Однажды мне в руки «по наследству» от предыдущего руководителя достался проект по автоматизации взаимодействия с подрядчиками. Задача важная: подрядчиков более 50, привлекаемых сотрудников — несколько тысяч, за всеми нужен учёт и контроль, который на тот момент осуществлялся полностью вручную, и занимался этим не один-два человека, а аж целый отдел. Неудивительно, что внутренний аудит это не устраивало, и нам было велено «срочно все автоматизировать». Генеральный директор поставил свою визу и отметил в календаре дату, когда ему нужен результат — через год.

Привет, Хабр! Меня зовут Иван, я руководитель отдела тестирования фронт-офисных и интеграционных систем в РГС.

В этой статье я хочу посмотреть на ключевые ценности Agile не сквозь розовые очки, а через призму управленческой практики. Разобрать, как они на самом деле работают, где помогают, где ломаются и что с этим делать тем, кто отвечает за результат.

Привет, Хабр! Меня зовут Дмитрий, я руководитель проектов в РГС. Недавно коллеги запустили сервис по интеграции страховки в экосистему умного в коллаборации со spruthub и рассказали, как бы собирали свой первый умный дом с нуля (вот тут). А я в этой связи решил тоже поделиться опытом, как собирал свою умную дачу на практике в лучших традициях, то есть «от балды».

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

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

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

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

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

Привет, Хабр! Меня зовут Николай, я начальник управления клиентских коммуникаций РГС. Мы, как и большинство компаний на рынке сегодня, стараемся оптимизировать процессы с помощью искусственного интеллекта (ну а как иначе?). Но есть нюанс: недавно я задумался, как часто я сам, будучи адептом внедрения ИИ в контакт-центр, прошу голосового помощника позвать оператора. И, как оказалось, — очень часто.

Привет, Хабр! Меня зовут Максим, я тестировщик в РГС. Сейчас мы с командой разрабатываем новое приложение для клиентов, и нам очень хотелось, чтобы у нас была прозрачная картина актуальности и полноты тестового покрытия, для повышения качества выпускаемого продукта и эффективности процессов.

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

Привет, Хабр! Меня зовут Катя, я начальник отдела методологического сопровождения проектов в РГС. Как руководителю мне постоянно приходится балансировать между контролем (чтобы всЁ работало) и свободой действий (чтобы всЕ работали). И на практике это куда сложнее, чем кажется. Поэтому хочу обсудить, как правильно передавать полномочия в IT-команде, какие задачи тимлид должен оставить себе и где проходит грань между развитием сотрудников и банальной эксплуатацией.