Тестирование программного обеспечения — ключевой этап в разработке любого продукта. Он позволяет обнаружить и исправить ошибки до того, как продукт попадет к конечному пользователю. Однако в эпоху новых технологий и постоянных инноваций подходы к тестированию неизбежно меняются.
Наш гость — Николай Зубков, директор по качеству в Comindware, известной своим решением для автоматизации бизнес-процессов — Comindware Business Application Platform 4. Он поделился своим видением развития автоматизированного тестирования, рассказал о лучших практиках применения различных инструментов, а также дал свой прогноз о возможном влиянии искусственного интеллекта на тестирование.
«Уже на этапе разработки можем быть уверенными в качестве будущего продукта»
Какую роль автоматизированное тестирование играет в вашей стратегии обеспечения качества продуктов команды? Почему следует стремиться к автоматизированному тестированию, и чем оно лучше ручного?
Прежде всего, надо понимать, что качество начинается гораздо раньше этапов тестирования или разработки. Есть четко структурированный набор правил, позволяющих не наступать на грабли, начиная с этапа первичного сбора информации, подготовки и описания требований. В подготовке артефактов, по которым в дальнейшем может быть осуществлена автоматизация, участвуют все члены команды, начиная от специалиста по продажам и далее по списку, включая представителей клиентов.
Если говорить о моменте реализации требований в программный код, то в Comindware мы применяем подход, называемый test-driven development, когда прежде, чем будет написан программный код — пишется тест на проверку будущего функционала. Каждая новая функция в системе генерирует один или несколько юнит-тестов, которые помогают убедиться в том, что результат будет получен такой, как это было запланировано, а не как получится. Эти тесты, несмотря на свою простоту, позволяют уже на этапе разработки быть уверенным в минимально достаточном уровне качества будущего продукта.
Что касается вопроса о том, как можно тестировать функцию до ее реализации, то здесь важно понимать, что юнит-тесты не являются сложными или логически разветвленными структурами. Это простая сущность, проверяющая выдачу корректного результата работы функции. К примеру, если разработчик пишет новую функцию сложения, он заранее планирует, что «2+2=4» и пишет тест на это. Пока функции нет в системе, тест будет падать с ошибкой. Затем он пишет программный код, который реализует функцию сложения. Как только функция сложения реализована, тест будет проходить успешно. В этом и заключается первичный анализ качества функции, остающийся актуальным, пока функция не удалена и используется.
Далее, на этапе тестирования мы подаем на вход более сложные варианты данных, проверяя функцию в различных условиях или сценариях. Итак, на выходе мы получаем уверенность в качестве функции в целом.
«Роль тестировщика не исчезает, она просто эволюционирует»
Насколько тестирование сохраняет свою важность и актуальность в текущих реалиях разработки?
Современные тенденции показывают, что роли тестировщика, разработчика, аналитика и инженера поддержки становятся все менее четко определенными. Специалисты становятся более универсальными. Я бы не сказал, что наступает эра конкуренции за рабочее место с ИИ, но наличие глубоких фундаментальных основ и интеграции знаний различный граней в ИТ однозначно имеет тенденцию на повышение значения. Например, тестировщик сегодня должен владеть навыками аналитика и разработчика, быть способным читать логи и код, а также обладать навыками инженера поддержки, поскольку знание специфики и основ бизнеса клиентов помогает посмотреть на проблему под несколько другим углом, что в свою очередь помогает выявить проблему и предложить варианты решения или обходные пути. Таким образом, роль тестировщика не исчезает, она просто эволюционирует и превращается в нечто более совершенное.
Какие конкретные инструменты и технологии для автоматизированного тестирования вы используете в своей работе сегодня?
Мы используем Selenium. В нашей инфраструктуре используются Jenkins и Selenoid. Для управления версиями мы используем Git. Для сбора отчетов и логов мы применяем Allure. Сборки проектов автоматизации реализованы с помощью Maven или Gradle, в зависимости от предпочтений исполнителя.
Если говорить о тестировании производительности или организации нагрузки, то мы используем JMeter. Все эти технологии, хорошо справляются с поставленными задачами.
В качестве примера успешного применения автоматизации тестирования можно вспомнить ситуацию, которая произошла более года назад. Наши клиенты столкнулись с проблемой некоторой деградации выполнения операций журналирования бизнес-событий на версии 3.5 нашей платформы. Мы подготовили и автоматизировали синтетические тесты, провели несколько циклов сравнительных измерений производительности системы, выявили проблемные места, сформировали рекомендации. В результате в версиях 4.x был оптимизирован интерфейс, часть бэкэнда, и изменена архитектура миграцией на Ignite.
Благодаря дополнительному исследованию, мы также внедрили отдельный сервис работы с историей бизнес-событий на базе ElasticSearch. Этот подход позволил обеспечить возможность горизонтального масштабирования, что в свою очередь улучшает и производительность, и стрессоустойчивость системы в целом. Такой проект, я считаю, успешно демонстрирует возможности автоматизированного тестирования в рамках совместной работы отдела тестирования, разработки и продакт-менеджмента.
«У нас сохраняется место для ручного тестирования»
Как вы определяете, какие тесты подлежат автоматизации, какие остаются для ручного тестирования? Вообще есть ли у вас ручное тестирование?
Да, мы используем ручное тестирование. Мы не поддерживаем подход, когда все без исключения тесты должны быть автоматизированы. Я осведомлен о подходе крупных компаний, где существует убеждение, что роль тестировщика скоро станет устаревшей, и тестирование будут проводить исключительно автотесты, разработанные «разработчиками-в-тестировании». Однако я бы поспорил с таким подходом по нескольким причинам.
Во-первых, автоматизация всех тестов требует значительных затрат времени и средств.
Во-вторых, поддержка актуальности автоматизированных тестов в случае любых изменений в основном продукте также влечет за собой дополнительные затраты.
Добавим к этому сложность найти достаточное количество опытных специалистов по автоматизации на рынке труда, особенно учитывая недавние обстоятельства, а также наличие доли здорового консерватизма — не поглядев и не пощупав нет смысла покупать кота в мешке, какие бы лейблы и надписи на этом мешке не стояли. Поэтому в наших процессах уделяется значительное внимание для ручного тестирования.
В нашем случае, программный продукт представляет собой low-code платформу, на основе которой можно создать великое множество различных решений. Очевидно, что мы физически не можем протестировать все эти варианты. Поэтому мы выбираем определенный набор сценариев, которые являются либо нашими стандартными «коробочными» решениями, либо решениями, разработанными для наших клиентов. В этих сценариях мы определяем ключевые аспекты, которые критически важны для бизнеса конкретного клиента или конкретного стандартного продукта, эти аспекты мы автоматизируем.
Важно знать меру в автоматизации, и мы придерживаемся правила Парето, автоматизируя примерно 20% функционала, которые используют 80% потенциальных и существующих клиентов.
«Каждый член команды — универсальная единица»
Как вы обучаете команду работать с инструментами автоматизированного тестирования?
Наша команда не особенно большая, но все ее члены — специалисты высокого уровня. Мы придерживаемся принципа — лучше меньше, да лучше.
Есть специалисты, которые глубже погружены в определенные области. Каждый из нас обладает уникальными знаниями и интересами, и вместе мы образуем сильную команду, способную решать задачи функционального тестирования, тестирования пользовательского интерфейса, тестирования производительности и нагрузки, а также улучшать разные стороны нашего продукта.
Если говорить об инструментах автоматизированного тестирования, то все достаточно просто: есть совместно согласованный стек технологий и инструментов, а также специалисты, уже умеющие с ними работать. Наставничество и совместное программирование приветствуются. При необходимости состав стека может быть пересмотрен, а наличие онлайн-тренингов и курсов по работе с инструментами делает максимально доступным возможность совершенствования своих навыков. Главное — не лениться.
А как организовано обучение внутри команды?
Конечно, есть система обучения. Когда новый сотрудник присоединяется к команде, даже если это уже опытный специалист, он проходит вводный курс, чтобы ознакомиться с нашей платформой и инструментами автоматизации. За обучаемым закрепляется наставник. Обычно это сотрудник, который последний проходил этот курс — таким образом, мы дополнительно развиваем навыки наставничества и укрепляем взаимопомощь в нашей команде. Есть база знаний, где собраны все необходимые материалы для справки и обучения.
Кроме того, есть эталонный автоматизированный сценарий с готовой библиотекой часто используемых функций. Новые члены команды проводят около недели, разбирая этот сценарий. В рамках тренинга ежедневно проводится сессия ответов наставника на появившиеся вопросы. Если вопросов у обучаемого нет — значит они появляются у наставника.
После этого этапа, каждый специалист начинает работать над своим сценарием или над новой функцией продукта, которая разрабатывается в несколько этапов: подготовки тест-кейсов, ручное тестирование и автоматизация.
«Мы видим, как работа над ошибками влияет на общую успешность продукта»
Как вы оцениваете результаты и эффективность автоматизированного тестирования в вашей команде?
Хоть мы уже достигли значительного прогресса в автоматизированном тестировании, еще многое предстоит сделать. Для оценки эффективности работы команды мы используем определенные ключевые показатели эффективности (KPI), которые связаны, в том числе и с общим ростом эффективности работы компании и доходов.
Я придерживаюсь мнения, что ни один продукт не идеален, и везде можно найти ошибки. Однако, если количество обращений от клиентов снижается, а количество функций продукта увеличивается это, очевидно, говорит о повышении качества и показывает как работа над ошибками влияет на общую успешность продукта.
Стоит заметить, что в Comindware тестирование играет роль третьей линии поддержки. Первые две линии представлены инженерами поддержки, которые ведут конкретных клиентов или группу клиентов. Их задача — реализовать решения на базе нашей платформы, учитывая специфику клиента. В то время как тестирование знает платформу, поддержка знает конкретные решения на ее основе. Если проблема не в решении, то есть не в инструментах настройки решения, скорее всего, проблема в платформе, и вопрос передается нам. Мы проводим исследование, выясняем причины и находим способы решения проблемы. Хочется заметить, что уровень сложности воспроизведения подобных проблем в последнее время значительно вырос, что говорит о росте степени вовлеченности клиента в создание собственных решений и повышение простоты работы с low-code инструментами Comindware Business Application Platform.
Каковы ваши видения будущего автоматизированного тестирования в команде? Как вы боретесь с "ложными срабатываниями" в автоматизированных тестах и как это влияет на процесс тестирования в целом?
В этом году мы разработали новые мобильные приложения, и здесь у нас есть большой потенциал для автоматизации. Ранее мы работали только с мобильным сайтом и автоматизировали его в рамках основного процесса проекта. Но мобильные приложения представляют собой другие технологии и подход.
Когда мы сталкиваемся с ложными срабатываниями в автоматизационных тестах, мы применяем стандартный подход: анализ логов и отладка. Может быть, проблема в инфраструктуре, например, некоторые сервисы не запущены, или проблема может быть в стенде, на котором проводится проверка. Мы также используем Allure для сбора отчетов и логов. Это позволяет нам добавить в отчет скриншот, что часто облегчает решение проблемы. Обычно я просто открываю финальный отчет, смотрю на помеченный красным элемент, смотрю на скриншот и вижу проблему прямо на экране.
«Важно знать меру в автоматизации»
Какие вызовы и проблемы возникают при автоматизированном тестировании, и как вы их решаете?
Здесь есть две главные проблемы: это объем работы и стоимость поддержки. Если проект автоматизации покрывает 100 миллионов тестов, и мы изменили пару кнопок в интерфейсе, то может потребоваться рефакторинг всех этих тестов, поскольку все может начать сыпаться. Важно знать меру в автоматизации и ориентироваться на те элементы, которые с большой долей вероятности не будут меняться в рамках платформы достаточно продолжительное время.
Как видится роль автоматизированного тестирования в Agile и как это влияет на работу вашего отдела? Есть ли новые технологии или подходы, которые вы планируете применить?
У нас есть IT-команда, в которой каждый член может в некоторой степени заменить другого. Каждый знает всё о работе команды. Таким образом, роль автоматизированного тестирования стала менее четкой, однако возможно, что что-то простое превратилось во что-то более сложное. Соответственно, достаточно высокий уровень зарплат в IT повышает уровень требований к работникам, важны не только знания, но и постоянные практические тренировки в различных ролях.
Более того, на мой взгляд, близится время, когда большая часть рутинных операций будет выполняться системами, основанными на базе искусственного интеллекта, что, безусловно, требует повышения планки уровня профессионализма не только в тестировании, но и в ИТ в целом.
Как вы видите использование искусственного интеллекта в тестировании? Возможно ли применение лингвистических генеративных моделей для проведения тестирования, учитывая сложности с приватностью данных, о которых говорят в крупных компаниях?
Тут надо быть очень аккуратным с терминами. Само определение понятия ИИ периодически меняется и расширяется, в зависимости от многих факторов. Например, согласно отчету независимой экспертной группы по искусственному интеллекту, созданной Европейской комиссией (AI HLEG), системы искусственного интеллекта — это разработанные человеком программные системы, которые интерпретируя собранные данные, рассуждая на основе знаний или обрабатывая информацию, полученную из этих данных, принимают решение о наилучшем действии для достижения поставленной цели. То есть, исходя из этого определения, формально, любое более-менее сложное решение, построенное на базе нашей Comindware Business Application Platform, de-facto является системой искусственного интеллекта.
Безусловно, использование искусственного интеллекта в тестировании имеет потенциал. Но, во-первых, это сейчас находится на ранней стадии развития. Нет четко определенных общепринятых правил, ограничений и стандартов использования и обучения подобных систем. Во-вторых, модели и существующие методы обучения ИИ созданы скорее учеными и основаны на научных алгоритмических подходах, а не инженерных. Т.е. нужны не только новые методы, но и инструменты для решения подобного рода задач. В-третьих, вопрос безопасности данных еще не полностью разрешен. Недопустимо раскрывать персональные или конфиденциальные коммерческие данные, даже опосредованно. На мой взгляд, на текущий момент стремление к инновациям и снижению издержек не оправдывают потенциальных рисков и возможных финансовых и репутационных потерь.
Присоединяйтесь к обсуждению темы автоматизации тестирования и применения систем искусственного интеллекта в комментариях, расскажите о вашей личной практике в этой области, новых решениях и инструментах.