Как часто любому из нас приходилось сетовать на то, что программа «глючит»! И в такие моменты хочется спросить: «Неужели этой ошибки не могли заметить при тестировании?» Увы. Тестированию ПО при собственной разработке зачастую сил и времени уделяется меньше, чем нужно. Сроки поджимают, заказчик торопит… В итоге вся тестовая работа сводится к отладке в «пожарном» режиме, буквально «в бою» — на рабочих местах конечных пользователей системы. Но такая проблема свойственна далеко не всем. О том, как можно организовать тестирование ПО, как внешней разработки, так и собственной, рассказывает Михаил Мериин — руководитель службы тестирования ОАО «ВымпелКом».

Intelligent Enterprise: Михаил, давайте начнем с самого начала: кто ставит задачу для разработки, как ведётся управление изменениями — один из самых сложных прцессов?

Михаил Мериин: Есть «люди бизнеса» — наши заказчики. Рано или поздно у них возникает желание что-то изменить в программах, которыми они пользуются. Свои пожелания (требования) они собирают в виде Request For Change — RFC, или же, по-русски, запрос на изменение. Дальше с этими запросами работают аналитики, которые должны «перевести» требования заказчика на язык информационных технологий, проверить, нет ли таких возможностей или функций в уже имеющейся системе (может, ничего и разрабатывать не нужно — достаточно настроить, и всё). Тут же надо понять, в каких интегрированных (смежных) системах потребуются доработки, каких специалистов следует привлечь к процессу. Каждое принимаемое изменение обязательно сравнивается с целевой архитектурой и принятыми стандартами. В итоге всей этой работы и обсуждений появляются требования, составленные языком ИТ, становится понятным, сколько времени потребуют эти доработки, составляются планы реализации.

Каждая ИТ-система живет и развивается по своим ритмам, у каждой складывается свой жизненный путь: релизы, патчи, аппендиксы. Сроки этих этапов, разумеется, не совпадают даже у двух систем (а в компании их сотни). Для их увязки существует процесс планирования и «упаковки» релизов. У нас данный процесс идет не на бумаге, а в приложении, связанном с Lotus Notes и другими информационными системами. Таким образом, релиз собирается из запросов на изменения и дефектов, которые предполагается исправить.

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

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

Это всё общие вещи, не связанные с тестированием непосредственно. На каком этапе подключаетесь вы, ваше подразделение?

Тестировщики участвуют в разработке и анализе требований с самых первых стадий обсуждения. Это по сути коллективная работа, и первичные требования от бизнеса могут видеть все: аналитики, разработчики, тестировщики. Мы все принимаем участие в согласовании и обсуждении RFC. Задача тестирования — понимать, реализуемы ли данные требования, как их можно будет проверить. Необходимо также убедиться, однозначно ли требования могут быть истолкованы и поняты. После согласования со всеми участниками процесса начинается непосредственная работа над реализацией поставленных задач. Появляется HLD — high level design и ТЗ — техническое задание, представляющее собой подробный документ, где понятным разработчику языком написано, какие функции нужно менять, какие «окошки» переделывать. Эту работу выполняет целая команда: бизнес-аналитики, разработчики (но не кодировщики!) — те, кто решает, как это будет выглядеть на уровне технологий, и бизнес-пользователи — сами инициаторы изменений. Напомню, что на протяжении всего процесса его участ­ники видят, что происходит с запросом, на каком этапе он находится.

На основании утвержденного пакета документов (HLD и ТЗ) по заказанному изменению программисты начинают кодировать, а тестировщики — писать план тестирования. Это еще не окончательный план, а лишь «скелет», основа. Многое уточняется в процессе разработки, ведь экран вам заранее никто не нарисует! Во время кодирования дорабатываются документы, касающиеся изменения, и все коррективы фиксируются. Вообще все документы на разработку хранятся в версионном хранилище, поэтому уточнить, что, когда и кем менялось, можно всегда. После того как кодирование закончено, все модули собраны в инсталляционный пакет и написана инструкция по установке продукта, начинается собственно тестирование.

Первый шаг — проверка «наката/отката». Тестовые среды у нас отдель­ные, и разработчики не имеют к ним никакого доступа. Релиз устанавливается, а потом деинсталлируется (откатывается). В первую очередь это делается для того, чтобы администраторы, которые будут инсталлировать его в продуктивную среду, могли потренироваться — как у них это получится. Ведь что разработчику кажется само собой разумеющимся, для администратора совершенно не очевидно. Проводится этот тест руками администраторов, а тестировщики сидят рядом и смотрят, все ли делается по инструкции. Чтобы не было такого, когда администратор говорит: «Ну, тут мне и так понятно» — и делает что-то по наитию исходя из собственного опыта… А завтра он заболеет, и ПО будет ставить его коллега, которому, возможно, совсем не всё будет понятно, что делать и почему. Все эти формальности и четкое следование инструкциям — не блажь, они не из пальца высосаны. Они, как воинские уставы, «кровью писаны».

Очень важно быть уверенным, что мы сможем вернуть систему в исходное состояние, если произойдет какой-то сбой при установке. После «отката/наката» выполняется первичная проверка. Цель ее — «пощупать» установленный релиз в нескольких местах, убедиться, что он «живой». Проверяется основная функциональность. Скажем, если мы проверяем платежную систему — давайте, полностью проведем один платеж. Это нужно, чтобы посмотреть, стоит ли нам с этим релизом дальше возиться, или его надо сразу на доработку отправлять.

После первичной проверки выполняется основное или системное тестирование. Этот тест проводится согласно полному плану, который обычно состоит из тестирования новой функциональности и регрессионного тестирования. Первое проверяет то новое, что сделано в данном релизе, второе — не поломаны ли при разработке этого нового старые функции. По итогам мы пишем отчет, прежде всего — для бизнес-пользователей. Бывает так, что не все требования реализованы в полном объеме, но заказчик может посчитать, что для начала хватит и эти части вполне пригодны для использования.

Какие еще виды тестирования вы проводите?

Очень часто к ПО предъявляются нефункциональные требования — по объемам данных, по быстродействию, по одновременной работе каких-то процессов. И здесь применяется нагрузочное тестирование. Это отдельное и весьма специфичное направление. Сюда же относится стресс-тестирование — проверка под заведомо большей, чем плановая, нагрузкой. На данном этапе можно выявить, какие нагрузки будут критическими для системы, и заранее предупредить об этом бизнес. Тут же проверяется, правильно ли «падает» система. Ведь серверы в таких ситуациях должны быть доступны для удаленного администрирования, в журналах должна появляться информация о критических ситуациях и падениях приложений, данные должны быть сохранены, а не испорчены и так далее.

Нагрузочное и стрессовое тестирование — довольно сложный вид работ. В первую очередь потому, что тестовые среды полностью аналогичными продуктивным никогда не бывают. Есть методики, которые позволяют высчитывать результаты исходя из того, что работа ведётся на другом оборудовании. В «ВымпелКоме» десятки периферийных систем, с которыми взаимо­действуют внутренние приложения, по­этому собирать тестовые стенды очень сложно. Это требует не только чисто технологических, но и организационных усилий — переговоров с владельцами всех нужных систем, выделения соответствующей техники, разработки «заглушек» и «имитаторов», которые тоже в свою очередь нужно тестировать. Организацией данного процесса занимаются тест-менеджеры. Результат нагрузочных тестов оформляется как отдельный отчет, с которым в первую очередь знакомятся администраторы системы.

Они оценивают, можно ли принять версию с такими-то особенностями поведения или нет, поскольку есть инфраструктурные ограничения. Какие-то вещи приемлемы, потому что решаются линейным масштабированием, а какие-то могут стать камнем преткновения.

Еще есть тесты на удобство использования продукта. Дело это серьезное, так как наши внутренние пользователи не менее важны, чем абонентны сети «Билайн». Ведь когда им удобно работать, то и скорость лучше, и выигрыш в обслуживании абонентов ощутимее. А если им будет неудобно, компания может потерять в деньгах, а это критично.

Теперь о быстродействии приложений. Эти параметры согласуются с бизнесом, и наши заказчики должны быть поставлены в известность о достигнутых показателях. Особо важна комфортность веб-сайтов, с которыми работают абоненты: доля самообслуживания растет постоянно, и от удобства применяемых для этого средств зависит эффективность бизнеса. Конечно, тут тестировщики приговор не выносят, поскольку оценки эти весьма сложны и могут быть субъективными. Но по поводу бэк-офисных приложений тестовый отдел свое мнение высказывает, указывая причины, по которым на наш взгляд неудобно работать с теми или иными элементами интерфейса. Исследования применимости абонентских приложений выполняются с привлечением фокус-групп, видеосъемки и т. д., но занимаются этим другие подразделения или внешние подрядчики.

А вот, к примеру, user acceptance test частично выполняются пользователями. «Вы заказывали в RFC такую-то функциональность? Зайдите и посмотрите, что получилось, удобно ли этим пользоваться…» На данном этапе выявляются интересные особенности, ведь даже выпадающими меню люди пользуются по-разному, и способность ПО поддерживать такое разнообразие тоже должна быть проверена.

Наконец, один из самых сложных видов тестирования — интеграционный. Здесь нужно собрать стенд из разных систем, разместить их на имеющихся серверах и платформах и провести все запланированные тесты. Конечно, абсолютно все тесты, все вероятные комбинации и ситуации проверить невозможно. Хорошо, если получится провести их на реальных объемах данных, но и это возможно не всегда из-за технических или временных ограничений.

Какие инструменты для автоматизации процессов тестирования вы применяете?

Мы применяем широкий набор средств для тестов разного характера, продукты семейства Mercury в том числе. Но при автоматизации тестирования нужно в первую очередь руководствоваться экономическими соображениями, просчитывать отдачу. Бывают случаи, когда экономически выгодней нанять большой штат малоквалифицированного персонала. Мы такие оценки делаем постоянно: эффект должен быть, причём не только денежный. Может повыситься качество или сократиться сроки, ведь автомат способен работать и ночью. В целом автотестирование у нас выборочное, и всегда нужно ясно понимать конечную цель его применения. Если кому-то лично нравится писать «скрипты» для автоматизации процессов тестирования, то это еще не повод им заниматься. Да и живых человеческих рук, глаз и головы никто не заменит, об этом тоже надо помнить.

Чем отличается тестирование приложений, разработанных внутри компании, от проверки ПО, сделанного внешними подрядчиками?

Прежде всего в случае внутренней разработки у нас есть исходные коды. Я могу получить отчет о тестировании от самих разработчиков, ведь они тоже проводят свои тесты. Могу затребовать от них код-обзор, то есть свидетельство того, что код написан в соответствии с нашими стандартами. От внешнего подрядчика мне таких документов не получить. Они не обязаны показывать нам результаты выполнения своих внутренних процедур. У внутренней разработки есть и еще один ощутимый плюс — открытый код. Если код открыт, можно посчитать, сколько сделано ошибок. С внеш­ней разработкой мы работаем как с черным ящиком, ведь нам поставляют скомпилированный код. В лучшем случае это «серенький ящичек», едва прозрачный.

Кроме того, если разработчик внутренний, то мы участвуем и в системных тестах, и вообще во всем проекте от начала до конца.

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

У нас в компании существуют методики тестирования внутренних и внешних разработок. Хотя научиться тестировать можно только практическим путём, общей теории или формального образования, к сожалению, пока нет.

Кстати о персонале. Как вы ищете, обучаете, удерживаете, мотивируете сотрудников отдела тестирования?

В условиях острого дефицита кадров мы все шире используем аутсорсинг. Многие наши тестировщики — из внешних компаний. У нас их несколько. Сотрудники «ВымпелКома» — в основном только тест-менеджеры, которые занимаются организационной работой и являются носителями знаний. Они принимают функционал по определенным схемам и в случае смены подрядчика должны организовать новую команду, передать ей знания и методы работы. Таким образом, в штате остаются только ключевые сотрудники. Даже будучи аутсорсером, сотрудник может у нас профессионально расти, выполняя все более сложные задачи, меняя области применения, поскольку такие вещи, как нагрузочное тестирование или автоматизация тестов, требуют весьма высокой квалификации и специальных знаний. Общий пул наших сотрудников — это «хорошие» десятки людей. Ну и активности у нас не меньше.

Тем не менее людей, как правило, ищем мы сами. Претенденты на интервью тоже проходят тестирование, в ходе которого выясняется, что они знают, а что нет. К сожалению, качество подготовки студентов в вузах пока оставляет желать лучшего. Удовлетворительные отзывы о тройке МГУ, МФТИ, МИФИ, иногда к ним примыкает «Бауманка». Огорчает не тот факт, что люди не знают чего-то (научиться можно всему, было бы желание!), а то, что в резюме пишут заведомую ложь. В последнее время мы сталкиваемся с необоснованными амбициями: без опыта, без знаний кто-то претендует на очень высокую зарплату. В подавляющем большинстве случаев в резюме содержится, скажем так, не совсем правдивая информация. И это тревожный симптом на самом деле. В службе тестирования есть четкие критерии по квалификации сотрудников в зависимости от должности. Так что уже после интервью я примерно знаю, какая квалификация у претендента и на какой уровень зарплаты он может у меня рассчитывать.

Проблема рынка, на мой взгляд, в том, что многие работодатели берут и тех, кто ничего не знает и при этом имеет необоснованные требования. Наша политика — таких людей не брать. Я готов возиться с человеком, у которого есть голова, способным учиться, и готов вкладывать в него средства и учить. Но он не должен врать и, конечно, не должен претендовать на высокий оклад, не имея должной квалификации. Так что к нам попадают только мотивированные люди. Есть несколько сотрудников, которые тратят много времени на обучение других. Составлена программа обучения, наработана определенная методика, по которой от двух недель до месяца мы занимаемся с новичками, и опыт показал, что это оправданно. Дальнейшее обучение идет уже в рамках текущих проектов.

Теперь о мотивации. Конечно, мы живет в материальном мире, который «дорожает» день ото дня. Но все же в центре мотивации не должна быть только зарплата. Увы, большинство людей говорят лишь о деньгах, а иное им не интересно. Предлагаешь изучить что-то новое, а в ответ: «Сколько я получу за это?». Я стараюсь искать людей, у которых жизненные ценности не сводятся к долларовому эквиваленту. Тогда таких людей можно мотивировать, понимая, чего они хотят. Кто-то стремится расти как специалист, как эксперт, стать «гуру» в своей области. А кто-то хочет подниматься «в чине», становиться управляющим. Но и это лишь отдельная задача для мотивации сотрудников. Что касается вовлеченности людей в процесс, их нагрузки, то, конечно, мы понимаем, какая работа сколько времени занимает. Если есть какие-то отклонения, то надо разбираться, почему это происходит. В цент­ре контроля качества видно, кто и сколько задач выполнил.

Несомненно, есть и материальная составляющая мотивации: общие для компании компоненты, оценка персонала и прочее. В своей службе мы сделали четкую градацию, и всем извест­но, что каждая должность означает, какой комплекс ответственности она несет, какой квалификации требует. По этой шкале проводится периодическая оценка тестировщиков, в том числе и внешних сотрудников — аутсорсеров. То, что я сейчас рассказываю, это и есть понятие «обратной связи». Мы стараемся, чтобы данный механизм работал постоянно, тогда человеку понятнее, как он растет и на что может рассчитывать.

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

Их довольно много. На нашем внутреннем сайте постоянно появляются новости: какие проекты и с какими результатами мы заканчиваем. Есть там и фото всех сотрудников с небольшой автобиографией. Лучших выделяем особо, присваиваем некий статус, который отражается на сайте. Например, «атлант» — сотрудник, «поднявший» важный и сложный проект. Или «лучший ученик»: новички осваивают нашу обязательную программу за определенное время, но бывают и рекорды по изучению SQL либо UNIX, и их мы обязательно отмечаем. «Лучший грузчик» — это мастер нагрузочного тестирования. Есть также «ударник труда», «человек-оркестр», «гуру», «лучший баголов»… Всё это работа менеджеров, они придумывают, как выбирать кандидатов.

Как-то уж очень по-социалистически это выглядит…

Социалистические стандарты? Вот, скажем, приходит письмо от релиз-менеджера с благодарностью нашим людям. Вы не представляете, как на сотрудников действует простое «спасибо, вы классно поработали». Кроме того, есть публичные награждения, грамоты, значки, поездки. Я не знаю, социалистический это подход или нет, но всем очень приятно бывает, разве не так? Ну и, конечно, мы довольно часто выбираемся все вместе шашлыков пожарить, на лыжах покататься, на каток сходить. И не надо ждать официального «корпоратива» — можно и самим все организовать, у нас это обычное дело.

А каков статус вашего подразделения и его сотрудников в компании? Ведь часто бывает так, что важность программистов всем ясна, а вот значимость тестировщиков, мягко говоря, не очень.

Если в какой-то компании тестировщик один, то понятно, какой у него будет статус. Понятно, и какое качество продукции будет в этой компании. Несколько лет назад и в «ВымпелКоме» тестировщики были не всем заметны: ну есть какие-то ребята, что-то они там делают, только непонятно, что... Но опыт всех внедрений говорит о том, что без тестирования — никуда. А раз мы участвуем во всех проектах, то о нас и знают. Я систематически общаюсь с проджект-менеджерами и другими руководителями и рассказываю, что такое тестирование, зачем оно нужно. Согласен, далеко не все это знают! Но статус нашей службы заметно изменился за эти годы. А зарплата опытных тестировщиков уже не отличается от зарплаты программистов. Так что тут главное — уметь себя проявить и не лениться.