Home

Международная конференция для специалистов по обеспечению качества программного обеспечения — SQA Days 6 — прошла с 28 по 29 октября в Москве в рамках Международной восточно-европейской научно-практической конференции по программной инженерии (для специалистов по разработке программного обеспечения) — CEE-SECR 2009.

Портал Software-Testing.ru представляет серию интервью с участниками прошедшего мероприятия.

Приглашаем всех на SQA Days 7 в Харькове, 14-15 мая 2010.

Юлия Нечаева, QA «Innova Systems» (Москва). Пришла в тестирование в 2006, с 2007 – тест-менеджер, руководитель команды тестирования. Автор и преподаватель-инструктор программы дистанционного обучения по направлению «Введение в тестирование программного обеспечения» в рамках сотрудничества с Харьковскими ВУЗами. С ноября 2009 года руководит отделом тестирования компании Innova.

На SQA-Days 6 ты делала доклад о стереотипах, которые мешают отличной работе в аутсорсинге тестирования (скачать pptx). Наболевшая тема?

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

На SQA-Days 6 я хотела поговорить как с представителями класса тестировщиков, так и с представителями класса заказчиков. Мне хотелось, чтобы эти два класса нашли общий язык.

Кого среди слушателей было больше? «Тестировщиков» или «заказчиков»?

Представителей исполнителей — примерно 40%, со стороны заказчиков — 30%, и остальные 30% — группа продуктовых компаний и все остальные.

Стереотипы, перечисленные в твоем докладе, были выбраны изо всех стереотипов, которые существуют, или это были те, которые тебя больше всего раздражают?

Это наиболее распространенные мнения об аутсорсерах.

Те, которые я чаще всего слышала от представителей заказчиков. В информационном поле другого человека они могут быть иными, но в моем — они такие.

Ты говорила с точки зрения тест-менеджера, который, скажем так, «ухаживает» за своей группой тестировщиков, охраняя их от дождя, жары и заказчиков?

Если говорить «грубыми мазками», то есть тест-менеджеры, которые сами по себе являются исполнителями, которым сверху спускается задача, и они распределяют работу среди своих «ребят» и возвращают наверх результат.

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

А о чем тебя спрашивали слушатели?

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

Например, Александр Александров спросил «А что делать, если заказчик сам не знает, чего хочет, либо же он постоянно и неконтролируемо меняет свои желания на ходу?» Если возможно, то я бы с таким заказчиком не стала бы работать, потому что это потеря времени. Не надо под каждого заказчика подстраиваться полностью. Если сотрудничество не получается, то и результат разочарует.

После просмотра презентации мне показалось, что команда, в которой ты работала, или состоит из тебя одной, или же она неимоверно сплоченная и выступает как единый организм. Что из этого верно?

Размер моих команд варьировался от трех до девяти человек, но, как правило, с заказчиком, как тест-менеджер, общалась я.

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

Прояснять проблемы — было моим делом, а решать их, конечно же, без помощи команды невозможно.

Коллективная ответственность?

Формально — нет.

Я стараюсь формировать команду таким образом, чтобы каждый человек понимал свой вклад в качество продукта, и чтобы он за него отвечал и «горел», но по сути, в случае невыполнения задания, или невыполнения должным образом, перед заказчиком ответственна одна я, как тест-менеджер.

В Харькове ты работала в аутсорсинге тестирования. В Москве профиль твоей работы сильно поменялся?

Существенно поменялся. Когда я пришла, отдела тестирования в «Innova Systems» не было. Первоочередной задачей было — найти людей и поставить процесс. Первое получилось, над вторым постоянно работаем. Как известно — улучшать можно бесконечно. Особенно, если есть куда.

Мои ребята тестируют продукты, которые наша компания выпускает под своим именем. Тут надо заниматься не только поиском ошибок и контролем качества, но и предотвращать возникновение багов. Я тут не только руковожу тестированием, но и вношу вклад в другие процессы с точки зрения тестирования. Такой себе «маленький дятел» :)

Еще на «PM labs» в конце июля 2009 с Тимуром Хайруллиным, руководителем службы нагрузочного тестирования в Яндексе, делали доклад «Компании-разработчики ПО: темная и светлая сторона». Мы с ним очень много разговаривали об аутсорсинговых и продуктовых компаниях, особенно когда разговорились про найм тестировщиков, и обнаружили совершенно разные подходы к этой теме. Начали копать глубже, и поняли, что речь идет не об отличиях моего подхода как тест-менеджера от подхода Тимура, а это вообще тенденции в двух разных мирах.

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

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

Как у тебя складываются дела в игровой индустрии?

«Innova Systems» является, в первую очередь, локализатором и издателем онлайн-игр. Мне пришлось погрузиться в отрасль, с которой я раньше не сталкивалась. Первое время мне казалось, что с точки зрения тестирования, игровая индустрия — особенная. Потом пришло понимание, что, в общем-то, различие между тестированием игры и приложения для банка такая же, как и между тестированием любых приложений из разных областей: банки и интернет-магазины, страхование и интернет-сервисы. Своя специфика есть везде, но принципиально постановка процесса тестирования не отличается. Кстати, на SQA-Days 7 я буду как раз рассказывать про то, в чем специфика тестирования игровых приложений.

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

Ну и у нас есть отдел разработки, который разрабатывает нормальный, обычный, «человеческий» софт. Там свои задачи и проблемы.

Часто ли тебе приходилось сталкиваться с людьми, которые считают тестирование «дабл-кликингом»?

Конечно. Очень частый стереотип.

Как ты доносишь до них понимание того, что тут вам ТЕСТИРОВЩИКИ сидят, а не дабл-кликеры?

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

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

В этом секрет успешного сотрудничества?

Секрет в отношениях.

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

Как ты выстраиваешь отношения внутри команды?

Расскажу на примере того, как я даю тестовое задание на собеседовании.

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

А можно так: «Нужно протестировать эту функциональность. Она связана с такими-то модулями, у нее такой-то приоритет. Как ее можно тестировать наилучшим образом? Руками, или отдать на автоматизацию?»

Когда человек может выбирать подход для выполнения задания — это срабатывает даже в самых мелких мелочах.

За рутиной надо замечать стратегические вещи.

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

Этот менеджерский подход у тебя сам появился или ты этому отдельно училась? Что подсказало тебе такую модель поведения?

Я точно знаю, что менеджер должен давать своим людям возможность выполнять задачи, а не задания.

Ну, в какой-то момент я (рядовой тестировщик) подошла к моему менеджеру, и предложила перестать давать мне задания, а дать самостоятельно выполнять задачи. Когда я еще была без права принимать решения, я поняла, что мне хотелось бы принимать решения на моем кусочке ответственности, и когда я увидела, какой прогресс этот подход дал мне, я подумала «Чёрт, наверное, другим тоже было бы интересно так работать!»

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

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

С кем ты общалась на конференции?

Помимо старых знакомых довелось поговорить со многими новыми, интересными людьми, и хочу отметить, что это были представители как из тестирования, так и из разработки, как исполнители, так и руководители. В частности, очень длительный был разговор с директором R&D-департамента (Research & Development) одной из питерских компаний — он впервые узнал о том, что есть конференция SQA Days, очень заинтересовался, и сказал, что теперь обязательно будет посылать на SQA Days своих тестировщиков.

Разговаривала с коллегами, которые управляют тестированием, мы обменялись некоторыми приемами и подходами в тест-менеджменте.

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

Довелось присутствовать при диспуте, в котором Алексей Баранцев рассказывал о том, как он нанимает тестировщиков на работу, и сказал, что возьмет в тестировщики только разработчика, который на собеседовании был инициирован в тестировщики, на что его собеседник (кстати, разработчик) начал очень сильно возражать, но после 15-ти минут разговора он уже сам был готов пойти к Баранцеву тестировщиком.

Очень продуктивно пообщалась с ребятами, которые занимаются автоматизированным тестированием, в частности, Виталий Помазенков и Борис Фролов. Все прекрасно знают, что есть нюансы в управлении ручными и автоматизированными тестами, но не все знают нюансы — это мы и обсуждали.

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

Подготовка SQA Days 7 в полном разгаре. Ожидается ли там такая же разнообразная аудитория, как и на SQA Days 6?

Ну, не будет «насильственной» кооперации с разработчиками, как это было на SQA Days 6, совмещённой с SECR, но я думаю, что посредством этой кооперации мы все-таки расширили свою аудиторию, и на следующие наши конференции пригласим и обогреем различных представителей процесса разработки программного обеспечения, и программистов, и менеджеров проектов, и аналитиков, я думаю, что на следующих выпусках будет интересно всем.

Интервью брал Алексей Лупан.

На постсоветском пространстве ежегодная конференция «Software Quality Assurance Days» (SQA Days) считается одним из крупнейших событий в области обеспечения качества программного обеспечения. Сайт конференции: www.it-conf.ru

Приглашаем всех на SQA Days 7 в Харькове, 14-15 мая 2010.