- +7 (495) 120-87-87
- info@ls-gp.com
- ПН - ПТ: 9:00 - 18:00
Статья на тему:
Тестирование — страховка инвестиций во внедрение 1С на производстве
Вы решились бы купить автомобиль без тест-драйва? Скорее всего, нет. Вы понимаете, что характеристики машины на бумаге и поведение ее на дороге, разные вещи. Внедрение 1С:ERP или комплекса программ 1С — это та же покупка сложного механизма. Только вместо дороги производственный учет, вместо тормозов — расчет себестоимости, а вместо подушек безопасности — контроль за складскими остатками.
В статье расскажем, к чему приводит отказ от тестирования. Разберем, чем программа и методика испытаний (ПМИ) отличается от сценариев, зачем нужны протоколы тестирования и почему автоматические тесты не всегда лучше ручных. Материал статьи поможет вам понять, как принять работу подрядчика и запустить систему 1С без финансовых рисков.
Риски формального подхода к тестированию
Тестирование для собственника бизнеса, руководителя или финдиректора — это не про «баги» и «фичи». Это про деньги. На этом этапе решается, окупятся ли вложения в 1С или проект превратится в источник бесконечных доработок и постоянных расходов:
- финансовые потери — ошибки в расчетах себестоимости, списании материалов или начислении затрат делают управленческую отчетность недостоверной;
- операционные сбои — некорректная работа системы может остановить отгрузки, нарушить производственное планирование или заблокировать закрытие периода. В итоге клиенты недовольны и уходят к конкурентам, а бизнес теряет свою репутацию на рынке и рушится;
- репутационные издержки — пользователи саботируют новую систему, потому что с первого дня столкнулись с ошибками. Так, неудачный запуск подрывает доверие сотрудников компании к новой системе учета.
В нашей практике были проекты, где тестирование заказчик воспринимал как формальность «нажать кнопки» или сокращал бюджет проекта и совсем отказывался от проверки работоспособности системы 1С. Итог был предсказуем: после запуска выяснялось, что себестоимость считается неверно, складские остатки не соответствуют действительности, а ошибки в учете растут как снежный ком. Услуги исправления 1С в рабочей базе обходились бизнесу в несколько раз дороже, чем качественная проверка работы системы 1С на этапе внедрения.
Пример из практики. В одном проекте заказчик очень торопился, и тестирование решили проводить точечно, по принципу «быстро проверили кусочек — поехали дальше». В результате мы исправляли одну ошибку — появлялась другая, чиним ее — находим третью. Мы ходили по кругу. Проект стоял на месте. Заказчик задавал одни и те же вопросы: «А это работает? А это? А почему это не работает?». И только когда мы внедрили систему тестирования с протоколами и сценариями, процесс сдвинулся с мертвой точки.
Важно. Качественное тестирование — это инвестиция в спокойствие и стабильность бизнеса на годы вперед. Лучше заплатить за проверку работоспособности системы 1С во время разработки, чем потом долго, дорого и больно ликвидировать последствия ошибок в рабочей базе.
Считаем деньги: аренда 1С в облаке vs свой сервер
Функциональная проверка работоспособности ИТ-системы в проекте внедрения 1С:ERP/1С:КА/1С:УТ — это стратегический этап управления рисками, который позволяет проверить:
- соответствует ли система 1С требованиям бизнеса;
- корректно ли работают бизнес-процессы.
Что тестирование дает бизнесу
1. Прозрачность статуса проекта.
Тестирование позволяет увидеть, на какой стадии находится проект внедрения 1С:ERP или других программ 1С. Заказчик видит функционал, который уже прошел проверку и подтвержден протоколами тестирования (о протоколах рассказываем ниже). Это снимает неопределенность — главный источник стресса при запуске.
2. Управление бюджетом.
Техническая ошибка сразу дает о себе знать, т.е. она появляется на экране, а логическая, например в расчетах, может проявиться спустя несколько месяцев работы в системе и исправить ее будет в разы сложнее. Ошибку, которую определили на этапе разработки, эксперты LS Group исправляют за несколько часов. Та же ошибка, если ее обнаружат после запуска системы 1С, тянет за собой проблемы в учете при сдаче отчетности, при отгрузке товара или проведении инвентаризации. Это может грозить бизнесу: простоями производства, авральными доработками в рабочей базе и дополнительными финансовыми затратами.
3. Инструмент уточнения требований.
Часто заказчик утверждает техническое задание на внедрение 1С:ERP или комплекса программ 1С, и кажется, что задачи будущей ИТ-системы продуманы, учтены все требования. Но когда пользователи начинают работу в программе, приходит понимание: «А нет, мы хотели иначе». Тестирование позволяет поймать этот момент до того, как система 1С уже запущена в промышленную эксплуатацию.
В процессе тестирования заказчик видит систему 1С в действии и у него появляется возможность сказать: «Здесь нам будет неудобно, давайте сделаем по-другому». И это нормально. Потому что тестирование работает не только на поиск ошибок, но и на валидацию требований.
Пример из практики. Мы разрабатывали мобильное приложение для производства. Согласовали и построили архитектуру для мобильной платформы, которая закрывала 90% бизнес-процессов заказчика. В ходе разработки специалисты LS Group выяснили, что есть еще один процесс, который не укладывался в предложенную архитектуру, он полностью выпадал из общей логики решения. Мы внесли изменения в архитектуру под этот процесс. И следующим шагом надо было протестировать его работу. Для этого мы написали сценарий тестирования, пошаговый план действий пользователя в приложении. А когда продемонстрировали сценарий заказчику, он сказал: «А, так это будет так работать? Нет, нам неудобно, давайте по-другому».
В результате мы пересмотрели проектное решение и вернулись к исходной архитектуре мобильной платформы, дополнительные доработки не потребовались. Сценарий тестирования сработал как инструмент «примерки». Заказчик увидел шаги, которые будет совершать его сотрудник в приложении. Это позволило уточнить требования до того, как началась доработка. Так, мы сэкономили бюджет проекта и сократили сроки внедрения, а заказчик получил мобильное приложение, которое решает задачи бизнеса и удобно для пользователей.
Неочевидные, но важные плюсы тестирования
Тестирование требует от специалистов LS Group детального погружения в специфику учета производства заказчика. Время, потраченное на проверку, дает практические результаты для бизнеса, которые экономят ресурсы уже после запуска системы:
- сокращение времени на адаптацию сотрудников. Инструкции для пользователей мы готовим детально, на основании реальных действий сотрудников.
- повышает скорость реакции на запросы сопровождения после запуска. Экспертам LS Group не нужно заново изучать специфику вашего производства — это уже сделано в ходе тестирования. Любая доработка или консультация занимает меньше времени, а значит, обходится дешевле.
Три документа тестирования, которые защищают бюджет проекта
Тестирование при внедрении 1С:ERP или комплекса программ 1С дает результат только тогда, когда оно опирается на четкую документацию. Без нее процесс становится неуправляемым: непонятно, что уже проверено, что еще нет, и на каком основании принимать решение о готовности всей системы 1С к промышленной эксплуатации. Для организации тестирования на проекте внедрения ERP системы 1С мы используем три документа:
- программа и методика испытаний (ПМИ);
- сценарии тестирования;
- протоколы тестирования.
Программа и методика испытаний
Программа и методика испытаний (ПМИ) – документ (Рис. 1.), который систематизирует и формализует процесс тестирования. Он определяет цели, задачи, объем, методы, критерии и порядок проведения испытаний программного продукта, например, при внедрении 1С:ERP под ключ или при переходе с 1С:КА на 1С:ERP и отвечает на вопрос: «Что будем проверять и как поймем, что система 1С работает правильно?».
ПМИ мы разрабатываем на основе аудита, концепции решения и технического задания (ТЗ), о которых подробно рассказали в статье «Аудит и план проекта: с чего начать внедрение 1С на производстве, чтобы не слить бюджет».
Что внутри ПМИ:
- описание доработанных и типовых процессов, которые должна выполнять система;
- способы проверки каждого процесса: какие шаги необходимо выполнить пользователю;
- ожидаемый результат, который подтвердит работоспособность процесса.
Рис. 1. ПМИ. Фрагмент рабочей документации
Сценарии тестирования — скрипт для проверки
Если ПМИ — это стратегия, то сценарий — тактика. Сценарий тестирования отвечает на вопрос «как это проверить?». Главная задача сценариев: повторить реальную работу пользователей, охватить максимальное количество кейсов при проверке и комплексно отразить рабочий процесс.
Тестирование — это пошаговая инструкция (Рис. 2.), которая описывает действия пользователя в системе 1С для выполнения конкретной бизнес-операции: какие кнопки нажимать, какие данные вводить, в какой последовательности. Сценарии тестирования связаны друг с другом, один сценарий идет совместно с другими, без отрыва или один сценарий ссылается на другой.. Такой подход делает весь процесс связанным, логичным и понятным.
Рис. 1. ПМИ. Фрагмент рабочей документации
Важно. Сценарий тестирования должен охватывать всю цепочку бизнес-процесса. Если мы изменили логику одного учетного документа, например, заказ поставщику, эта доработка может повлиять на расчет себестоимости или корректность последующих отчетов. Поэтому эксперты LS Group проверяют работу бизнес-процесса целиком, а не только доработанный фрагмент.
Протоколы тестирования
Результат тестирования мы фиксируем в протоколе (Рис. 3.). Эксперты LS Group сравнивают два результата: ожидаемый (как должно работать) и фактический (что получили). Если они совпадают — тестирование пройдено. Если нет — делаем скриншот, описываем ошибку и отправляем задачу на доработку. Для оперирования кодами ошибок мы ведем сквозную нумерацию ошибок — баг трекер. После исправления ошибки проводим повторное тестирование.
Рис. 3. Протокол тестирования. Фрагмент рабочей документации
Важно. ПМИ, сценарии и протоколы делают процесс тестирования на этапе разработки ERP системы прозрачным для всех участников проекта. Заказчик видит, какие процессы уже проверены и закрыты, какие еще в работе. Руководитель проекта получает объективную картину статуса разработки, а команда разработки — четкие, формализованные и зафиксированные задачи на доработки.
Автоматизированное или ручное тестирование
Частый вопрос от заказчиков: «А можно все прогнать автотестами, чтобы быстрее и дешевле?». Да, можно, но не нужно. Автоматизация — это инструмент, а не волшебная палочка. На проектах внедрения 1С:ERP или других программ 1С мы используем три подхода к тестированию: ручное, автоматизированное и гибридное. Давайте разбираться, какой подход выбрать.
Автоматизированное тестирование
Автотесты хорошо работают, когда нужно проверить множество однотипных операций. Например, в системе есть документооборот с несколькими статусами: документ создан, документ подписан, документ закрыт. Если таких документов десятки, а у каждого есть несколько типов, количество возможных комбинаций очень большое. Вручную проверять каждую из них долго и утомительно. В таких случаях логично передать проверку автотестам.
Важно. Автотест — это программа, которая автоматически выполняет проверку работы бизнес-процесса. Но сначала надо описать сценарий тестирования, а потом написать код проверки, настроить и отладить. Это отдельная работа специалистов по внедрению 1С:ERP и других систем 1С, которую нужно планировать и закладывать в бюджет проекта.
Ручное тестирование, когда лучше выбрать
Во-первых, если процесс сложный, с отраслевыми особенностями учета, автоматизация часто проигрывает. Писать скрипт под каждый нюанс долго и дорого. В таких случаях надежнее протестировать систему 1С вручную.
Во-вторых, ручное тестирование незаменимо, когда нужно проверить и оценить, удобство интерфейса для пользователя, например, не приходится ли делать лишних кликов при выполнении типовой операции или насколько быстро пользователь находит нужный документ.
В-третьих, только ручная проверка выявляет логические ошибки. Например, когда система технически сработала без сбоев, но результат выдала неверный. Автотест покажет, что все работает, а консультант-аналитик заметит, что себестоимость посчиталась с ошибкой.
Гибридный подход
На крупных производственных проектах внедрения 1С:ERP или комплекса программ 1С мы комбинируем ручное и автоматизированное тестирование. Такой подход позволяет направить экспертизу консультантов-аналитиков на интеллектуальные функциональные проверки, а рутину — доверить алгоритмам. В результате заказчик получает решение 1С, которое работает на задачи бизнеса и все это без переплаты за избыточную автоматизацию.
|
Примеры задач
|
Подход
|
Почему
|
|---|---|---|
|
Проверка расчетов себестоимости при 1 тыс. вариантах входных данных
|
Автотесты
|
Скорость, точность, повторяемость
|
|
Оценка удобства интерфейса
|
Ручное тестирование
|
Субъективная оценка, контекст использования
|
|
Проверка целостности процесса «заказ → выпуск → отгрузка»
|
Ручное тестирование
|
Сложная логика, ветвления, принятие решений
|
Двухконтурная система тестирования LS Group
Тестирование — это совместная работа исполнителя и заказчика. Без участия ключевых пользователей проверить систему 1С полноценно невозможно. Чтобы гарантировать заказчику качественное тестирование, в проектах внедрения 1С:ERP или комплекса программ 1С мы выстраиваем два контура тестирования: внутренний и внешний.
Внутренний контур тестирования
Первый этап. Базовая проверка разработчиком
Разработчик LS Group проводит первичную проверку работоспособности своего кода перед передачей задачи тестировщику. Это базовый фильтр, который отсеивает элементарные ошибки, например, отсутствие реакции интерфейса на действия пользователя. Такой подход сокращает количество возвратов задач на доработку и экономит время команды проекта.
Важно. Если этот уровень пропустить, тестировщик потратит время на поиск очевидных ошибок, вернет задачу разработчику, а тот вынужден будет заново погружаться в контекст. В итоге неконтролируемое количество доработок, рост трудозатрат и срыв сроков проекта.
Второй этап. Функциональное тестирование консультантом-аналитиком
Консультант-аналитик одинаково хорошо знает и специфику бизнеса заказчика, и функционал 1С, проверяет бизнес-сценарий целиком, как это будет делать реальный пользователь. На этом этапе тестирования часто всплывают ошибки, когда технически все исправно, но бизнес-логика нарушена. Например, документ проводится без сбоев, но себестоимость считается с искажением, или материалы списываются не с того склада. Такие логические разрывы может выявить только специалист, который понимает контекст учета заказчика. Он выявляет эти ошибки и возвращает задачу на доработку разработчику.
Рекомендация. Функциональное тестирование лучше доверить консультанту-аналитику, а не тестировщику. Тестировщик проверяет систему по инструкции: если в сценарии не прописано «проверить остаток на складе», он этого не сделает. А консультант-аналитик проверяет не отдельную функцию, а целостность процесса, например, заказ сформирован → материалы списаны → операции закрыты → себестоимость рассчитана верно. Потому что только так можно выявить логические ошибки на этапе разработки и избежать глобальных доработок уже в рабочей базе 1С.
Внешний контур тестирования
После внутреннего тестирования мы демонстрируем заказчику функционал решения. Далее два варианта развития событий. Первый, заказчик принимает разработку по итогам внутреннего тестирования. Второй, переходит к внешнему контуру тестирования, а потом принимает результаты разработки системы 1С.
На этапе внешнего тестирования функциональную проверку работы решения 1С проводят сотрудники заказчика. Тестирование системы 1С проводим по тем же сценариям, которые использовали специалисты LS Group (если у заказчика есть свои сценарии — работаем по ним).
Алгоритм внешнего тестирования:
- ключевые пользователи заказчика проверяют работоспособность системы 1С, например, создают заказ, списывают материалы, закрывают смену;
- консультант-аналитик LS Group отвечает на вопросы и помогает, если что-то не получается;
- сотрудники заказчика фиксируют расхождения и возвращают задачу на доработку.
Важно. Внедрение новой системы — это новые алгоритмы, интерфейс и логика. Не стоит сразу пытаться из новой программы сделать старую, в первую очередь стоит обратить внимание на то, покрывает ли новая программа потребности заказчика или нет.
Рекомендация. Закладывайте время сотрудников для тестирования на старте проекта внедрения 1С:ERP или комплекса программ 1С. Объясните команде, что это возможность повлиять на результат внедрения. Чем раньше ваши сотрудники увидят систему в действии и скажут «так удобно» или «так нет», тем дешевле обойдется любое изменение.
Ответы на часто задаваемые вопросы
По документам. Если по каждому блоку есть подписанные протоколы тестирования, где зафиксированы результаты проверки по каждому сценарию, значит, система прошла полноценную проверку. Если документов нет — процесс был формальным.
Мы гарантируем, что система прошла все запланированные проверки по согласованным сценариям и готова к запуску. Полностью исключить риски нельзя, но качественное тестирование сводит их к минимуму.
Сотрудники могут оценить и функционал, и удобство работы в новой системе 1С. Только они знают свои процессы изнутри и могут сказать: «Здесь нам неудобно, здесь лишние действия, а здесь не хватает контроля». Во время тестирования сотрудники привыкают к новому функционалу. Это крайне важно для знакомства с программой.
Без участия ключевых пользователей вы рискуете получить технически исправную систему, но, если интерфейс окажется неудобным или будет непонятна логика процессов, сотрудники начнут саботировать работу в новой системе 1С.
Важно. Тестирование исполнителем должно быть выполнено качественно. Если это не так, то пользователи системы 1С будут сталкиваться с ошибками на этапе внешнего тестирования и получат негативный опыт работы с новой системой. Поэтому передача функционала на проверку сотрудникам заказчика — это крайне ответственный и важный этап проекта внедрения 1С:ERP или комплекса программ 1С..
Это нормальная ситуация: когда пользователь видит систему в действии, требования часто уточняются. Мы фиксируем изменение, оцениваем его влияние на сроки и бюджет, и вместе принимаем решение: включить изменения в текущий проект внедрения или перенести на этап развития и сопровождения системы.
Это важно делать продуманно. Нет смысла передавать на тестирование пользователям взаимосвязанные блоки, если не все из них готовы. Заказчику важно проверить сразу бизнес-процесс, а не отдельную его часть. Поэтому мы тестируем функциональные блоки по мере их готовности. Параллельное тестирование и разработка снижают риск множества доработок в конце проекта, когда все ошибки всплывают одновременно.
Около 30% от общего времени разработки. Сроки зависят от сложности процессов и количества доработок. На этапе предпроектного обследования мы рассчитаем точный объем работ под ваш проект.
Заключение
Тестирование в проекте внедрения 1С на производстве — это страховка того, что ваши деньги и время не окажутся заложниками человеческого фактора после запуска. Проверка работоспособности системы 1С в процессе разработки позволяет закончить проект в срок и защищает ваш бюджет от расходов на исправление ошибок в рабочей базе. Грамотно организованное тестирование помогает:
- ускорить приемку работ;
- снизить стоимость владения системой;
- повысить качество и стабильность работы решения 1С;
- улучшить компетенции команды и создать единое понимание работы бизнес-процессов.
Хотите, чтобы система 1С работала стабильно с первого дня? Приходите на консультацию
Обсудим вашу задачу и покажем, как можно защитить бюджет и сроки проекта
Полезное про внедрение 1С на производстве
Мы запланировали цикл материалов «Внедрение 1С на производстве». Сегодня была четвертая часть. В следующих статьях разберем и покажем, как проходит внедрение на практике — от выбора решения до сопровождения и развития.
- Часть 1. Аудит и план проекта: с чего начать внедрение 1С на производстве, чтобы не слить бюджет — первый этап внедрения, что проверяем, какие документы вы получаете, сколько времени занимает и можно ли обойтись без аудита.
- Часть 2. Какую программу 1С выбрать для автоматизации производства и как это сделать, чтобы не переделывать через год — как определиться с ПО, что учитывать при выборе и с каких систем чаще всего переходят: Oracle, Axapta, старые версии 1С и другие продукты.
- Часть 3. Команда проекта 1С: как не сорвать сроки внедрения и не выйти за рамки бюджета — роли, ответственность, согласование, рабочие группы, коммуникация, график работ.
- Часть 4. 70% проекта и 90% рисков: что под капотом этапа разработки в проекте внедрения 1С на производстве — основной и самый длительный этап внедрения. Почему на этом этапе высокие риски срыва сроков внедрения, какие контрольные точки и артефакты нужны, и как выстроить управление проектом так, чтобы минимизировать риски по срокам, объему и качеству работ.
