Я хочу обсудить, пожалуй, самую знаменитую из устаревших концепций тестирования. Кто-то говорит о ней с восторгом, а кто-то не очень понимает, о чем речь. Зачастую ее недопонимают или применяют неправильно, и поэтому она, наверное, лучший кандидат на вышедшие из моды концепции тестирования, которые имеет смысл обсуждать. Так поговорим же про автоматизацию тестирования!
Прежде чем начать разговор
Под автоматизацией я – лично я – понимаю автоматизированное выполнение какого-либо действия. Соответственно, автоматизированное тестирование для меня – это автоматизация действий, помогающая процессу. Подчеркиваю: под автоматизацией я понимаю только это, а не автоматизацию процесса тестирования как такового. Я сознательно не прибегаю к термину "проверка", чтобы не удариться в долгую дискуссию про "тестирование" и "проверки" - я просто не готов поддержать этот спор в данный момент. Если вам интересна эта тема, прочитайте статью Испытания и проверки: уточнения" Майкла Болтона и Джеймса Баха - это потрясающая работа, я согласен с многими идеями в статье и рекомендую ее всем заинтересованным.
Посещая недавно прошедшие конференции, я осознала, что люди задают неправильные вопросы, когда речь заходит об автоматизации. Прошедший 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-тестов. Разговор будет основан на опыте использования данной идеи на одном из проектов, а также будут даны общие рекомендации, применимые для широкой аудитории.
Сделать побольше, потратить поменьше, тестировать одновременно и быстро, и качественно – вот задача современных компаний. Бизнес требует высоких скоростей разработки, внедрения новых возможностей и исправления дефектов, и качество продукта не должно при этом пострадать. Однако время- и трудозатратное ручное тестирование несравнимо по точности с автоматизированными тестами – и значит, настало время познакомить вашу команду с преимуществами автоматизации
"Единственный способ принять перемены - это погрузиться в них, осознавать их, двигаться в танце с ними" - Алан Уоттс.
Все хоть раз в жизни проходили собеседование. К нему нужно готовиться! Первые минуты собеседования могут стать решающими в вопросе, возьмут ли вас на работу. Почему? Да потому, что первое впечатление - всегда самое сильное. Никогда не недооценивайте силу первых впечатлений. Используйте аналогичный подход при внедрении автоматизации в команде ручных тестировщиков. Считайте, что презентация нового подхода вашей команде или организации - это собеседование. Тщательно подготовьтесь к нему. Оправдайте ожидания команды, разъясните им их новые обязанности - это очень важно, потому что люди склонны эмоционально реагировать любые потенциальные угрозы их работе.
Выступление Дмитрия Миндры на онлайн-конференции для специалистов по автоматизации тестировния Auto ConfeT&QA.
Разработка через тестирование (TDD) известна уже более 10-ти лет. Эту практику применяют десятки тысяч разработчиков. Есть масса успешных примеров, и при этом масса людей, не верящих в эффективность разработки через тестирование. Также есть заблуждение о том, что TDD заменяет работу тестировщика. При этом TDD – это всего лишь один из инструментов разработчика, решающий определенные задачи. Данный доклад является быстрым введением в TDD, который даст вам представление о нем, а также о популярных заблуждениях и мифах.
Многим знаком инструмент Selenium. Это стандарт de facto (а вскоре и de juro) в области автоматизации веб-приложений и мобильных приложений. Невероятно популярный инструмент. Но удивительно то, что Selenium развивается без чёткого плана. С одной стороны, это вполне объяснимо – команда разработки представляет собой группу энтузиастов, работающих над проектом в свободное время. С другой стороны, непонятно, почему коммерческие вендоры не могут повторить этот успех. Вот вы верите в то, что такое возможно?
