Как тестируют в Google

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

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

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

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

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

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

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

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

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

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