Стремясь к автоматизации тестирования, команды QA часто допускают ошибки, которые стоят времени и денег. В этой статье мы рассмотрим 7 наиболее распространенных ошибок автоматизации тестирования, и как их избежать.
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
1. Вы пропустили первый шаг
Очень заманчиво начать составлять список того, что нужно автоматизировать, а затем искать инструменты, которые выполнят эту работу. Bas Dijkstra, специалист по автоматизированному тестированию, говорит: “Команды забывают сначала спросить себя: зачем мы вообще собираемся это автоматизировать?”
Paul Merrill, специалист по автоматизации тестирования в компании Beaufort Fairmont, предлагает начать с вопросов: “Какие риски мы пытаемся снизить с помощью наших тестов, и как автоматизация может помочь нам в этом?
Решение: Тщательно определить цели и ожидания для каждого проекта по автоматизации и помнить, что автоматизация должна улучшать качество и ускорять процессы разработки продукта.
2. Вы автоматизировали не то, что нужно
Многие команды пытаются автоматизировать то, что, по сути, не нуждается в автоматизации. Это приводит к тому, что тестировщики тратят много времени и сил на пустую работу.
Например, если вы запускаете тест только, скажем, раз в год, то не стоит тратить месяцы на создание фреймворка и скриптов для его автоматизации. “Убедитесь, что вы автоматизируете то, что принесет вам реальную пользу, – говорит Joe Colantonio, основатель TestTalks.com – не старайтесь автоматизировать всё, что только можно.”
По словам Colantonio, команды могут столкнуться с проблемами, стремясь, например, реализовать требование руководства в том, чтобы автоматизировать 90% тестирования. Если менеджеры установят требуемый процент автоматизации тестирования, команды будут автоматизировать много лишнего только для того, чтобы увеличить этот процент.
Решение: Для достижения хороших результатов автоматизируйте те тесты, которые необходимо многократно повторять, например, такие, как тесты производительности, которые можно выполнить только с использованием инструментов автоматизации.
3. Выбранные инструменты не могут решить ваши проблемы
“Многие руководители стремятся к тому, чтобы выбрать один инструмент для всего проекта”, – говорит Merrill. Это заблуждение, поскольку есть множество проблем, которые вы хотите решить с помощью автоматизации, и один инструмент не может решить их все. “Главное – выяснить, какую проблему вы хотите решить с помощью инструмента, – говорит Dijkstra, – а не покупать инструмент, а затем искать для него проблему”.
Меррилл советует искать “правильные инструменты для правильной работы и правильной команды”. В противном случае вы рискуете приобрести инструменты, а затем обнаружить, что для того, чтобы они делали то, что вам действительно нужно, необходимо потратить много времени на их настройку или доработку.
Решение: Определите конкретные проблемы, которые необходимо решить, прежде чем искать инструмент, и протестируйте его, прежде чем покупать. Colantonio советует провести двухнедельное пробное тестирование с каждым инструментом, чтобы увидеть, как он работает в вашей среде, и убедиться, что он решает нужную вам проблему.
4. Выбранные инструменты не подходят для ваших тестировщиков
В реальном мире проблемы возникают “из-за hard skills (или их отсутствия) у людей, которые будут работать с инструментами”, – говорит Angie Jones, senior developer advocate в компании AppliTools. Убедитесь, что вы знаете, какие навыки потребуются вашей команде для эффективного использования нужного вам инструмента.
По словам Diego Lo Giudice, вице-президента и главного аналитика компании Forrester Research, поставщики разрабатывают свои инструменты с учетом того, какие специалисты в дальнейшем будут их использовать. По его словам, существует три вида тестировщиков:
- Developer-testers – разработчики, которые пишут код и одновременно тестируют его.
- Technical testers – специалисты по автоматизации тестирования, предпочитающие инструменты, которые не требуют навыков программирования.
- Business testers – люди, которые тестируют продукт с точки зрения бизнеса, не обязательно технически подкованные. Они предпочитают использовать естественный язык для написания тестов и чаще всего проводят приемочное тестирование, юзабилити-тестирование.
Если купить инструмент, предназначенный для developer-tester, и попросить technical или business tester использовать его, то каждый раз они будут сталкиваться с проблемами.
Решение: Проведите пробное тестирование с каждым инструментом с привлечением реальных тестировщиков, которым придется его использовать, чтобы выявить пробелы в их скиллах. Ищите инструменты, доступные как для тестировщиков со знаниями программирования, так и без них. Например, некоторые инструменты для автоматизации функционального тестирования предоставляют возможность создания сценариев как без кода, так и с использованием кода.
Кроме того, убедитесь, что у вас есть бюджет на повышение квалификации команды в случае необходимости. “Если компании не начнут активно обучать своих сотрудников и развивать специальные навыки, это может стать основным препятствием, замедляющим развитие в области QA и тестирования “, согласно World Quality Report 2018-19.
5. Вы не учли полную стоимость инструмента
Если вы не учтете все затраты, связанные с выбором инструмента, то, очевидно, быстро столкнетесь с проблемами после его покупки. Merrill рассказывал: “У меня был клиент, который хотел перейти с коммерческого инструмента на Selenium. Когда я спросил о его целях, клиент сказал, что больше не хочет платить за лицензию. Очевидно, у него не было других целей, ему просто было важно сэкономить деньги.”
“Я сразу же понял, что при тех усилиях, которые ему придется приложить, экономии не будет в течение многих лет, – говорит Merrill – у них уже были тысячи созданных скриптов, и им пришлось бы потратить время на обучение команды из 13 человек.”
С учетом затрат на обучение, поддержку и переписывание всех скриптов, учитывая постоянные изменения, происходящие каждый день, прошло бы много лет, прежде чем они действительно смогли бы сэкономить деньги. В итоге клиент все-таки последовал совету и решил не менять инструмент.
Решение: Прежде чем переходить с одного инструмента на другой, подумайте о последующих затратах. Учитывайте обучение команды и поддержку нового инструмента, затраты на миграцию существующих тестов.
6. Вы выбрали инструмент только потому, что он open source
По мнению Lo Giudice, предпочтения на рынке в области QA быстро меняются, и сейчас open source продукты стали общепризнанными. Однако это не должно быть вашим основным критерием выбора инструмента. “Идея в том, чтобы сначала выявить задачу, и только потом искать инструмент, который решает эту задачу наиболее эффективно, независимо от того, как он лицензируется”, – говорит Dijkstra.
В целом инструменты с открытым исходным кодом требуют от вас более высокой технической квалификации. Как правило, вы не сможете дозвониться до поставщика и обратиться за поддержкой, если инструмент не работает.
Инструменты с открытым кодом также имеют некоторые ограничения. Многие из них имеют ограниченный функционал, поэтому важно четко определить, что именно вам нужно.
Кроме того, будьте готовы к переменам. Как правило, вначале люди предпочитают open-source инструмент и “в какой-то момент обнаруживают, что им лучше всего подходит надежный коммерческий инструмент, который может масштабироваться и не нуждается в поддержке”, – говорит Lo Giudice.
Многие компании в итоге используют и open-source, и коммерческие инструменты вместе, поскольку коммерческие инструменты могут восполнить недостающий функционал, которого нет в open-source инструментах.
Решение: Определите проблему, которую вы хотите решить, и функционал, который вам необходим, а затем найдите среди коммерческих и open-source инструментов такой, который удовлетворял бы этим требованиям. Затем рассмотрите компромиссы между открытыми и коммерческими вариантами. Например, учитывая уровень квалификации ваших тестировщиков и необходимость в их обучении, подходит ли вам вариант с открытым исходным кодом? Оцените активность конкретного сообщества, поддерживающего инструмент с открытым исходным кодом, чтобы определить, будет ли доступна бесплатная поддержка от этого сообщества.
7. Вы не создали культуру тестирования, которая бы поддерживала автоматизацию
“Если у вас нет культуры тестирования, инструменты этого не исправят. Люди склонны винить свой инструмент, когда что-то идет не так, “- говорит Colantonio. Но обычно виноват не инструмент, а команда, ее подход к тестированию и отношение к автоматизации.
Colantonio работал в крупной компании, которая использовала коммерческий инструмент, но тесты были нестабильны и занимали много времени. “Они перешли на Selenium, и знаете, что произошло? Специалисты стали жаловаться на то, что тесты работают медленно и их трудно поддерживать, а это те же проблемы, которые они испытывали и с коммерческим инструментом”. По его словам, реальная проблема заключалась в том, что в компании отсутствовала культура тестирования.
В компаниях, где существуют проблемы с культурой, может быть предвзятое отношение к автоматизации тестирования, либо они могут все еще иметь только одного человека, ответственного за тестирование.
Изменение культуры тестирования может занять много времени. По словам Colantonio, достаточно одного человека, который возьмет на себя инициативу и расскажет всей команде о преимуществах, обучая других и продвигая идею автоматизации тестирования.
По словам Merrill, формирование культуры зависит от руководителей компании. Они могут поощрять инициативу лидеров.
Решение: Оценить культуру команды и самой компании и совместно с руководством способствовать развитию культуры тестирования.
Перевод статьи «The top 7 test automation mistakes: How to avoid your next fail».