11.05.2017 08:04 |
Автор: Александр Андряшин
Оригинальная публикация: 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-тестов локально. |
Подробнее...
|
25.04.2017 08:42 |
Автор: Майкл Фритциус (Michael Fritzius)
Оригинал статьи: https://testzius.wordpress.com/2017/01/09/how-to-start-learning-automation/
Перевод: Ольга Алифанова
Люди спрашивали меня, как им узнать больше про автоматизацию тестирования. Я думаю, все согласны, что знать что-то про автоматизацию, работая в сфере QA – дело хорошее, и может быть подспорьем в нашей работе – не говоря уже о росте ценности наших резюме.
Но с чего же начать? Это огромное непаханое поле информации. Я понимаю, почему люди не знают, с чего начать – очень трудно преодолеть инерцию по ряду причин, связанных с большим количеством материала, который нужно усвоить.
Я хочу поделиться с вами тремя Большими Секретами. Бесплатно. Только сегодня, только у нас. И вы сможете начать учиться автоматизации.
Большой секрет №1: "Нельзя рулить припаркованной машиной"
Эту фразу произнес мой тесть много лет назад, когда я просил у него духовного наставничества. Я задумался, как я узнаю, в каком направлении мне двигаться, одобряет ли Господь то, что я делаю?
Ответом тестя было "Нельзя рулить припаркованной машиной".
Нет, дальше он развил свою мысль, конечно же.
Где-то минуту я осмыслял, что он имеет в виду, и в конце концов понял: Господь будет направлять мою жизнь, если я начну движение. Я начну движение – он начнет рулить.
Довольно крутая аналогия.
Эта мудрость достаточно коротка и влезет даже на кепку, но применима в большом количестве ситуаций. "Если речь идет об обучении автоматизации, спросите себя, в каком направлении вам двигаться?" А движетесь ли вы вообще? Вы не можете двигаться в каком-то направлении, если вы припаркованы.
Если вы не движетесь хоть в какую-то сторону (которую можно выбрать позднее), то заведите машину и нажмите на газ. |
Подробнее...
|
30.03.2017 10:46 |
Автор: Дмитрий Мамонов, Департамент разработки, Wrike
Додо сказал: — Правильность формы несущественна! А потом расставил всех без всякого порядка по кругу. Никто не подавал команды — все побежали, когда захотели. Л.Кэрролл, «Приключения Алисы в стране чудес»
Развивая автоматизацию тестирования, можно найти много мест, куда приложить силы. Распыляя усилия и преследуя ложные цели мы не только потратим время и ресурсы впустую, но и нанесем разработке вред.
Если знать, на каком уровне развития находится автоматизация тестирования проекта сейчас и куда в такой ситуации инвестировать, можно не просто добиться большей отдачи, но и улучшить разработку в целом. Основные принципы инвестирования ресурсов можно попробовать сформулировать в виде короткого манифеста. |
Подробнее...
|
03.03.2017 12:45 |
Автор: Олег Половинкин
Оригинальная публикация
Материал основан на реальном проектном опыте.
Для начала скажем несколько слов о проекте. Существует сайт букмекерской конторы для принятия ставок онлайн. До начала работ по автоматизации каждый ручной сет регрессионных тестов занимал около двух дней, релизы проводились примерно раз в неделю. Главным ожиданием заказчика от автоматизации было максимально возможное покрытие регресса автотестами, а также ускорение этого процесса.
Забегая вперед, отмечу, что сейчас релизы проходят каждый день или через день, а ручная часть тестов (то, что оказалось невозможно автоматизировать по тем или иным причинам) занимает примерно столько же времени, что и прогон автотестов с просмотром результатов. |
Подробнее...
|
02.03.2017 11:24 |
Автор: Баз Дикстра (Bas Dikstra)
Оригинал статьи: http://linkis.com/ontestautomation.com/E2sHz
Перевод: Ольга Алифанова
Эта статья о том, что беспокоит меня уже довольно давно и продолжает всплывать по ряду причин. Когда я разговариваю с клиентами, вижу дискуссии на ЛинкедИне или StackOverflow, или читаю блог об автоматизации, слишком часто я вижу нечто вроде "как мне решить проблему А при помощи инструмента Б" (где инструмент Б, как правило, Селениум). То, что меня беспокоит – это вопрос "как". У меня дергается глаз, потому что вместо этого "как" мне хочется спросить "зачем". Точнее говоря, "зачем и какого черта это вообще делать"?
Где-то полгода назад я писал про это пост на LinkedIn. Он не изменил мир, я все еще вижу кучу "как" там, где, думается мне, спрашивать надо "зачем". Но, как изящно выражаются на латыни, repetition mater studiorum est (повторение – мать учения).
Я думаю, стоит повторить: задавая вопрос, связанный с автоматизацией, спросите себя "зачем", перед тем , как начинать думать, "как". |
Подробнее...
|
13.02.2017 00:00 |
Автор: Баз Дийкстра (Bas Dijkstra)
Оригинал статьи: http://www.ontestautomation.com/choose-wisely/
Перевод: Ольга Алифанова
В своей недавней статье, опубликованной на TechBeacon, я утверждал, что тесты на уровне API копают золотую жилу скорости выполнения, стабильности (как стабильности запуска, так и стабильности требуемой поддержки) и тестового покрытия. Однако я забыл упомянуть, что именно сподвигло меня написать такую статью. Об этом я и расскажу.
На самом деле причина для такой темы у меня была только одна: я слишком часто вижу, как все идет наперекосяк, когда люди начинают писать автотесты. Сейчас я работаю с несколькими клиентами над двумя разными проектами, и их объединяет стремление к end-to-end тестам (зачастую при помощи инструментов вроде Selenium или Protractor), с проверками, которые выходят за рамки юнит-тестов.
Вот вам пример. Я работаю над проектом, в котором мы собираемся создать автоматические проверки для веб-магазина, который продает электронные сигареты и аксессуары для них в Соединенных Штатах Америки. В магазине несколько продуктовых категорий, возрастных групп покупателей (некоторые продукты можно приобретать, если вам больше 18, некоторые – если вам больше 21, некоторые продукты не учитывают возраст, и так далее). К тому же это США – 50 разных штатов, и в каждом свои правила и законодательство. Короче говоря, возможных комбинаций тут куча (я не считал, но точно в районе сотен). К тому же из-за жестких правил США, и штрафов за нарушение этих правил, автотесты должны включать абсолютно все возможные комбинации.
Звучит логично, но проблема в том, что заказчик предлагает написать автоматизированный end-to-end тест для каждой из возможных комбинаций. Следовательно, нам нужно создать заказ для каждой комбинации продуктовой группы, возрастной группы и штата, и каждый заказ включает заполнение трех или четырех разных форм и несколько переходов по страницам. Другими словами, такой тест будет медленно запускаться (счет пойдет на часы), и его будет тяжело поддерживать. |
Подробнее...
|
06.02.2017 16:41 |
Автор: Амир Гахрай (Amir Ghahrai)
Оригинал статьи: http://www.testingexcellence.com/choose-tests-automate/
Перевод: Ольга Алифанова
Как вы решаете, какие тесты автоматизировать, а какие оставить для ручного тестирования?
Перед тем, как вы начинаете автоматизировать тест, вам нужно выяснить, какую выгоду вы получите от автоматизации этого теста, учитывая время, силы и ресурсы, вложенные в автоматизацию.
Ниже перечислены факторы, которые стоит принять во внимание, решая, какие ручные тесты должны или не должны быть автоматизированы. Как говорится, только то, что вы можете что-то автоматизировать, не означает, что вы должны автоматизировать все и вся. |
Подробнее...
|
06.02.2017 11:50 |
Автор: Эрика Чиковски (Ericka Chickowski)
Оригинал статьи: https://techbeacon.com/5-proven-ways-blow-your-test-automation-budget
Перевод: Ольга Алифанова
Так как ответственность за автоматизацию тестирования все больше увязывается с Agile-командами, роль фреймворка автоматизации тестирования развивается, становится более распыленной. Все меньше организаций полагается на монолитный коммерческий фреймворк, и движутся к слабо соединенным инструментам с открытым исходным кодом, более соответствующим целям отдельно взятой команды.
Это позволяет организации быть гибкой, но создает проблему управления издержками. Распыление ответственности за автоматизацию и ее инструменты усложняет QA-экспертам оценку того, сколько в точности автоматизация тестирования стоит.
Но несмотря на отсутствие точных параметров расчета издержек, ветераны тестирования хорошо знакомы с наиболее дорогостоящими сценариями автоматизации. TechBeacon попросил трех профессионалов тестирования поделиться своими мыслями о том, какие практики бессмысленно задирают издержки построения и поддержки эффективного фреймворка автоматизации. Вот пять наиболее затратных из них: |
Подробнее...
|
30.01.2017 11:37 |
Автор: Андрей Шальнев Оригинальная публикация
На сегодняшний день многие проекты, имеющие сложную разнообразную функциональность, характеризуются очень короткими промежутками между релизами. В таких случаях приходится часто выполнять большое количество повторяющихся проверок (регрессионных тестов). Возможно, этот факт и является главной (хотя и не единственной) движущей силой активного развития автоматизации тестирования. Все больше компаний в сфере IT принимают решение оптимизировать процесс тестирования, сократив затратные по времени и финансам действия.
При этом автоматизация является довольно молодым направлением. Опытных специалистов, владеющих соответствующими навыками, как правило, не хватает. Зачастую встает задача подготовить таких специалистов самостоятельно внутри компании в разумные сроки. Однако, освоение автоматизации предъявляет высокие требования к технической подготовленности тестировщика, так как от него требуется читать и писать программный код, редактировать конфигурационные файлы, читать логи и т. д. В этой статье речь как раз пойдет о том, какие именно шаги можно предпринять для достижения нужного уровня технической подготовленности такого специалиста.
Мне пришлось осваивать автоматизацию «с нуля», т. е. не имея академического образования в сфере IT, навыков программирования и практики работы в смежных «технических» направлениях (например, в системном администрировании). Теперь, уже имея опыт написания тестов на двух языках программирования (Python и Java) и продолжая совершенствоваться в сфере автоматизации, я дам рекомендации, как приобрести нужные знания и опыт. |
Подробнее...
|
25.01.2017 12:14 |
Если вы задумались над внедрением автоматизации, вам стоит обратить внимание на записи выступлений с конференции CEE SECR “Разработка ПО”. В своих докладах специалисты рассказали о том, почему такая необходимость возникла на их на проектах, с чего они начинали процесс автоматизированного тестирования, а также о применяемых в работе инструментах.
Разработка системы автоматизированного тестирования при помощи фреймворка Protractor для web-приложений
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ |
Подробнее...
|
|