Как повысить рациональность тестирования?

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

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

На портале realitsm.ru мы редко поднимаем вопросы, связанные с Quality Assurance, а ведь они действительно значимы. И предложенный мини-кейс очень похож на то, что я видел на практике.

Пытаясь подражать коллегам, хочу подойти к решению задачи системно. Итак:

  1. На стратегическом уровне: следует определить список наиболее важных систем, продемонстрировать потери, которые терпит бизнес от невыявленных при тестировании ошибок. Следует убедить заказчиков выделять средства на обустройство полноценных тестовых сред, расходы на которые будут меньше, чем такие потери. Наглядно сработает в бизнесе, результаты которого критичны для конечных клиентов: здравоохранение, военная промышленность…
  2. На тактическом уровне: организовать «опытно-промышленный периметр»: часть продуктивной среды, в которой новые версии будут тестироваться уже в боевых условиях, с реальными сценариями, данными и нагрузкой. Влияние выявленных ошибок будет ограничено этим небольшим периметром. Здесь нужно предусмотреть резервные мощности и сверхбыстрые механизмы отката на стабильную версию. И, конечно, широко разрекламировать «лётчиков-испытателей» – пользователей, которые попали в периметр.
  3. На операционном уровне: конечно же, поможет виртуализация. Сегодня можно настроить имитацию почти любых аппаратных ресурсов, и установить буквально «за один щелчок» почти любое ПО в ней. Стоит недорого. Позволит нескольким командам QA использовать одну и ту же платформу, обеспечивая ее ритмичную нагрузку.

Вот. А что думаете вы?

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Practitioner — новый учебный курс 2016

Правильный следующий шаг после ITIL Foundation.
 

Узнайте больше!

Комментарии и мнения

  1. Олег Скрынник

    То, что в заметке названо стратегическим уровнем, мне представляется вполне логичным и здравым. Не нужно тщательно и досконально тестировать всё и вся, нужно выделить важное. Проблема в данном случае будет не с определением критичных ИТ-систем, а с общей разделяемой ИТ-инфраструктурой. Например, заливка новой версии операционки в какую-нибудь Cisco, или изменения в Active Directory могут повлечь массу неприятностей, которые можно было бы отловить при тестировании. Однако ИТ-инфраструктура, как правило, широка, и выделить в ней что-то особенно важное не всегда легко, а то и возможно.

    «Операционный уровень» — тоже согласен, виртуализация уже давно позволяет делать достаточно дёшево подобные штуки.

    А вот «тактический уровень» мне не очень понятен. Зачем такой периметр? Много ли случаев, когда можно быстро откатиться назад, особенно если затрагиваются данные? Рациональность такого подхода вызывает вопросы...

    0
    0
    1. Константин Нарыжный Автор

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

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

      0
      0
  2. Лялеко Владимир

    Про стратегический уровень:

    Почему нет варианта «Ничего не делать?» 🙂

    Даже не полноценный стенд позволяет выявить большинство кретических ошибок в ИС. А некоторые из ошибок даже при полноценном тестировании могут ускользнуть.

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

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

    Про тактический уровень:

    Опытно промышленная эксплуатация необходима внезависимости от качества тестирования. При этом:

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

    — вводятся механизмы управления рисками (Здесь нужно предусмотреть резервные мощности и сверхбыстрые механизмы отката на стабильную версию и т.д)

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

    Про операционный уровень:

    Мне кажется это лишь один из хороших и дешёвых способов управления рисками на тактическом уровне.

    ИМХО Сейчас похоже стало модно доводить совершенство тестирования ИС до паранои 🙂

    0
    0
    1. Константин Нарыжный Автор

      Владимир, как обычно — всё по делу))

      Ну вопрос конечно не в совершенствовании тестирования, а в том, как сделать его рациональным усилиями различных ИТ-шников.

      А какие еще дешёвые способы управления рисками на тактическом уровне вы назовёте?

      0
      0

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ОКТ
23