Home

Автор: Майкл Болтон (Michael Bolton)

Оригинал статьи

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

На днях меня вновь спросили "Когда заказчик спрашивает, сколько времени займет тестирование нашего проекта, что мне ему отвечать?"

Простейший ответ, который я могу предложить, таков: если тестирование – часть процесса разработки, то оно займет ровно столько же времени, сколько разработка. Это связано с тем, что эффективное и продуктивное тестирование не разделено с разработкой – оно встроено в разработку.

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

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

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

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

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

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

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

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

Тут важно помнить, однако, что определение уровня удовлетворенности – это то, о чем можно догадываться, но нельзя высчитать. Удовлетворенность – это чувство, а не финишная черта.

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