Сегодня поговорим о тестировании у нас в Alente, а конкретно — о том, как трансформировалась роль тестировщика в проектах.
Пару лет назад мы работали как большинство студий: привлекали тестировщика только на этапе тестирования. Но сейчас он принимает деятельное участие в работе уже на этапе сбора требований к сайту. Почему так получилось и как это помогает улучшить продукт? Читайте — и вы всё узнаете.
Как было раньше?
Проекты приходили на тестировку перед запуском. И мы получали набор стандартных проблем данного этапа: непроработанные изначальные требования приводили к переделкам на этапе тестирования. При этом отметим, что непроработанные требования — это не только недостаточное описание работы функций, но и возникающие противоречия в их трактовке. Мы все люди, и бывают ситуации, когда команда разработки, начиная от проект-менеджера и дальше по цепочке верстальщик — программист — тестировщик, трактует требования по-своему. А в итоге получается проект-«франкенштейн».
Причиной чаще всего были ошибки коммуникации, потому что не все требования фиксировались текстом или выражались в виде прототипов и макетов. Что-то оставалось в переписках, в обсуждениях и даже просто в головах, терялось в потоке задач и выпадало из процесса.
Другой проблемой становились изменения требований по ходу разработки. Отсутствие чёткого механизма фиксации изменений приводило к ситуациям, когда что-то делалось по договорённости, а потом не было никакой возможности выяснить, кто, с кем и о чём конкретно договаривался. В случае кадровых ротаций в команде это приводило к очень серьёзным проблемам.