Переформулирую, пожалуй – зачастую автоматизация кажется очень простой штукой.
Когда вы смотрите на первое демо, или запускаете свой первый автотест, вы чувствуете себя волшебником . Ого-го! Это так круто! Хотел бы я уметь печатать так быстро!
Но хорошая автоматизация сильно отличается от этого вашего первого запуска.
Представьте, что вы гуляете по огороду и видите на ветке спелый фрукт, призывно манящий вас. Вы срываете его, думая, что это же так круто – одно простое движение, и в вашей руке что-то красивое и вкусное.
Однако хорошая автоматизация – это скорее организация этого огорода, позволяющего прокормить небольшой городок.
Привет! В вашей компании наверняка есть автотесты в той или иной форме, которые делают работу за вас.
Они экономят вам время, правда?
Эээ... не всегда.
Чем больше команд переходит на DevOps, тем очевиднее становится необходимость автоматизировать автотесты.
Просто необходимо стартовать автотесты автоматически, при соблюдении определенных условий, и получать отчет о том, прошли тесты или нет, чтобы определиться с последующими действиями.
Этот процесс называется "непрерывная интеграция" (CI) или "непрерывная разработка" (CD).
Эти понятия используются как синонимы. Вот и я туда же. Важно подчеркнуть, что это всегда непрерывный процесс.
Где-то я видел утверждение, что тестирование на данный момент поглощает около 25% бюджета IT, и эта доля растет. Не знаю, правда ли это, но даже если это полуправда - это очень большие деньги. Вполне естественно, что менеджеры и финансисты стараются изыскать возможность сократить подобные расходы.
Тестирование и качество - это неосязаемые вещи, и непрофессионалу трудно вникнуть в их суть. Потому-то идея урезать расходы на них так привлекательна, ведь мы ничему не навредим – ну, протестируют наполовину, но протестируют же? Когда появятся проблемы, отследить их связь с урезанным бюджетом уже не так-то просто (а бюджет уже согласован и утвержден). К тому же все мы знаем, что тестировщикам лишь бы поныть и пожаловаться на жизнь.
Поэтому автоматизация тестирования преподносится менеджерам (в большинстве случаев не имеющим к тестированию никакого отношения), как эротичная модель в купальнике из глянцевого журнала. Блага, которые предлагает автоматизация, просты и понятны:
Экономия денег: успеете больше, наняв меньше людей
Сокращение сроков: протестируете продукт быстрее.
Простота: этим может заниматься кто угодно (особенно если вы снабдите этого "кого угодно" специнструментами, отправите на тренинги и купите у нас еще что-нибудь).
За автоматизацией будущее! Вы же не хотите, чтобы вас поймали на отсутствии автотестов?
Запись и воспроизведение тестов (этот аргумент помер еще в конце 90-х, но все равно иногда всплывает).
Тестировщик, научись автоматизировать или вон из профессии!
Гибкие методологии невозможны без автоматизации.
Непрерывная интеграция и деплой невозможны без автоматизации.
Это передовой опыт!
Единороги и радуги! Хотя нет, такого аргумента я не видел... пока что.
Я хочу обсудить, пожалуй, самую знаменитую из устаревших концепций тестирования. Кто-то говорит о ней с восторгом, а кто-то не очень понимает, о чем речь. Зачастую ее недопонимают или применяют неправильно, и поэтому она, наверное, лучший кандидат на вышедшие из моды концепции тестирования, которые имеет смысл обсуждать. Так поговорим же про автоматизацию тестирования!
Прежде чем начать разговор
Под автоматизацией я – лично я – понимаю автоматизированное выполнение какого-либо действия. Соответственно, автоматизированное тестирование для меня – это автоматизация действий, помогающая процессу. Подчеркиваю: под автоматизацией я понимаю только это, а не автоматизацию процесса тестирования как такового. Я сознательно не прибегаю к термину "проверка", чтобы не удариться в долгую дискуссию про "тестирование" и "проверки" - я просто не готов поддержать этот спор в данный момент. Если вам интересна эта тема, прочитайте статью Испытания и проверки: уточнения" Майкла Болтона и Джеймса Баха - это потрясающая работа, я согласен с многими идеями в статье и рекомендую ее всем заинтересованным.
Посещая недавно прошедшие конференции, я осознала, что люди задают неправильные вопросы, когда речь заходит об автоматизации. Прошедший ISTQB-опрос звучал как "Как много (какой процент) тест-кейсов вы автоматизируете?". После своего доклада по автоматизации я беседовала с участницей конференции, которая сказала мне, что ее менеджер задавал ей тот же вопрос, и она не знала, что ему сказать. Она не одинока. Менеджеры часто задают этот вопрос. Ответить на него трудно, потому что это неверный вопрос.
Почему люди спрашивают об этом? Возможно, им нужна информация о прогрессе автоматизации, особенно если она только внедряется. Не то чтобы это необоснованный интерес, но это плохой вопрос - он основан на ряде неверных допущений:
Неверное допущение номер 1. Все ручные тест-кейсы должны быть автоматизированы.
Публикуем подборку докладов с SQA Days-18, посвященных автоматизированному тестированию.
"Внедрение автоматизации" прохождение на различных уровнях сложности – доклад Владимира Худойкина о том, как внедрять автоматизацию в командах с различным внутренним устройством.
Docker + Selenium Webdriver в рамках Continuous Integration – доклад Антанаса Мачярниса о создании инфраструктуры запуска автотестов.
Оценка качества автотестов – доклад Алексея Баранцева о том, какими должны быть качественные автотесты.
Keep it calm and functional. Автотесты для iOS приложений – доклад Марии Трофимовой о трудностях и тонкостях автоматизированного тестирования iOS-приложений.
Автоматизация визуального тестирования адаптивного дизайна на примере Galen Framework и Applitools Eyes – доклад Дарьи Кисель о тестировании визуальных регрессий.
Автоматизированное тестирование верстки веб-сайтов, используя сравнение с дизайн-макетом – доклад Эмиля Хуснетдинова о тестировании digital-проектов.
Архитектура автоматизированных тестов: представление предметной области – доклад Екатерины Бобровой.
Selenium, а давай подождем? – доклад Сергея Матвеева о механизмах ожидания Selenium и том, как с ними работать.
20-21 мая 2016 г. в Санкт-Петербурге пройдет 19-я международная конференция в области обеспечения качества ПО «Software Quality Assurance Days».
Наши читатели при регистрации на конференцию могут получить скидку.
Автоматизированные тесты -- это программный продукт. И как для любого другого программного продукта, для автотестов можно сформулировать требования к качеству, выработать критерии для оценки их качества, ну и проверить, удовлетворяются ли эти требования. Вот об этом я и хочу рассказать в своём докладе -- какими должны быть качественные автотесты.
Выступление Андрея Иваровского на онлайн-конференции для специалистов по автоматизации тестирования Auto ConfeT&QA, весна 2013 года
При автоматизации тестирования веб-приложений часто возникают трудности с распознаванием элементов.
Веб-элементы могут не распознаваться, у них могут меняться идентификационные свойства.
Это, пожалуй, самые распространенные проблемы, возникающие при взаимодействии инструмента автоматизации с веб-интерфейсом приложения.
Однако самая серьезная проблема возникает, когда имеется много веб-элементов, много тестов и функционал приложения часто меняется.
В этом случае на поддержку автотестов могут потребоваться значительные затраты времени. Уж лучше протестировать руками.
Как оптимизировать распознование элементов так, чтобы не тратить столько времени на поддержку? Как вдохнуть жизнь в ваш тестовый фреймворк? Как же сделать так, чтобы автоматизация тестирования вновь обрела смысл на проекте?
Зачем тестировщику-автоматизатору учить теорию? Может быть достаточно освоить какой-нибудь популярный инструмент, например, Selenium или TestComplete? Выучить какой-нибудь язык программирования, например, Java или Python? И никакая теория не нужна.
Но подождите! Раз уж зашла речь о программировании ("выучить какой-нибудь язык") -- давайте посмотрим, как там обстоят дела с теорией.
Обучение программированию начинается с понимания того, что такое алгоритм. Базовые элементы описания алгоритма одинаковы для множества языков программирования. И если человек один раз понял, что такое условие и что такое цикл -- он сможет узнать их под разными масками в разных языках программирования.
После этого, конечно, хорошо бы уже научиться писать на каком-нибудь языке, чтобы эти теоретические знания об алгоритмах применить на практике.
Но через некоторое время оказывается, что помимо алгоритмов языки содержат конструкции для описания классов -- и тогда приходится снова возвращаться к теории, чтобы понять суть объектно-ориентированного подхода. Это тоже достаточно универсальная идея, которая применяется во многих языках программирования, хотя может выглядеть очень по разному.
Освоив принципы работы с классами и объектами, человек получает в руки новый мощный инструмент. Он уже не только алгоритмы пишет, он строит архитектуру приложения. Это позволяет писать более сложные программы.
Но ещё через какое-то время выясняется, что архитектура местами получается какая-то кривая, костыли подпирают её тут и там. И приходится снова возвращаться к теории -- читать книжки про шаблоны проектирования, изучать типовые приёмы, учиться избегать стандартных ошибок проектирования.
И эти колебания от теории к практике и обратно могут повторяться многократно. Потому что есть ещё много интересного, выходящего за рамки отдельно взятого языка программирования.
А когда вы разрабатываете автоматизированные тесты -- к общей теории программирования добавляется ещё и специфическая дополнительная теория.
Выступление Игоря Хрола на онлайн-конференции Selen ConfeT&QA
UI-автотесты не отличаются высокой надёжностью. Где-то может не хватать синхронизации и тесты будут «падать» время от времени просто так. Или фокус «слетел» и кнопка не нажалась. Эти и другие случаи зачастую делают результаты автотестов непредсказуемыми и не вызвающими доверия.
В докладе хотелось бы поделиться опытом того, как пожертвовав целью 100%-но точной эмуляции действий пользователя, можно добиться надёжных и воспроизводимых результатов от Selenium-тестов. Разговор будет основан на опыте использования данной идеи на одном из проектов, а также будут даны общие рекомендации, применимые для широкой аудитории.
