ITSM в тестировании

Сейчас я занимаюсь изучением библиотеки ITIL, a так же ITSM. На данный момент набор лучших практик в ИТ, собранных в ITIL, является стандартом №1. Последняя, на данный момент редакция, очень тесно перекликается с принципами ITSM. Более того, сам ITSM взял за основу саму библиотеку ITIL. Цель ITSM буквально в следующем - управлять ИТ услугами наиболее эффективно. Эффективность оценивается в наше время очень просто, можете прочитать книгу Элия Голдрат «Та самая цель». Но и без нее все совершенно очевидно: цель коммерческой компании - получение прибыли. Соответственно бизнесу нужна прибыль, вот что он понимает под успешным управлением чего-либо. Поэтому, все процессы в компании должны выстраиваться от бизнеса. Надеюсь основную фабулу данного метода, я вам раскрыл.

Так вот, подход ITSM применяется успешно во многих компаниях, причем не только в ИТ, но и в производстве. Его Основные этапы:

• Стратегия ИТ
• Портфель проектов, процессов по достижению стратегии
• Разбиение процессов на более мелкие
• Стандартизация каждого процесса
• Повышение качества процессов производства чего-либо

Меня заинтересовало последнее, т.к. улучшение качества процессов и является успехом в любом предприятии. Делаете ли вы сам продукт качественнее, или его стоимость, или скорость его создания - все это является главными конкурентными преимуществами. В итоге, вы получаете преимущество, а соответственно и прибыль. Быстро, качественно и в срок. Что может быть лучше? Отдел тестирования можно рассмотреть как один из процессов производства. Теперь вернемся к производству продукта, и посмотрим, какое место «проверка качества» занимает в его жизненном цикле.

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

В этой системе есть такое понятие колесо Шухарта-Деминга (см Схему 1).

Основное требование, этой системы - разделить все 4 этапа, чтобы они не влияли друг на друга. Если проводить данные действия в компании над процессом, то с каждой такой итерацией, мы будем улучшать качества самого процесса. Тут как раз наиболее четко видна задача отдела контроля качества – проверить именно то, что необходимо, сделать эту работу качественно и быстро(относится и к остальным частям разработки). Это крайне необходимо, чтобы быстро прокрутить это колесо качества. Данный метод уже находит свое применение в подходе «Continuous Integration».

В итоге, что же получается у нас на практике, в части разработки Программного Обеспечения? Существует отдел контроля качества (отдел тестирования), а качества так и нет.

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

Я далек от мысли, что у нас в тестировании так не получится, т.к. у нас все по-другому. Основной причиной, я вижу, что процессом полностью управляет Project manager. И у нас не получается разделить каждый этап по принципу Шухарта. Все начинается с первого этапа -Планирование. Это спецификации, технические задания. Далее идет - разработка. После этого тестирование. Далее корректировка. Почти везде, все функции в конечном итоге принадлежат одному человеку, которые решает: начнем писать По без четкой спецификации, потом пусть проверят, то что написано. А если найдут ошибки, то можно и сними выпускать продукт. И продукт выпускают!

Почему же данный метод все-таки работает, раз компании существуют? Причина, на мой взгляд, что так делают почти все. Альтернатив нету, при этом рынок ПО очень сильно востребованный. Сейчас, важно чтобы что-то было сейчас. Но ведь компании хотят, чтобы их продукт был качественный, нанимают людей, платят деньги. А ничего не получается.

Выходом я вижу, использование принципов ITSM. Одной из главных – это разделение полномочий по циклу разработки и контролю качества. Тестирование - должно представлять собой службу по контролю качеством. Со всеми вытекающими (из ITSM) последствиями (каталог услуг тестирования, SLA, итд). Управление качеством будет разговаривать с бизнесом на одном языке.

Это придет, я уверен, как только разработчики получат конкуренцию на рынке.