Автор: Джоэл Монтвелиски (Joel Montvelisky)
Оригинал статьи
Перевод: Ольга Алифанова

Не удваиваете ли вы усилия без нужды?

Я давно заметил, что некоторые QA-команды, внедрившие автоматизацию, все еще прогоняют часть своих автоматизированных кейсов вручную.

Но ЗАЧЕМ?

Когда я спросил тест-сообщество о причинах, то получил вот такие ответы:

1. QA-командам нравится прогонять некоторые тесты вручную, потому что они "очень важны" – тут я немного запутался, потому что это кажется контрпродуктивным, не так ли? Но второй ответ несколько прояснил ситуацию.
2. QA-команды не доверяют своему автотесту на сто процентов. Окей, при нехватке доверия ручные тесты играют роль обеспечения качества автотестов. Однако такой подход все равно не кажется мне хорошей идеей. Создать хорошую, устойчивую автоматизацию, конечно, нетривиальная задача – но если уж вы вкладываетесь в автоматизацию, займитесь ей серьезно и создайте скрипты, которым можно доверять.
3. Это происходит, если нет четкого определения или понимания того, что именно автоматизировано. Поэтому люди тратят время на прогон ручных тестов, которые уже автоматизированы, предполагая, что не автоматизировано ничего и работая так, как будто автоматизации нет. Зачем им тогда вообще автоматизаторы?
4. За автотесты отвечает другая команда. Две тест-команды, для ручного и для автоматизированного тестирования – это само по себе неплохо, и в ряде случаев позволяет наилучшим образом достичь эффективной и достойной доверия автоматизации. Плохо то, что эти команды могут быть полностью разъединены и работать над одним проектом, не общаясь и не кооперируясь.
5. Команды прогоняют тесты вручную, чтобы внести результаты автотестов в системы тест-менеджмента и получить полные и внятные отчеты для руководства. Это мне близко, потому что стремление к видимости процессов – одна из ценностей разработки в PractiTest. Неважно, сколько интеграций или фич тест-менеджмента мы добавляем – мы всегда фокусируемся на кросс-командной коммуникации.
6. Ряд автоматизированных и ручных тестов "связаны", а не "продублированы". К примеру, автотест убеждается в инсталляции на все ОС, а "связанный с ним" ручной тест проверяет влияние абнормального сетевого трафика в ходе процесса установки. По сути, эти тесты дополняют друг друга.
7. Некоторые тесты автоматизированы "наполовину", а не полностью – к примеру, тесты, в ходе которых проводится ряд операций с постоянной съемкой скриншотов. Эти скриншоты затем быстро просматриваются вручную в поисках проблем и багов GUI.
8. Дополнительные ручные тесты добавляются к уже имеющейся автоматизации. К примеру, автоматизация используется для проверки установки системы и валидации процедур по добавлению, удалению и изменению данных. Когда эти тесты готовы, можно взять созданную систему и прогонять на ней дополнительные ручные тесты на основании существующих данных и настроек.

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

Проблемы координации автоматизированного и ручного тестирования

В ответ на мой вопрос люди рассказали о проблемах, возникающих при координации ручного и автоматизированного тестирования, не связанных напрямую с повторным прогоном тестов. Вот самые интересные моменты:

Определить, что нужно перевести из ручного в автоматизированное тестирование

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

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

Сложность теста – тут речь о том, насколько сложно создать автотест, и насколько легко провести этот тест вручную. Существуют тесты, чересчур сложные для ручного прогона (к примеру, тесты API), а ряд тестов почти невозможно автоматизировать (к примеру, удобство использования). Нужно грамотно выбирать, какие тесты больше подходят для автоматизации, а какие –для ручного тестирования.

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

Координация задач между командами ручного и автоматизированного тестирования

Серьезные проблемы также возникают из-за исходных различий между хорошим ручным тестировщиком и хорошим автоматизатором.

Кто за что отвечает?

• Должны ли автоматизаторы решать, что тестировать, или это решение за ручными тестировщиками?
• Кто отвечает за расписание прогонов – автоматизаторы или ручные тестировщики?
• Что будет, если автотест упадет? Должен ли "ручник" проверять баг, или это задача команды автоматизации?

Ответы на все эти вопросы нужно дать заранее, и тут тоже нет идеальных решений.

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

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

Снятие табу с тест-автоматизации

Мне очень понравился комментарий Марко Вензелааера на LinkedIn: "Некоторые команды автоматизации превращают автоматизацию в "черную магию", секреты которой бдительно оберегаются от непосвященных".

Я, конечно, посмеялся – но и схватился за голову, потому что Марко озвучил то, что я чувствую не первый год. Некоторые автоматизаторы думают, что если их работа воспринимается как нечто загадочное, тяжелое и крайне сложное, то это обезопасит их рабочие места. Они крайне успешно сеют эти мысли в головах ручных тестировщиков, у которых нет опыта программирования – они искренне верят всему, что им говорят коллеги-автоматизаторы.

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

Как же координировать работу автоматизаторов и ручных тестировщиков в команде?

Я думаю, что ключ к поддержанию здоровых взаимоотношений ручного и автоматизированного тестирования – это командная работа и коммуникация.

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

Тривиальные вещи, которые надо учесть:

1. Убедитесь, что тестировщики скоординированы, проводя регулярные планерки и убеждаясь в активном участии обеих команд в планировании тест-задач.
2. Пусть обе команды работают в интегрированном окружении, в котором выполняются и ручные, и автоматизированные тесты. Это позволит тестировщикам и другим участникам команды видеть полную картину и понимать, что покрыто, что протестировано, и каков результат тестов, как на этапе планирования, так и на этапе выполнения. В конце концов, никого не волнует, как именно проведен тест – вручную или нет, важны его результаты.
3. Наладьте процесс так, чтобы автоматизация была инструментом, помогающим вашей ручной команде. Правильный процесс – залог хороших взаимоотношений ручных и автоматизированных тестов. Обе команды должны понимать, что задача автоматизации – освободить время для ручного прогона более сложных тестов, которые сложно или дорого автоматизировать. Понимание, что команды дополняют друг друга, а не соревнуются, позволит им сконцентрироваться на общих проблемах, а не на разногласиях.

Если вкратце, вам нужно убедиться, что у ваших команд есть общая цель и инфраструктура, позволяющая координировать их работу.

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

Обсудить в форуме