testomat.io управление авто тестами
Часть 1, Часть 2, Часть 3, Часть 4
Как тестировщики сотрудничают с разработчиками автоматизированных тестов
Работа разработчиков автоматизированных тестов должна быть «на виду». Каждый тестировщик в команде, даже если лично сам не сотрудничает с разработчиками тестов, должен видеть их взаимодействие с другими участниками команды.
Тестировщики являются заказчиками для разработчиков автоматизированных тестов. Ни одна задача, не утвержденная тестировщиками, не должна реализовываться вообще.
Тестировщик может в любой момент обратиться за помощью к тим-лидеру команды разработчиков автоматизированных тестов. На практике, тим-лидер команды разработчиков автоматизированных тестов должен регулярно общаться с тестировщиками и проверять, что разработчики тестов могут делать для тестировщиков. Альтернативный вариант – менеджер по тестированию может назначать определенных тестировщиков для сотрудничества с командой разработки автоматизированных тестов для решения некоторых задач.
Запросы могут быть, например, такими:
- Как я могу протестировать этот новый функционал?
- Как я могу отследить, что произошло внутри продукта?
- Как я могу знать, успешно ли прошел тест или потерпел неудачу?
- Есть ли способ автоматизировать эту операцию?
- Есть ли способ воспроизвести данную ошибку проще?
- Помогите мне исследовать данную ошибку.
- Это тест, который я хочу провести. Можете ли вы помочь сделать 1000 его вариаций?
- Насколько хорошо я покрыл тестами продукт?
- Мне надо провести стрессовое тестирование продукта. Есть ли у вас подходящие инструменты для этого?
После оформления запроса, тестировщик будет вскоре ожидать реакции от команды по автоматизации. От тестировщика ожидается распределение работы с разработчиками тестов. Они должны решать проблемы совместно.
Как программисты работают с разработчиками автоматизированных тестов
Программисты также являются заказчиками команды автоматизации тестирования. Когда программист создает определенный инструмент для своих собственных целей, и он также может быть полезным для тестировщиков, в его же интересах передать данный инструмент команде автоматизации тестирования, чтобы они его внедрили для тестов. Разработчик тестов становится ответственным за техническую поддержку этого инструмента.
Программисты могут получать больше информации от разработчиков тестов, чем от других тестировщиков. Разработчики автоматизированных тестов имеют техническую возможность изучить работу разрабатываемого продукта изнутри, а также обсудить функционал для тестирования с точки зрения его разработки. Они могут более эффективно и согласованно обрабатывать запросы, чем если бы напрямую общались с тестировщиками, или если бы каждый тестировщик напрямую рассказывал свое видение функционала каждому программисту.
Разработчики автоматизированных тестов находятся в преимущественном положении для начала проектирования и последующего использования функционала для тестирования приложения. Это очень важно, так как на практике при организации тестирования зачастую обременительно думать о функционале для тестирования и он может упускаться.
Как менеджмент работает с разработчиками автоматизированных тестов
Менеджмент всегда заинтересован в получении быстрых путей отличиться (выслужиться). Работа по автоматизации тестирования на один шаг отдалена от тестирования, которое уже само по себе отдалено на шаг или два от денежных потоков, поэтому автоматизация тестирования должна сама себя определять в терминах «как она улучшает тестирование», или другими словами, полезна бизнесу, оправдана ли ее стоимость.
Менеджмент сотрудничает с разработчиками автоматизированных тестов, в основном, запрашивая и получая регулярные отчеты о выполнении работ, которые должны содержать ответы на стандартные вопросы, к примеру:
- Что мы получаем от автоматизации тестирования?
- Сколько она нам стоит?
- Учитывая стоимость, достаточно ли мы выигрываем от автоматизации тестирования?
- Что плохого может произойти, если будет приостановлено финансирование автоматизации?
Список задач, упомянутый ранее, составляется таким образом, чтобы обеспечить базовые ответы на эти вопросы. Еще одна способность тестирования – предоставление сбалансированного списка метрик, которые кратко отображают достоверное впечатление о продуктивности тестирования.
Вот некоторые потенциальные метрики и другие специфичные наблюдения, которые могут помочь пролить свет на продуктивность тестирования, и, следовательно, оценить вклад автоматизации:
- Коэффициент найденных ошибок, подлежащих исправлению (за исключением тех, которые невозможно воспроизвести, ошибки тестировщиков, не баги, и другие категории, создающие «шум»). На это число влияет множество факторов. Чрезвычайно опасно использовать только эту метрику. Но как бы то ни было, многие значительные улучшения могут быть привнесены в тестирование исходя из результатов этой метрики.
- Коэффициент найденных скачков. Это краткосрочный скачок в количестве найденных багов, вследствие внедрения нового вида тестирования. Ключевой фактор, показывающий, где баги не были найдены без применения нового подхода в тестировании.
- Коэффициент исправлений. Возрастающее отношение исправленных багов к найденным говорит о качестве ошибок, сроках, необходимых для сообщения об ошибках, о качестве взаимодействия программистов и тестировщиков. Все это может быть упрощено с применением автоматизации тестирования.
- Возможности тестирования. Благодаря автоматизации, можно применить некоторые методы тестирования, которые людям-тестировщикам не по силам. На самом деле эта метрика является списком, который разработчики автоматизированных тестов поддерживают актуальным для периодического пересмотра менеджерами. Вопросы, которые должны задать менеджеры, это «Наступил ли момент использовать эту возможность тестирования?» и «Принесет ли реализация этой возможности тестирования пользу, такую как увеличение уверенности в качестве или коэффициента найденных ошибок».
- Предотвращение катастроф. Это список серьезных проблем, которые были предотвращены благодаря автоматизации тестирования. Также может содержать описание предполагаемых действий для тестирования предотвращения повторения обнаруженных раннее критических проблем.
- Время цикла тестирования. Сколько времени на него потребуется, если не будут обнаружены критические ошибки, для получения очевидных доказательств надежности определенного релиза продукта? Сокращение этого времени вносит гибкость во весь процесс разработки.
- Время цикла разработки/тестирования. На практике, тестирование зависимо от разработки. Мы хотим видеть уменьшение затраченного времени на разработку нового продукта относительно количества задействованного в проекте персонала.
- Уверенность менеджмента. Это не совсем метрика, скорее, фактор. Миссией тестирования является обеспечение менеджмента информацией, необходимой ему для принятий бизнес-решений. Видит ли менеджмент улучшения качества по информации, полученной от тестировщиков? Иногда сравнение состояний «до» и «после» позволяют поставить точку.
- Стоимость технической поддержки. В конечном счете, ключевым фактором в оценивании успешности тестирования является проверка того, насколько хорошо наше априорное предположение о качестве релиза сравнимо с реальными результатами. Именно поэтому техническая поддержка очень важна. Необходимо внедрить систему регулярно обращаться к сотрудникам технической поддержки и выяснять, какие проблемы возникают у пользователей. Посмотрите на количество звонков в поддержку относительно количества пользователей. Посмотрите, как можно уменьшить время звонка, если предоставить технической поддержке более хорошие инструменты для диагностики, похожие на те, что могут предложить разработчики автоматизированных тестов.
- Удержание пользователей. Если качество будет лучше, возможно, пользователи будут довольны.
- Репутация. Она может казаться неосязаемой, но это не так. Репутация выражается в историях, рассказываемых о группе тестирования среди других сотрудников компании. Репутация передается в историях, поэтому вы должны иметь видимые, позитивные и впечатляющие победы настолько часто, насколько это возможно. Также, чем чаще команда автоматизации и команда тестирования говорят «да» просьбам о помощи, тем лучше будет их репутация.
- Завершенные решения. Ищите способы постоянного увеличения количества завершенных решений задач, выполняемых командой автоматизации тестирования.
Риски автоматизации с использованием agile-подхода
- автоматизация может не принести существенных улучшений в продуктивности тестирования, если тестировщики не знают, как надо тестировать;
- метрики продуктивности такие как количество созданных или выполненных тест-кейсов за день могут быть очень обманчивыми, и могут привести к большим затратам на проведение бесполезных тестов;
- тестировщики могут не хотеть сотрудничать с разработчиками автоматизированных тестов. Члены команды автоматизации должны быть своего рода консультантами: доступными, отзывчивыми и изобретательными, иначе эта система быстро разрушится;
- разработчики автоматизированных тестов могут предлагать и реализовывать решения тестовых задач, которые постоянно требуют дорогостоящей поддержки;
- разработчикам автоматизированных тестов может не хватать квалификации для планирования и реализации эффективных решений;
- разработчики автоматизированных тестов могут быть настолько успешными, что им не хватает важных заданий для работы и они переключаются на незначительные проблемы.