Хто такий тест-менеджер

Книга: Як тестують в Google

Хто такий тест-менеджер

Робота з тестування проектів в Google насправді не виглядає так ідеально, як описана в цій книзі ситуація, де кожен інженер зайнятий тільки своєю справою. На допомогу приходить менеджер, який координує роботу тестувальників і розробників в тестуванні, - тест-менеджер. Трохи про його місце в ієрархії Google: він підпорядковується директору з тестування, у якого може бути кілька таких підлеглих, [65] а Патрік Коупленд керує всіма директорами по тестуванню.

На роль тест-менеджера ми рідко наймаємо людей зовні, частіше намагаємося виростити їх усередині компанії. Співробітники, що прийшли ззовні, зазвичай (але не завжди) стартують з позиції без підлеглих. Навіть Джеймс Уіттакер, який був найнятий на позицію директора, майже три місяці не мав підлеглих.

Велика частина тих, хто зараз керує тестуванням, виросли з тестувальників, і це не дивно, враховуючи, наскільки у них широкий спектр завдань. Інженер з тестування управляє завданнями з тестування, тримаючи в фокусі всю широку картину проекту. Тут рукою подати до управління людьми. Тестувальник розуміє більшу частину функціональності продукту і спілкується з набагато більшою кількістю інженерів, ніж, наприклад, розробник в тестуванні. Однак успішний інженер зовсім не обов'язково стане успішним тест-менеджером. В Google будь-який успіх - справа колективна. Ми всі разом працюємо над тим, щоб вибрати правильних менеджерів і допомогти їм добитися успіху.

Друга порада - знайте ваших людей. Звичайно, тест-менеджер - експерт свого продукту і чудово розуміє роботу, яку потрібно виконувати, але все-таки її безпосередньо виконують інженери з тестування і розробники в тестуванні. Щоб робота виконувалася швидко і ефективно, неймовірно важливо добре знати своїх людей і їх навички.

У нас в Google працюють дуже розумні хлопці, але їх кількість не нескінченно. Кожен тест-менеджер, що приходить ззовні, скаржиться, що в його проекті недостатньо людей. Ми лише дружно посміхаємося у відповідь. Ми знаємо це і не збираємося нічого міняти. Добре знаючи своїх людей і їх навички, керівник може маленької командою домогтися тих же результатів, що і великою кількістю людей. У цьому сила тест-менеджера.

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

У тестуванні програмних продуктів в Google працює така ж схема. Керівник не може просто кинути всіх людей на завдання, тому всі дії оптимізуються. Автоматизація, що не приносить користі, знищується. Тести, які не виявляють регресію, не пишуть. Якщо розробники вимагають від тестувальників певної діяльності, вони повинні самі в ній брати участь. Люди не придумують собі роботу, щоб просто не сидіти склавши руки. Не потрібно робити те, що зараз не принесе цінності.

Завдання керівника - поставити всіх на свої місця. Якщо він добре знає свій продукт, то легко визначить пріоритетний напрямок і ті частини, які повинні отримати потрібне покриття в першу чергу. Якщо менеджер добре знає команду, то він зможе правильно розподілити людей по областям роботи для максимальної ефективності. Звичайно, якісь завдання залишаться невиконаними. Але якщо все зроблено правильно, це будуть фонові завдання або завдання досить прості, щоб їх можна було довірити зовнішньому підряднику, краудсорсерам або внутрішнім користувачам.

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