Нужны ли бизнесу тестировщики и как оценить качество их работы? Что обсуждали на конференции CodeTalks
16 ноября в Алматы прошла конференция для ИТ-специалистов CodeTalks. Кроме докладов, на мероприятии были «Квартирники» — панельные дискуссии с экспертами, которые обсуждали волнующие темы индустрии. Один из «Квартирников» был посвящен реальным историям из жизни QA-инженеров. В качестве спикеров выступали специалисты из Авито, Dodo Engineering и Home IT — казахстанской компании, которая разрабатывает мобильные и веб-приложения для крупного бизнеса в сферах fintech, страхования, e-commerce и телекоммуникаций.
Одним из экспертов панельной дискуссии как раз стал герой материала Digital Business — руководитель отдела тестирования МСБ Home IT Дмитрий Ремезов. Он поделился своим мнением насчет тестирования цифровых продуктов.
В каких проектах нужны QA-инженеры?
Через всю дискуссию красной нитью проходил вопрос — можно ли заменить QA-специалистов автоматическими тестами, написанными разработчиками? Андрей Аксенов — разработчик движка Sphinx в Авито — продвигал позицию, что тестировщики в компании вовсе не обязательны, а Дмитрий Тучс из Dodo Engineering, наоборот, активно защищал важность работы QA-инженеров.
Руководитель отдела тестирования МСБ Home IT Дмитрий Ремезов
Дмитрий Ремезов считает, что все зависит от продукта, который разрабатывает компания:
— Есть такие проекты, где без QA-инженеров можно обойтись. Например, если разрабатываете СУБД — систему управления базами данных. Вся ее работа сводится к тому, чтобы выполнить запрос, который отправляет другая программа. Все сценарии предсказуемы, поэтому проверить корректность работы СУБД можно с помощью юнит-тестов, которые пишут сами разработчики.
Другое дело, если нужно проверить то, что связано с поведением реального человека. Например, если кнопка сместилась и в результате пользователь не может совершить нужное действие, автоматические тесты здесь не помогут. Поэтому некоторые кейсы нужно тестировать вручную.
Так в Home IT мы располагаем парком как мобильных устройств, так и ноутбуков на разных платформах. Соответственно, в рамках ручного тестирования можем покрыть большое количество различных кейсов. Однако практикуем и автоматизацию тестирования на разных уровнях. Обязательное требование для наших разработчиков — покрытие кодовой базы unit-тестами. Также для уменьшения времени регрессионного тестирования используем UI и интеграционные автотесты.
Как оценить качество работы тестировщиков
После обсуждения востребованности QA-инженеров эксперты перешли к другому вопросу — как понять, насколько эффективно тестировщики справляются с задачами и приносят пользу проекту?
— В тестировании есть общепринятые метрики. Например, количество инцидентов в продакшене — число багов, которые все-таки попали в финальную версию продукта и были выявлены пользователями. Чем меньше таких случаев, тем качественнее провели тестирование.
Важно учитывать и обратную связь от пользователей: оценки и отзывы в приложении, комментарии на форумах или в социальных сетях. Эти данные помогают понять, насколько продукт удобен и соответствует ожиданиям аудитории, — объяснил Дмитрий Ремезов.
Все инциденты заводятся в баг-трекинговую систему, включая категоризацию по бизнес-направлению и типу ошибки. Ежедневно команда мониторинга проводит анализ и составляет отчет по этим ошибкам, который становится вводными данными для команд разработки.
В своей работе мы постоянно смотрим на метрику Voice of client из сторов мобильных систем. У нас есть цель — поддерживать данный показатель на уровне 4,8 и выше.
Что лучше для бизнеса: ручное или автоматическое тестирование
В ходе дискуссии эксперты обсудили вопрос, на который в индустрии уже много лет не могут найти однозначный ответ, — можно ли полностью автоматизировать тестирование?
Дмитрий Ремезов отметил, что, выбирая тип тестирования, важно учитывать бизнес-модель компании — аутсорс или продуктовую. В аутсорс-проектах часто сжатые сроки и ограниченные бюджеты. Автоматизация же требует времени на внедрение — нужно разработать тестовые сценарии, настроить инфраструктуру для их запуска, адаптировать тесты под изменения в продукте. В случае, когда нужно быстро создать MVP и передать клиенту, автоматизация может быть экономически невыгодной.
В продуктовом бизнесе автоматизация, напротив, приносит долгосрочную выгоду. Продукт развивается и обновляется годами, а автоматические тесты помогают быстро проверять стабильность системы при каждом изменении, ускорять выпуск новых версий, каждая из которых улучшит качество продукта.
