Что дает автоматизация тестирования

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

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



    Зачем тестировать


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

    Например, одна из знаменитых “аварий” финансового мира произошла в Первом национальном банке Чикаго в конце 90-х: в одночасье счета клиентов безосновательно выросли на 900 миллионов долларов. Тогда старший вице-президент банка Джеймс Ланкастер признал, что дело в «программной ошибке в компьютере» – которую, к счастью, никто не успел использовать.

    Дорогостоящие ошибки бывают и в других отраслях, казалось бы, не связанных напрямую с IT. Известный пример – аварии при запуске космической техники, в частности, в 2017 году Роскосмос утратил спутник стоимостью 2,6 млрд рублей.

    При работе с масштабными IT-решениями, например, системами дистанционного банковского обслуживания (ДБО), важно постоянно тестировать не только работу отдельных функциональностей, но и их взаимодействие. В условиях сжатых сроков, когда ведущие банки каждый месяц обновляют свои приложения, проверить все вручную невозможно – на это как минимум не хватит времени.

    При создании IT-продуктов для бизнеса обычно сочетают два подхода:

    • осуществляют проверки вручную, с помощью специалистов QA (Quality Assurance);
    • комбинируют ручное тестирование и автоматизацию ключевых тест-кейсов, с помощью экспертов SDET (Software Development Engineer in Test).

    Работа SDET-специалиста находится на границе трех областей – разработки, QA и DevOps, охватывая как непосредственное написание автоматических тестов, так и другие задачи. Например, SDET может настраивать CI для автоматической доставки и разворачивания приложений, вести документацию, организовывать процессы. Однако, в этой статье мы рассматриваем один аспект – автоматизацию тестирования.

    Что дает автоматизация


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

    1. решит все проблемы выпуска качественного ПО;
    2. позволит отказаться от ручного тестирования;
    3. необходима просто потому, что является «крутым трендом»;
    4. ускорит выпуск релизов;
    5. увеличит покрытие платформ и версий операционных систем при тестировании.

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

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

    Когда автоматизация обязательна


    • Масштабное приложение с большим количеством бизнес-функций
    • Значительный срок жизни приложения (от 1 года и более)
    • Внедрение CI/CD, регулярные релизы + небольшое количество QA специалистов

    Задачи автоматизации


    Как правило, мы привлекаем экспертов SDET для решения следующих задач:

    • Автоматизация рутинных и частых проверок, снижение нагрузки на QA специалистов.
    • Контроль основных функций приложения и отслеживание изменений в продукте.
    • Возможность проводить тестирование с большим количеством устройств, версий браузеров и операционных систем.
    • Тестирование производительности приложения в условиях одновременной работы с большим количеством данных и пользователей.

    Результаты


    Автоматизация помогает выстроить баланс:

    • проверять вручную то, что требует человеческого внимания (как правило, до 25% кейсов);
    • автоматизировать остальные кейсы.

    При этом автоматизация в долгосрочной перспективе снижает как расходы на тестирование, так и риски, связанные с человеческим фактором.

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

    Бизнес, благодаря автоматизации, получает возможность в любое время убедиться в том, что ключевые функции системы работают правильно и проверить, нет ли ошибок (а если они есть, то в чем заключаются).

    Пример


    Предположим, что на текущий момент в мобильном банке нужно проходить до 700 кейсов, каждый – от 70 до 100 раз в год. Ручной проверки требуют менее 25% кейсов, остальные 75% можно автоматизировать.

    Затраты времени при ручной проверке:

    — 30 часов

    Затраты времени при автоматизации:

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

    Прочие затраты времени:

    • 8 часов на ручную проверку кейсов, которые нельзя покрыть автотестами (25%);
    • 6 часов на анализ результатов, а также, если необходимо, на проверку отказов (до 10% тестов).

    Итого: автоматизация тестирования позволяет снизить затраты времени с 30 до 14 часов.

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

    В среднем, автоматизация экономит от 30 до 50% времени как минимум, позволяя выделить больше времени, например, на развитие и улучшение продукта.

    Как происходит автоматизация тестирования


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

    Процесс тестирования начинается с разработки стратегии – тест-плана, основы для составления отдельных тест-кейсов. Для автоматизации SDET инженеры выбирают ключевые, часто используемые сценарии работы пользователя с продуктом – такие сценарии дают около 80% бизнес-ценности.

    После этого мы создаем основу для дальнейших автотестов, настраиваем стенды и workflow по работе с ними, CI для регулярного запуска тестов на различных ветках. Мы выбираем, какие подходы к подготовке тестовых данных мы будем использовать (API, доступ к базам данных, генерация синтетических данных, использование данных с прода). Инженеры SDET пишут тесты, которые покрывают ключевые сценарии работы с продуктом, анализируют полученные результаты и необходимость дальнейшей автоматизации.

    Мы разрабатываем автоматизированные тесты, используя все наиболее востребованные языки программирования – Java, Python, Kotlin и др. Наши основные инструменты и технологии – Appium, TestNG | JUnit, RobotFramework | Pytest, Selenium | Senenide, Allure, TeamCity, Jenkins, JMeter.

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

    Мы в своей практике выстраиваем процессы автоматизации тестирования уже на старте разработки, параллельно с ручным тестированием. Эта работа – не единоразовая, она ведется непрерывно, особенно на крупных проектах, в том числе банковских.

    Подводя итоги


    Баланс ручного и автоматизированного тестирования позволяет постоянно контролировать качество IT-продукта. Некоторые проекты проверяют вручную, другие задачи можно успешнее решить с помощью автоматизации. Тестирование вручную используют в тех случаях, когда люди незаменимы, например, если нужна локализация, описание ошибок, ручная проверка юзабилити. В небольших проектах часто тесты пишут сами разработчики.

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

    Спасибо за внимание! Надеемся, что статья была вам полезна!
    SimbirSoft
    59,75
    Лидер в разработке современных ИТ-решений на заказ
    Поделиться публикацией

    Комментарии 7

      0
      Спасибо за статью.
      У меня есть пара вопросов по статье и по организации работы:
      1. Подскажите пожалуйста в статье не упоминания о unit тестах, как и в каком объеме они у вас используются, и влияют ли на конечное количество сценариев UI и API тестов?
      2. Очень интересно какие вы используете среды запуска тестов, например тестирование в облаке, тестирование в докер контейнерах. Как при этом выглядит кроссплатформенное и кроссбраузерное тестирование?
      3. Вы писали «Для автоматизации SDET инженеры выбирают ключевые, часто используемые сценарии работы пользователя с продуктом» — можете подсказать, на основе чего идет выбор сценариев для автоматизации, берутся частые баги из трекера, берутся строгие сценарии из документации, либо происходит еще какое-то внутреннее согласование с аналитиками проекта/ручными тестировщиками?
        0
        Спасибо!
        1. Чаще всего unit-тесты пишут и сопровождают разработчики. Специалисты направления SDET не разрабатывают и не используют в процессах автоматизации тестирования unit-тесты, реализуя независимое тестирование.
        2. Для запуска тестов мы используем и различные тестовые окружения-стенды, и докер-контейнеры. Кроссплатформенность можно реализовать через разведение по различным окружениям, а кроссбраузерность — на уровне кода автотестов с использованием параметризации, либо с использованием контейнеров.
        3. В первую очередь выбираем самые часто используемые сценарии использования со стороны пользователей (например — авторизация, добавление товара в корзину), затем идут сложные (для воспроизведения) или длительные (по времени выполнения) сценарии, и так далее. Приоритеты выставляем по согласованию со специалистами QA, тимлидом, product owner.
        0

        Да, до этих штучек мастер этот самый Джеймс Ланкастер.

          0
          Да, действительно автотесты существенно повышают качество продукта, при этом трудозатраты на проверку в перспективе снижаются. В случае ночных тестов экономится ещё и время. А с формальной верификацией не разбирались?
            0
            Как правило, мы используем методы тестирования
            0

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

              0
              Да, в примере мы рассматриваем не разработку тестов, а непосредственно их проведение. Кстати, ниже мы отметили, что время на поддержку тестов тоже учитываем)

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое