Как заставить разработки работать

Гладко было на бумаге, да забыли про овраги

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

Процесс проработки сценария испытаний можно представить в виде следующей диаграммы (для каждого бизнес-процесса прорабатывается свой сценарий):

1. В процессе формализации сценария описывается существующий рабочий бизнес процесс, который на данный момент реально существует на предприятии и подлежит автоматизации.
2. При попытке формализации учетного процесса уже предпринимается попытка прогнать сценарий в системе, уточнив в сценарии название функций системы, которые будут применяться для учета тех или иных задач процесса. При этом в сценарии прописываются конкретные данные (с точностью до заполнения всех реквизитов и таблиц с наименованиями и цифрами), что бы из раза в раз прогон давал одинаковый результат в виде каких-то отчетных форм.
3. Далее принимается решение, если процесс удалось прогнать, используя имеющийся функционал системы, то переходим к согласованию сценария с заказчиком (демонстрации, см. п. 6).
4. Если же существующего функционала не хватило, чтобы с достаточной степенью автоматизировать учетный процесс, но видно, что если изменить сам бизнес-процесс, то существующего функционала будет достаточно, чтобы произвести автоматизацию – выполняется попытка согласовать изменение бизнес-процесса с заказчиком. В случае, если согласовать удалось, то согласно измененного бизнес-процесса снова пытаемся формализовать учетный процесс (пункт 2).
5. Если путей изменить рабочий процесс нет, либо заказчик не согласен пойти на это, подается задача разработчику на доработку функционала системы, а затем, после доработки функционала, снова предпринимается попытка формализовать учетный процесс (пункт 2) с новым функционалом.
6. Когда учетный процесс формализован, выполняется согласование сценария с заказчиком путем демонстрации системы на этом сценарии приемочной комиссии, в состав которой обязательно должен входить представитель от группы людей, которые будут непосредственно использовать систему. В процессе демонстрации заказчик либо полностью все одобряет, либо высказывает свои замечания.
7. Далее принимается решение, если сценарий был утвержден комиссией, то на этом процесс проработки данного сценария завершен. Если же в процессе демонстрации были замечания, то переходим к пункту 2, т.е. согласно замечаний сценарий дорабатывается.

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

1. Пришёл клиент с накладными, кладовщик собирает заказ по накладной, для этого в отчете по товарным остаткам убеждается в наличии товаров;
   Кладовщик: Находит документ Реализация товаров и услуг в базе (по номеру на бумажной накладной, которую предоставил клиент) и формирует печатную форму сборочной ведомости, идёт на склад и собирает заказ;
2. Вернувшись с собранным заказом кладовщик отражает расход;
   Кладовщик: На основании Реализации товаров и услуг из п1 создаёт Расходный ордер;

К сценарию предъявляются следующие требования:

• Сценарий должен быть составлен так, чтобы любому пользователю было понятно в какой момент что происходит и что при этом нужно сделать в системе;
• Каждый сценарий должен начинаться с определенного состояния базы (пустого, либо имеющую начальные данные), например, это может быть выгрузка базы, либо сценарий действий, которые нужно выполнить, чтобы привести пустую базу к данному состоянию;
• Каждый сценарий наряду с исполнением действий должен иметь контрольные точки. Например, это могут быть сохранённые эталонные отчетные либо печатные формы, с которыми в последствии в процессе выполнения можно производить сравнение и убеждаться, что отображаемые в них данные не изменились по отношению к тем, которые были в момент проработки;
• Каждое действие, описанное в сценарии – это реально существующая в системе функция, описание которой можно найти в инструкции.

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

Однако испытания это ещё не все. Что бы система заработала, и затем работала без перебоев, необходимо обучить пользователей, а для обучения необходимо наличие методического материала, без которого обучение превратиться в импровизированное шоу. Я бы выделил 3 категории методического материала, который необходим для обучения и дальнейшей работы пользователей: инструкции, сценарии и регламенты.

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

1. Перейдите Торговля – Номенклатура, откроется справочник Номенклатура:

2. В открывшемся списке нажмите Создать, откроется карточка новой номенклатуры:

3. Укажите наименование номенклатуры:

4. Нажмите Записать и закрыть;

Но, наличие инструкции не дает полной картины о системе. Прочтя инструкцию (а пользователя ещё нужно заставить её прочесть), пользователь может получить понимание того, как выполнить ту или иную функцию. Но вот когда какую функцию использовать пользователю все равно будет не понятно.

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

Таким образом, чтобы пользователь смог работать в системе, его нужно научить тому, когда и какие функции он должен использовать. Процесс обучения может состоять из двух этапов. На первом этапе пользователям даётся теория (демонстрация возможностей), на втором – практические занятия по сценариям в заранее подготовленной базе. Второй этап можно опустить, если функционал достаточно прост, а пользователи достаточно подготовлены. Демонстрация возможностей проводиться по сценариям испытаний, при этом подготавливается база – заполняется данными по сценарию до места, с которого начнётся демонстрация. Выполнив показ пользователям по сценарию, мы дадим ему представление о том, в каких ситуациях какие инструменты он должен использовать. Далее, та же подготовленная база, предоставляется в распоряжение пользователя и по сценарию под наблюдением инструктора он закрепляет полученные знания на практике.

Но и это ещё не все. Что бы в процессе работы пользователь не терялся и не обращался по каждому пустяку в службу поддержки, его рабочее место, в добавок к инструкции, рекомендуется снабдить регламентом. Регламент разрабатывается на каждое рабочее место и прописывает в какой ситуации какую функцию системы пользователь должен использовать. Например, регламент кладовщика может содержать раздел под названием «Пришёл клиент с накладными». В этом разделе по пунктам должно быть описано что в этом случае должен сделать кладовщик. Например:

Пришёл клиент с накладными

1. Найдите накладную в 1С по номеру (номер на бумажной накладной у клиента);
2. Соберите заказ на складе;
3. Отразите расходный ордер в 1С;
4. Вручите товар клиенту;

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

Таким образом регламент и сценарий предписывают что и когда делать, а инструкция – как это делать. Например, в сценарии (или в регламенте) указано: создайте номенклатуру. А вот уже в инструкции есть раздел, который называется Создание номенклатуры, и в нем по шагам описано как её создавать с картинками. Не стоит раздувать регламент и сценарий до инструкции с картинками, т.к. в них получиться множество одинаковых частей (ведь одна функция может быть использована в разных ситуациях). А это в свою очередь приведёт к тому, что при доработке системы, вместо доработки одной инструкции придётся пересмотреть кучу регламентов и сценариев и внести в них одинаковые исправления.

Не мешай системе работать

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

• Программная ошибка;
• Логическая ошибка функционала;

Программная ошибка, как правило, сопряжена с отказом работы какой-либо отдельной функции с выдачей ошибки (например, Деление на 0) и вызвана плохим качеством работы программиста.

Логическая ошибка, сопряжена с неправильной работой системы с точки зрения пользователя без выдачи сообщения об ошибке (не те цифры в отчете, не по стандартам отчетная форма). Такие ошибки связаны с плохим качеством работы внедренца.

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

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

Ошибки после доработок работающей системы зачастую проявляются при использовании следующей схемы внесения изменений:

К1 – это конфигурация базы, которую эксплуатирует заказчик. Буква С в скобках означает что она стабильная. Стабильная – это значит, что пользователи в ней работают и не испытывают никаких проблем, т.е. система решает поставленные задачи. В какой-то момент в конфигурацию разработчик вносит изменение (не важно, либо редактирует прямо в рабочей базе, либо путём сравнения объединения), в результате получается конфигурация К2, но, так как после внесения изменений функционал в базе никто не тестировал (так как это бы привело к остановке работы в базе на какое-то время до завершения отладки), то конфигурация получилась нестабильной. Причём, она будет нестабильной, даже если тестирование делалось где-то в базе разработки либо тестовой базе, ведь сам момент внесения изменений в конфигурацию – это потенциальная возможность что-либо сломать, причём в самом неожиданном месте. Это как если вы сдадите автомобиль на СТО для ремонта двигателя, а забрав его, спустя время обнаружите, что у него повреждена краска на заднем бампере. Лишь только внесение изменений путём полной загрузки конфигурации, которая выгружена из полностью протестированной базы, даст гарантию стабильности функционала рабочей базы. Однако, такое возможно только если изменения в систему вносит один разработчик. В нашем случае, Изменение 2 вносит второй разработчик, путём сравнения объединения, в результате получается конфигурация К3, еще более не стабильная, причем в ней могут оказаться испорчены изменения 1-го разработчика.

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

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

Решением этой проблемы может стать функциональное и приемочное тестирование.

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

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

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

• Каждый тест должен начинаться с определенного состояния базы (пустого, либо имеющую начальные данные), например, это может быть выгрузка базы, либо тест по выполнению различных настроек, которые нужно выполнить, что бы привести пустую базу к данному состоянию;
• Каждый тест наряду с исполнением действий должен иметь контрольные точки. Это могут быть контрольные значения в определенных полях электронных форм документов, либо определенных областях отчета. Не плохой вариант – mxl выгрузки эталонных отчетов, которые в процессе выполнения теста можно сравнить с полученным в ходе выполнения теста отчетом;
• Каждый тест должен заканчиваться тем, что все данные, которые были в процессе добавлены, должны быть удалены, что бы для очередного теста выполнялось первое требование и данные полученные в этом тесте не повлияли бы на ход очередного теста;
• Каждое действие, описанное в сценарии – это реально существующая в системе функция, описание которой можно найти в руководстве пользователя.

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

Все тесты стоит объединить в один реестр, и в дальнейшем, каждый раз прогонять их перед обновлением работающей системы. Ускорить процесс тестирования можно воспользовавшись специализированными инструментами, позволяющими его автоматизировать. Например, «1С:Сценарное тестирование 8», входящий в состав «1С:Корпоративный инструментальный пакет 8».

Если, при прогоне теста, обнаруживается проблема (тест отрабатывает не так как задумано, возникают исключения либо не проходит контроль по контрольной точке) проблему нужно решить - отладив поломку функционала.

Для примера рассмотрим ситуацию:

От заказчика, эксплуатирующего некоторую учетную торговую систему стороннего поставщика, поступило требование, что у пользователя должна быть возможность продавать определенные позиции по себестоимости, причём так, чтобы не пришлось самому высчитывать себестоимость каждой позиции (ранее такой возможности в системе не было). Внедренец, получив такое требование, обдумав его, ставит задачу разработчику: в документ РТУ добавить функцию Заполнить цену себестоимостью, при выборе которой, для номенклатуры, которая добавлена в документ, должна просчитываться текущая себестоимость и подставляться в колонку Цена.

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

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

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

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

Заполнение РТУ себестоимостью

1. Добавляет номенклатуру Перчатки;
2. Отражает поступление перчаток (Поступление товаров) в количестве 10 шт по цене 100 р;
3. Отражает Реализацию перчаток (Реализация товаров) в количестве 5 шт, цену заполняет себестоимостью;

Контроль: цена перчаток автоматически установилась 10 р;

Этот тест добавляется в реестр функциональных тестов.

Затем, обновление конфигурации релизом от стороннего поставщика выполняется на тестовой базе, конфигурация в которую загружается из рабочей. Допустим тот же разработчик так же при обновлении взял форму документа РТУ из конфигурации поставщика. Теперь, после обновления производиться функциональное тестирование. Когда тестировщик дойдёт до теста Заполнение РТУ себестоимостью, он столкнётся с проблемой: невозможно произвести заполнение себестоимостью, так как эта команда отсутствует. Проблему он зафиксирует в протоколе тестирования, который будет предоставлен разработчику, который в свою очередь неспешно в общем порядке разберется с этой проблемой, восстановит команду и снова отдаст конфигурацию на тестирование.

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

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

Приемочное тестирование

Для примера рассмотрим следующую ситуацию (логическую ошибку):

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

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

Далее, от другого пользователя (руководителя отдела продаж), спустя некоторое время, поступило новое требование, что он хочет вот в таком-то отчете (как раз в том, который делался для менеджера по продажам) видеть цены не в рублях, как сейчас, а в долларах.

Теперь предположим, что разработчик сменился (хотя компания, оказывающая поддержку та же), или просто прошло много времени и разработчик уже забыл, что кому и когда делал. Новый разработчик, полагая что этим отчетом пользуется только руководитель, берет и переделывает существующий отчет, демонстрирует его руководителю отдела продаж. Руководитель одобряет. Рабочую систему обновляют, но на следующий день прибегает менеджер по продажам и говорит, что отчет, которым он постоянно пользовался работает не так как надо. Теперь разработчик вынужден в срочном порядке выяснять как работал отчет раньше и производить новую разработку – отчет, который удовлетворяет требованиям обоих пользователей. Заказчик снова недоволен, может понести убытки из-за простоя, а мы имеем дополнительные затраты на повторную доработку отчета и повторный релиз функционала.

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

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

Тест 1:

1. Администратор (А): Добавляет пользователя Менеджер по продажам (МП);
2. Менеджер по продажам (МП): Создает номенклатуру Шапка-ушанка;
3. МП: Отражает поступление номенклатуры:

4. МП: Формирует отчет Анализ цен номенклатуры
   Контроль: Эталонный отчет «Анализ цен номенклатуры 1.mxl»

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

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

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

Обобщенный процесс разработки функционала

Для обеспечения стабильности функционала и логики работы системы в рабочей базе предлагается применять следующую схему:

Допустим в какой-то момент имеется конфигурация Х2.0.6.15С. Первая буква Х означает что эта конфигурация находится не в рабочей базе, а в хранилище конфигураций, буква С означает что она стабильна. На основании этой конфигурации собран релиз (поставка) Р2.0.6.15, который распространён среди клиентов.

Далее принимается решение разработать новый функционал. Для этого разворачивается новое хранилище Х2.0.7.0 путём копирования хранилища Х2.0.6.15С. В новом хранилище начинается разработка и разработчики фиксируют из своих баз с конфигурациями КР3 и КР4 изменения с новым функционалом и в какой-то момент получается конфигурация с новым функционалом Х2.0.7.1Н (Н – нестабильная). Так как конфигурация 2.0.7 нестабильна, начинается процесс тестирования, посредством выполнения всех функциональных и приемочных тестов. Так как были выявлены проблемы в ходе тестирования, конфигурация по-прежнему нестабильна. Эти проблемы исправляются и получаем конфигурацию Х2.0.7.2Н. Так продолжается до тех пор, пока в процессе тестирования не будет выявлено ни одной проблемы и не получим стабильную конфигурацию Х2.0.7.5С, на основании которой можно собрать поставку и предоставить клиентам очередной релиз.

Если в процессе разработки функционала в хранилище 2.0.7 в релизе 2.0.6 клиентами обнаруживаются критические ошибки, не выявленные в процессе тестирования, их исправление выполняют разработчики в базах с конфигурациями КР1 и КР2, полученными из хранилища Х2.0.6.15С. После исправления изменения фиксируются в хранилище и полученную конфигурацию Х2.0.6.16Н тестируют. Параллельно эти же исправления вносятся и в хранилище 2.0.7, чтобы эти критические ошибки не попали в релиз 2.0.7, а внутренняя документация пополняется тестами, направленными на их отлов. Так как ошибок в конфигурации Х2.0.6.16Н не было найдено, она признается стабильной и выпускается релиз Р2.0.6.16, который предоставляется клиентам.

Важно понимать, что:

• после начала тестирования (когда начат прогон по всем имеющимся тестам) и до выпуска релиза, изменения в тестируемую конфигурацию вноситься не должны;
• после выполнения всех тестов, если были обнаружении проблемы, они устраняются, а затем, тестирование выполняется с самого начала;

Если, в процессе разработки функционала для релиза 2.0.7 возникла потребность ещё в каких-то функциях, то принимается решение начать разработку релиза 2.0.8, хранилище которого разворачивается путём копирования хранилища конфигурации в состоянии Х2.0.7.1Н. В этом случае, по завершении разработки в хранилище 2.0.7 изменения, которые были в него внесены начиная с состояния Х2.0.7.1Н должны быть перенесены в хранилище 2.0.8.

Итоги

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

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

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

• Облегчить использование функционала пользователями;
• Упростить обучение нового сотрудника и перемещение пользователя с одного рабочего места на другое;
• Обезопасить систему от останова при уходе ключевого пользователя, который, единственный умел в ней работать;
• Посадить на телефон службы поддержки малоквалифицированного сотрудника, который может оказывать консультации используя регламенты и инструкции;

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

В совокупности, наличие всей перечисленной сопроводительной документации, обезопасит компанию-разработчика от возможного паралича проектов внедрения и сопровождения, в результате ухода ключевых сотрудников (например, ведущего разработчика), которые при отсутствии документации все держат в голове.