Home

Думаете, в крупную компанию в сфере кибербезопасности сложно попасть?

Дмитрий Кузнецов, руководитель отдела контроля качества облачной инфраструктуры «Лаборатории Касперского» десять лет назад попробовал свои силы и теперь руководит одним из ключевых отделов компании, к тому же решает нестандартные задачи и успевает играть в футбол. Мы поговорили с ним — о том, как в его отделе организован процесс тестирования, какие интересные задачи приходится решать, а ещё – про противостояние с разработчиками, знаменитостей среди тестировщиков и многое другое.

Но и это не всё! В конце вас ждет бонус: тестовое задание, которое дает возможность выиграть один из трёх ценных призов и попасть на работу в компанию. Дерзайте :)

Дмитрий Кузнецов, руководитель отдела контроля качества облачной инфраструктуры в «Лаборатории Касперского»

Чем занимается твоё подразделение?

Моё подразделение занимается тестированием по трём большим направлениям, это инфраструктуры и веб-порталы: B2B, B2C, BackOffice. Изначально мы занимались только инфраструктурами, без web-частей, без GUI, то есть инфраструктурами, которые не видны пользователю. Потом на основе этого были реализованы другие крупные проекты, которые уже стали видны пользователям, а также в наше «портфолио» добавились веб-порталы. Можно сказать, теперь мы тестируем практически все виды разрабатываемых R&D продуктов, кроме разве что продуктов для рядовых пользователей в их традиционном понимании.

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

Как организован сам процесс тестирования?

У нас есть долгоиграющие проекты, где процессы уже давно выстроены, но появляются периодически и новые. В целом структура плюс-минус одна и та же.

• Всё начинается с общения. Сначала с заказчиком, причем, как правило, это внутренний заказчик, поэтому общение довольно лёгкое и быстрое. Нам надо понять его цель и конкретные ожидания от тестирования: формат общения, отчётность и т. д.
• На втором этапе мы выдвигаем свои требования, на основании которых должен быть написан продукт или инфраструктура. Это стандартные требования: тестопригодность, хотя бы минимальная документация, а также договоренности по формату взаимодействия с контрагентами.
• Начинаем исследование: какой подход лучше выбрать, чтобы протестировать решение. Большинство моих коллег — автотестеры, в основном мы тестируем API и веб-порталы, разные интеграционные сценарии, поэтому и применяется в основном автотестирование. С другой стороны, мы оцениваем стоимость такого проекта. Ведь всё покрывать автотестами — это дорогое и не всегда нужное удовольствие.
• В конце концов мы создаём некий фреймворк, набор тестов. Это происходит в тесном взаимодействии с командой, которая разрабатывает продукт, с заказчиком, с аналитиками. Основная ценность, которую мы даём, — это непрерывный фидбэк о качестве продукта и о том, достигаются ли цели заказчика.

Рассмотрим наш подход на примере проекта Kaspersky Endpoint Security Cloud Infrastructure. Этот проект является частью программы проектов Kaspersky Endpoint Security Cloud. Программа Kaspersky Endpoint Security Cloud состоит из нескольких приложений: Kaspersky Endpoint Security, Kaspersky Security for Mobile, Kaspersky Endpoint Security Cloud Infra, Kaspersky Security Center Cloud Console. В рамках нашего проекта заказчиком выступает программа.

В проекте Kaspersky Endpoint Security Cloud Infra мы реализуем облачную геораспределенную инфраструктуру для развёртывания и обслуживания серверов администрирования и консолей управления, а также веб-порталы для управления аккаунтом пользователя и для управления рабочей областью (уже они владеют конкретными инстансами консолей в конкретном регионе).

У заказчика были определённые пожелания на старте:

1. Покрытие тестами сквозных пользовательских сценариев.

2. Проведение аудита безопасности.

3. Проведение тестирования скорости отображения страниц на веб-порталах в различных пользовательских сценариях.

4. Помощь с тестированием локализации документации, веб-порталов и писем (восемь языков).

5. Участие в приёмочном тестировании программы.

6. Поддержка тестовой среды.

7. Участие в программных статусных встречах по тестированию.

8. Формат багов для продуктовых команд.

Какие требования выдвигали мы:

1. Запросили список пользовательских сквозных сценариев для покрытия тестами.

2. Договорились, кто и в какие сроки заказывает аудит безопасности.

3. Запросили нефункциональный профиль, в котором попросили отразить ожидания по количеству пользователей, сценариям, частоте запросов, ожидаемой скорости, различным исключениям.

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

5. Проговорили скоуп и сроки, формат отчёта о тестировании.

6. Договорились в каком формате и объеме мы можем осуществлять поддержку тестовой среды, какие есть ограничения.

7. Согласовали формат встреч и состав участников с нашей стороны.

8. Выдвинули свои требования по оформлению багов на нас.

Что имеем сейчас:

1. Покрытие пользовательских сквозных сценариев программой оценено как удовлетворительное, перед каждым релизом актуализируем его.

2. Несколько раз был проведён аудит безопасности, были исправления в коде.

3. В процессе подготовки релиза проводим регулярные замеры скорости загрузки страниц. Периодически актуализируем нефункциональный профиль с заказчиком.

4. Автоматизировали процесс получения текстов для тестирования локализации. Сами вычитываем русский и английский текст.

5. Регулярно участвуем в приемочном тестировании программы, как и они в нашем. Сейчас активно автоматизируем приёмочные тесты – не делали этого сразу, т.к. было дорого, но сейчас у нас расширилась команда.

6. Есть несколько веб-интерфейсов для управления тестовыми средами, составлено описание по работе с ними. Разграничили с программой зоны ответственности.

7. Участвуем в еженедельных статусных встречах.

8. Оформление багов не вызывает вопросов ни у кого из участников программы, дискутируем по поводу ответственности за сбор логов – это логи продукта, который «крутится» в облаке, генерируя ну очень большой объём при подробном логировании.

Еженочно и по запросу в течение дня запускаются наборы регрессионных тестов для проверки API веб-сервисов, а также WEB-тесты для проверки порталов.

Отдельно выделены наборы тестов на длительные функциональные проверки, вроде backup/restore. Всего сейчас примерно 1500 автотестов с суммарной продолжительностью выполнения – 3 часа. Такая продолжительность обусловлена работой с почтой, а также длительным временем первоначального развёртывания продукта в облаке. В планах, конечно, ускорение прохождения регрессионных тестов.

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

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

Мы участвуем в проектах для B2B, например, Kaspersky Endpoint Security Cloud, Kaspersky Security Center Hosted, а также в программе SaaS внутри компании, помогаем с инфраструктурой для портала My Kaspersky. Важно понимать, что наше подразделение работает не только на внешнюю аудиторию, но и на внутреннюю. В нашей зоне ответственности – бэкофисные системы, ими пользуются только сотрудники компании. Например, единый каталог для всех e-comm-провайдеров, который заполняют наши коллеги из других подразделений.

Ты упомянул, что большинство в твоей команде — автотестеры. Как это помогает вам в работе?

Автотестирование помогает экономить время и даёт возможность перенаправить ресурсы на более важные задачи. Исторически в подразделении были только инфраструктуры. API очень хорошо покрывается тестами, это достаточно дёшево и результат можно получить довольно быстро. Поэтому это подразделение и собирает автоматизаторов. Теперь же появились новые проекты, где появились GUI, web-части, но их тоже можно тестировать автоматизированно. Но тут главное оценить, не будет ли это слишком дорого, потому что автоматизировать всё дорого, да и честно говоря не нужно. Разработчик может запустить автотест, и сразу увидеть, как его коммит повлиял на качество продукта.

Какие интересные задачи приходится решать, когда высвобождается время?

У каждого из нас есть цель: выполнять не только свою обычную работу, но и сделать что-то ещё интересное, на стыке. Например, мы помогали разрабатывать различные системы мониторинга для наших коллег, писали бизнес-чеки – это утилита, которая запускается на продакшене и пытается симулировать действие пользователя, и выдает вердикт – все хорошо или нет, показывая, как наша инфраструктура или продукт работает. Как-то я написал утилиту для помощи коллегам из подразделения Digital Online Sales, которая помогает им автоматизировать рабочие процессы.

Есть ли в команде сертифицированные сотрудники? Нужно ли это?

Да, среди наших коллег есть сертифицированные сотрудники. У одного тестера сертификатов даже больше, чем у некоторых разработчиков. Он уже не просто эксперт по тестированию, а software-эксперт. Лично я считаю, что это хорошая тенденция. Хотя, сама сертификация, конечно, нужна больше человеку. В этом году хотим всем подразделением пройти сертификацию ISTQB. Она позволит нашим коллегам говорить на одном языке. Да, мы все тестировщики, но тем не менее есть нюансы, когда два человека могут не понять друг друга, хотя говорят примерно об одном и том же. Существует некий глоссарий и стандарты, которые надо использовать.

Есть ли противостояние или недопонимание с разработчиками?

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

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

Участвуют ли твои сотрудники в чём-то кроме тестирования? Какие у вас ещё зоны ответственности?

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

Очень много времени занимает разбор потока входящих внешних багов и проблем. Например, от технической поддержки приходит что-то, мы разбираемся и стараемся помочь. Также приходят запросы от любых команд, с которыми мы взаимодействуем. Например, мы инфраструктура для портала My Kaspersky. Нас вызывают, когда у них какой-то вопрос. Также с нами взаимодействует продуктовый отдел, это практически все продукты «Лаборатории Касперского» сегмента B2C. Из B2B самое большое – это, конечно, Kaspersky Endpoint Security Cloud. Мы деплоим, пишем деплои, у нас есть и отдельные DevOps’ы. Правда их не так много.

Вы работаете со всей линейкой B2C, включая продукты для мобильных пользователей?

Все эти продукты взаимодействуют с инфраструктурой, чтобы можно было купить, например, в Google Play или AppStore наш продукт, лицензию нашего продукта. Мобильный пользователь взаимодействует с этим магазином, Потом продукт с чеком от AppStore идёт в инфраструктуру и регистрирует там покупку. Мы идем в Kaspersky Order Management и выписываем там лицензию, отдаем её продукту и он ей пользуется. Таким образом мы взаимодействуем с продуктами. Но это не только покупки, ещё есть SaaS, Kaspersky Password Manager, Kaspersky Internet Security для Android, Kaspersky Safe Kids, Kaspersky Secure Connection и многие другие — для таких приложений есть даже отдельные инфраструктуры.

Есть ли любимый продукт?

Сам я с удовольствием пользуюсь Kaspersky Password Manager — один из любимейших, сейчас ещё и Kaspersky Who Calls. Ещё, конечно, Kaspersky Internet Security.

Какие используются стек-технологии в тестировании?

Исторически так сложилось, что наше подразделение состоит из двух больших под-подразделений. В одном из них стек технологий – Windows, .NET, C#, Microsoft Visual Studio, облачные платформы Azure и Amazon Web Services. Второе подразделение занималось только C, C++ и Python-разработкой и тестированием, так и продолжает. Это такие проекты, как Kaspersky Security Network, Kaspersky Private Security Network.

Кто отвечает у вас за качество продукта, сервиса, как это организовано?

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

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

Как развивается карьера у тестировщика?

У нас есть вертикальные и горизонтальные пути развития карьеры. Можно пойти по экспертной лестнице и стать тестировщиком-экспертом. А можно двигаться по менеджерской и стать тимлидом, менеджером и так далее. Или вообще можно перейти в другое подразделение, если есть желание и возможность. У нас не запрещено менять сферы, например, из тестировщика становиться разработчиком и наоборот. В моем подразделении были такие случаи, правда за всё время работы разработчиками стали всего три человека.

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

У нас в «Лаборатории Касперского» постоянно появляются новые проекты и направления, некоторые из них огромны, поэтому компания находится в состоянии непрерывного поиска новых сотрудников. Конкретно в моём подразделении наблюдается нехватка «рук» из-за роста существующих проектов (те же Kaspersky Endpoint Security Cloud и Kaspersky Security Center Hosted) и близкого появления новых. Мы, конечно, пытаемся оптимизировать процессы и улучшать методику, но новые коллеги нам нужны, сейчас есть несколько открытых вакансий.

Как тестировщику развиваться?

Мы с удовольствием пользуемся всеми видами обучения, которые доступны внутри компании. У нас есть тренинги как для развития софт-скиллов, для хард-скиллов. Но, пожалуй, самое крутое обучение у нас было семь лет назад, тогда приезжал гуру тестирования Майкл Болтон. Он читал свой курс Rapid Software Testing. Собирали всех тестировщиков компании и в течение двух дней нам проводили тренинг! Самое главное, что я оттуда почерпнул, —  это то, что, как ни странно, вначале нужно точно уточнить у заказчика, что он именно хочет от нас.

К тому же для самостоятельного развития есть куча ресурсов. Самые доступные — это книги и статьи. Например, блог developsense.com, подкаст для тестировщиков, а также хабы на Habr, в частности Тестирование IT-систем, Тестирование веб-сервисов.

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

А есть, на твой взгляд, у тестировщиков свои «звезды», за которыми надо следить?

Да, конечно, но в основном, это зарубежные специалисты. Помимо Болтона есть ещё Джеймс Бах, его книги тоже советую посмотреть.

Как оценивается качество работы в вашем подразделении? На что ты обращаешь внимание в первую очередь?

Одним из важнейших критериев качества работы конкретного сотрудника является то, что в целом весь проект, над которым он работает, успешен. Да, это метрика может быть весьма относительной, ведь проект может быть успешным даже в том случае, если кто-то из команды косячит. Я смотрю на ревью своих подчинённых, провожу с ними встречи, сам хожу на все ежедневные митинги, собираю фидбек от разработчиков и проектных менеджеров. Поэтому я всегда в курсе, кто и как делает свою работу. Опять же годовая оценка сотрудников, это довольно субъективное мероприятие. Например, один сотрудник может работать 24/7, но у него может оказаться низкий визибилити (т.е. как он презентует свои достижения). Потому важно показывать свою историю успеха и визибилити.

Смотрите ли вы на человеческие качества кандидатов? Насколько важно быть «командным игроком»?

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

У вас жёсткий график работы? Как обстоит дело с работой в праздники и в выходные?

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

Расскажи о себе. Чем ты занимался до того, как попасть в «Лабораторию Касперского»?

Свой путь в ИТ я начал в техподдержке одной компании, которая занималась биометрическими технологиями, железками и софтом. Я реагировал на обращения пользователей, сам разбирался в проблеме и находил ошибки. Там же мне удалось перейти в тестирование: была вакансия и меня взяли на свободное место. Потом перешёл в другую компанию, это был издательский дом, я работал в отделе, в котором делали web-версии досок объявлений по разным темам: авто, недвижимость и так далее. После этого перешёл в частную компанию, которая работала на несколько московских департаментов. Для них мы пилили информационные системы. С этой работой связан один случай: однажды наш офис сгорел, а мы за небольшую премию помогали переносить всю мебель в другие помещения. Долгое время ощущался стойкий запах костра. И такое бывает!

Потом я попал в «Лабораторию Касперского», но не с первого раза. Сначала я откликнулся на вакансию в ИТ-департаменте (группа тестирования и разработки). Меня туда не взяли. Я, конечно, расстроился. Но захотел попытаться ещё, поэтому решил приложить больше усилий, подготовиться получше и попробовать через некоторое время ещё раз. Пошёл в R&D, успешно прошёл собеседование и попал в небольшое подразделение. Раньше у нас был отдельный департамент контроля качества, все тестировщики были там. Я попал в небольшое подразделение, которое занималось тестированием для заказчиков вроде группы выпуска обновлений и некоторых других. В этом году будет уже 10 лет, как я работаю в «Лабораторию Касперского».

А какие вопросы задавали на собеседовании?

Раньше собеседования проводили ресурсные руководители больших департаментов. У одного из них был стандартный круг тем для вопросов. Я про него узнал. Поспрашивал к тому времени знакомых, кто тут уже работал, какие вопросы могут задавать на собеседовании в «Лабораторию Касперского». Начал целенаправленно готовиться к этим вопросам, прямо как к экзамену. Кроме базовых вещей вроде стека протоколов TCP/IP спрашивали про внутреннее устройство Windows. Были и ситуационные вопросы-задачи. Я на всё ответил, так и начался мой путь в компании.

Что-то изменилось с тех пор? Как теперь проходит процесс собеседования?

За 10 лет много что изменилось. Когда у нас появляется вакансия, мы даем нашим рекрутерам список вопросов, чтобы они провели телефонный скрининг, выбрали нужных кандидатов и отсеяли тех, кто нам уж совсем не подходит. Вопросы, на самом деле, несложные. Такой подход прилично экономит время. Но есть и особенность в этом процессе – перед рекрутером стоит задача понять, правильный ли ответ на вопрос дал кандидат. Поэтому, конечно, рекрутер тоже должен на определенном уровне разбираться в тестировании и разработке.

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

А даёте ли вы какие-то особенно сложные задания?

Если мы сомневаемся, например, когда берем senior-сотрудника, то есть платформа codility, наш HR на неё подписан. Это внешняя платформа, которая позволяет написать код на сайт, запустить его и выполнить задание. Там есть счётчик времени и записываются все действия человека. Мы можем видеть весь алгоритм действий кандидата, чтобы понимать, что он не скопировал откуда-то и не вставил код, а сам его написал.

А ты смотришь на предыдущий опыт работы кандидата? Или значение имеет только навыки человека?

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

А если человек пробовал себя в разных направлениях и надолго не задерживался на одном месте работы?

Меня это скорее насторожит. Логично предположить, что и с нами он может так поступить. Поэтому такие «скачки» вызывают вопросы. Хотя мой самый первый руководитель рассказывал, что это поведение может быть обусловлено некой стратегией получения высокой зарплаты. Ты «прыгаешь» между компаниями до своего потолка, пока не сможешь получать больше. Потом нарастишь экспертизу, прокачаешься и сможешь менять компании дальше, увеличивая зарплату.

Какие этапы ты прошел в компании?

Изначально это было ручное тестирование с элементами запуска определенных утилит. Через год мы уже сами начали писать утилиты, которые помогали нам тестировать. Но это всё равно оставалось ручное тестирование. А потом была реорганизация, когда разные департаменты поделили по-новому, матрицу убрали и был образован штаб WhiteListing and Cloud Research. Там мы начали заниматься инфраструктурой портала My Kaspersky. Тогда он ещё назывался UCP (User Centric Platform).

Что входит в твои обязанности руководителя?

У меня в подчинении 18 человек и ещё открыто две вакансии. Как руководитель я чаще ставлю стратегические, а не тактические задачи. Например, занимаюсь постановкой целей всей нашей группы на год, транслирую эти цели на конкретных исполнителей, а потом контролирую работу над проектами. Естественно, это ресурсная часть, то есть общение с людьми: я провожу с ними встречи, согласую обучение, помогаю советами. Но я всё равно остаюсь «играющим тренером» из-за большой накопленной экспертизы в ряде проектов, её я использую, чтобы разбирать поток входящих багов и обращений – могу сразу понять, к какому проекту это может относиться, а что-то могу и сам решить.

То есть ты считаешь, что руководитель должен «работать в поле»?

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

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

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

Что тебе больше всего нравится в «Лаборатории Касперского»? Назови две-три вещи.

• Больше всего нравятся люди – отличные коллеги и хорошие друзья!
• Возможности, которое дает подразделение облачной инфраструктуры, то есть мы занимаемся передовыми технологиями и используем все новое в облаках, от самых топовых производителей – Azure и Amazon Web Services.
• Культура компании: взаимовыручка, помощь, у людей, что называется «глаза горят». Они настолько ответственно подходят к своей работе, что порой перерабатывают. Хотя их об этом не просят. Возможно, это и плохо, но если нравится, то почему бы и нет.

Какие есть плюшки в компании в плане обучения? Чем ты пользуешься?

В прошлом году отправил коллегу на конференцию Software Quality Assurance Days в Польшу. После конференции он смог погулять по Варшаве, ему понравилось.

Есть бонусы в виде обучения иностранным языкам. Компания не только дает возможность изучать самые разные языки, но и компенсирует значительный процент стоимости занятий. Можно ходить на встречи разговорных клубов, и вместе с коллегами общаться с преподавателями-иностранцами из Великобритании или США.

А ещё можно бесплатно заниматься в спортзале прямо в бизнес-центре. Сам я не хожу, к сожалению, не успеваю. Но с удовольствием пользуюсь тем, что компания снимает нам футбольное поле, где мы играем с коллегами – участвуем в чемпионатах и корпоративных лигах.

В компании отличный соцпакет, редко слышу жалобы на ДМС или другие льготы. Кстати, пользуясь случаем, хочу сказать спасибо компании и коллегам за классные подарки на 23 февраля, 8 марта и новый год, а также за суперские детские дни и бомбические корпоративы!

Чувствуешь ли ты, что работаешь в международной компании?

Наверное, ярче всего это ощущается в языке. Наши основные заказчики русскоязычные, поэтому в плане иностранного языка особо не прокачаешься. Но у нас есть иностранные контрагенты, например ecommerce-провайдеры вроде DigitalRiver, с ними у нас еженедельный созвон на английском. С контрагентами из Франции тоже общаемся на английском. Периодически нам нужно заводить тикеты Microsoft по поводу их облаков. Мы используем самые свежие их решения, некоторые из них находятся ещё на стадии бета-тестирования, а мы сообщаем о найденных проблемах или предлагаем что-то улучшить. По этому поводу тоже часто бывают созвоны, и тут с Microsoft тоже общаемся уже на английском.

От чего страдают тестировщики? Что можно считать основной болью? И как вы с этим справляетесь?

Главная болевая точка — это дедлайны. Так получается, что самая активная часть тестирования (финальная) – в конце, прямо перед запуском. И если что-то идёт не так, то нужно сделать всё возможное, чтобы исправить. Ведь не всегда можно подвинуть дедлайн. Как мы с этим боремся? Мы пытаемся входить со своими тестами как можно раньше. В идеале, в самом начале, когда идет только архитектурная и аналитическая проработка решения. Мы договорились с коллегами-разработчиками, что они публикуют специально для нас некий контракт, то есть описание того, как будут работать инфраструктурные методы. На основе этого описания можно писать тесты. Они, конечно, будут падать, потому что это только оболочка, внутри ничего не реализовано. Но это позволяет нам раньше начинать тестирование. Из-за сроков иногда приходится выходить в нерабочее время. Бывают, конечно, проблемы во взаимодействии с контрагентами, но это редкость. Чаще всего такое случается с кем-то новым, тогда помогает личная встреча.

Что нужно знать тестировщику, чтобы добиться успеха?

Самое главное – умение учиться: быстро впитывать информацию и структурировать её. Это помогает в освоении новых технологий и подходов к процессам, а также в плане оперативного вхождения в проектную деятельность. Нужно обладать высоким уровнем внутренней ответственности, самоорганизации, так как именно нас считают ответственными за качество. Необходимо прокачивать soft skills, крупные современные решения не создаются одним человеком. Это результат работы команды из десятков или даже сотен людей.

А вот и обещанный бонус. Попробуйте свои силы (тем более что это не займет больше 5 минут) и у вас появится шанс присоединиться к команде «Лаборатории Касперского» и выиграть ценный приз!

Участие в конкурсе завершено.

Решить задачу

Правила участия в конкурсе