Автоматизированные тесты -- это программный продукт. И как для любого другого программного продукта, для автотестов можно сформулировать требования к качеству, выработать критерии для оценки их качества, ну и проверить, удовлетворяются ли эти требования. Вот об этом я и хочу рассказать в своём докладе -- какими должны быть качественные автотесты.
Выступление Андрея Иваровского на онлайн-конференции для специалистов по автоматизации тестирования Auto ConfeT&QA, весна 2013 года
При автоматизации тестирования веб-приложений часто возникают трудности с распознаванием элементов.
Веб-элементы могут не распознаваться, у них могут меняться идентификационные свойства.
Это, пожалуй, самые распространенные проблемы, возникающие при взаимодействии инструмента автоматизации с веб-интерфейсом приложения.
Однако самая серьезная проблема возникает, когда имеется много веб-элементов, много тестов и функционал приложения часто меняется.
В этом случае на поддержку автотестов могут потребоваться значительные затраты времени. Уж лучше протестировать руками.
Как оптимизировать распознование элементов так, чтобы не тратить столько времени на поддержку? Как вдохнуть жизнь в ваш тестовый фреймворк? Как же сделать так, чтобы автоматизация тестирования вновь обрела смысл на проекте?
Зачем тестировщику-автоматизатору учить теорию? Может быть достаточно освоить какой-нибудь популярный инструмент, например, Selenium или TestComplete? Выучить какой-нибудь язык программирования, например, Java или Python? И никакая теория не нужна.
Но подождите! Раз уж зашла речь о программировании ("выучить какой-нибудь язык") -- давайте посмотрим, как там обстоят дела с теорией.
Обучение программированию начинается с понимания того, что такое алгоритм. Базовые элементы описания алгоритма одинаковы для множества языков программирования. И если человек один раз понял, что такое условие и что такое цикл -- он сможет узнать их под разными масками в разных языках программирования.
После этого, конечно, хорошо бы уже научиться писать на каком-нибудь языке, чтобы эти теоретические знания об алгоритмах применить на практике.
Но через некоторое время оказывается, что помимо алгоритмов языки содержат конструкции для описания классов -- и тогда приходится снова возвращаться к теории, чтобы понять суть объектно-ориентированного подхода. Это тоже достаточно универсальная идея, которая применяется во многих языках программирования, хотя может выглядеть очень по разному.
Освоив принципы работы с классами и объектами, человек получает в руки новый мощный инструмент. Он уже не только алгоритмы пишет, он строит архитектуру приложения. Это позволяет писать более сложные программы.
Но ещё через какое-то время выясняется, что архитектура местами получается какая-то кривая, костыли подпирают её тут и там. И приходится снова возвращаться к теории -- читать книжки про шаблоны проектирования, изучать типовые приёмы, учиться избегать стандартных ошибок проектирования.
И эти колебания от теории к практике и обратно могут повторяться многократно. Потому что есть ещё много интересного, выходящего за рамки отдельно взятого языка программирования.
А когда вы разрабатываете автоматизированные тесты -- к общей теории программирования добавляется ещё и специфическая дополнительная теория.
Выступление Игоря Хрола на онлайн-конференции Selen ConfeT&QA
UI-автотесты не отличаются высокой надёжностью. Где-то может не хватать синхронизации и тесты будут «падать» время от времени просто так. Или фокус «слетел» и кнопка не нажалась. Эти и другие случаи зачастую делают результаты автотестов непредсказуемыми и не вызвающими доверия.
В докладе хотелось бы поделиться опытом того, как пожертвовав целью 100%-но точной эмуляции действий пользователя, можно добиться надёжных и воспроизводимых результатов от Selenium-тестов. Разговор будет основан на опыте использования данной идеи на одном из проектов, а также будут даны общие рекомендации, применимые для широкой аудитории.
Сделать побольше, потратить поменьше, тестировать одновременно и быстро, и качественно – вот задача современных компаний. Бизнес требует высоких скоростей разработки, внедрения новых возможностей и исправления дефектов, и качество продукта не должно при этом пострадать. Однако время- и трудозатратное ручное тестирование несравнимо по точности с автоматизированными тестами – и значит, настало время познакомить вашу команду с преимуществами автоматизации
"Единственный способ принять перемены - это погрузиться в них, осознавать их, двигаться в танце с ними" - Алан Уоттс.
Все хоть раз в жизни проходили собеседование. К нему нужно готовиться! Первые минуты собеседования могут стать решающими в вопросе, возьмут ли вас на работу. Почему? Да потому, что первое впечатление - всегда самое сильное. Никогда не недооценивайте силу первых впечатлений. Используйте аналогичный подход при внедрении автоматизации в команде ручных тестировщиков. Считайте, что презентация нового подхода вашей команде или организации - это собеседование. Тщательно подготовьтесь к нему. Оправдайте ожидания команды, разъясните им их новые обязанности - это очень важно, потому что люди склонны эмоционально реагировать любые потенциальные угрозы их работе.
Выступление Дмитрия Миндры на онлайн-конференции для специалистов по автоматизации тестировния Auto ConfeT&QA.
Разработка через тестирование (TDD) известна уже более 10-ти лет. Эту практику применяют десятки тысяч разработчиков. Есть масса успешных примеров, и при этом масса людей, не верящих в эффективность разработки через тестирование. Также есть заблуждение о том, что TDD заменяет работу тестировщика. При этом TDD – это всего лишь один из инструментов разработчика, решающий определенные задачи. Данный доклад является быстрым введением в TDD, который даст вам представление о нем, а также о популярных заблуждениях и мифах.
Многим знаком инструмент Selenium. Это стандарт de facto (а вскоре и de juro) в области автоматизации веб-приложений и мобильных приложений. Невероятно популярный инструмент. Но удивительно то, что Selenium развивается без чёткого плана. С одной стороны, это вполне объяснимо – команда разработки представляет собой группу энтузиастов, работающих над проектом в свободное время. С другой стороны, непонятно, почему коммерческие вендоры не могут повторить этот успех. Вот вы верите в то, что такое возможно?
Автоматизация в тестировании применяется гораздо шире, чем может показаться на первый взгляд. Этим занимаются не только специально назначенные люди, у которых на бейджике (или на лице) написано "автоматизатор". В традиционно "ручном" тестировании автоматизация тоже встречается, пусть и в меньшем количестве.
Посмотрите небольшой видеоролик "Автоматизация в тестировании", записанный Алексеем Баранцевым, а потом посмотрите вокруг -- есть вероятность, что вы активно используете автоматизацию, даже не задумываясь об этом!
А если задуматься и подойти к этому осознанно, не окажется ли внезапно, что сфера применения автоматизации в вашей повседневной работе может быть расширена, иногда даже без приложения сколь-нибудь значительных усилий?
У пользователей Selenuim WebDriver нередко возникает вопрос -- почему Selenium не дожидается завершения загрузки страницы? А иногда, наоборот, пользователи жалуются, что Selenium ждёт слишком долго -- страница вроде бы уже загрузилась, но тесты дальше не хотят выполняться.
На самом деле Selenium и в том и в другом случае действует по одним и тем же правилам. У него есть формальные критерии завершения загрузки страницы, и он неукоснительно их придерживается.
Алексей Баранцев написал серию из трёх статей, в которых объясняются эти правила и способы их "настройки" под ваши требования, если вас не устраивает стандартное поведение:
