Текст книги "Как тестируют в Google"

Автор книги: Джеймс Уиттакер

Соавторы: Джефф Каролло,Джейсон Арбон
сообщить о нарушении

Текущая страница: 19 (всего у книги 26 страниц)

Жонглирование людьми и дирижирование проектами

Фирменная особенность инженерной работы в Google – возможность поменять проект. Как правило, у сотрудника появляется такая возможность примерно раз в 18 месяцев. Конечно, мы не заставляем людей это делать. Если инженеру нравятся мобильные операционные системы, никто не будет кидать его бороздить просторы YouTube. Такая мобильность позволяет попробовать разные проекты. Многие хотят оставаться на одном проекте годами или в течение всей своей карьеры, другие предпочитают узнать обо всем, что делает Google. Мы просто хотим, чтобы у сотрудников был выбор.

Такая особенность работы на руку тест-менеджеру. Фактически получается, что можно в любое время нанять к себе сотрудника с опытом в разных областях. Представьте, что ваш проект – Google Maps, и вы привлекаете к работе ребят, которые работали с Chrome и Google Docs! То есть вы всегда можете пополнить свою команду инженерами с необходимым опытом и свежим взглядом на ситуацию.

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

Тест-менеджер управляет процессом распределения. Он может размещать вакансии в специальном веб-приложении, которое просматривают инженеры. Переход не требует формального разрешения от текущего или будущего менеджера, и любой инженер после полутора лет работы в Google может свободно сменить проект. Конечно, скорость такого перехода согласовывается, так как она не должна создавать помех дате выпуска или ключевым точкам плана проекта, но с разногласиями по поводу подобных переходов мы еще не сталкивались. [66]66
  В этом может помочь концепция «20%», о которой мы говорили ранее. Переходя из проекта A в проект Б, инженер занимается проектом Б в свое «двадцатипроцентное» время около квартала, а в следующем квартале меняет пропорции: 80% времени отводится проекту B, а 20% – проекту A.


[Закрыть]

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

Основные приоритеты распределения:

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

– Пожелания нового сотрудника. Обретение работы мечты может сделать его счастливым, а значит, и производительным инженером.

– Потребности проекта. Стратегически или экономически важные проекты иногда получают более высокий приоритет.

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

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

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

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

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

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

Влияние

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

Целью любого отдельного инженера и всей команды должно быть реальное влияние. Именно тест-менеджер отвечает за то, чтобы команда тестирования оказывала реальное влияниев компании.

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

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

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

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

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

Давайте помечтаем о команде тестирования, в которой каждый инженер способен выполнять работу, приносящую ценность, и работает с максимальной пользой. О тщательно оптимизированном процессе тестирования, в котором каждая выполняемая единица работы направлена на достижение цели. О команде разработки, которая осознает объем работы по тестированию и участвует в ней. Задача тест-менеджера превратить все эти мечты в реальность.

Наконец, у тест-менеджера есть еще одна обязанность, связанная с взаимодействием между командами. Тест-менеджер, особенно опытный, не должен быть зашорен настолько, чтобы не видеть, что творится за пределами его проекта. Google – компания, в которой десятки продуктов разрабатываются и тестируются одновременно. У каждого из таких продуктов есть один или несколько тест-менеджеров, в зависимости от размера и сложности, и каждый из них придумывает свои способы, как увеличить влияниекоманды. Хороший менеджер отслеживает все передовые методы работы, распространяет информацию о них и применяет сам. Ведь проще всего доказать результативность инструмента, если эффективно использовать его в нескольких продуктах.

Наши команды тестирования подтверждают репутацию Google как инновационной компании. Множество тестовых приемов и инструментов, которые мы создали и которые используются за пределами Google, тому доказательство. Это стало возможным, потому что наши тестовые команды связаны общим духом инноваций. Тест-менеджеры обмениваются опытом не потому, что им так приказано свыше, и не потому, что ежемесячная встреча добавлена в календарь. Они собираются и общаются потому, что не хотят упустить свой шанс попробовать новые полезные изобретения другой команды. Кто-то хочет остаться последним тестировщиком, не пользующимся новейшим инструментом? Кто-то не хочет работать быстрее? У нас таких нет!

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

Интервью с Анкитом Мехтой, тест-менеджером Gmail

Анкит Мехта вырос в менеджера из инженера по тестированию, который в основном выполнял работу разработчика в тестировании. Начало своей карьеры в Google он провел, закопавшись в коде и автоматизации. Свое первое серьезное повышение до менеджера он получил в проекте Gmail.

Gmail не для слабаков: в этом продукте очень много динамических частей, за которыми нужно следить. С одной стороны, Gmail интегрируется с другими технологиями Google, включая Docs, Calendar и т.д., с другой – Gmail должен взаимодействовать с форматами других почтовых сервисов. Здесь требуется огромная работа с базами данных, так как Gmail работает в облаке, а его пользовательский интерфейс доступен через любой браузер. Не верите, что это сложно? Тогда вспомните, что Gmail имеет сотни миллионов пользователей, которые ожидают, что почта будет работать быстро, надежно, безопасно, а заодно справится с потоком спама. Добавляя новые фичи, надо сохранять рабочее состояние старых, что здорово затрудняет тестирование. Если в Gmail появляется баг, то весь мир узнает об этом мгновенно. Помидоры летят во многих в Google, но в первую очередь в находящегося на передовой менеджера.

Мы встретились с Анкитом, чтобы узнать, как было организовано тестирование Gmail.

– Расскажи, как ты подходишь к новому проекту по тестированию. Что ты делаешь в первую очередь, какие вопросы задаешь?

Анкит:Первые несколько недель в проекте я только слушаю. Очень важно сориентироваться, узнать архитектуру продукта и динамику команды. Я бы не стал слушать врача, который в первые пять минут моего визита выписывает мне антибиотики. Так же и команда не станет работать со мной, если я с ходу начну «ставить диагноз». Чтобы получить право выписывать лекарства, нужно многому научиться.

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

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

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

– Какие же ответы на вопрос «почему» для тебя приемлемы?

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

– Команда Gmail известна своей целенаправленностью и производительностью. Теперь понятно, откуда берутся эти качества. Какие советы ты дашь менеджерам по тестированию для формирования здоровой рабочей среды?

Анкит:Очень важна динамика команды. Я считаю, что качество продукта связано с качеством команды тестирования. Сначала подберите нужных людей, с правильными навыками и настроем, а потом направьте их делать правильные вещи. Вы – руководитель команды, и именно ваше влияние создает здоровую рабочую культуру. Работая с Gmail, я формировал команду шесть месяцев, потому что мне хотелось создать сплоченную группу людей, где все понимают и уважают роли друг друга. Если вам удалось создать крепкую команду, она выдержит даже присутствие пары специалистов, которые не очень в нее вписываются.

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

– Судя по всему, тебе удалось исправить ситуацию, давай поговорим об этом. Расскажи, что ты сделал для того, чтобы рабочая среда стала комфортной?

Анкит:Когда я присоединился к проекту, команда тестирования была сосредоточена на тестах WebDriver, которые выполнялись для каждой сборки. Они проводили тесты, следили, как состояние меняется с зеленого (тесты проходят) на красный (тесты не проходят), и прикладывали титанические усилия к исправлению тестов, чтобы они не показывали ложные срабатывания. Команда разработки не сомневалась в том, что вся работа построена правильно, потому что тесты действительно обнаруживали важные проблемы, а значит, были оправданны. Однако иногда изменения затрагивали большие объемы кода, и оперативно исправить тесты не получалось. Чтобы достичь результатов, приходилось выполнять слишком большую работу. Весь процесс был ненадежным и недостаточно гибким для такого подвижного и сложного сервиса, как Gmail.

Так как я был новичком в проекте, мой взгляд не был замылен. Мне казалось, что самой серьезной проблемой Gmail были задержки. Серьезно, ведь для пользователя главный атрибут Gmail – скорость. Я решил, что если мы справимся с этой проблемой, мы сможем заслужить уважение разработчиков и они будут воспринимать нас как равных.

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

Я вместе с одним разработчиком в тестировании искал способ специально замедлить работу Gmail. Мы хотели лучше контролировать взаимодействие между клиентской частью и дата-центром, чтобы найти регрессии, влияющие на производительность. Собрав несколько старых компьютеров и лишив их всех ускоряющих компонентов, мы получили целую комнату системных блоков с 512 мегабайтами памяти, 40-гигабайтными дисками и медленными процессорами. Работа Gmail стала медленной, и мы смогли отличить сигнал от шума. Мы запустили долгосрочные тесты, которые создавали дополнительную нагрузку системе.

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

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

– Отличный урок: возьмите трудную задачу, решите ее, заслужите уважение. А что ты делал после этого?

Анкит:Трудную задачку можно найти всегда! Хотя общая идея остается в том, чтобы сосредоточиться на самом важном. Мы обозначили самую серьезную проблему Gmail, собрались вместе и решили ее. Затем мы пошли дальше по списку, и все решалось легко, так как у нас была сплоченная команда. Все-таки я больше верю в пользу сфокусированной работы. Когда я вижу, как команда пытается прыгнуть выше своей головы (скажем, работает над пятью задачами одновременно, хотя каждую выполняет только процентов на восемьдесят), я заставляю их сделать шаг назад и расставить приоритеты. Пусть количество задач будет меньше, но зато они будут решены на все сто. Плюс для команды: появляется чувство удовлетворения от выполненной работы, незавершенные задачи перестают нависать у них над головой. Плюсы для меня: качество продукта улучшается и я счастлив.

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

Анкит:Обилие подчиненных и время, которое тратится на координацию работы команд, сильно отвлекает. Чтобы сохранить техническую квалификацию и остаться инженером, я сделал две вещи.

Во-первых, я свел команды разработчиков и разработчиков в тестировании вместе. Работы там достаточно для всех, и я смог стащить кусочек для себя. Я занимался проектом с фазы проектирования и работал в нем достаточно, чтобы самостоятельно писать тесты.

Во-вторых, и это ключевая штука, если вы собираетесь заниматься технической работой, нужно абстрагироваться от всех отвлекающих факторов руководства. Сначала я просто выделял пару дней в неделю для самостоятельной работы. Взглянуть на тестирование глазами разработчика мне помогла работа по интеграции Google Feedback в Gmail. Каждый раз, когда я сталкивался с ненадежным тестом или неудобной частью тестовой инфраструктуры, я понимал, как наша работа выглядит для разработчиков. И все же, находясь в центральном офисе Google, полностью абстрагироваться от управленческой работы я не мог, поэтому я перебрался к команде Gmail в Цюрихе. Находясь в девяти часовых поясах от постоянного места работы, там, где я не являюсь начальником, я сумел влиться в инженерную команду и сделать очень много полезного!

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

Анкит:Главное правило найма – никаких компромиссов. Нанять неподходящего человека всегда хуже, чем подождать идеального кандидата. Нанимайте только лучших, и точка. Google не освещает соотношения инженеров в команде, но скажу, что раньше на нашем проекте тестировщиков было больше нормы. Решив первоочередные проблемы, мы увеличили долю участия разработчиков и вернулись к средним по Google показателям. Для Gmail хорошо сработал следующий вариант: 20% тестировщиков занимались исследовательским тестированием. Любой продукт, в котором взаимодействие с пользователем на первом месте, должен проходить исследовательское тестирование. Еще 30% составляли инженеры по тестированию, которые были сильнее сконцентрированы на продукте, они работали рука об руку с разработчиками в тестировании и обеспечивали максимальный результат их работы. Оставшиеся 50% составляли разработчики в тестировании, работающие над автоматизацией, добавлением инструментов для поддержания кодовой базы в рабочем состоянии и улучшением производительности разработчиков. Не знаю, буду ли применять такую разбивку ролей в следующем проекте Google, но для Gmail она сработала хорошо.

– Мы знаем, что тебе поручено тестирование Google+. Какие ценные уроки тестирования Gmail помогут тебе в работе с новым продуктом?

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

– Пишите тесты на том же языке, на котором написано приложение.

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

– Создавайте инфраструктуру, в которой писать тесты будет легко. Тесты должно быть проще написать, чем пропустить.

– Примерно 20% всех сценариев использования отражают 80% самого использования. Автоматизируйте эти 20% и не беспокойтесь об остальных. Оставьте их для ручного тестирования.

– Мы все-таки в Google, а здесь важна скорость, ее ждут от нас пользователи. Убедитесь, что продукт работает быстро. Выделите это, если вам нужно доказать это остальным.

– Сотрудничество с разработчиками совершенно необходимо. Если его не будет, тестирование станет простым сглаживанием дефектов, а это не самая лучшая работа.

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

– Есть ловушки, в которые попадают инженерные команды?

Анкит:Да. Они думают, будто знают, чего хотят пользователи, и могут серьезно изменять продукт или новые фичи, не проводя экспериментов. Зачем вам хорошая тестовая инфраструктура для фичи, которую выкинут за ненадобностью? Дайте нескольким пользователям новую версию, получите обратную связь, а уж потом вкладывайтесь в грандиозную автоматизацию тестов.

Пока вы будете долго строить идеальное решение, рынок оставит вас позади. Работайте короткими итерациями, двигайтесь небольшими шагами, но двигайтесь!

Наконец, нужно найти идеальный момент для тестирования. Напишете тесты слишком рано – архитектура изменится, и вся работа коту под хвост. Затянете – вам придется переносить выпуск из-за нехватки качественного тестирования. TDD вам в помощь!

– А что же про конкретных людей? Ты заметил какие-нибудь типичные ошибки молодых инженеров по тестированию и разработчиков в тестировании?

Анкит:Ошибка новичков – отчаянно бросаться в работу. Они неистово пишут тесты, не обдумывая их назначение и место в общем процессе тестирования. Они не всегда понимают, что нужно брать ответственность за тесты, которые они приручили. То есть написали. Ошибка разработчиков в тестировании в том, что они пытаются работать за разработчиков.Разработчики в тестировании должны помнить, что тестировать код – задача разработчика, а их задача – ввести тестирование в рабочий процесс разработчика. Мы создаем условия, чтобы разработчик занимался сопровождением не только кода, но и тестов. Пусть разработчик в тестировании сосредоточится на ускорении выполнения тестов и предоставлении качественной диагностической информации.

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

– Какие еще успехи в области тестирования принесли пользу Gmail?

Анкит:Автоматизация JavaScript. Мы встроили сервлет автоматизации прямо в Gmail, и разработчики смогли писать сквозные тесты на том же языке, на котором была написана клиентская часть. Разработчики легко освоились с написанием тестов, потому что в них использовались те же методы и библиотеки – не пришлось тратить время на изучение. Стало просто писать тесты и определять, не нарушает ли новая возможность работу Gmail, и тем самым защищать старые фичи. Каждая функция Gmail теперь выпускается по меньшей мере с одним тестом, написанным с помощью этого сервлета. Кстати, сейчас я использую такую технологию в своей новой работе над Social. У нас уже более 20 тысяч автоматизированных тестов!

Еще одно достижение – нагрузочное тестирование. В Google без него никак, потому что все наши приложения интенсивно используются, а дата-центры сильно загружены. По сути, мы должны смоделировать типичную нагрузку с нашим обычным трафиком. Мы потратили месяцы на анализ реального использования приложений, чтобы построить модель поведения пользователей. Затем мы сделали модель более реальной, проведя тестирование нагрузки на таких же компьютерах, на каких работают дата-центры. Параллельно были запущены две серии тестов: экспериментальная и контрольная. Мы наблюдали за ними, чтобы найти различия. Мы обнаружили много регрессий и передали их в руки разработчиков.

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

– Итак, ты набил руку и теперь переходишь в социальные сервисы. На что ты будешь обращать внимание при найме участников в эту команду тестирования?

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

– Мы подходим к последнему вопросу. Почему ты выбрал тестирование?

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