"Время — деньги. Создание команды разработчиков программного обеспечения" - читать интересную книгу автора (Салливан Эд)

Кто должен тестировать?

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

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

В период стабилизации и интеграции к тестированию приступает вся команда разработчиков — это коллективная работа. Появляется шанс увидеть, где команда находится в данный момент и сколько ещё нужно сделать. Обычно руководитель группы контроля качества выполняет задачу, распределяя ответственность за тестирование между всеми членами команды. Большую часть времени работа проводится в областях, где автоматические тестовые задания справляются плохо. Также сотрудников просят «сыграть роль пользователя» для ключевых частей продукта. Итак, команда, работавшая над продуктом в течение всего цикла разработки, просто незаменима. Это то, что должно стать частью вашей культуры и одним из ваших основных технологических процессов.

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

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

Разработчики влияют на качество продукта больше всего. В конце концов они находятся ближе всего к коду, и риск внесения ошибок исходит прежде всего от них. Чтобы гарантировать отлов «жучков» до того, как команда тестировщиков увидит функциональный блок, они должны его тестировать в процессе написания. Хороший разработчик ускорит работу тестировщиков, предоставляя им надёжные функции. И наоборот, плохой разработчик затормозит работу тестировщиков, выдавая им компоненты с таким количеством ошибок, что о тестировании уже и речи не будет. Для тестировщика нет ничего более неприятного, чем находить массу очевидных проблем, которые разработчик мог найти сам всего за несколько минут работы.