• Тестирование и качество информационных систем
• Сообщество специалистов отрасли
• Публикации и обсуждения материалов
• Журнал "Тестирование и Качество"

Авторский проект
Вячеслава Панкратова

Записки тестировщика

Все помнят чудесную притчу-миф о Сизифе, который был покаран богами вечным, бесполезным трудом? Если нет - напомним.

Примечание

Тема Сизифа в этом выпуске будет затронута несколько раз, поэтому он вынесен в название статьи и я рассказал о товарище поподробнее. Очень постараюсь не увлекаться мифологическим стилем, но не обещаю, что получится.

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

Вступление

Я часто сталкивался на практике и слышал от коллег из других компаний, насколько бывает сложно убедить руководство внедрять процедуры внутренней работы отделов или групп тестирования. Если группы разработки зачастую работают по определённым правилам, формализуемым в процедуры, то работу отделов тестирования часто можно назвать хаотичной или "ведомой" вслед разработке. Оговорюсь, что я не рассуждаю о компаниях, в которых все отделы и направления работают согласно определённой модели или процессы которых сертифицированы. Таких компаний на сегодня немного, они также сталкиваются с проблемами при работе с процедурной основой, однако сложности эти несколько иные - если у меня появится такой опыт, я смогу рассказать вам подробнее. Также я не говорю исключительно об IT-компаниях: подразделения, так или иначе связанные с разработкой, внедрением или эксплуатацией информационных систем, сейчас есть практически везде. И если в этих группах затронуты вопросы тестирования, то проблемы рано или поздно возникают, как и у всех остальных.

Откуда

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

В чём же дело?

Получается более-менее традиционная картина, когда на тестировании (в его самом широком смысле) экономят. Что же получается? На тестирование приходит продукт (версия) с отсутствующей или недостоверной (устаревшей) документацией. Изменения в документацию не могут быть внесены, по причине того, что ресурсы разработчиков брошены на «залатывание дыр» (приложение после тестирования ещё будет и исправляться, и перетестироваться, Сюрприз! - коллеги, понимаю, что у многих из вас эти элементарные, казалось бы вещи, вызывают улыбку, но давайте припомним, разве вы не попадали в такие ситуации?). Времени на полноценное тестирование нет изначально. Отдел или группа, которая ведёт этот проект, работает в "штормовом" режиме, когда откладываются в сторону и наработанные документы ("Какие чек-листы? Тут бы основной функционал успеть посмотреть!" - знакомо?) и скрипты автоматизации (они прекрасно работали до предпоследней версии, то есть ДО той версии, которая уходит заказчику или в продуктивную эксплуатацию) в которые никто не успевает вносить изменения вслед за "фиксами" в версиях. Если процесс позволяет, то происходит выпуск нескольких сборок, в которых методично (или по мере нахождения новых дефектов) закрываются основные ошибки, то есть приложение или система "готовится к сдаче". Риторический вопрос, чем до сих пор, как не этой самой подготовкой занимался отдел разработки и направление тестирования, оставим висеть в воздухе. Ситуация может принимать различные формы, когда тут же "висят над душой" менеджеры проекта (кстати, никогда не мог понять этой стратегии поведения - раньше надо было рулить, а теперь дайте уже нам выправить ситуацию по мере сил), которые упорно не хотят слышать "не выпускаем". Или кто-то из руководства постарше принимает участие в выпуске и любит задать вопросы на тему "почему же вы тестируете руками, если есть тул?". Словом, те, кто проходил "школу жизни" в подобных ситуациях, меня поймут прекрасно.

Кто заинтересован?

В этих простых, жизненных ситуациях и кроется, как я понимаю, желание изменить стиль и порядок работы. И именно тестировщики в этой ситуации наиболее заинтересованная сторона. Потому что на них сходит вся лавина накопленных временных задержек и внесённых отклонений от плана проекта: от внесения недокументированных функций или не внесения документированного функционала в версию до реализации "временных решений", заглушек и прочих моментов, которые уводят систему от первоначальных требований всё дальше и дальше. "С кого спрос?" Хороший и простой выход из ситуации, когда у заказчика посыплются ошибки, или на презентации что-то "упадёт" (подобные казусы бывают и у мировых лидеров), это возложить ответственность на отдел тестирования. Даже опытный менеджер команды тестирования, не раз попадавший в такую ситуацию и наученный опытом составлять соответствующие документы для руководства (отчёты о состоянии продукта или записка о неготовности выхода продукта), может оказаться в тупике. Реальная ситуация просто не оставит ему времени на работу с документацией и подготовкой отчёта. Схема "вечером деньги - утром стулья" начинает звучать по-новому: "вечером версия - утром грабли". Придя на следующее утро на работу, после упорного "вечернего заседания" можно обнаружить разъярённого шефа (вариации: расстроенного ПМ-а, слишком вежливого заказчика на телефоне, гору писем от своих же пользователей), который получил результаты использования / демонстрации версии, которую вчера под вечер "выкатили на гора" общими усилиями. Разговаривать в такой ситуации о том, что продукт ушёл будучи неготовым, просто нереально. И никакие документы после полученных (негативных, как правило) результатов работы продукта не будут приниматься всерьёз. Составлять их всё-таки нужно (это история работы отдела!), но это тема несколько другого разговора. Думаю, я достаточно прояснил позицию, почему же тестировщики, как никто другой, заинтересованы в том, чтобы навести порядок в подобных ситуациях. И во многом тут помогут вынесенные в заголовок процедуры. Иначе никакие договорённости не спасут отдел / группу от повторения подобной ситуации.

Сизифов труд - картина первая

Штурмовая работа перед выдачей версии (причём работа, как направления разработки, так и тестирования), трата невосполнимого ресурса нервных клеток всеми участниками проекта и, что самое смешное, на выходе постоянно "сырая" версия, которая уступает промежуточным, рабочим версиям.

Коллеги, я наблюдал со стороны эту чудную картину в одной компании, в которую был вхож, на протяжении полутора лет. Забавно? Компания не из аутсайдеров на рынке. Продукты выпускаются, версии идут своим чередом. Но камень Сизифа в виде постоянно недовольных заказчиков/пользователей и до сих пор накрывает команду разработки с головой, после каждой версии. Это уже "стиль".

Что же нам поможет?

Хочется процитировать чудесного героя из кинофильма "Операция Ы":
- Простите, не "нам", а "вам".
И тут же ему возразить:
- Нет, на этот раз именно нам!

Я, как и вы, коллеги, периодически оказываюсь в ситуации, когда вижу эту картину со стороны или принимаю в ней активное участие. Пятничные авралы, сдача версий в конце месяца - думаю это и многое другое, что могло бы быть сделано без спешки и качественней, знакомо многим из нас. И понимаю, что "разбор полётов" после очередной неудачной (хорошо, если не провальной) версией системы ничуть не изменят сложившейся ситуации. Нельзя менять правила, если нет арбитра и правила нигде не записаны. Толку от таких договорённостей мало. Как я понимаю, правила работу могут чётко ложится в понятие "процедура", а вот кто будет арбитром в тяжелом деле её внедрения и использования можно решить исходя из расстановки сил в компании / подразделении. Кто же должен разрабатывать и внедрять процедуры, которые регламентируют взаимоотношения разработка / тестирование / менеджмент проекта?

Командовать парадом будет...

Больней всех от камня, который скатывается с горы вниз, всё равно тестировщикам. Они стоят в конце цепочки выпуска, они же и отвечают за качество перед заказчиком или клиентом / пользователем. Менеджмент, конечно, тоже получается не в выигрыше, но требовать многого от специалистов, которые ведут проекты в компаниях сегодня, не приходится. И тут уже оговорка про средние компании не применима. Хороших, опытных менеджеров проектов не хватает и в крупных компаниях. (При этом проектов не только IT-шных. Это могут быть и крупные проекты по ведению контрактов и т.п.) Это либо кто-то из структуры компании, который на предыдущих проектах (если они были) проявил умение договариваться и отслеживать сроки / ресурсы, либо вовсе кто-то из разработки. Человек, которому поручают проект, в надежде получить менеджера проекта, так сказать, готового, который просто знает приложение, возможно, руководил его разработкой со стороны разработки. Тут надежды никакой, потому что видение у такого человека практически совпадает с точкой зрения разработки, то есть программистов, которые в свою очередь стоят в середине цепочки производства продукта и имеют все шансы "найти крайнего". Оговорюсь, что на практике встречаются исключения (мне, к примеру, на таких людей везло) и, бывает, сам менеджер проекта стремится что-то менять. В этом случае группа тестирования просто становится дополнительной силой за спиной такого ПМ-а, и вместе пытается "ломать" ситуацию.

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

Сизифов труд - картина вторая

Я не зря так долго рассказывал о том, как происходит на первой картине полотна "Сизифов труд", вернёмся к ней и рассмотрим подробнее "заинтересованных" в реальных изменениях лиц. Наиболее заинтересован всех тот, кому больнее. Имеем направление тестирования, которое пытается "снизу" предложить своё видение "правильного" процесса. Что в нём? Попытка оградить себя от лавины временного сдвига (опоздания) в проекте, требования по документации, времени на внесение изменений и перетестирование. Помним, что время, отведённое на проект не резиновое. Значит время, которое нужно тестированию (я не затрагиваю те задачи, которые можно распараллеливать), будет отбираться у разработки. Другого выхода нет. И этот момент понимают все участники второй части картины. То есть: планирование и контроль выполнения планов (обсчёт контрольных точек или другие варианты, не суть важно), словом всё то, чего мы все так не любим… Все с доверием смотрят вам в глаза и начинают объяснять, почему то, что вы предлагаете работать не будет. И объяснят. Потому что вы, равно как и они в этой ситуации пытаетесь натянуть одеяло (время проекта) на себя. Попытка доказывать, уговаривать, объяснять, зачастую заранее обречена на провал. У разработки есть свои планы, свои трудности. В этой ситуации тестирование, такой же игрок в проекте, как и разработка или менеджмент. О свою часть ресурсов по доброй воле никто никому не отдаст.

Я намеренно не рассматриваю вариантов, когда тестирование удобно держать в подобной позиции той же разработке (бывает масса политических моментов, особенно в крупных компаниях), я беру обычную (как бы странно не звучало тут слово "обычный"), нормальную ситуацию, когда проблема ясна всем игрокам, и все заинтересованы в переменах... За чужой счёт.

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

И снова камень Сизифа накрывает уже само начинание что-то менять. Этот камень по определению тяжелее, чем тот, кто его катит. Потому что что-то менять могут те, кто принимает решение. Эти, казалось бы, избитые слова, кажутся мне единственным правильным ответом на вопрос "снизу-вверх" или "сверху-вниз" нужно внедрять изменения.

Пока "Титаник" плывёт...

Реальных изменений можно будет добиться только тогда, когда "Титаник"... простите, компания встретит свой "айсберг". И сколько не будут убеждать нас в обратном консультанты и крупные фирмы, которые уже прошли эти трудности, ситуация зачастую именно такова. Даже консультанты компаний-вендоров решений для автоматизации тестирования и сопровождения смежных процессов, то есть те люди, которые, внедряя технологию и инструменты, по сути, перестраивают наш процесс разработки - открыто говорят о таких "айсбергах" на которые налетала компания, прежде чем пришла к более-менее ясному пути движения. Пути, который начинается именно с внедрения простых (возможно административно-командных) процедур и правил.

Вывод

Сидеть и ждать жутко не хочется. Ведь наш корабль, наша компания (отдел / подразделение) это наш труд и наша компенсация. Пережить столкновение "Титаника" и айсберга удалось далеко не всем, как вы помните. Сидеть и видеть, как тебя накрывает тень камня при очередной попытке закатить его наверх - удовольствия мало.

Делать, как советуют консультанты западных компаний? "Отхлестайте их фактами о размерах финансовых потерь" - хороший совет, который, возможно, сработает. В единичных компаниях, которые и так уже стоят на пути перемен.

Внедрять снизу - усилия достойные лучшего применения.

Менять место работы? Срабатывает, опять-таки, от случая к случаю, но не конструктивно по отношению к тому кораблю, на котором мы сейчас находимся.

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

PS

Я не ударился в мифологию и, хотя, первая версия статьи и была переполнена чем-то таким "сизифовским", вы её не увидели. Надеюсь, все оценили мои титанические усилия? До скорой встречи в эфире.

--
Панкратов Вячеслав
18/01/2005