Home

Оригинал статьи: http://www.ontestautomation.com/monitoring-the-quality-of-your-test-automation-code/

Автор: Баз Дийкстра (Bas Dijkstra)

Перевод: Ольга Алифанова

Если вы работаете в Agile-команде, то периодически вам придется (или "у вас будет возможность", зависит от ваших взглядов) браться за задачи, находящиеся вне вашей "зоны комфорта", или как минимум отличающиеся от ваших обычных дел. В течение нынешнего спринта у меня было свободное время, а в проекте накопился приличный технический долг, относящийся к качеству кода, и команда решила, что неплохо бы с ним частично разделаться. Я никоим образом не разработчик, но кое-что понимаю в коде (я и не шеф-повар, но ужин приготовить могу), поэтому я усмотрел в этом возможность получить дополнительный опыт по чтению, интерпретированию и правке кода. В нашем нынешнем проекте мы используем SonarQube в качестве платформы для управления качеством. Я никогда раньше не работал с этим инструментом, поэтому ничего особенного от него не ожидал, но пока что мне все нравится.

Пока я вдумчиво разбирался с кодом, удаляя ненужные куски и переписывая нужные, меня осенило мыслью, что код наших автотестов, тесно связанный с кодом продукта, не оценивается с точки зрения требований к качеству, которые мы предъявляем к продукту. В этой статье я бы хотел обсудить, хорошо это или плохо – оценивать качество кода автотестов.

Аргумент "за": создание автотестов – это разработка ПО.

Успешное внедрение автоматизации требует к себе отношения, аналогичного отношения к любому другому проекту по разработке ПО: автоматизация требует планирования, внятного дизайна и наличия разработчиков автотестов, которые знают толк в своем деле. Почему бы не отнестись к коду автотестов так же, как и к коду продукта, вплоть до оценки его качества? Как и любой другой код, созданный в течение жизненного цикла ПО, код ваших автотестов должен быть читабелен и легок для поддержки. Под "легким для поддержки" я имею в виду возможность исправлять и дополнять его после того, как создавший автотесты гений перешел на другую должность или покинул компанию. Опять-таки, мы же поступаем так с кодом продукта, почему бы не поступать так с автотестами?

Автор: Баз Дийкстра (Bas Dijkstra)

Оригинал статьи: http://www.ontestautomation.com/trust-automation/

Перевод: Ольга Алифанова

Сейчас большинство людей уже в курсе, что цель автоматизации – это НЕ "поиск багов". Конечно, неплохо, когда ваши автотесты ловят баг-другой, которые иначе просочились бы в продакшн. Но пока искуственный интеллект автоматизации не достиг больших высот (я имею в виду, действительно БОЛЬШИХ), тестировщики куда более искусны в поиске багов, чем самые умные, развитые автоматизированные решения для тестирования.

Нет, добавочная ценность автоматизации совсем в другом – в уверенности. Из оксфордского словаря:

"Уверенность: твердое убеждение в надежности, правдивости, или способности чего-либо или кого-либо."

Набор хороших автотестов вселит в ваших заинтересованных лицах (включая, но не ограничиваясь тестировщиками) уверенность, что тестируемая система дает результат или выполняет определенные функции так, как предварительно было определено (правильно ли было определено – тема для другой дискуссии). Даже после кучи изменений, фиксов, патчей, рефакторингов и других обновлений.

Эта уверенность появляется благодаря доверию:

Автор: Александр Андряшин

Оригинальная публикация: https://habrahabr.ru/post/327184/

Представляю вам перевод моей статьи на Medium.com.

Selenium сегодня является стандартом де-факто для автоматизации выполнения тестов в браузерах. Все популярные браузеры поддерживаются из коробки, а архитектура хорошо известна. Существуют даже компании, предоставляющие Selenium за деньги. Но удобен ли обычный Selenium сервер для локальной отладки тестов?

Проблема

Как веб-разработчик или инженер по автоматизации тестирования вы можете столкнуться со следующими неудобствами при работе со стандартным Selenium сервером:

1. Нужно устанавливать несколько разных браузеров себе на компьютер. В обычной жизни вы, как правило, используете один браузер, например, Chrome, но вам приходится устанавливать себе Firefox и Opera, чтобы отлаживать в них Selenium-тесты.
2. Трудно устанавливать и использовать несколько версий одного браузера. Если вы устанавливаете браузер из пакетов, то вообще можно иметь только одну установленную версию. Кроме того Selenium и его веб-драйверы обычно ищут исполняемый файл браузера по определенному пути. Поэтому, поверьте, использовать несколько версий может быть трудной задачей.
3. Если вы запускаете браузер, установленный в вашей операционной системе — он забивает место на диске своими временными файлами и содержимым кеша.
4. Нельзя гарантировать, что настройки браузера всегда останутся в том же состоянии, как после чистой установки. Например, вы можете случайно изменить адрес прокси-сервера или настройки безопасности. Это может привести к падению ранее работавших тестов.
5. Трудно запускать несколько тестов в разных браузерах параллельно. Попытка сделать это как правило приводит к различным проблемам: окна начинают конкурировать за фокус, не срабатывающие события, не ожидаемые CSS стили и так далее.
6. Нужно знать какая версия Selenium совместима с какой версией браузера. То же самое верно для исполняемых файлов веб-драйверов (например, Chromedriver).

Приведенный выше список недостатков далеко не полный. Но давайте остановимся на этом и попробуем гораздо более удобный способ отладки Selenium-тестов локально.

Автор: Майкл Фритциус (Michael Fritzius)

Оригинал статьи: https://testzius.wordpress.com/2017/01/09/how-to-start-learning-automation/

Перевод: Ольга Алифанова

Люди спрашивали меня, как им узнать больше про автоматизацию тестирования. Я думаю, все согласны, что знать что-то про автоматизацию, работая в сфере QA – дело хорошее, и может быть подспорьем в нашей работе – не говоря уже о росте ценности наших резюме.

Но с чего же начать? Это огромное непаханое поле информации. Я понимаю, почему люди не знают, с чего начать – очень трудно преодолеть инерцию по ряду причин, связанных с большим количеством материала, который нужно усвоить.

Я хочу поделиться с вами тремя Большими Секретами. Бесплатно. Только сегодня, только у нас. И вы сможете начать учиться автоматизации.

Большой секрет №1: "Нельзя рулить припаркованной машиной"

Эту фразу произнес мой тесть много лет назад, когда я просил у него духовного наставничества. Я задумался, как я узнаю, в каком направлении мне двигаться, одобряет ли Господь то, что я делаю?

Ответом тестя было "Нельзя рулить припаркованной машиной".

Нет, дальше он развил свою мысль, конечно же.

Где-то минуту я осмыслял, что он имеет в виду, и в конце концов понял: Господь будет направлять мою жизнь, если я начну движение. Я начну движение – он начнет рулить.

Довольно крутая аналогия.

Эта мудрость достаточно коротка и влезет даже на кепку, но применима в большом количестве ситуаций. "Если речь идет об обучении автоматизации, спросите себя, в каком направлении вам двигаться?" А движетесь ли вы вообще? Вы не можете двигаться в каком-то направлении, если вы припаркованы.

Если вы не движетесь хоть в какую-то сторону (которую можно выбрать позднее), то заведите машину и нажмите на газ.

Автор: Дмитрий Мамонов, Департамент разработки, Wrike

Додо сказал:
— Правильность формы несущественна! А потом расставил всех без всякого порядка по кругу. Никто не подавал команды — все побежали, когда захотели.
Л.Кэрролл, «Приключения Алисы в стране чудес»

Развивая автоматизацию тестирования, можно найти много мест, куда приложить силы. Распыляя усилия и преследуя ложные цели мы не только потратим время и ресурсы впустую, но и нанесем разработке вред.

Если знать, на каком уровне развития находится автоматизация тестирования проекта сейчас и куда в такой ситуации инвестировать, можно не просто добиться большей отдачи, но и улучшить разработку в целом. Основные принципы инвестирования ресурсов можно попробовать сформулировать в виде короткого манифеста.

Автор: Олег Половинкин

Оригинальная публикация

Материал основан на реальном проектном опыте.

Для начала скажем несколько слов о проекте. Существует сайт букмекерской конторы для принятия ставок онлайн. До начала работ по автоматизации каждый ручной сет регрессионных тестов занимал около двух дней, релизы проводились примерно раз в неделю. Главным ожиданием заказчика от автоматизации было максимально возможное покрытие регресса автотестами, а также ускорение этого процесса.

Забегая вперед, отмечу, что сейчас релизы проходят каждый день или через день, а ручная часть тестов (то, что оказалось невозможно автоматизировать по тем или иным причинам) занимает примерно столько же времени, что и прогон автотестов с просмотром результатов.

Автор: Баз Дикстра (Bas Dikstra)

Оригинал статьи: http://linkis.com/ontestautomation.com/E2sHz

Перевод: Ольга Алифанова

Эта статья о том, что беспокоит меня уже довольно давно и продолжает всплывать по ряду причин. Когда я разговариваю с клиентами, вижу дискуссии на ЛинкедИне или StackOverflow, или читаю блог об автоматизации, слишком часто я вижу нечто вроде "как мне решить проблему А при помощи инструмента Б" (где инструмент Б, как правило, Селениум). То, что меня беспокоит – это вопрос "как". У меня дергается глаз, потому что вместо этого "как" мне хочется спросить "зачем". Точнее говоря, "зачем и какого черта это вообще делать"?

Где-то полгода назад я писал про это пост на LinkedIn. Он не изменил мир, я все еще вижу кучу "как" там, где, думается мне, спрашивать надо "зачем". Но, как изящно выражаются на латыни, repetition mater studiorum est (повторение – мать учения).

Я думаю, стоит повторить: задавая вопрос, связанный с автоматизацией, спросите себя "зачем", перед тем , как начинать думать, "как".

Автор: Баз Дийкстра (Bas Dijkstra)

Оригинал статьи: http://www.ontestautomation.com/choose-wisely/

Перевод: Ольга Алифанова

В своей недавней статье, опубликованной на TechBeacon, я утверждал, что тесты на уровне API копают золотую жилу скорости выполнения, стабильности (как стабильности запуска, так и стабильности требуемой поддержки) и тестового покрытия. Однако я забыл упомянуть, что именно сподвигло меня написать такую статью. Об этом я и расскажу.

На самом деле причина для такой темы у меня была только одна: я слишком часто вижу, как все идет наперекосяк, когда люди начинают писать автотесты. Сейчас я работаю с несколькими клиентами над двумя разными проектами, и их объединяет стремление к end-to-end тестам (зачастую при помощи инструментов вроде Selenium или Protractor), с проверками, которые выходят за рамки юнит-тестов.

Вот вам пример. Я работаю над проектом, в котором мы собираемся создать автоматические проверки для веб-магазина, который продает электронные сигареты и аксессуары для них в Соединенных Штатах Америки. В магазине несколько продуктовых категорий, возрастных групп покупателей (некоторые продукты можно приобретать, если вам больше 18, некоторые – если вам больше 21, некоторые продукты не учитывают возраст, и так далее). К тому же это США – 50 разных штатов, и в каждом свои правила и законодательство. Короче говоря, возможных комбинаций тут куча (я не считал, но точно в районе сотен). К тому же из-за жестких правил США, и штрафов за нарушение этих правил, автотесты должны включать абсолютно все возможные комбинации.

Звучит логично, но проблема в том, что заказчик предлагает написать автоматизированный end-to-end тест для каждой из возможных комбинаций. Следовательно, нам нужно создать заказ для каждой комбинации продуктовой группы, возрастной группы и штата, и каждый заказ включает заполнение трех или четырех разных форм и несколько переходов по страницам. Другими словами, такой тест будет медленно запускаться (счет пойдет на часы), и его будет тяжело поддерживать.

Автор: Амир Гахрай (Amir Ghahrai)

Оригинал статьи: http://www.testingexcellence.com/choose-tests-automate/

Перевод: Ольга Алифанова

Как вы решаете, какие тесты автоматизировать, а какие оставить для ручного тестирования?

Перед тем, как вы начинаете автоматизировать тест, вам нужно выяснить, какую выгоду вы получите от автоматизации этого теста, учитывая время, силы и ресурсы, вложенные в автоматизацию.

Ниже перечислены факторы, которые стоит принять во внимание, решая, какие ручные тесты должны или не должны быть автоматизированы. Как говорится, только то, что вы можете что-то автоматизировать, не означает, что вы должны автоматизировать все и вся.

Автор: Эрика Чиковски (Ericka Chickowski)

Оригинал статьи: https://techbeacon.com/5-proven-ways-blow-your-test-automation-budget

Перевод: Ольга Алифанова

Так как ответственность за автоматизацию тестирования все больше увязывается с Agile-командами, роль фреймворка автоматизации тестирования развивается, становится более распыленной. Все меньше организаций полагается на монолитный коммерческий фреймворк, и движутся к слабо соединенным инструментам с открытым исходным кодом, более соответствующим целям отдельно взятой команды.

Это позволяет организации быть гибкой, но создает проблему управления издержками. Распыление ответственности за автоматизацию и ее инструменты усложняет QA-экспертам оценку того, сколько в точности автоматизация тестирования стоит.

Но несмотря на отсутствие точных параметров расчета издержек, ветераны тестирования хорошо знакомы с наиболее дорогостоящими сценариями автоматизации. TechBeacon попросил трех профессионалов тестирования поделиться своими мыслями о том, какие практики бессмысленно задирают издержки построения и поддержки эффективного фреймворка автоматизации. Вот пять наиболее затратных из них: