Привет, Хабр! На связи QA-специалисты SimbirSoft Алена и Светлана. В компании мы тестируем проекты 1С в составе выделенной команды или на усилении команды заказчика. 

Сегодня платформа 8.3 компании 1С — популярный и востребованный продукт на рынке учетных систем СНГ, несмотря на различные мнения коллег по разработке. Комьюнити 1С расширяется, и материалов для изучения становится всё больше. Но наши коллеги часто ломают голову над тем, как подступиться к тестированию 1С:Предприятие и автоматизировать процесс.

1С это целая экосистема, которая имеет свои особенности и специфичные термины. Поэтому сегодня разберем виды, порядок, инструменты и особенности тестирования 1С, автоматизацию и подход к подготовке документации на примере одного из проектов. Если вы QA, AQA или SDET, тимлид или продукт-оунер на платформе 1С — эта статья для вас.

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

Даже опытный QA, когда впервые погружается в 1С, сталкивается с неизвестной ему терминологией — например, «Платформа» или «Конфигурация». Без знания этих фундаментальных понятий будет очень сложно разобраться в работе с 1С.

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

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

Одним из примеров является применение 1С для кинотеатра:

Виды тестирования 1С

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

Общий порядок тестирования может иметь такой вид:

1. Тестирование разработчиком собственного кода.

2. Ревью кода — тестирование кода другими разработчиками.

3. Ручное функциональное тестирование QA-командой.

4. Автоматизированное нагрузочное тестирование и оптимизация быстродействия, проводимая ответственным за этот аспект специалистом. Это может быть QA fullstack, SDET-специалист или отдельная команда.

Каждый этап проверки важен и может выявить разные типы проблем:

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

2. Код-ревью направлено на выявление несоответствий написанного кода внутрифирменным стандартам.

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

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

Обратимся к тестированию, которое проводим мы как QA-специалисты.

Функциональное тестирование 

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

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

• Негативные сценарии — проверка реакции программы на ввод некорректных входных данных, их полное или частичное отсутствие

Тесты должны выполняться от имени пользователей с ограниченным уровнем доступа (не Администратора). Важно также правильно оформить тесты — каждый из них должен содержать подробное и четкое описание действий. Это позволяет исключить возможность неправильной трактовки теста и, как следствие, неверного его проведения. 

Всё это уже знакомо опытным QA-специалистам, так что если придется столкнуться с функциональным тестированием продуктов 1С, вам не составит труда переложить свой опыт для тестирования данной платформы.

Автоматизированное тестирование

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

• Vanessa Automation — open sourceприложение, которое находится в свободном доступе. На github всегда можно найти бесплатную и последнюю версию Ванессы 1С. Использование инструмента упрощает задачу разработчикам, позволяя экономить время на написании сценариев тестирования вручную и более того автоматизировано создавать видеоматериалы в качестве инструкции для пользователя.

• 1С:Тестировщик — конфигурация от 1С, используется для работы с одним сценарием.

• 1С:Сценарное тестирование — конфигурация от 1С, которая состоит из двух внешних обработок: одна предназначена для записи теста, вторая – для его выполнения. Имеет достаточно простой и понятный интерфейс, который позволяет проводить тестирование без навыков и знаний в программировании, если вы имеете общее представление о свойствах тестируемой конфигурации.

• 1С:Автоматическое тестирование конфигураций — конфигурация от 1С, тестирование без предварительной настройки сценариев и алгоритмов, они уже имеются в программе и применимы для любых конфигураций. Участие пользователя минимально – достаточно просто запустить тестирование, и затем система формирует отчет о различиях и ошибках.

Особенности тестирования 1С 

Одной из главных особенностей 1С является синтаксис, ведь он здесь русскоязычный. По структуре 1С можно сравнить с Pascal и BASIC.

Таким образом, тестирование с помощью составления запросов к БД 1С будет проходить на русском языке.

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

Поэтому ручное тестирование силами разработчиков имеет два серьезных недостатка:

1. Отнимает дополнительное время и усилия.

2. Разработчик может пропустить ошибки из-за невнимательности или из-за другого подхода к проведению тестирования. Всё же разработчики и QA-специалисты нацелены на разные нюансы.

По этим причинам в дополнение к ручному тестированию используется автоматизированное. Для этого можно использовать разные инструменты, но в основе лежит механизм автоматизированного тестирования, встроенный в саму платформу 1С.

Как проходит автоматизация тестирования 1С

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

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

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

• Менеджер тестирования — клиентское приложение, запущенное для исполнения сценария тестирования и оценки результатов в случае необходимости. Менеджерами тестирования могут выступать только толстый или тонкий клиенты. Запуск может осуществляться:

  — из командной строки с помощью ключа /TESTMANAGER, например:

  "C:\Program Files (x86)\1cv8\8.3.2.163\bin\1cv8.exe" ENTERPRISE /F C:\Users\username\Documents\InfoBase /TESTMANAGER

  — из Конфигуратора. Для этого в параметрах конфигуратора можно установить режим запуска клиентского приложения:

Запускать как менеджер тестирования (Сервис → Параметры → Запуск 1С:Предприятия → Дополнительные → Автоматизированное тестирование):

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

  — из командной строки с помощью ключа /TESTCLIENT, например:

  "C:\Program Files (x86)\1cv8\8.3.2.163\bin\1cv8.exe ENTERPRISE /F C:\Users\username\Documents\1C\Platform82Demo /N Администратор /TESTCLIENT" -TPort 1537

  При помощи параметра TPort указывается номер порта, через который будет вестись взаимодействие менеджера и клиента тестирования. Если этот параметр не указан в командной строке, то по умолчанию будет использован порт 1538.

  — интерактивно из Конфигуратора. Для этого по аналогии с запуском менеджера тестирования, переходим по цепочке:

Сервис → Параметры → Запуск 1С:Предприятия → Дополнительные → Автоматизированное тестирование → Запускать как клиент тестирования. 

Не забудьте при этом указать номер используемого порта:

План действий при автоматизированном тестировании в 1С

1. Разработать сценарий тестирования. Это можно сделать двумя способами: либо написать его вручную в менеджере, либо записать свои действия на клиенте тестирования, выгрузить их в XML-файл и на его основе создать сценарий тестирования. Для его написания используется модификация языка Gherkin, которая разработана специально для использования с платформой 1С:Предприятие. Это человекочитаемый язык для описания поведения системы.

2. Запустить первый экземпляр 1С предприятия в режиме менеджера тестирования.

3. Запустить второй экземпляр 1С предприятия в режиме клиента тестирования.

4. Установить TCP-соединение между менеджером и клиентом тестирования. Менеджер тестирования может быть подключен к нескольким клиентам, а клиент может быть подключен только к одному менеджеру.

5. Запустить сценарий в менеджере, который будет выполнять все действия на клиенте тестирования. По завершении теста результат будет зафиксирован в менеджере.

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

Документация 1С 

На проекте мы сталкивались с тем, что если продукт 1С внедрялся для пользователей, ранее не работавших с платформой, им было трудно разобраться в продукте и функциональности. Им был непривычен интерфейс, название кнопок. К тому же процессы, настраиваемые в 1С, часто относятся к юриспруденции, а они всё же сложны в понимании для новичков. 

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

Для пользователей продуктов 1С существуют общедоступные ресурсы с описанием функциональности, например, Информационная система 1С:ИТС. Однако если вы используете продукты 1С для своих нужд и адаптируете функциональность для конкретных локальных задач, встает необходимость в написании документации для разработчиков продукта — то есть команды, так и в написании инструкции для пользователей.

Пример: ведем прозрачную документацию на проекте

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

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

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

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

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

Для него используются инструменты, применяемые разработчиками для написания кода: IntelliJ IDEA и GitLab. При написании документации используется язык разметки (в нашем случае это был AsciiDoc). Стоит отметить, что разметка AsciiDoc весьма проста и интуитивно понятна, а возможности с помощью применения дополнительных инструментов открываются значительные. К тому же AsciiDoc можно конвертировать во многие форматы (HTML, PDF, docx).

Использование инструментов разработчика в таком подходе позволяет вести документацию абсолютно прозрачно: можно увидеть, кто вносил изменения, когда и что именно редактировалось в документации. Можно настроить доступ и просмотр всех изменений в одном месте для всех членов проекта: аналитика, разработчика, QA, других членов команды. И используя CI/CD, можно настраивать публикацию документов для пользователей – например, в Confluens.

Заключение

Учитывая особенности 1С и исходя из собственного опыта, можем сказать, что специалистам по тестированию стоит относиться к продуктам 1С как к обычным десктоп- или веб-приложениям, просто адаптируя свои навыки. 1С отличается от других программ так же, как тестирование одного приложения от тестирования другого — в каждом продукте свои особенности, у каждого приложения своя тонкая настройка. Да, в 1С используются специфические программы, но изучение любых новых инструментов может вам потребоваться для любого стека. Всё это можно отнести к общим особенностям работы в сфере IT. 

Конечно, отличительные черты 1С все же есть. Система начала свою историю с далёкого 1991 года, и некоторые подходы к ПО сложились и устоялись исторически. В том числе поэтому интерфейс для современного пользователя может казаться перегруженным. Могут быть непривычны исторически сложившиеся названия кнопок и весь интерфейс на русском языке (например, кнопка «Перечитать» более привычна под названием «Обновить», кнопка «Ещё» в современных приложениях обозначена как «Настройка», кнопки «Да»/«Нет» в большинстве приложений встречаются как «Применить»/ «Отмена»). Функциональность 1С используется для таких сфер, как бухгалтерия, логистика, документооборот, юриспруденция, управление предприятием и другие, поэтому вам потребуется время на адаптацию и знакомство со спецификой направления. 

В остальном набор компетенций для QA-специалиста в 1С не сильно разнится с коллегами по тестированию других проектов:

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

• Теория тестирования — основа знаний каждого специалиста по обеспечению качества

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

• Знание программных продуктов 1С. Некоторые инструменты достаточно сложные, и в них надо последовательно погружаться. Если у вас есть опыт работы с программными продуктами 1С или профессиональные знания в какой-то из областей учета, то это будет хорошим преимуществом. Но его отсутствие не является проблемой. В большинстве случаев программные продукты изучаются в процессе работы, этому посвящены первые дни новичка в 1С. Для эффективного погружения мы в SimbirSoft закрепляем за каждым новым сотрудником ментора и содействуем повышению квалификации специалистов на курсах и сертификациях. Для направления тестирования 1С это сертификаты «1С:Профессионал» и «1С:Специалист-консультант» по различным прикладным решениям компании 1С. 

Спасибо за внимание!

Авторские материалы для QA-специалистов мы также публикуем в наших соцсетях – ВКонтакте и Telegram.