Стремясь к автоматизации тестирования, команды QA часто допускают ошибки, которые стоят времени, денег, доверия и срывают прогресс. Эти промахи могут заставить вашу команду слишком нервничать, чтобы попробовать еще раз, несмотря на то, что, по данным World Quality Report, QA сегодня рассматривается как ключевой фактор роста бизнеса.
Хорошая новость заключается в том, что в большинстве случаев этих ошибок можно избежать. Вот семь наиболее распространенных ошибок автоматизации тестирования, которых следует избегать вашей команде.
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
1. Вы пропустили первый шаг
Очень заманчиво начать составлять списки того, что нужно автоматизировать, а затем искать инструменты, которые выполнят эту работу. Но есть шаг, который должен предшествовать этому, говорит Бас Дийкстра, тренер и консультант по автоматизации тестирования. “Команды забывают сначала спросить себя: Зачем мы вообще собираемся это автоматизировать?”.
Пол Меррилл, консультант по автоматизированному тестированию компании Beaufort Fairmont, предлагает начать с вопросов: “Какой риск мы пытаемся снизить с помощью нашего теста, и как автоматизация может помочь в этом?
Решение: Тщательно определять цели и ожидания для каждой инициативы по автоматизации и помнить, что каждая потенциальная область автоматизации должна вносить измеримый вклад в “качество на скорости”.
2. Вы автоматизировали не то, что нужно
Многие команды пытаются автоматизировать то, что не является хорошим кандидатом для автоматизации. Одним из основных просчетов в этой области является попытка перевести существующие действия по тестированию один к одному в автоматизацию. Это приводит к тому, что тестировщики тратят много времени и сил на то, что не нужно автоматизировать или что автоматизировать не следует.
Например, можно попытаться автоматизировать все существующие регрессионные тесты дословно. “Это залог неудачи, поскольку автоматизация в таком случае работает не очень эффективно, – говорит Дийкстра.
А если вы проводите тест только, скажем, раз в год, то не стоит тратить месяцы на создание фреймворка и скриптов для его автоматизации”. “Убедитесь, что вы нацелены на то, что сразу же даст вам реальную пользу, – говорит Джо Колантонио, основатель TestTalks.com, – не автоматизируйте все, что только можно”.
По словам Колантонио, команды могут столкнуться с проблемами, реагируя на цели руководства, поощряющие количество, например, на требование автоматизировать 90% тестирования. Если менеджеры установят высокоуровневую приборную панель, показывающую процент автоматизации, команды будут автоматизировать много неправильных вещей только для того, чтобы увеличить это число, пояснил он.
Решение: Лучше всего автоматизировать тесты, которые являются повторяющимися и детерминированными. “Если в тесте присутствуют какие-либо случайности или код постоянно меняется, он не будет хорошо реагировать на автоматизацию”, – сказал Колантонио. Для получения успешного результата с измеримым ROI ищите тесты, которые вы будете выполнять снова и снова, или такие, как тестирование производительности, которые можно выполнить только с помощью автоматизированного инструмента”.
3. Выбранные инструменты не могут решить ваши проблемы
Многие руководители хотят выбрать один инструмент для всего предприятия, говорит Меррилл. Это ошибка, поскольку существует множество различных проблем, которые вы хотите решить с помощью автоматизации, и один инструмент не может решить их все. “Главное – выяснить, какую проблему вы хотите решить с помощью инструмента, – говорит Дийкстра, – а не покупать инструмент, а затем искать для него проблему”.
Меррилл советует своим клиентам искать “правильные инструменты для правильной работы и правильной команды”. В противном случае вы рискуете получить инструменты в свое распоряжение, а затем обнаружить, что для того, чтобы заставить их делать то, что вам действительно нужно, вам придется приложить немало усилий или доработать их.
Решение: Определите конкретные проблемы, которые необходимо решить, прежде чем искать инструмент, и попробуйте, прежде чем покупать. Колантонио советует провести двухнедельную пробную версию каждого инструмента, прогнав его через весь жизненный цикл разработки, чтобы увидеть, как он работает в вашей среде, и убедиться, что он решает проблему, которую вы пытаетесь решить.
4. Выбранные инструменты не подходят для ваших тестировщиков
В реальном мире проблемы возникают из-за “технических навыков (или их отсутствия) у людей, которые будут работать с инструментами”, – говорит Энджи Джонс, старший специалист по работе с разработчиками компании AppliTools. Убедитесь, что вы знаете, какие навыки потребуются вашей команде для эффективного использования любого рассматриваемого вами инструмента. Этот вопрос должен быть включен в запрос на предложение, например, в руководство покупателя по средствам автоматизации тестирования.
По словам Диего Ло Джудиче, вице-президента и главного аналитика компании Forrester Research, поставщики разрабатывают свои инструменты с учетом “персон”, которые, скорее всего, будут их использовать. По его словам, существует три типа профилей тестировщиков:
- Разработчики-тестировщики, которые предпочитают оставаться в своей среде кодирования для написания тестов
- технические тестировщики, специалисты по автоматизации тестирования, предпочитающие инструменты более высокого уровня, использующие моделирование и не требующие навыков кодирования
- бизнес-тестировщики, нетехнические специалисты, которые занимаются приемочным тестированием, тестированием юзабилити и т.д. и предпочитают использовать естественный язык для написания тестов.
Если купить инструмент, предназначенный для разработчика-тестировщика, и попросить технического или бизнес-тестировщика использовать его, то каждый раз можно столкнуться с проблемами. Скорее всего, это будет происходить все чаще по мере того, как организации будут выходить за рамки ограниченного штата разработчиков-тестировщиков и обращаться к другим специалистам за помощью в автоматизации тестирования.
Решение: Проведите пробное тестирование каждого рассматриваемого инструмента с привлечением реальных тестировщиков, которым придется его использовать, чтобы выявить пробелы в навыках. Ищите инструменты, которые могут использовать как кодеры, так и не кодеры. Например, некоторые средства автоматизации функционального тестирования обеспечивают редактирование как без сценариев, так и на основе сценариев. Такие инструменты не требуют развитых навыков разработчика и будут более удобны для всех.
Кроме того, убедитесь, что у вас есть бюджет на повышение квалификации команды в случае необходимости. “Если организации не предпримут активных действий по переобучению своих сотрудников и развитию специализированных навыков, это может вскоре стать критическим узким местом, сдерживающим прогресс функции QA и тестирования”, – говорится во Всемирном докладе о качестве 2018-19.
5. Вы не смогли подсчитать общую стоимость владения инструментом
Вы быстро столкнетесь с проблемами при покупке инструмента, если не учтете все расходы, связанные с этим выбором. “У меня был клиент, которому нужна была помощь в переходе с коммерческого инструмента на Selenium, – рассказывает Меррилл. Когда его спросили о целях, клиент ответил: “Мы не хотим больше платить лицензионные отчисления”. Других целей у него не было; все сводилось к экономии денег.
“Я сразу же понял, что при тех усилиях, которые ему придется приложить, экономии не будет в течение многих лет”, – говорит Меррилл. У них уже были тысячи созданных сценариев, и им пришлось бы потратить время на обучение команды из 13 человек.
Если учесть расходы на обучение и поддержку, а также на переписывание всех скриптов при ежедневном поступлении новых, то экономия средств будет достигнута только через несколько лет”. Клиент последовал совету Merrill и не стал менять инструменты.
Решение: Прежде чем переходить с одного инструмента на другой, подумайте о сопутствующих затратах. Учитывайте обучение команды и поддержку нового инструмента, затраты на перенос существующих тестов, а также влияние перехода на способность нанимать и удерживать в команде квалифицированных тестировщиков.
6. Вы выбрали инструмент только потому, что он с открытым исходным кодом
По мнению Ло Джудиче из Forrester, предпочтения рынка в этой области определенно меняются, и открытые исходные коды стали общепризнанными. Однако это не должно быть основным критерием выбора. “Фокус в том, чтобы сначала выяснить, что вам нужно решить, и только потом искать инструмент, который решает эту задачу наиболее эффективным способом, независимо от того, как он лицензирован”, – говорит Дийкстра.
В целом инструменты с открытым исходным кодом требуют более высокой технической квалификации. Как правило, вы не сможете дозвониться до поставщика и обратиться за поддержкой, если инструмент не работает, предупреждает Джонс.
Инструменты с открытым кодом также имеют некоторые ограничения, несмотря на привлекательное отсутствие лицензионных платежей. Некоторые из них имеют ограниченную функциональность и могут не предоставлять всех необходимых функций, поэтому четко определите, что именно вам нужно.
“Возможно, вам нужно лишь немного отчетов, и тогда будет достаточно инструмента с открытым кодом. Или же Вы работаете в организации с жестким регулированием или нуждаетесь в более широкой отчетности; в этом случае стоит потратиться на приобретение коммерческого инструмента”, – говорит Джонс.
Кроме того, будьте готовы к переменам. Как правило, вначале люди предпочитают открытые исходные коды, начинают внедрять инновации, а “в какой-то момент они масштабируются и приходят к выводу, что лучше использовать надежный коммерческий инструмент, который может масштабироваться и не нуждается в поддержке”, – говорит Ло Джудиче.
Многие организации в итоге используют и открытые, и коммерческие инструменты вместе, поскольку коммерческие инструменты могут восполнить недостающую функциональность, которой нет в открытых инструментах, и часто добавляют ценность поверх открытых инструментов.
Решение: Определите проблему, которую вы хотите решить, и функции, которые вам необходимы, а затем найдите среди коммерческих инструментов и инструментов с открытым исходным кодом инструмент, удовлетворяющий этим требованиям. Затем следует рассмотреть компромиссы между открытыми и коммерческими вариантами. Например, если учесть уровень квалификации пользователей, их потребности в обучении и поддержке, подойдет ли вариант с открытым кодом? Наконец, оцените жизнеспособность конкретного сообщества разработчиков инструмента с открытым исходным кодом, чтобы определить, будет ли обеспечена бесплатная поддержка сообщества.
7. Вы не сформировали культуру тестирования, которая бы принимала автоматизацию
Если у вас нет культуры тестирования, инструменты ее не исправят. Люди склонны винить свой инструмент, когда что-то идет не так, – говорит Колантонио. Но обычно виноват не инструмент, а команда, ее подход к тестированию и отношение к автоматизации.
Колантонио работал в крупной компании, которая использовала коммерческий инструмент, но его тесты были нестабильны и требовали много времени для выполнения. “Они перешли на Selenium, и знаете, что произошло? Люди стали жаловаться на то, что тесты работают медленно и их трудно поддерживать, а это те же проблемы, которые они испытывали с коммерческим инструментом”. По его словам, реальная проблема заключалась в том, что в компании не было культуры, ориентированной на тестирование.
В компаниях, где существуют проблемы с культурой, может быть предвзятое отношение к автоматизации тестирования, или же в них до сих пор только один человек назначен тестировщиком и требует, чтобы все действия по тестированию проходили через него.
Для изменения культуры может потребоваться много обучения. По словам Колантонио, достаточно одного человека, который возьмет на себя инициативу и расскажет всей команде о преимуществах, обучая других и продвигая идею автоматизации тестирования изнутри. “Достаточно одного человека, который возьмет на себя инициативу и станет чемпионом по автоматизации тестирования”.
Если все члены команды занимаются своим делом, но никто не понимает, зачем они это делают, кто-то внутри команды должен указать на конкретные успехи. Это может быть экономия времени, а также информация о том, как это произошло.
По словам Меррилла, формирование культуры зависит от руководителей организации. Они могут поощрять инициативу чемпионов и создавать условия, поощряющие эксперименты и приветствующие успехи.
“Наличие лидера, который возьмет на себя инициативу и будет вести ее с энтузиазмом, является абсолютно ключевым фактором, – сказал он. Люди слышат об опыте, видят, как что-то работает, как за этим стоит энергия, как это приносит пользу, и это гораздо легче принять, чем какую-то статью, которую они прочитали”.
Решение: Оценить культуру команды и организации и совместно с руководством способствовать развитию культуры тестирования. Найдите людей, которые будут способствовать этому изнутри команды, и помогите им добиться успеха.
Ваш следующий шаг: Найдите проект, который может принести победу
Если в прошлом автоматизация тестирования дала неоднозначные результаты или даже грандиозные провалы, это не должно помешать вам попробовать еще раз. Без нее вы никогда не сможете соответствовать темпам agile-разработки.
Внимательно изучите ошибки, которые могли помешать вам в прошлом, и воспользуйтесь этими рекомендациями, чтобы найти проект, который принесет вам победу. Именно так можно заложить основу надежной стратегии автоматизации тестирования в вашей организации.
Ставки становятся все выше с каждым днем. Согласно докладу World Quality Report 2018-19, автоматизация является самым большим узким местом, сдерживающим эволюцию QA и тестирования сегодня. Согласно отчету, “автоматизация, и особенно интеллектуальная автоматизация тестирования, способна привести к значительным изменениям в способах выполнения QA и тестирования” в ближайшие два-три года. Если вы рассчитываете воспользоваться ее преимуществами, вам необходимо разработать стратегию и дорожную карту.
Перевод статьи «The top 7 test automation mistakes: How to avoid your next fail».