Организация автоматизированного UI тестирования

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

В основном сейчас работают по Agile и Scrum-у, где все члены проектной команды сидят вместе и творят, чтобы успеть закрыть все запланированное в спринте. Где тестировщики в принципе могут и не знать что делают их коллеги в других командах, т.к. области их ответственности мало или вообще не пересекаются. Все это может быть и не плохо, пока разговор не заходит об организации автоматизированного UI тестирования и всего связанного с ним: планирование, проектирование, разработка фреймворков, имплементация тестов и поддержка.

Основная проблема, на мой взгляд, состоит в том, что не все понимают, что автоматизация UI тестирования – это отдельный проект, который разрабатывается по «определенным» требованиям, для реализации которых, необходимо использовать «определенный» стек технологий и задействовать разработчиков с «определенным» опытом. Под «определенным» я подразумеваю уклон в сторону тестирования:

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

Не для кого не секрет, что не все разработчики любят писать тесты и тестировать. Подобные таски выполняются нехотя и не всегда с должным качеством. Так зачем их грузить еще и автоматизацией через UI?

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

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

Начинаешь интересоваться что да как. Получаешь ответ, что не было времени, из-за того что надо было тестировать то, что разрабатывает команда». А в конце концов, вы идете и общаетесь с Product Owner-ам всех команд, доказываете важность вашей задачи и ищите того кто имеет ресурсы для реализации вашего запроса.

На мой взгляд, наиболее логичным было бы выделение отдельной команды с опытным автоматизатором в качестве Product Owner для работы над автоматизацией UI тестирования. Это многим покажется дорого, но дороже ли чем распределять эту работу между разными командами? Мне кажется, что в итоге выйдет то на то.

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

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

Перевод: Organizing the UI automation testing