Тестирование и контроль качества — ответственность каждого
Мечта любого человека из игровой индустрии — работать в универсальной, многофункциональной команде. Мало кто когда-то встречался с такими, но мы точно знаем, что, как минимум, в теории, они существуют. Универсальная команда. Что же это за зверь? Это коллектив, в котором все участники рабочего процесса независимо от специализации вносят максимальный вклад на всех этапах и во все аспекты разработки продукта. Однако, чтобы достичь такой продуктивности, необходимо выполнить несколько обязательных условий.
Разработчики должны разбираться не только в модульном тестировании (unit testing), а в тестировании как совокупности огромного количества форм деятельности. Обязанности тестировщиков, в свою очередь, не должны ограничиваться исключительно тестированием.
В гибкой методологии разработки (Agile) продукт не считается готовым до тех пор, пока он не закодирован, протестирован, интегрирован и развернут в среде эксплуатации.
Так имеет ли значение, кто выполняет работу? Есть ли смысл в разделении ответственности между четко определенными рабочими ролями?
Существует мнение, что если ты не приносишь вклад в разработку кода готового продукта, ты не приносишь пользы для разработки продукта в целом.
Тестирование воспринимается многими как пассивная активность, которая не имеет коммерческой ценности. Конечно, есть возможность сделать тестирование ощутимым и ценным для компании, но это не распространенная практика. Другими словами, качественное тестирование приносит доход бизнесу, низкопробное — нет.
Что произойдет, если объединить обязанности, опыт и образ мышления разработчика и тестировщика?
Как мы отметили выше, мало кто сталкивался с такой практикой в жизни, поэтому рассмотрим ситуацию в теории. Скорее всего, на этапе разработки будет предотвращаться больше проблем. Тестирование с большей вероятностью будет включено в прогнозируемые оценки. Найдутся новые, более эффективные способы тестирования. А самое главное, тестирование будет непосредственно приниматься во внимание во время реализации продукта и станет одним целым с процессом разработки, что отлично от существующей модели, где тестировщики являются некой “потусторонней силой” в глазах разработчиков.
Имеет ли тестирование ценность для цикла поставки? Несомненно. Оно является своеобразной подстраховкой для разработчика и позволяет ему добавлять или изменять функции продукта, а также подтверждает, что продукт работает.
Полезен ли тестировщик для цикла поставки? Это зависит от двух вещей: от разработчиков, принимающих участие в процессе, и от тестировщиков, работающих над тем же продуктом.
Если разработчики понимают что-то в тестировании и умеют это делать, пользы от тестировщика нет никакой, если только он не владеет языком программирования. В то же время, далеко не всем разработчикам можно доверить тестирование, так как большинство их них работает исключительно с модульным тестированием и знает, что в команде есть достаточно тестировщиков, которые смогут выполнить работу за них.
Получается, чтобы объединить две эти роли в одну, разработчикам нужно понять, чем занимаются тестировщики в их команде, какие задачи выполняют, и как эти задачи отличаются от задач разработки. Скорее всего, «фишка» тестировщиков заключается в точной, зависящей от контекста постановке аналитических вопросов, касаемых требований. Они редко принимают все написанное в описании продукта за действительное. Тестирование приложений не воспринимается как развлечение, уделяется гораздо больше внимания требованиям, поставленным заказчиком. Чтобы объединить разработку и тестирование, разработчикам необходимо начать думать, как тестировщик.
Тестировщикам в этом случае остается только расширять свои знания вне области тестирования, чтобы обеспечить свое существование в индустрии в долгоиграющей перспективе.
Качество разрабатываемого продукта — ответственность каждого сотрудника компании. И это большой вопрос, как долго мы сможем поддерживать качество ПО на должном уровне, если продолжим использовать систему разделения обязанностей между специалистами разных областей.
В теории, если разработчики освоят образ мышления тестировщиков, и этот образ мышления превратится в некую «мышечную память», компания сможет прийти к большему успеху и эффективности.
