Lesson 235
Слово Канеру
Набирайте в команду тестирования сотрудников с разным багажом
Не пытайтесь собрать группу, каждый в которой будет иметь степень по компьютерным наукам, опыт от двух лет в тестировании, опыт работы с указанным инструментом автоматизации и так далее. Создайте группу людей, в которой каждый имеет свои сильные качества и отличается от других. Мы нанимали людей, которые никогда не тестировали, и нанимали тех у кого есть опыт. Будет хорошо, если вы соберете все навыки, которые нужны группе.
Мы не говорим вам, что не нужно нанимать программистов. Безусловно, берите и их. Они вам понадобятся для многих задач. Тем не менее, вам придется обучать их некоторым не-программистским областям знаний. Другие ваши сотрудники могут быть не программистами, имеющие массу знаний, которых нет у программистов. Создайте команду, и сильные стороны одних членов которой будут компенсировать слабости других.
Например (эти примеры основаны на нашем успешном опыте) представьте, что вы наняли человека, который может применить опыт своей предыдущей работы в качестве роли, с которой он будет тестировать спецификацию или продукт. Это может быть адвокат, директор по маркетингу, продавец, техник по ремонту аппаратуры, библиотекарь, программист, менеджер не-IT проекта, сотрудник техподдержки вашего продукта, переводчик (особенно полезно, если ваша компания выпускает программное обеспечение на многих языках), секретарь (Подумайте об информации, которую вы собираете, храните и распространяете, а также о организационных вопросах, которые ложится на плечи вам и вашей команде), системный администратор, который знает сети и пользователей ПО, которое вы тестируете. Любой (или многие) из этих людей может оказаться пользователем вашего продукта.
Но есть ограничение для этого совета. Для некоторых продуктов тестировщик должен уметь программировать. Представьте себе тестировщика компилятора. Для создания интересных тестов вы должны быть способны писать код. В некоторых компаниях непрограммирующие тестировщики считаются сотрудниками второго сорта и не имеет значения, насколько они хороши. В таких случаях нанимайте программиста. Вашей задачей будет нанять программистов, имеющих различны бекграунд. По нашему опыту, это сложно, но достижимо, если вы работаете в хорошей компании и не во время очередного бума занятости.
Еще один вопрос достоин упоминания. Иногда публикуются статьи о расизме, сексизме и дискриминации по возрастному признаку в IT индустрии и мы видели подобное. Нанимают, обучают и стимулируют группы, в которых преобладают белые мужчины, хотя они, напротив, скорее всего будут менее эффективны в тестировании. Чем шире спектр опыта и культуры представлен вашими сотрудниками, тем больше способов они найдут для анализа вашего ПО и больше проблем обнаружат. Разнообразие является одним из важнейших аспектов в тестировании и это не то, чего стоит избегать.
Хотя мы и не всегда имеем возможность следовать этим советам, но все же согласны с одним из наших обозревателей Rex Black: «Когда вы тестируете, используя специальные навыки, например автоматизированное тестирование и особенно при тестировании производительности, я считаю разумным иметь в команде как минимум двух человек, обладающих этими навыками».
Набирайте в команду тестирования сотрудников с разным багажом
Не пытайтесь собрать группу, каждый в которой будет иметь степень по компьютерным наукам, опыт от двух лет в тестировании, опыт работы с указанным инструментом автоматизации и так далее. Создайте группу людей, в которой каждый имеет свои сильные качества и отличается от других. Мы нанимали людей, которые никогда не тестировали, и нанимали тех у кого есть опыт. Будет хорошо, если вы соберете все навыки, которые нужны группе.
Мы не говорим вам, что не нужно нанимать программистов. Безусловно, берите и их. Они вам понадобятся для многих задач. Тем не менее, вам придется обучать их некоторым не-программистским областям знаний. Другие ваши сотрудники могут быть не программистами, имеющие массу знаний, которых нет у программистов. Создайте команду, и сильные стороны одних членов которой будут компенсировать слабости других.
Например (эти примеры основаны на нашем успешном опыте) представьте, что вы наняли человека, который может применить опыт своей предыдущей работы в качестве роли, с которой он будет тестировать спецификацию или продукт. Это может быть адвокат, директор по маркетингу, продавец, техник по ремонту аппаратуры, библиотекарь, программист, менеджер не-IT проекта, сотрудник техподдержки вашего продукта, переводчик (особенно полезно, если ваша компания выпускает программное обеспечение на многих языках), секретарь (Подумайте об информации, которую вы собираете, храните и распространяете, а также о организационных вопросах, которые ложится на плечи вам и вашей команде), системный администратор, который знает сети и пользователей ПО, которое вы тестируете. Любой (или многие) из этих людей может оказаться пользователем вашего продукта.
Но есть ограничение для этого совета. Для некоторых продуктов тестировщик должен уметь программировать. Представьте себе тестировщика компилятора. Для создания интересных тестов вы должны быть способны писать код. В некоторых компаниях непрограммирующие тестировщики считаются сотрудниками второго сорта и не имеет значения, насколько они хороши. В таких случаях нанимайте программиста. Вашей задачей будет нанять программистов, имеющих различны бекграунд. По нашему опыту, это сложно, но достижимо, если вы работаете в хорошей компании и не во время очередного бума занятости.
Еще один вопрос достоин упоминания. Иногда публикуются статьи о расизме, сексизме и дискриминации по возрастному признаку в IT индустрии и мы видели подобное. Нанимают, обучают и стимулируют группы, в которых преобладают белые мужчины, хотя они, напротив, скорее всего будут менее эффективны в тестировании. Чем шире спектр опыта и культуры представлен вашими сотрудниками, тем больше способов они найдут для анализа вашего ПО и больше проблем обнаружат. Разнообразие является одним из важнейших аспектов в тестировании и это не то, чего стоит избегать.
Хотя мы и не всегда имеем возможность следовать этим советам, но все же согласны с одним из наших обозревателей Rex Black: «Когда вы тестируете, используя специальные навыки, например автоматизированное тестирование и особенно при тестировании производительности, я считаю разумным иметь в команде как минимум двух человек, обладающих этими навыками».