Автоматизация процессов тестирования при соблюдении практики непрерывной поставки программного обеспечения должна быть совершенной насколько это возможно. Первое, что приходит на ум, это изменение наполненности программного кода. Но также не стоит забывать и о подсчете количества строк этого кода. Ну и, естественно, никуда не деться от количества тестов, выполняемых при проверке ПО.
Ниже представлены 5 признаков хороших автотестов.
Автотест должен проверять что-то важное
Любой автотест может быть создан для чего угодно, но стоит проверить, что то, что конкретно вы тестируете, реально стоит приложенных усилий. Любой программный код нуждается в технической поддержке, а значит банальное создание тестов ради галочки здесь не подходит.
Небольшой пример того, что не нужно автоматизировать: например, вам дана задача протестировать новую веб-страницу сайта и вы сразу же обнаруживаете, что в заголовке содержится орфографическая ошибка. Вы, скорее всего, тут же заведете баг в трекинг систему, отдел разработки будет его исправлять, а вы затем протестируйте фикс. Какова вероятность того, что ошибка отобразиться по-новой? Наверное, риски не очень высоки, надобности писать автотест на тестирование орфографии нет!
Он не проходит только тогда, когда нужно
Junior QA-инженеры компаний по тестированию ПО порой забывают проверить, что созданные ими тесты не проходят, когда это и ожидается. Если пользовательские тесты выполняются на всех случаях вне зависимости от текущих технических обстоятельств, это отлично выглядит в отчетах, но в самих тестах смысла вообще нет.
Тесты надёжны
Созданный тест должен давать полную информацию из 100% случаев. Данный уровень идеала, может быть, не будет никогда достижимым, но автор теста должен в обязательном порядке к нему стремиться. Нестабильные тесты ни в коем случае не нужно удалять. Никогда в жизни нестабильный тест не сможет дать корректной информации: он не прошел из-за ошибки или потому что нестабилен?
Тесты можно легко поддерживать
Как известно, любой автоматизированный набор тестов, содержащий запутанную программу, крайне трудно поддерживать в техническом плане. При любой редакции программного кода внутри ПО уходит от нескольких часов до пары дней на то, чтобы отредактировать текущий набор тестов. Программный код проверок должен быть чистым, логически организованным, и, конечно же, не повторятся с имеющимися.
Тест мгновенно запускается
Отдел тестирования должен обладать только теми тестами, которые запускаются очень быстро, дабы команда могла сразу понять, если ли сбой и в чём конкретно он кроется. Ускорить процедуру автоматизации можно разными вариантами: например, отдать преимущество API-тестам над классическими UI-проверками, либо же доверится параллельному старту и однократной конфигурации непосредственно перед прогоном вместо настройки перед самим тестом.
Оставить комментарий