Привет!
У меня для вас отличная новость! Руки добрались поделиться с вами правильным подходом при внедрении системы SAP. Правильный он исключительно с моей точки зрения. И еще нескольких тысяч проектов в области разработки программных продуктов в мире. Но сначала послушайте сказку в нагрузку.
Полтора года назад я засел за свой мини-стартап семейного масштаба. Для меня это был новый язык программирования, новые технологии, слова и умности-премудрости. Мне нравится создавать что-то новое, а программирование именно таковым инструментом и является. И все шло хорошо, пока не начали появляться ошибки. Я привык по-старинке разрабатывать решения, тестировать их в меру своих способностей, прокручивая в голове последствия, причины, следствия и связи. Это отлично работает на первых этапах и редко когда подводило меня. Но тут новый язык, новые решения, и что-то стало часто ломаться. Там поменяешь код(настройку), тут сломается, вернешь обратно, в другом месте сломается. Знакомая ситуация при настройке заработной платы? Вроде бы один класс обработки поменял, веточку в правило добавил, а количество ошибок только растет в Solution Manager.
Умные люди придумали системы автоматизированного тестирования. По сути это алгоритм, повторяющий действия человека, где заранее известны входные и выходные параметры. Мы же знаем, что оклад в тысячу рублей надо считать вот так, а при неполном периоде, вот сяк. На входе величина оклада, количество часов нормы, количество фактических часов. На выходе деньги в кошельке (на карточке). Мы всегда делаем каталог видов оплаты на каждом проекте, где описываем виды оплаты, их базы входимости и алгоритмы. То есть можем просчитать все варианты. Почему бы работу по вводу данных в систему, запуск расчета и сверки результата с нашим Excel файлом не поручить компьютеру?
За время моих мытарств с проектом написано на сегодня 985 тестов. И это на несколько тысяч строчек кода. Трудоемко. Но теперь я знаю, что любое изменение в коде я могу всегда проверить. В 90% случаев я сразу же вижу ошибку, влияние моего изменения на другие участки программы. Это позволяет мне не выкладывать версию на рабочий сервер. Нам, саперам, это позволяет не отправлять запрос в продуктив, пока не пройдены все тесты. Пока одна наша галочка во входимости не пройдет тест по нескольким тысячам тестов, всем видам оплаты, шпунтикам и винтикам.
Как все это относится к внедрению САП? Легко. Что такое проектное решение/концептуальный проект? Толстая книжечка с описанием что на входе, что на выходе. Те самые процессы, где есть стрелочка начала процесса и его завершения. Процесс приема на работу начинается с первичных документов (и их перечень регламентирован проектной документацией) и завершается табельным номером в системе и приказом на столе. Расчет заработной платы начинается с первичных документов и завершается проводками — записями в таблицах системы.
Идея заключается в том, чтобы заменить проектную документацию на каталог тестов с бизнес описанием. Каталог не на бумаге, а в системе САП. Это гарантирует разработчикам и бизнесу то, что система работает строго по описанным в тестах правилам и процессам. Часто ли мы актуализируем проектные решения по результатам изменений (особенно в закрытие периода)? Тесты будут актуальны всегда, иначе запрос просто не уйдет в продуктив.
Любое изменение в системе проходит через все тесты. Казалось бы какое отношение изменение настройки вида оплаты имеет к кадровому учету? Но эта настройка может изменить допустимость вида оплаты для ввода в инфотип, формат отражения в приказе или повлиять на косвенную оценку.
Тест для пользователя есть своего рода проектная документация, где в описании он может увидеть бизнес процесс, описание алгоритма, входные и выходные параметры. Это то же самое проектное, только в другом виде. Появляется новый процесс или алгоритм, пользователь описывает параметры на входе, выходе, логику обработки. И консультант сначала пишет тест, а затем делает настройку. Для пользователя это прозрачно тем, что он видит тест и свое же описание со своими же данными. Консультант видит, что решение не готово до тех пор, пока тест не станет «зеленым». Пока все тесты системы не пройдут без ошибок. Второй бонус для пользователя — меньше тестировать в системе тестирования. Пользователи этого уж очень как не любят. Надо же ввести тестовые данные, полностью повторить ситуацию, написать отчет о тестировании. А здесь бац и система все будет повторять столько раз, сколько нужно.
При чем тут САП? При том, что мы имеем отличный инструмент eCATT, который как раз и умеет запускать тесты. Окошечки рисовать, данные из файликов считывать, подставлять, проверять и рапортовать. Компания САП предоставила нам инструмент для организации тестирования на своих проектах. Вот только я не видел ни одного проекта, где бы этот инструмент использовался.
Предлагаю всем сообществом начать. Писать библиотеку тестов и пользоваться всеми. Open Source для начала. Системы у всех примерно стандартные, логики тоже. Например, я сегодня сделал первый тест — проверка ввода вида оплаты в инфотип. Тест проверяет, появляется ли сообщение ‘Record created’ после сохранения инфтипа 0015.
Если вам интересно пообщаться на эту тему, посмотреть в картинках, как создавать тесты, то прошу проголосовать. Как только наберется 100 голосов «ЗА» я выложу материал по созданию теста. А там как пойдет. Если мы решим, что надо и интересно, то попробую сделать несколько типовых тестов для разных бизнес-ситуаций в SAP HR/HCM.
Активнее, дамы и господа!
