В одном из сертификационных экзаменов попался примерно такой вопрос, из области вполне себе прикладных. Естественно, я его перефразирую, и вариантов ответов не привожу, чтобы не нарушить авторских прав.
Ваша ИТ-организация обслуживает множество информационных систем, программно-аппаратные комплексы у них различные. С одной стороны ощущается недостаток тестирования новых версий ИС, так как тестовые среды не очень похожи на продуктивные (используются только примерные значения, недостаточно данных для проведения нагрузочных испытаний и т.п.), то есть множество ошибок выявляется уже в продуктиве. С другой стороны – средств на содержание полноценных тестовых сред, дублирующих продуктивные, в бюджете нет. Что делать?
На портале realitsm.ru мы редко поднимаем вопросы, связанные с Quality Assurance, а ведь они действительно значимы. И предложенный мини-кейс очень похож на то, что я видел на практике.
Пытаясь подражать коллегам, хочу подойти к решению задачи системно. Итак:
- На стратегическом уровне: следует определить список наиболее важных систем, продемонстрировать потери, которые терпит бизнес от невыявленных при тестировании ошибок. Следует убедить заказчиков выделять средства на обустройство полноценных тестовых сред, расходы на которые будут меньше, чем такие потери. Наглядно сработает в бизнесе, результаты которого критичны для конечных клиентов: здравоохранение, военная промышленность…
- На тактическом уровне: организовать «опытно-промышленный периметр»: часть продуктивной среды, в которой новые версии будут тестироваться уже в боевых условиях, с реальными сценариями, данными и нагрузкой. Влияние выявленных ошибок будет ограничено этим небольшим периметром. Здесь нужно предусмотреть резервные мощности и сверхбыстрые механизмы отката на стабильную версию. И, конечно, широко разрекламировать «лётчиков-испытателей» – пользователей, которые попали в периметр.
- На операционном уровне: конечно же, поможет виртуализация. Сегодня можно настроить имитацию почти любых аппаратных ресурсов, и установить буквально «за один щелчок» почти любое ПО в ней. Стоит недорого. Позволит нескольким командам QA использовать одну и ту же платформу, обеспечивая ее ритмичную нагрузку.
Вот. А что думаете вы?
То, что в заметке названо стратегическим уровнем, мне представляется вполне логичным и здравым. Не нужно тщательно и досконально тестировать всё и вся, нужно выделить важное. Проблема в данном случае будет не с определением критичных ИТ-систем, а с общей разделяемой ИТ-инфраструктурой. Например, заливка новой версии операционки в какую-нибудь Cisco, или изменения в Active Directory могут повлечь массу неприятностей, которые можно было бы отловить при тестировании. Однако ИТ-инфраструктура, как правило, широка, и выделить в ней что-то особенно важное не всегда легко, а то и возможно.
“Операционный уровень” – тоже согласен, виртуализация уже давно позволяет делать достаточно дёшево подобные штуки.
А вот “тактический уровень” мне не очень понятен. Зачем такой периметр? Много ли случаев, когда можно быстро откатиться назад, особенно если затрагиваются данные? Рациональность такого подхода вызывает вопросы…