Мне всегда казалось, что самая старая технология, на которой мне придется создавать проект будет php 5.3, но так получилось, что я теперь веду проект на SAP.

Если отбросить в стороны шутки про 1С за 100500 денег, то это достаточно бодрый и живой фреймворк на языке ABAP, который пишется, развивается и продается с 1980-х годов. Компания SAP сделала ряд удачных M&As и покрывает весь спектр ERP и CRM для больших и малых компаний.

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

• Нет git-подобного механизма. Все делается через так называемые “транспорты”. По сути, это пакеты изменений, которые нужно мержить, но САП не даст тебе мержить в стиле гита. Один объект кода может разрабатывать несколько разработчиков, но транспорт перенесет весь объект, а не новые изменения.
• Т.е. приходится ждать, пока вся работа по объекту не завершена, чтобы перенести ее дальше. Ты не можешь сделать ролл-бэк, тебе надо создать корректирующий транспорт, который спецом уберет затронутые объекты.
• Как следствие, разработка строго итеративная. Даже в организационной структуре роли разделены для контроля каждой итерации.
• Нет автотестов. В теории они конечно есть для САП, но мой клиент не сделал на них ставку в свое время.
• Тестирование только ручное. Осуществляется большой толпой народу. Для одного релиза часть тест кейсов могут делать ребята из Бразилии, для другого релиза это будут делать австралийцы
• Много мишн критикал вещей, вроде заказов, оплат, инвойсов.
• Релиз на продакшн только 3 раза в год 🙂

В общем, мне достался типичный энтерпрайзо-каскадный проект на “устаревшей” технологии. В мире, где аджайл уже давно стал “новым нормальным”, принято насмехаться и критиковать мифический “водопад”. Но давайте будем умнее и рассмотрим те вещи, которые могут быть полезны.

И главное – конечно управление качеством. Ни один из аджайл подходов не говорит тебе, как работать с качеством. Разве что XP предлагает ряд инженерных практик и ТДД. В 2019 мы полагаем, что пилюля от всех болезней это CI/CD и автоматические тесты. Но что делать, если ты физически не можешь начать внедрять автомат тесты? Что делать, если у тебя нет CI/CD?

Что мы сделали?

Все упирается в довольно простой ландшафт. Есть 4 типа окружений:

• D – разработка
• Q – тестирование
• E – UAT
• P – живой проект. Примерно 20к очень активных пользователей по всему миру.

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

И вот что мы сделали в планн управления качеством. Часть из этого уже у клиента существовало, часть мы подтянули под себя:

1. Работа с требованиями

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

2. Тестирование

• У нас 4 гейта при тестировании: внутреннее тестирование разработчиками, тестирование аналитиками клиента, тестирование представителем бизнеса, тестирование конечными пользователями.
• Каждая фича покрывается ручным тест-кейсом. Описывается в экселе, в общепринятом формате для компании. Затем, такие кейсы агрегируются аналитиками в один сводный тестовый сценарий, который и прогоняют конечные пользователи на UAT.
• Тест-кейс включает в себя в явном виде, как позитивное так и негативное тестирование.
• Забудьте про это ваше exploratory testing, как главный тип тестирования, потому что в случае беды мы не можем откатиться назад. Легче пустить себе пулю в лоб 🙂
• Импакт анализ для оценки воздействия на другие части системы.

Что по итогу?

Когда мы задеплоили первый майлстоун на UAT то получили 11 ишью от конечных пользователей, где:

• 4 (36.4%) – оказались запросами на улучшение
• 4 (36.4%) – действительно багами
• 3 (27.2%) – непонятки с пониманием и решились тренингами

Общий размер майлстоуна составил 4 недели для команды из 3 разработчиков и 2-х тестировщиков. Я такой результат оцениваю, как позитивный, по сравнению с моими другими проектами, где кол-во багов при UAT может легко переваливать за 50%.

Мне хочется принести эти практики и на другие мои проекты. Да, у тебя есть оверхед в виде документации, но с качеством у нас проблем точно нет.