Меня зовут Татьяна Головкина. Я руковожу группой тестирования решений 1С в департаменте ERP и учетных систем Ozon. В сфере тестирования работаю более 10 лет. Начала со специалиста по тестированию и пришла к текущей позиции руководителя группы.
Ручное тестирование
История становления тестирования во многих компаниях одинакова: изначально его нет вовсе. По мере роста количества доработок появляется ручное тестирование, которое поначалу применяется выборочно – только для отдельных задач, а не для всего объема работ.
Рассмотрим, как это происходит:
-
Разработчик. Первым шагом является ручное тестирование кода самим разработчиком. Он выполняет задачу и проверяет ее работоспособность.
-
Аналитики. Затем к тестированию подключаются аналитики. Они также вручную проверяют результат разработки на соответствие требованиям, описанным в техническом задании.
-
Специалисты по тестированию. Если в команде уже есть специалисты по тестированию, то часть задач переходит к ним. Но и они тестируют вручную.
Казалось бы, все хорошо: команда пишет, тестирует, разрабатывает и анализирует. Но чем больше становится объем задач, тем больше не хватает времени. Полностью протестировать весь объем задач становится невозможным. В этот момент начинаешь задумываться, что необходимо автоматизировать эти рутинные проверки и освободить время для других задач.
Что нас сподвигло задуматься об автоматизации:
-
Необходимость регулярных проверок.
-
У каждого продукта есть важный функционал, который пользователь использует постоянно. Такой функционал нужно регулярно проверять при каждом релизе и даже чаще.
-
Объем работ большой, он постоянно увеличивается, а свободных ресурсов не хватает.
-
Хочется исключить человеческий фактор из процесса постоянно повторяющихся одинаковых проверок.
-
Сокращение сроков выполнения регулярных проверок.
Мы начали анализировать: что у нас есть для того, чтобы начать внедрять автоматизацию.
Чем мы располагали в самом начале:
-
Windows-сервер с зарегистрированным GitLab Runner.
-
У каждой конфигурации был свой GitLab-репозиторий для ведения разработки.
-
Сборочная линия, настроенная для доставки релизов в продуктовую среду.
-
Рабочий SonarQube, на замечания которого никто не обращал внимания.
Первые автотесты
Нам предстояло проанализировать имеющиеся инструменты и решить, какой из них подходит для быстрого старта. Что использовать первым: тестер, сценарное тестирование, Vanessa-ADD, Vanessa Automation? Нам требовалось быстрое решение для проверки критически важного функционала «здесь и сейчас». Выбор пал на Vanessa-ADD, а точнее на ее компонент xddTestRunner, предназначенный для запуска дымовых тестов.
Причины выбора Vanessa-ADD:
-
Быстрый старт. Vanessa-ADD не предъявляет специальных требований для запуска в CI-контуре. Это обеспечивало быстрый старт с минимальными усилиями.
-
Масштабируемость. Так как у нас много конфигураций и они разные, соответственно, нам требовалась возможность запустить тесты во всех из них. Еще один критерий: тесты должны работать не только на управляемых формах, но и на обычных.
-
Готовые тесты. В Vanessa-ADD предоставляется готовый набор универсальных дымовых тестов для основных проверок критичного функционала: проведение документов, проверка проводок (до/после), печатные формы, макеты СКД, запись элементов и групп справочников. Без лишних усилий мы получаем готовый набор полезных проверок.
Интеграция в CI (GitLab)
Затем мы приступили к решению вопроса о том, как интегрировать тексты в CI контур. Мы воспользовались GitLab CI и работающим Windows-сервером с зарегистрированным на нем gitlab-runner. На сервере уже был установлен OneScript с нужными библиотеками, а в vanessa-runner есть встроенные команды, позволяющие запускать тесты (в том числе и тесты Vanessa-add).
Ниже представлена наша джоба для их выполнения:
|
xunit:
Вступайте в нашу телеграмм-группу
Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
HighLoad оптимизация Тестирование QA Программист 1С 8.3 Бесплатно (free)
Шесть внешних отчётов на боевой базе крупной сети переписали за неделю. По секундомеру ускорились четыре, в акт пошли три: у одного отчёта минус тринадцать процентов оказались выбросом нагрузки прода, а не эффектом кода. Поймал это чередующийся замер до/после в одном окне, обычные три прогона с метрикой "минимум" показывали ускорение уверенно.
Дальше в тексте: почему построчная сверка выхода ломается ровно на тех правках, ради которых её заводят; из чего собирается повторяемый слепок результата и почему главную работу в нём делает нормализация, а хеш только сигнализация; где слепок не берётся вовсе и его заменяет по-колоночная сверка; чем проверять пересчёт итогов, чистку данных и операции с кластером. Отдельно - гипотеза, которую замер отклонил, и честный счёт, во что вся эта дисциплина обходится.
вчера в 13:00
202
nedomolkov.ivan
0
Тестирование QA Программист Бесплатно (free)
Пентест – это не только поиск уязвимостей, но и сложный проект, в котором ошибка может привести к простою, инциденту и потере доверия заказчика. Рассказываем, как правильно определить цели и границы работ, распределить ответственность, выстроить коммуникации и сделать неизбежные риски и изменения контролируемыми. На реальных кейсах разбираем, почему задержка с сообщением о критической уязвимости способна перечеркнуть технический успех, как управленческая рамка помогла разобраться в остановке турбины и когда выход за пределы скоупа приносит пользу бизнесу, а когда становится нарушением договоренностей.
17.08.2026
334
user2181343
0
Тестирование QA Программист 1С 8.3 Россия Бесплатно (free)
Написать тест на 1С несложно. Дорого стоит привести базу в состояние, где прогон вообще стартует: семь шагов, каждый ломает запуск молча — без ошибки, без записи в журнале. И эту цену платит заново каждый новый человек на проекте. Разбираю молчаливый отказ окружения как класс проблем, показываю, почему его не закрывают ни документация, ни скрипт развёртывания, и предлагаю решение — фиксацию состояния в артефакте с машинно-проверяемым критерием приёмки. Подход проверен на сквозной задаче (первая задача экзамена «1С:Специалист по платформе» с юнит- и функциональными тестами), а затем перенесён на пул тестовых баз с типовыми конфигурациями. Отдельно — каталог симптомов и их настоящих причин, который пригодится независимо от инструментария.
13.08.2026
681
chagbig
1
Тестирование QA Программист Бесплатно (free)
Разбираем, как в крупных компаниях регуляторные требования, постмортемы и внутренние ограничения постепенно превращаются в многоуровневую систему инструкций, в которой разработчику все сложнее понять, что и когда нужно проверить. Показываем opensource-сервис внешних проверок для GitLab, который автоматизирует часть этой бюрократии и сводит результат к понятному сигналу: зеленое – все в порядке, красное – нужно обратить внимание на конкретное требование. Объясняем, как такие проверки помогают «сдвинуть влево» контроль задач и снизить риск отказа во внедрении задачи в последний момент перед релизом. А заодно смотрим, может ли связка Autumn + «Вино» + немного разработческого энтузиазма превратить обязательные инструкции в инструмент, который команда сама захочет развивать.
12.08.2026
612
Golovanoff
2
Поиск данных Тестирование QA Программист 1С 8.3 1С 8.5 Бесплатно (free)
Как мы пришли к Юнит-тестированию и почему стоит его использовать.
Использование универсальных тестов для проверки работы IS MagicInput в вашей конфигурации.
16.07.2026
1919
Evg-Lylyk
2
Тестирование QA Программист Бесплатно (free)
Tantor Postgres 18 - масштабный релиз СУБД, за которым стоят месяцы тестирования, сотни часов нагрузочных прогонов и десятки исправлений, о которых пользователь никогда не узнает просто потому, что они были найдены и устранены до выхода версии. Александр Симонов, руководитель направления развития 1С в "Тантор Лабс", рассказывает, как устроен процесс тестирования изнутри - почему одного эталонного прогона недостаточно, что делать, когда ванильный PostgreSQL 18 ломает собственные оптимизации, и как Tantor Postgres приближается к той планке, которую MS SQL Server держал годами.
07.07.2026
1351
Tantor
2
Тестирование QA Программист Бесплатно (free)
Юнит-тестирование в 1С – тема, о которой много говорят, но внедряют далеко не везде: для одних это признак зрелой разработки, для других – избыточная формальность или лишняя трата времени. Разбираем, почему классическая пирамида тестирования в 1С часто оказывается перевернутой, какие ограничения накладывает платформа и почему юнит-тесты в реальных проектах нередко смешиваются с интеграционными. Показываем, где юнит-тесты действительно помогают ускорить разработку, упростить проверку логики и повысить качество кода, а где их применение превращается в хрупкую и дорогую поддержку. Отдельно разбираем типичные ошибки: зависимость тестов от данных и окружения, избыточное мокирование, тестирование платформы вместо бизнес-логики и отсутствие негативных кейсов.
29.06.2026
2968
alexandr_yang
6
Тестирование QA Программист 1С:Предприятие 8 Бесплатно (free)
Как мы пришли к использованию Ванессы для автоматизации действий пользователей? Сначала я увидел в интернете лекцию Олега Филиппова про RPA. И когда встал вопрос про автоматизацию небольших процессов, то эта лекция у меня прекрасно соединилась с опытом тестирования программ с помощью Vanessa Automation. Минимум усилий, минимум ручного кода и высокая скорость внедрения. И самое главное, не надо менять программу. А если программа изменится, то алгоритм быстро поправить и дополнить.
19.06.2026
2103
swimdog
3
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора. № 2418640 Создание 27.06.25 14:19 Обновление 27.06.25 14:19
Просмотры
7364
Загрузки
0
Рейтинг
27
Комментарии
5
Код открыт
Да
Рубрики
Тестирование QA
Кому
Программист
Тип файла
Нет файла
Платформа
Не имеет значения
Конфигурация
Универсальные
Операционная система
Не имеет значения
Страна
Не имеет значения
Отрасль
Не имеет значения
Налоги
Не имеет значения
Вид учета
Не имеет значения
Доступ к файлу
Бесплатно (free)
|
