Когда начинаешь проект автоматизации, то сразу начинаешь мечтать об этом этапе - тестировании и апробации: как все будет замечательно и волшебно, как проблемы рутины будут сняты, в процессах выстроится стройный порядок, ресурсы высвободятся для дальнейших свершений! Ну, а если что и придется поправить, то только самую малость.
Ах, если бы... Но надеяться то на лучшее не запретишь, более того, без надежды на успех не начнешь и реализовывать инновационные проекты, которые в автоматизации, практически, все.
Этап апробации или тестирования очень важный в проекте автоматизации. Это и понятно - контролировать процесс реализации необходимо, чтобы на выходе было именно то, что планировалось или даже лучше, но никак не хуже. Главное, конечно, чтобы программа работала корректно и бесперебойно.
При проверке разработанного программного обеспечения, необходимо тщательно проверить все планируемые функции, "все кнопочки и формочки". При этом, необходимо проверять все методично, пройдясь по всему процессу с самого начала и до конца.
Чтобы ничего не забыть, рекомендуется составить сценарий или план проверки, разделенный на этапы или операции. Так вы не рискуете что-то пропустить, и при обнаружении багов и недочетов, сможете зафиксировать правильно определить место ошибки, что поможет разработчикам быстро решить выявленные проблемы. Лучше, если вы будете вести таблицу или реестр этапов автоматизированного процесса с указанием промежуточных результатов, где можно было бы оставлять комментарии. Таким образом документируя весь процесс тестирования легче найти источники проблем и договариваться с разработчиками.
Если возникают споры на счет того, что было задумано, а что нет и как должно было работать, то нужно руководствоваться разработанным ранее документами.
Если разработчик внешний, то это условия договора, техническое задание, бизнес-требования и (если есть) дополнительные соглашения.
Если разработчик внутренний - то техническое задание, бизнес-требования и все дополнительные требования, зафиксированные либо в электронной переписке, либо в любой другой документирующей форме, которая принята в компании. В противном случае, рискуешь оказаться в невыгодной позиции, когда сложно,что либо доказать, а исполнители скажут, что сделали все, "как вы заказывали и написали", или как в детской песенке про Антошку "Это мы не проходили! Это нам не задавали! Парам пам па!" - "В ТЗ об этом не говорится".
Поэтому необходимо быть предельно внимательным и следить за соответствием с ТЗ - в случае возникновения дополнительных пожеланий (а они всегда есть и будут) обязательно оформлять это документально, или хотя бы подтверждать в электронном виде "со свидетелями" - с добавлением адресатов из руководства в копию на протяжении всей переписки. Это избавляет заказчика от лишних и ненужных хлопот.
И тогда, когда вся система будет "вычищена" и "отполирована", проект можно будет считать успешно завершенным и можно будет заняться подготовкой сдачи ее в эксплуатацию! Это очень торжественный и приятный момент, ради которого стоит так усердно потрудиться.
Если вам интересна тема автоматизации бизнес-процессов заказчика, подписывайтесь, чтобы получать уведомления о продолжении.
Также буду благодарна вашей обратной связи и вопросам. Пишите и я отвечу!
To be continued...
Всегда ваша
Денисова Елена,
Комментариев нет:
Отправить комментарий