Миру нужно все больше программного обеспечения: любому магазину или автосервису нужен сайт или мобильное приложение.
Но никому не нужно программное обеспечение с ошибками; нам нравится, когда все работает красиво и правильно.
Тестирование помогает эффективно находить ошибки, причем иногда это происходит автоматически.
Именно об этом случае мы и поговорим.
Качество разрабатываемого продукта, конечно, зависит от всей команды, но выделим тестирование, я это понимаю.
Меня зовут Дмитрий Ремезов, я QA-инженер в компании «Технократия», и в этом тексте я познакомлю вас с автоматизированным тестированием: когда оно поможет, а когда от него стоит отказаться.
Я приведу список плюсов и минусов подхода, а в конце опишу проект, который обязательно требует автоматизации.
Автотесты - инструмент
Мы, тестировщики, хотим переложить бремя регрессии на плечи автоматизированных тестов.Однако автоматизация тестирования — не панацея, а инструмент. А чтобы инструмент работал и приносил прибыль, его нужно сначала правильно выбрать, а затем не забывать его обслуживать и иногда заменять на новый – более качественный.
Следующее предупреждение – бывают спорные случаи, поэтому к процессу автоматизации следует подходить вдумчиво.
Может случиться так, что преимущества автоматизированного тестирования не смогут покрыть затраты, затраченные на этот процесс.
Давайте подробнее рассмотрим такие случаи.
Тестирование макета
Клиенты и пользователи смотрят на приложение глазами, поэтому красивый, качественный интерфейс играет важную роль.Но разные браузеры, их обновления, обновления фронтенд-библиотек могут нарушить нашу красивую верстку.
Это может повлиять на приложение только визуально и даже заблокировать его функциональность.
Например, вот так.
Магазин одежды предлагает познать боль.
Нельзя отрицать плюсы в виде появления нового мема и увеличения посещаемости сайта.
Но есть и более серьезные проблемы.
Недавно я сменил телефон.
Мой предыдущий аппарат имел маленькую диагональ.
В конце месяца зашёл в интернет-банк, чтобы обновить категории кэшбэка, но нужная мне позиция была под футером и не пролистывал - не смог выбрать эту позицию.
Такая проблема является поводом для возмущения пользователей, плохой технической поддержки, ухода части пользователей и понесения убытков.
Из этого экономит тестирование .
Давайте рассмотрим средний проект. у нас есть:
- несколько различных разрешений экрана
- две популярные ОС
- несколько браузеров в сети.
Давайте автоматизировать В идеальном мире всё выглядит так: выбираешь фреймворк, тратишь время.
Автотестер нажимает кнопку, и программа сама начинает тестирование.
Выгода! Но ждать.
В настоящее время приложения со стабильным, неизменяемым интерфейсом встречаются редко.
Чтобы пользователь не заскучал и не привык к нему, менеджеры и дизайнеры часто проводят редизайны и обновляют интерфейсы.
К этому мы добавляем частые обновления UI-китов, выпуск новых устройств с новыми типами экранов — iPhone и новых MacBook с челкой — обновление подключаемых библиотек и обновление браузеров.
Получается удручающая картина.
Помните, я говорил, что тестирование — это инструмент? А значит, автотесты верстки придется постоянно обновлять.
А это не всегда легко и быстро.
Это необходимо иметь в виду.
Эимитация сбоя сервера
Это следующий случай.В чем смысл? У нас микросервисная архитектура, и мы хотим проверить, как поведет себя приложение в случае сбоя одного из сервисов.
По-хорошему, при сбое какой-либо службы приложение не должно аварийно завершить работу:
- Пользовательский интерфейс должен отображать экран прогнозируемой ошибки.
- Трассировка стека не должна вылетать вперед.
- Сообщение о сбое сервера должно регистрироваться в журналах и системах мониторинга.
Тестер получает доступ к серверам.
Руками через терминал вы «опускаете» нужную услугу.
Затем он смотрит, как приложение ведет себя в этой ситуации.
Другой вариант — развернуть все локально, использовать сниффер для установки точек останова и эмулировать сбой сервера.
Что сделает автотестер в этой ситуации?
Будет ли он писать сценарии с указанием титров? Это поднимает вопрос безопасности.Развертывание безопасной инфраструктуры тестирования — это процесс, требующий навыков и усилий.
Использовать макеты? Правильный макет предполагает тестирование «белого ящика», что не всегда под силу инженеру по автоматизации и требует помощи разработчика.
Я даже не рассматриваю возможность проведения тестов локально, поскольку мы все стремимся к CI с помощью тестов.
Поднятие такого стенда на отдельной виртуальной машине опять-таки требует дополнительных ресурсов и, возможно, помощи девопса.
Опять же злоупотребление моками и заглушками негативно влияет на качество автотестов.
Об этом написано много статей.
Так что давайте не зацикливаться на этом.
Родные окна браузера
Именно здесь вы можете открыть ортопедический салон.С ними все знакомы: они постоянно вылетают и просят разрешения на действие, уведомляют о возможных проблемах или предлагают сохранить кредиты.
Сколько обсуждений в Интернете, сколько собственных костылей, сколько усилий разработчиков фреймворка.
И вроде бы всё ясно и понятно, но каждый раз сталкиваешься с этим, и не всегда можешь справиться.
Приведу пример из собственного опыта.
Недавно перешёл в новый проект. На стенде банальная блок-схема: кнопка обращения в техподдержку.
После нажатия открывается новая вкладка с номером телефона и заполнителем, которые зависят от региона, введенного пользователем при регистрации.
Необходимо было проверить, что отображается правильный номер телефона и заполнитель.
Но есть нюанс, как в анекдоте, да.
При открытии новой вкладки появляется собственное окно.
Он предлагает открыть программное обеспечение по умолчанию, чтобы совершить звонок.
И это родное окно блокирует дальнейшие действия на странице, и я не могу на него нажать, могу только закрыть вкладку.
Я разволновался и провел 3 дня.
Но я так и не решил.
В итоге я проверил ссылку, прикрепленную к кнопке, а проверку заглушки оставил на ручное тестирование.
Как вы думаете, в чем смысл этого примера? Вам нужно рассчитать свое время и силы.
Я потратил много времени, но так и не добился ничего.
Но он мог остановиться раньше.
Пока вы работаете над проблемой, которую не можете решить, вы можете написать несколько других тестов, которые уже принесут пользу проекту.Я уже говорил, что не все однозначно..
Автоматизация имеет плюсы и минусы.
Вот так они выглядят, на мой взгляд. Плюсы:
- Исключение человеческого фактора: автоматизированные тесты не устают, не страдают от рассеянного внимания и не могут пропустить ошибку после ссоры с женой.
Для них вполне нормально работать 24/7.
- Скорость.
Гораздо быстрее, чем ручное тестирование.
- Многопоточность.
Человек не может, но автотесты могут параллельно тестировать разные среды, применять разные настройки или поднимать неограниченное количество пользователей.
- Автотесты требуют обновления.
Выпуск новых функций может повлиять на функциональность приложения, что делает тесты неактуальными.
Время обновления автотестов прямо пропорционально количеству тестов.
- Автоматизация тестирования не гарантирует 100% обнаружения дефектов.
Программа работает в узком заданном потоке.
То, что написано в коде, пройдет проверку.
При этом человек может обратить внимание на некоторые моменты, которые идут не так, но не включены в тестовый пример.
- Тем не менее, есть случаи, которые невозможно автоматизировать.
Пока.
Исследования в области искусственного интеллекта идут полным ходом, так что ждем.
- Автоматизация тестирования требует квалифицированного специалиста и значительных трудозатрат на старте.
Однако если все идет гладко и по плану, то использование автотестов практически бесплатно.
Однако если подход или планирование неверны, затраты на автоматизацию могут не окупиться.
- Чтобы автоматизация проекта не стала узким местом в зависимости от одного сотрудника, который его написал, нужно разработать общедоступные стандарты в отделе тестирования, стиль кодирования и использовать одни и те же инструменты автоматизации.
Такая система гарантирует текучесть специалистов, ведь отпуска, больничные и увольнения никто не отменял.
Однако внедрение каких-либо новых инструментов становится сложно осуществимым, поскольку требует переработки стандартов и обучения персонала.
- Регрессия требует больших человеческих и временных затрат. Если проект разросся до такой степени, что для проведения регрессии требуется отдельный отдел тестирования, или регрессия занимает более 50% спринта, то это тревожный сигнал для внедрения автоматизации.
- У проекта нет возможности отказаться от поддержки старых версий ПО.
Возможность запуска автотестов в многопоточном режиме решит эту проблему. - Видно влияние человеческого фактора .
Из-за усталости, «замыленности глаз» или нехватки времени на производство начали вытекать баги.
Есть дела, которые пока нельзя автоматизировать, дела, которые нужно автоматизировать, и спорные дела.
То есть не сразу очевидно, будет ли от них польза.
Как можно решить, автоматизировать эти дела или нет?
- Это должен делать квалифицированный тестировщик, который знает, как это сделать и сколько времени это займет. Примерно рассчитать трудозатраты перед внедрением какого-либо функционала — это своего рода искусство, которому тоже нужно учиться.
- Вам необходимо понимать, на каком этапе находится рассматриваемая функция.
Рассчитайте риски, связанные с гибкой методологией разработки.
- Регулярно рассчитывайте коэффициент рентабельности инвестиций.
Есть разные методы расчета, но мне нравится формула: доходы разделить на расходы.
А если коэффициент меньше или равен единице, то от этой автоматизации нет толку.
- Не забывайте о пирамиде автоматизации тестирования.
Нет смысла спешить с покрытием UI, если нет автоматизации тестирования API.
Примеры, которые я привел, можно покрыть автотестами.
Хочу сказать, что к автоматизации тестирования нужно подходить вдумчиво.
Вам нужно постараться, чтобы ваша работа приносила максимальную пользу, а не увязла в каких-то сложных задачах.
Так что автоматизируйте осмысленно! Да пребудет с тобой сила!
Также подписывайтесь на наш телеграм-канал «Голос Технократии» .
Каждое утро мы публикуем дайджест новостей из мира IT, а по вечерам делимся интересными и полезными шедеврами.
Теги: #Тестирование веб-сервисов #Тестирование мобильных приложений #Тестирование ИТ-систем #автотестирование #автотесты #тестирование ПО #тестирование веб-приложений #автотест
-
Поисковая Оптимизация – Забытые Правила
19 Oct, 24 -
Перенос Данных Из Visionflow В Servicenow
19 Oct, 24 -
Впф 4.0. Что Нового? Часть 5
19 Oct, 24 -
Навигация По Страницам В Php
19 Oct, 24 -
Сми В Интернете, Это Www?
19 Oct, 24
