В теории, автоматизация — это быстрые, эффективные и надежные тесты. Почему же до сих пор все ИТ-компании не автоматизировали свои QA-процессы? Есть на то причины, расскажем о них.
- Завышенные ожидания
- Неправильный менеджмент
- Игнор ручного тестирования
- Горят дедлайны
- Необучаемые тестировщики
- Не разбираются репорты
- Автоматизируются только UI-тесты
- Нет опыта автоматизации в узкой сфере / Не владеют языками программирования
- Плохой менеджмент
- Слабая инфраструктура
- Автоматизация в отрыве от разработчиков
- Нет плана автоматизации
- Тесты не автономные
- Незнание паттернов программирования
- Плохое масштабирование
- Темнота
По некоторым оценкам, лишь около четверти крупных компаний (масштаба HP и IBM) может похвастаться тем, что их QA-департаменты применяют автоматизацию в значимых масштабах; руководство остальных компаний полагает, что ручное тестирование в целом надежнее. И это при доступности качественных инструментов автоматизации, и бурном развитии этого рынка. Согласно отчету, основные причины неприятия автоматизации — “у компании нет опыта автоматизации”, и/или “не хватает квалифицированных автоматизаторов”. Компании в отчете — западные, но полученные данные релевантны и для российского рынка.
Экономия времени и раннее обнаружение дефектов — известные преимущества автоматизации; однако достаточно часто компании, опробовав автоматизацию, отказываются от нее! Далее перечислены причины, почему так происходит.
Завышенные ожидания
Ситуация: QA-команде удалось убедить руководство (и разработчиков), что существует идеальное решение “все в одном”, которое “должно решить все проблемы с QA”. Разработчикам впасть в “заблуждение завышенных ожиданий” еще легче чем руководству компании, поскольку они мыслят как разработчики, а не как тестировщики, а в разработке подобные универсальные инструменты действительно могут существовать. Итак, QA “продают” коллегам автоматизацию на нереалистичных обещаниях, например “автоматизировать абсолютно все ручное”, или “сильно сократить время на тестирование”. Затем автоматизация превращается в фейл, вполне закономерный.
Неправильный менеджмент
Рукводящие сотрудники (менеджеры) могут наоборот не отдавать должное автоматизации, не давать ей приоритета при распределении задач (и средств) — по своей загруженности, или неверию в автоматизацию, или чаще по нежеланию менять хорошо налаженные процессы в компании.
Если QA Lead не имеет желания/способности красочно рассказать руководству, какой полезной может быть автоматизация, то она вряд ли хорошо получится.
Вариант: если QA Lead не способен заставить QA-команду освоить автоматизацию. По опыту, часть команды считает, что раз плохо умеет программировать (или вообще не владеет языками программирования), или опасается своей “ненужности” в качестве manual QA, поэтому поддерживают идею, что автоматизация “как-нибудь потом”, и могут даже противодействовать. Автоматизация — не та вещь которая делается в одиночку, это командная вещь, поэтому видимо в “тяжелых случаях” должны быть “оргвыводы” со стороны QA Lead.
Игнор ручного тестирования
Компетенции тестировщиков отличаются, так же как их опыт, поэтому лиду не стоит ожидать, что написанные командой автотесты будут на одном уровне. Даже если все пишут тесты со 100% аккуратностью, manual-тестировщики в команде необходимы, хотя бы для подстраховки. Правильная автоматизация, “автоматизация получилась” — это когда лид грамотно сочетает ручное и автоматизированное QA, это один из ключей его успеха как лида.
Когда горят дедлайны
Например, есть маленькая QA-команда в маленькой компании, команда уже смирилась с необходимостью автоматизации и как-то освоила фреймворки. Чаще она идет “по кратчайшему пути”: автоматизируются “неважные” кейсы, или “пробные”, или “то что осталось” когда горят дедлайны. Такой подход иногда имеет смысл, когда требуются многократные тесты одного и того же, или ручное тестирование уж слишком тормозит пайплайн.
Устав от сложных размышлений — автоматизировать или нет, теряя время, команда решает вообще не автоматизировать, ей так проще.
Необучаемые тестировщики
Тестировщики могут быть попросту необучаемые, что касается инструментов автоматизации, или методологий. Такое можно пробовать исправить подбором инструментов попроще. Надо учитывать скиллы команды, и тратить время на обучение — это должно окупиться. Надо постараться подобрать инструменты с крутым графиком обучения, то есть которые можно освоить очень быстро (ориентируясь по отзывам тех, кто уже освоил).
Не разбираются репорты
Может быть и такая причина: недостаточно внимания уделяется разбору отчетов по тестам (то есть репортов). Специфика автотестов такова, что они выполняются пакетно, что само по себе увеличивает вероятность случайных ошибок. Поэтому репорты должны разбираться внимательно — иначе позитив от автоматизации превратится в негатив, в потерю времени и денег.
Автоматизируются только UI-тесты
Пользователь работает с приложением только через свой интерфейс, ничего иного не видит. Когда он кликает по кнопкам, в приложении происходят какие-то события, которые нужно протестировать тоже, и так же тщательно, как UI (на чем QA-команда не всегда настаивает). Если катастрофически не хватает времени и речь идет о веб-приложениях, то для тестирования “внутренней функциональности” можно применять headless-браузеры, без UI и выполняющие много параллельных тестов. Вообще, в небольших командах существует вредная привычка “только интерфейс, а остальное как-то по возможности”, а возможности появляются редко, поэтому вопрос надо согласовать со стейкхолдерами.
Нет опыта автоматизации в узкой сфере / Не владеют языками программирования
Статистически, чаще всего в крупных и средних компаниях на Западе применяется Selenium, Robot, и Cucumber. Нужно еще раз подчеркнуть, что QA-команда должна иметь приемлемый уровень владения языками программирования.
Плохой менеджмент
Если автотесты сделаны “на уровне QA-команды и не выше”, без учета мнения менеджеров и разработчиков, есть большой шанс, что автоматизации не придадут должного значения. При жестких дедлайнах это приведет к тому, что проект могут передать в продакшн до того как будут идеальные автотесты. Команда примет следующие решения, исходя из некорректных данных, и сделает негодный продукт.
Если цель лида и сеньйоров — продвигать автоматизацию в компании чтобы экономить свои усилия (как и должно быть), значит менеджеров надо подключать к ранней стадии QA-планирования, и не терять с ними контакт.
Чем лучше и чаще проинформировано руководство, тем лучше оно относится к такой чудесной вещи как автоматизация, и вникает в процедуры. Доказано на практике, что если автоматизация спланирована и выполнена правильно, она окупится всегда — а руководство это любит.
Слабая инфраструктура
Важный фактор в успехе или неуспехе автоматизации. Будь это потребительский продукт, или В2В-продукт — речь идет о браузерах, а значит о тестовой инфраструктуре.
Тестируя веб-приложение, в принципе можно начать с ручного тестирования — понимая его ограничения. Ручное тестирование не “нагружает” инфраструктуру, при этом можно достичь какого-то приемлемого тестового покрытия.
Хотя команда теоретически может нормально протестировать на небольшом количестве браузеров, ОС и девайсов, потом все равно придет необходимость расшириться и сделать автоматизированное кроссбраузерное тестирование. Ручное тестирование способно выполнить какое-то ограниченное количество тестов в день, возможности автоматического — ограничены лишь инфраструктурой. И вот тут-то возникают проблемы: инфраструктура не приспособлена.
Автоматизация в отрыве от разработчиков
Часто называемая в вышеуказанном отчете причина неудачи автоматизации в мировых ИТ-компаниях: QA-команды работают как бы “в отрыве” от остальных команд, то есть не имеют хорошей коммуникации с ними.
Многие мировые компании, как ни странно, все еще не отказываются от классической модели водопада. Впрочем, какова бы ни была модель, и для разработки и для тестирования полезно, чтобы QA-автоматизация была как бы частью разработки.
То есть, автотесты пишутся параллельно с разработкой продукта. Это может приводить к усложнению тестирования (то есть к усложнению задач тестировщикам) — дефекты должны быть найдены уже на первых стадиях разработки. Плохая коммуникация между QA и разработчиками на этой стадии грозит обилием “пропущенных” дефектов: функциональных, нефункциональных, к проблемам с производительностью.
Нет плана автоматизации
Если нет грамотного плана автоматизации, это почти гарантия, что она закончится фейлом. В планах надо прописать, что будет автоматизировано, затем убедиться, что всем доведены эти планы — тестировщики хотя бы примерно знают, что будут делать. Потом, (и это тоже часть правильного плана), так называемый fallback — когда тестировщики понимают, что от автоматизации пока нельзя требовать идеала, и они знают свои действия, когда что-то пойдет не так.
Тесты не автономные
Неавтономные тесты это тоже одна из известных причин. Идеальная автоматизация позволяет запускать тесты автономно, то есть отдельно друг от друга, такая модульная структура позволяет легче находить проблемные места. Если автотесты не модульные, то есть слишком завязаны друг на друга, автоматизация может усложнить жизнь QA-команды.
Например есть плохие автотесты, “конфликтующие” с другими автотестами, или в тест-кейсе есть общие элементы, вызывающие конфликты во всех связанных тестах. Единственный путь устранить эти проблемы — изолировать тесты друг от друга. Ну и, размещать их в папках легко находимых по имени, и запускающихся отдельно.
Незнание паттернов программирования
Автоматизация сложное дело, и здесь полно подводных камней. Тестировщики работают на многих браузерах и платформах, и должны разбираться в них, но если у него есть время, он должен изучать паттерны. Если тестировщик не имеет фундаментального понимания правильных практик автоматизации, он не напишет стабильный надежный код. Фундаментальное владение предполагает владение паттернами программирования. Невладение означает некачественный код и срывы дедлайнов, и значит надо забыть о продвижении к миддлу.
Плохое масштабирование
А иногда команды хорошо начинают автоматизацию, а потом не могут так же хорошо масштабировать. То есть автоматизируются только некоторые “привычные” тесты/кейсы, на большее просто не рассчитывают, такого нет в планах. Нужно планировать будущий рост, это часть процесса Agile и CI/CD — постоянно добавлять функциональность и сразу же тестировать, не отставая.
Темнота
Автотесты должны облегчать проблемы ручного тестирования. А случается, некоторые фреймворки наоборот ухудшают ситуацию, особенно те которые генерируют код автотестов. С этим бороться можно — хорошо контролируя логи и проводя быстрый дебаг. Надо всегда видеть, что делает новомодный фреймворк. А то бывают ситуации.
***
Подытоживая: автоматизация должна хорошо дополнять (а не заменять) ручное тестирование, лид должен быть опытным и красноречивым, и руководство должно быть 100% уверено, что инвестиции в автоматизацию окупятся.
***
Часто упоминаемые проблемы с автоматизацией в крупных компаниях:
Цена: стоимость написания автотестов превышает возможности компании в данный момент.
Сложность: многие тесты и кейсы принципиально нельзя автоматизировать.
Время: автотесты писать дольше, чем делать ручные тесты.
Сложно поддерживать автотесты из-за их постоянных изменений.
