Home

Автор: Джастин Рорман (Justin Rohrman)

Оригинал статьи: http://blog.smartbear.com/automated-testing/software-testing-skills/

Перевод: Ольга Алифанова

Типичная команда тестирования – это набор таких разных людей, как бизнес-эксперт, системный программист, пара-тройка технарей-тестировщиков и (иногда) менеджер.

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

Что делать разумному менеджеру в таких случаях? Об этом мы и поговорим.

1. Определите типажи своих тестировщиков.

Мы любили говорить о составе команды как о соотношении количества программистов и количества тестировщиков.

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

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

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

Вот одна из тактик для такого случая: концентрируйтесь на сильных сторонах.

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

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

Как вариант - мы оба можем сосредоточиться на своих слабых сторонах и развивать их.

2. Учитесь вместе.

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

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

Работа в паре - почти всегда хорошее подспорье. Сотрудничая с фронтэнд-разработчиками, мы идем через Javascript-код и беседуем о том, как очищаются данные перед тем, как попасть в базу данных. К примеру, удаляются ли ведущие и конечные пробелы? Покопаться в Javascript какое-то время - хороший способ быть в курсе новых библиотек, которые, по-моему, выходят не переставая. Такая работа также научила меня описывать баги так, чтобы разработчику было легче найти ошибку в коде.

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

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

3. Внедряйте обучение

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

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

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

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

4. Как быть с плохо подходящими команде людьми

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

• Перетасовать команды. Если тестировщик не подходит одной команде, возможно, у него будут шансы в другой. Скажем, вашей команде нужен кто-то технически подкованный, который может помочь с налаживанием разработки через тестирование (TDD) или писать тесты на сервисном уровне. Через пару недель становится ясно, что новенький не справляется. Возможно, ему больше подойдет другая команда, не так сфокусированная на автоматизации. Человек без технических знаний может принести там много пользы, даже не наращивая эти знания. Над ними он сможет поработать в свободное время.
• Тестировать всей командой. Старая поговорка "тестировать может кто угодно" в целом верна, но убедитесь, что вы набрали подходящих для этого людей. Организация процесса очень важна, даже при отсутствии команды тестирования. Продакт-менеджеры - обычно знатоки продукта, они хорошо знают заказчика и отрасль, и быстро найдут баги бизнес-логики. Продажники здорово ищут проблемы в основных частях продукта, которые они регулярно демонстрируют покупателям. Продажники - это вообще ходячие смоук-тестировщики.
• Повысить тестируемость. Она определяет, насколько легко тестировать ваш продукт. Можно ли его тестировать без пользовательского интерфейса? Легко ли разобраться, как использовать ваше ПО? Чем легче найти информацию о вашем продукте, тем проще тестировщикам.

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

Обсудить в форуме