Как протестировать доработку в программе 1С: самоучитель бухгалтера

Почему бухгалтеру важно разбираться в тестировании 1С

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

Как тестировать программы 1С

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

Проще говоря, тестирование помогает ответить на три вопроса: доработка делает то, что просили, делает это без ошибок и не мешает остальной работе в базе.

Виды тестирования программы 1С и не только

Об основных видах тестирования, которые применяют при проверке 1С, в видео рассказала Кристина Растягаева, тестировщик 1С, преподаватель курса «Аналитик 1С» в Action Digital School. Она объяснила, по каким критериям в целом классифицируют тестирование, и все разобрала на конкретных примерах.

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

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

2️⃣ Функциональное тестирование. Здесь проверяют, выполняет ли доработка свою основную функцию. Если программист сделал автоматическое заполнение реквизитов, бухгалтер смотрит, действительно ли реквизиты подставляются правильно. Если создан новый отчет, нужно проверить суммы, отборы, группировки и итоговые строки.

3️⃣ Тестирование юзабилити. Это проверка удобства. Бывает, что доработка технически работает, но пользоваться ей неудобно: кнопка спрятана, названия полей непонятные, отчет требует лишних действий. Бухгалтеру важно оценить, реально ли новая функция ускоряет работу или только добавляет путаницу.

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

5️⃣ Приемочное тестирование. Финальная проверка перед тем, как принять доработку. Бухгалтер проходит основной рабочий сценарий и смотрит, можно ли использовать результат в реальной базе. Если все работает корректно, доработку принимают. Если нет, фиксируют ошибки и возвращают на исправление.

Как протестировать конкретный функционал в 1С: пошаговый алгоритм

Шаг 1. Тестирование документации. Предположим, что нам необходимо заново разработать функционал «Продажи» в 1С:Бухгалтерии.

Итак, документация для функционала написана, мы должны ее протестировать. Что может помочь при тестировании документации:

• Убедитесь, что у вас есть вся необходимая информация по функционалу: в требованиях, переписках, в почте, в описаниях от заказчика и т.д.
• Обращайте внимание на свои ощущения: легко ли понять то, что написано, возникают ли вопросы при чтении. Саморефлексия вам поможет обратить внимание на сложности и неточности в требованиях, избавиться от ощущения «замыленного глаза».
• Можете составить чек-лист, список проверок по предоставленному требованию, нарисовать диаграммы процессов и т.д.
• Вовлекайте в процесс тестирования документации различных специалистов: тестировщиков, прожект-менеджеров, бизнес-аналитиков, разработчиков. Это позволит взглянуть на требования с разных сторон и убедиться, что команде понятно то, что написано в документации.

Шаг 2. Функциональное тестирование. Приступать к тестированию функционала можно сразу после реализации первого документа. Например, документа «Счет покупателю». Такое тестирование будет являться модульным, так как мы будем проверять один документ отдельно от всего функционала.

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

Таким образом, нашим сценарием тестирования для каждого документа будет проверка его создания и связанных документов, их заполнение и проведение.

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

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

Шаг 3. Юзабилити тестирование. После того как мы убедились, что критичных ошибок нет, то приступаем к юзабилити-тестированию. Такое тестирование лучше передавать сотруднику, который компетентен в области, которую выполняет тестируемый функционал, но еще не видел его. Важно, чтобы он в первый раз попытался протестировать ПО без документации, без инструкций. Его задача проверить, сможет ли пользователь с необходимыми знаниями в заданной области без труда выполнить задачи с помощью ИС.

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

Шаг 4. Тестирование безопасности. Затем пробуем протестировать наш функционал на безопасность. Нам из описания известно, что документы «Договор», «Счет покупателю», «Реализация», «Счет-фактура» должны быть доступны для просмотра и записи пользователям «Продавец» и «Главный бухгалтер», а документ «Поступление на расчетный счет» должен быть доступен только пользователю «Главный бухгалтер». Поэтому нам нужно зайти под каждым пользователем и проверить, может ли он создать все необходимые документы.

Шаг 5. Приемочное тестирование. После того, как мы зарегистрировали и исправили все ошибки, то можно передавать реализованный функционал заказчику. Для этого необходимо выполнить приемочное тестирование. Оно входит в процесс передачи продукта от разработчика к заказчику. В зависимости от особенностей продукта и от требований заказчика, приемочное тестирование могут проводить в различной форме: проверка им самим, конечными пользователями или специальной приемочной комиссией.

От простого пользователя к специалисту, который реально разбирается в 1С

Чем лучше бухгалтер разбирается в логике тестирования, тем увереннее чувствует себя при работе с доработками и автоматизацией. Это уже не уровень «нажать кнопку и проверить», а понимание того, как система ведет себя внутри процессов. Такой навык помогает быстрее находить ошибки, грамотно ставить задачи и сильнее ценится в компаниях, где 1С постоянно развивается.