|
Автор: Руслан Ахметзянов Оригинальная публикация: https://habrahabr.ru/company/jugru/blog/327362/ Порой даже в авторитетных источниках проскальзывает снисходительное отношение к тестированию программных продуктов и, соответственно, к людям, занятым в этом направлении. Там, дескать, и требования к работникам ниже, и сами кадры — так себе, и денег особо не заработаешь. О том, как на самом деле выглядит тестирование изнутри, мы поговорили с Никитой Макаровым, занимающимся в «Одноклассниках» одновременно и ручным, и автоматизированным тестированием.
— Расскажите, пожалуйста, немного о себе и своей работе. Как вы связаны с тестированием?
Никита Макаров: В настоящий момент я руковожу тестированием в «Одноклассниках». К текущей должности я пришел через несколько ступеней. Изначально я был инженером, но в какой-то момент по инициативе технического директора началось внедрение автоматизации тестирования и мне предложили заняться продвижением этого направления.
Первые четыре года я занимался исключительно автоматизацией тестирования. Когда мы победили самые большие проблемы в этой области, мне дали управление delivery. Т.е. я стал уже не только руководителем автоматизации тестирования, но и delivery-менеджером, определяющим кто, в какой последовательности и по каким правилам будет ломать продакшн.
Еще спустя год (с апреля 2016 года) я стал руководить всем тестированием в «Одноклассниках», сохранив за собой и предыдущие позиции. В итоге сфера моих обязанностей довольно широка — чаще всего я могу назвать себя психоаналитиком в IT.
— Рынок подталкивает выпускать продукты быстрее. Так ли часто происходит это в ущерб тестированию? Оправдано ли это?
Никита Макаров: Действительно, скорость выпуска релизов очень часто является определяющим фактором. Связано это с тем, что найти сейчас свежую идею и выкинуть ее на рынок очень сложно. Вдвойне сложнее сделать это одному, так чтобы никто о ней не узнал и не попытался скопировать (копирование идей, применение чуть более фрагментированной нишевой аудитории может быть также успешно; яркий пример — Uber, Яндекс.Такси, GetTaxi и куча аналогичных сервисов по миру). Чтобы выходить на рынок быстрее, очень часто приходится сокращать фазу тестирования.
В той или иной степени в массовых продуктах пользователи являются конечными тестировщиками. О том, что вы сделали не так, что в продукте работает плохо, можно узнать из фидбека от пользователей через маркеты, формы обратной связи и т.п.
Оправдано ли это? С точки зрения скорости — да. С точки зрения аудитории продуктов — не всегда, не каждый продукт так можно продавать.
Акцентирую внимание на том, что мы сейчас говорим о продуктах для массового пользовательского рынка — не life critical, не mission critical — о вещах, вроде Instagram, Facebook, Uber и т.п. В подобных продуктах в случае неудачи кто-то, может быть, потеряет не очень много денег. В областях life critical решений тестирование, как и сама разработка, очень жестко прописаны стандартами, поэтому там срезать что-либо не всегда получается. А если и получается, стоимость ошибки здесь может быть очень большой.
Один из примеров — случай с Knight Capital Group: в течение 45 минут ребята потеряли порядка полумиллиарда долларов. Совсем свежий случай — ДоДо Пицца, когда неаккуратным деплоем сервиса откатила транзакций на несколько миллионов рублей.
Насколько оправдан такой риск? Каждый бизнес решает по-своему.
— То есть объем тестирования определяет отдел тестирования в диалоге с бизнесом? Кто в данном случае должен понять язык собеседника, выдвинув понятные ему аргументы?
Никита Макаров: Инициатива тут на стороне тестирования. Отдел тестирования, который не понимает языка бизнеса, — заведомо мертв. Отдел тестирования сам по себе деньги не зарабатывает (если мы не говорим о продаже этого отдела на аутсорсинг). Соответственно, он должен способствовать сокращению потерь или большему заработку. Поэтому правильный подбор аргументов для бизнеса — это одно из основных качеств хорошего тестировщика, особенно в продуктовых проектах.
— Как вы относитесь к идее, что путь в IT проще прокладывать через тестирование? Мол, там требования ниже, спрос на рынке выше. А через пару лет можно заняться программированием, когда все процессы освоил, закрепился в профессии?
Никита Макаров: Это стереотип. Он с одной стороны верный, с другой — нет.
Если ты хочешь «с места в карьер», работая продавцом телефонов, попасть в IT, сделать это быстро и на какие-то более-менее внятные деньги, сейчас у тебя это скорее всего не получится. Но через тестирование действительно можно попасть в отрасль, т.к. спрос на тестировщиков высокий, а требования к junior-ам действительно ниже. Это подтверждает данный стереотип.
А после того, как человек попал «внутрь», начинается ежедневная, тяжелая работа, и вот тут стереотипы подводят — тебе либо нравится этим заниматься, либо нет. И бывает по-разному — кто-то остается в тестировании надолго, кто-то быстро понимает, что это не его, кто-то понимает, что IT — вообще не для него, «здесь головой работать надо ©».
На рынке, кстати, есть множество кейсов совместных проектов компаний с высшими учебными заведениями. В рамках таких проектов идет нишевая подготовка под свои кадровые потребности. Через них в принципе в IT тоже зайти просто, особенно студенту. Но надо понимать, что чаще всего ты затачиваешься под потребности какой-то конкретной компании.
— Получается, что последующие шаги в отрасли под вопросом?
Никита Макаров: Если вы продолжаете развиваться, следующий шаг внутри компании может быть вполне хорошим и определенным. У меня есть масса примеров того, как мы брали стажеров и они очень классно выстреливали. Они окунаются в культуру компании, понимают, что от них требуется, сами по себе начинают развиваться. Это классно. Но если ты учишься в образовательном проекте одной компании и уходишь в рынок, это не всегда справедливо. Потребности рынка намного шире, нежели потребности какой-то одной компании.
То, что существует большой дрейф из тестировщиков в программисты и смежные профессии — это действительно так. Это видно хотя бы по возрастной статистике в ИТ: инженеров-программистов в возрасте 35-40 лет достаточно много, чего нельзя сказать о тестировщиках. Очень много тестировщиков уходит либо в программирование, либо в управление проектами (в последнее время в управление проектами уходит все больше).
— Есть ли приток кадров из смежных отраслей, например из техподдержки?
Никита Макаров: Приток есть, и техническая поддержка — это одно из мест, где действительно можно брать кадры. Техподдержка находится в конце цепочки поставки продукта и ее сотрудники знают продукт, исходя из общения с клиентами.
Правда, хороший инженер техподдержки на достаточно сложном продукте, который занимается этим не первый год, не всегда пойдет в тестирование хотя бы из-за денег. Хороший инженер поддержки получает не сильно меньше, а, может, даже больше.
— Правда ли, что сами кадры в тестировании по «качеству» сильно уступают разработчикам, аналитикам и т.п.? Если да, почему, на ваш взгляд, это происходит?
Никита Макаров: Это наблюдалось раньше, в середине 90х — начале 00-х, когда у нас была эпоха массового производства довольно стандартного enterprise-софта. Тогда действительно была мода нанимать людей сотнями и тысячами, чтобы они тестировали стандартные вещи по вполне определенным заскриптованным документам, а тестировщик казался «обезьянкой с тест-планом».
Но сейчас это не так — масштабироваться на людях намного сложнее, чем на железе или технологиях, не говоря уже про то, что это дороже.
Все очень быстро меняется. Те, кто думают, что они будут работать тестировщиками сейчас или через 10 лет так, как это было в 1995 — 96 или в начале нулевых, ошибаются. Сейчас на входном уровне действительно наблюдается низкое качество кадров. Но если тестировщик работал в индустрии 3 — 4 года (особенно если он поработал не в одном месте), его багаж начинает быстро пополняться разнообразными знаниями и навыками.
— Автоматизированное тестирование помогает справиться с кадровой проблемой (например, нехваткой кадров)? Или, скорее, порождает новые?
Никита Макаров: Нехватка сотрудников означает, что проблема есть на организационном уровне (о найме дополнительных сотрудников никто не подумал). И тут автоматизированное тестирование, скорее всего, наложит еще проблем поверх того, что у вас уже есть.
К автоматизированному тестированию надо относиться осторожно. Вероятно, автоматизированное тестирование действительно может решить вопрос. Но оно точно может много чего угробить, в первую очередь за счет того, что какие-то сценарии в принципе не будут рассмотрены. Кроме того, поддержка автоматизированного тестирования — это 80% всей его стоимости, и там нужны люди. А стоимость инженеров по автоматизированному тестированию на рынке сопоставима со стоимостью middle-разработчиков. И очень часто бывает дешевле просто этим не заниматься.
Если же есть желание заниматься автоматизированным тестированием, то оно должно быть обусловлено не кадровыми проблемами. Нужно знать точный ответ на вопрос «зачем», что требуется получить, и как-то анализировать в процессе достижение поставленных целей.
Успешные проекты по внедрению автоматизированного тестирования вообще начинаются с отдела разработки. Разработчики сами засучивают рукава и отращивают у себя дополнительную компетенцию. Зная свой продукт и свой код, они строят вокруг него довольно специализированные вещи по автоматизации тестирования.
— Как вы сами повышаете свою квалификацию и квалификацию подчиненных?
Никита Макаров: Начну с рассказа о себе. Чтобы как-то повышать квалификацию, ее надо не терять. Я долго занимался автоматизированным тестированием и прикладной разработкой вокруг него. Сейчас, когда я 90% времени занимаюсь исключительно менеджерскими задачами, стараюсь все-таки уделять время ревью кода. С одной стороны, чтобы не забывать, как вообще все это выглядит, а с другой — чтобы что-то писать самостоятельно. Иными словами, стараюсь быть «играющим тренером», чтобы не терять хватку и понимать контекст: чем живет команда автоматизированного тестирования, с какими проблемами она работает, все ли там хорошо.
А повышаю квалификацию я очень большим количеством чтения и просмотров профессиональных видео. Каждый день, когда я в силах, я стараюсь выделять как минимум час — два (обычно по дороге на работу и обратно) для просмотра видео, изучения профессиональной литературы — статей, книг, блогов.
— А что касается подчиненных?
Никита Макаров: С подчиненными все несколько сложнее. Их сначала нужно подвести к мысли, что квалификация не соответствует (или в ближайшее время перестанет соответствовать) тем задачам, которые они пытаются решить. И потом уже выработать конструктивное решение.
В «Одноклассниках» мы периодически отправляем сотрудников на внутренние и внешние курсы. Очень хорошо, когда они сами приходят и просят этого (это значит, что у сотрудника уже выстрелила в голове мысль, что он что-то не знает, и он даже поискал, где можно подтянуть знания на эту тему).
В целом я пока еще работаю с небольшим количеством людей, где можно общаться с каждым индивидуально, выяснять желания и потребности, соотносить их с целями компании.
— А как вы думаете, можно ли в таких условиях построить обучение по вузовскому принципу?
Никита Макаров: Я думаю, не получится. Процессы, выработанные в учебных заведениях, порождаются из фундаментальных сфер, которые не меняются как минимум десятками лет, а иногда и веками. А обучение в нашей индустрии должно носить исключительно прикладной характер, т.к. индустрия меняется очень быстро.
Когда я первый раз попал на проект работать тестировщиком, о session based test management или context driven testing никто еще не слышал, потому что тогда еще их не придумали. А это было 10 лет назад. В это время первые компании в России только начинали работать по agile-методологии, а при слове scrum у людей не было ни воздыханий, ни ненависти, потому что никто не знал, что это такое.
За 10 лет изменилось очень многое. Можно сказать, все.
— Современный тестировщик должен уметь программировать, зачастую, не хуже штатного разработчика. То есть это уже не тестировщик, а разработчик, который пишет код для тестирования. Итак, кто такой современный тестировщик?
Никита Макаров: Современный тестировщик — это человек, который помогает проекту не делать ошибок. Он не указывает проекту на его ошибки, а помогает их не делать в процессе. Он активно участвует во всей операционной деятельности команды, отлично коммуницирует со всеми участниками, вне зависимости от ролей.
Например, хороший тестировщик может вытрясти из админа необходимую информацию, сложить ее в какой-то умозрительной (пусть не всегда верной, но достаточно упорядоченной) форме себе в голову и отнести ее разработчику. Тем самым тестировщик может спровоцировать диалог между разработчиком и админом или между любыми другими ролями внутри проекта.
Современный тестировщик очень хорошо понимает архитектуру проекта на уровне квадратиков/кружочков и всех многочисленных связей между ними.
Он, возможно, не знает всех технических нюансов, но понимает принципы взаимосвязей между отдельными подвижными частями внутри проекта, степень их влияния друг на друга.
Также тестировщик понимает задачи бизнеса — стратегические и тактические, которые решаются конкретными итерациями или релизами (в краткосрочной перспективе), и может как-то их координировать, понимая, когда они не координируются. У современного тестировщика должен быть хорошо развит скилл планирования. Он должен понимать, что действительно пойдет в релиз и с чем ему нужно будет работать, а что точно не влезет. С учетом этого он точно понимает, как нужно расходовать силы.
По сути хороший тестировщик — это заполняющий материал в проекте, который обеспечивает обратную связь между частями процесса. Он внутренний интегратор продукта между головами всех участников, который всегда знает о реальном состоянии дел больше, чем другие члены команды.
Кстати, про навык программировать — он действительно необходим, хотя бы для того чтобы облегчить жизнь себе самому. Ставить знак равенства между тестировщиком и разработчиком, я думаю, не стоит, но и тот, и другой — инженеры, по сути своей.
— Есть ли в России (на постсоветском пространстве) своя специфика в сфере тестирования?
Никита Макаров: Тут можно вспомнить крылатую фразу о том, что все семьи счастливы одинаково и несчастливы по-разному. Все хорошие тестировщики выглядят одинаково, а все плохие — очень индивидуально.
Портрет хорошего тестировщика интернационален. За счет этого хорошие тестировщики сейчас быстро перемещаются между странами. Последние года два я наблюдаю серьезный отток кадров в Европу и США. Тестировщики и инженеры по автоматизации тестирования уезжают так же, как раньше уезжали разработчики.
Есть ли у нас какая-то специфика? В России эта специфика касается не только тестировщиков, но и всех участников процесса разработки. Заключается она в том, что все работают в условиях повышенного стресса. Поэтому стрессоустойчивость у наших коллег сильно выше (на фоне людей на Западе).
— Стресс связан с тем, что отрасль, условно говоря, куда-то спешит?
Никита Макаров: Да, мы пытаемся угнаться или даже перегнать. В России некоторые компании в течение месяца производят продукты, на которые на Западе потратили бы годы.
В России на уровне всех процессов разработки есть большая беда с пониманием нужд клиентов (это в большей степени проблема бизнеса). Здесь пытаются сделать фичу «на авось», в то время как где-нибудь в Швеции или Германии над ней долго думают, анализируют, а потом делают не торопясь, зная, что она точно выстрелит, имея тому какие-то подтверждения. Возможно, этот стресс отсюда.
— На каждому углу кричат, что нам нужно: «повысить процент автоматизированности продукта до 80%», «достичь code coverage 99%» и другие сумасшедшие лозунги. Насколько, по вашему личному опыту, такие лозунги могут принести пользу или вред?
Никита Макаров: Для начала, подобные лозунги очень глупые. Я лично участвовал в проекте, где покрытие unit-тестами было 10%. Мы его поднимали до 30% и на этом останавливались, потому что дальше это не имело никакого смысла. Каждый следующий процент — куча денег, которые превратятся ни во что, т.к. мы не добавляли этим процентом никакого качества продукту.
Подобные лозунги мне кажутся глупыми, потому что они пытаются под общую гребенку сгрести все типы проектов, вне зависимости от их специфики. А специфика есть. Надо каждый раз включать свою голову.
— А в качестве мотивации лозунги работают?
Никита Макаров: В качестве мотивации — может быть. Но тут надо понимать такую вещь: можно на ежедневных и еженедельных митингах скандировать лозунги — «давайте поднимать code coverage», «давайте покроем 80% продукта автотестами» — но с этого митинга каждый разработчик пойдет в свой маленький уголок, наденет хорошие наушники и будет работать с продуктом сам. И до тех пор, пока он сам не почувствует профит, который выражается через эти лозунги, он не начнет что-то делать. Здесь кроме лозунгов должен быть еще пример.
А англоязычной литературе это очень емко называют «lead by example». Из того, что я наблюдаю, это, пожалуй, единственная стратегия выживания — реальный живой пример, который можно наблюдать в динамике. Т.е. одних лозунгов недостаточно.
— Что вы можете пожелать всем, кто занимается тестированием?
Никита Макаров: Слушать бизнес и учиться.
Таким образом за последние годы отрасль тестирования сильно изменилась, и снисхождению теперь здесь места нет. Это самостоятельное IT-направление, без которого сложно представить разработку современного продукта. Кстати, одним из показателей того, что отрасль «доросла» до определенного уровня зрелости, является появление отдельных технических конференций, таких как Гейзенбаг 2017 Piter, которая пройдет в июне в Санкт-Петербурге.
Обсудить в форуме. |
