Home

Оригинальная публикация: http://bytextest.ru/2017/07/20/testing-and-quality-everyone-responsibility/

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

Разработчики должны разбираться не только в модульном тестировании (unit testing), а в тестировании как совокупности огромного количества форм деятельности. Обязанности тестировщиков, в свою очередь, не должны ограничиваться исключительно тестированием.

В гибкой методологии разработки (Agile) продукт не считается готовым до тех пор, пока он не закодирован, протестирован, интегрирован и развернут в среде эксплуатации.

Так имеет ли значение, кто выполняет работу? Есть ли смысл в разделении ответственности между четко определенными рабочими ролями?

Существует мнение, что если ты не приносишь вклад в разработку кода готового продукта, ты не приносишь пользы для разработки продукта в целом.

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

Что произойдет, если объединить обязанности, опыт и образ мышления разработчика и тестировщика?

Как мы отметили выше, мало кто сталкивался с такой практикой в жизни, поэтому рассмотрим ситуацию в теории. Скорее всего, на этапе разработки будет предотвращаться больше проблем. Тестирование с большей вероятностью будет включено в прогнозируемые оценки. Найдутся новые, более эффективные способы тестирования. А самое главное, тестирование будет непосредственно приниматься во внимание во время реализации продукта и станет одним целым с процессом разработки, что отлично от существующей модели, где тестировщики являются некой “потусторонней силой” в глазах разработчиков.

Имеет ли тестирование ценность для цикла поставки? Несомненно. Оно является своеобразной подстраховкой для разработчика и позволяет ему добавлять или изменять функции продукта, а также подтверждает, что продукт работает.

Полезен ли тестировщик для цикла поставки? Это зависит от двух вещей: от разработчиков, принимающих участие в процессе, и от тестировщиков, работающих над тем же продуктом.

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

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

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

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

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

По материалам Testing Excellence

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