Сможете заавтоматить поиск/выбор нужного элемента в дереве при помощи SpiderTest?
Эм, если честно, то не вижу целесообразности в этом действии. Автотесты должны четко знать где и что находится потому что если мы говорим SpiderTest КАКОЙ элемент искать, но не говорим ГДЕ, то он сам прокликивает все дерево и ищет. Но это глупо, если нужных элементов несколько и они находятся в разных директориях, то тест найдет первый и успокоится. Это плохой и неправильный подход.
Ну или проверку серверной сортировки для какой-нибудь таблички, если имеется пагинация?
Ну тут примерно та же беда: автотесту нужно знать, где лежит конкретный элемент.
А могли бы предметнее рассказать для каких «более-менее» серьезных задач инструмент не годится?
Пример посмотрел, возможно неплохой инструмент, но лично мне не показался интуитивно понятным.
Чего только люди не найдут в интернетах лишь бы не учить языки программирования…
А в том-то все и дело, что хотелось бы разбавить гегемонию программирования. А то ведь нет доступных инструментов для создания автотестов без скриптов, ладно бы их была куча, тогда бы SpiderTest был бы не нужен.
Не факт, но возможно. Хотя ценны ли такие тестировщики, которые автотесты писать ленятся?
Ну вот тут не соглашусь, дело тут не в лени. Возможные разные варианты:
1. Оптимизация трудозатрат. Разобраться с каким-нибудь тестовым фреймворком человеку, который никогда не занимался программированием довольно тяжело, а SpiderTest довольно интуитивен и на его освоение уйдет гораздо меньше времени.
2. Ценность тестировщиков, в том, что они не программисты. К ним применимо выражение «голь на выдумку хитра». Их задача написать автотест, который будет работать, а как это сделать: написав код, или собрав сценарий, или записав его в YourFavoriteIDE уже не важно, я считаю. Поэтому ценность тестировщика определяется не столько умением писать код, а сколько в ограниченных рамках (времени, знаний и умений) исхитриться и выполнить работу. Таково мое субъективное мнение.
В серьезных конторах обычно имеется специальный человек, который за инфраструктуру отвечает
Спору нет, но если уж мы заговорили о технологиях, которые не требуют инфраструктурной поддержки админа, то к этому можно отнести SpiderTest))
И напоследок, SpiderTest является по сути приложением для написания и отладки тестов, а сами тесты потом можно прикрутить к широко известным CI (дженкинс, бамбу, teamcity). Что же касается остальных CI, то всем не угодишь) Плюс ко всему это приложение разрабатывается одним разработчиком, вернее даже тестировщиком, который изначально писал это приложения для собственных нужд) к тому же это приложение можно сказать в самом начале своего пути. Поэтому любые замечания по функционалу будут восприняты с благодарностью)
Ага, прочитал про эти инструменты. Но они тоже для автотестов использую скрипты. Однако, как я понял, с помощью Ranorex и CodedUI можно писать тесты для десктопных приложений на C#? Это интересно.
И как я понял из этих двух инструментов Ranorex более дружелюбен для тестировщика, чем CodedUI.
Хах, суть проекта не в том, чтобы отменить все старые добрые Selenium'ы и уйти от писания автотестов на множестве языков, а в том, чтобы показать аудитории новые инструменты для создания тестов.Этакие шаги за горизонт!
К тому же это хорошее подспорье для начинающих тестировщиков, которые ну ни в какую не желают учить программирование и кодить.
Более того, по собственному опыту скажу: проект автотестов перенести с одной машину на другую не всегда просто, нужно такое же окружение настраивать (всякие либы скачивать и гемы нужных версий и т.д.), а тут ничего подобного не надо. Просто скопировал и запустил.
Постоянно падает с exception'ами и по сути только webkit-семья, а фаервокса, оперы и IE в нем нету.
Само приложение для написания тестов виндовое. Все верно! Но тесты можно запускать и на линуксе. В составе приложения есть SpiderTestCI.jar — этот джарник нужен для создания maven-проекта, который можно прикрутить к CI-серверу и запускать в том числе и на линуксе. Более того, после выполнения теста формируется красивый отчет посредством фреймворка Allure от Яндекса. Но об этом я планировал написать в следующей статье. Чтобы не перегружать эту смыслом.
Да ну, ну что вы в самом деле? selenium ide — это ж дополнение к firefox. Дополнение, Карл! А SpiderTest самостоятельное приложение. Тем более, в результате selenium ide генерится скрипт и в нем черт ногу сломит. А в SpiderTest все просто и понятно — тест записывается в виде xml-структуры. Не нужно заботиться о том как этот тест будет выполняться — просто сказать какой тест сделать и все.
Плюс, не стоит забывать о том, что SpiderTest работает в разных браузерах, а не только в Firefox.
А в следующей статье я расскажу про кроссплатформенность и быструю привязку к CI.
гхм, возможно он ругается на то, то в zip архиве могут содержаться вирусы. Но у меня с этой же версией проблем не возникало. Нажимаю «сохранить» и не парюсь.
Про совместную работу. Подразумевается работа нескольких тестировщиков и аналитиков над одной картой в режиме реального времени? Увы, совместная работа не предусматривается, все-таки это не Google Docs. Как я писал выше, MindMap скорее удобен для небольших и средних проектов, с которыми справится один человек. Но есть у нас проект достаточно объемный, который тестируют два человека. Мы разбиваем интеллект карту на несколько частей (можно либо на несколько файлов, либо на несколько страниц как в Excel). Каждая часть — это отдельная большая функциональность (и даже приложение, если проект состоит из нескольких приложений). Два человека делят между собой эти части и отмечают там информацию и тестировании.
Про производительность. Частично ответил на этот вопрос выше. Когда карта становится огромной, целесообразно ее дробить на части и их поочередно тестировать. Лично мною методика дробления карты опробована и в целом она удовлетворительна.
По поводу названия «Новый взгляд...». Оно обосновано тем, что мне хотелось посмотреть на использование интеллект-карт с новой стороны. В основном, используют MindMap разные категории людей: дизайнеры для придумывания концепций, бизнес-тренеры для презентаций, менеджеры для составления планов. А вот о том, как можно использовать интеллект-карты в тестировании как-то слышать не довелось, отсюда идея написания статьи.
По поводу «времени и сил». Вы отчасти правы. Если решить создать MindMap для готового и давно разрабатываемого проекта, то скорее из этого ничего не выйдет. Согласен, не хватит сил и времени. Но если вводить использование интеллект-карт на начальных стадиях проекта, то «тащить» карту несложно. Ну что стоит перед каждым релизом добавить десяток новых веток и убрать/переписать пару старых?
По поводу версионности. Гхм, тут можно изобрести своего рода костыль, когда в одном файле MindMap можно держать несколько разных версий проекта и с каждым билдом добавлять новую. Но тут вы правы, есть загвоздка. Но нужно ли это вообще? Мне кажется достаточно видеть актуальную версию карты с выделенными новыми функциональностями.
Однако, резюмировать бы я хотел так: MindMap для небольших проектов чудо как хорош. Для больших проектов с регулярными билдами MindMap будет не так полезен, возможно нужно рассмотреть что-то другое.
Забавно, суть этого behave в питоне, такая же как у Cucumber в руби. Даже директории и расширения файлов одинаково называются. А не пробовали пользоваться параллельно с этим фреймворком использовать Page Object? Тест был бы изящнее)
Гхм, несколько не понимаю сути вашего коммента. Причем здесь 2007 год? Это отсылка к году, когда уже использовали MindMap (вы или кто-то другой) в тестировании или троллинг-мем «где мой 2007 год», когда была трава зеленее, музыка громче, статьи интереснее и т.д.?
У меня был не большой опыт собеседований. Но безусловно смущают стандартные вопросы про люки, почерпнутые из паблика «Все для HR» и «Это интересно».
А еще я бы добавил, что соискателя на собеседовании может смутить излишняя суровость интервьюера. Собеседующий должен показать, что помимо интересных задач, карьерного роста и т.д. в колликтиве хороший микроклимат. В свое время, когда я пришел на собеседование на должность QA (не обладая большими знаниями, но стремясь их получить) меня спросили знаю ли я что такой bash, то я вместо того чтобы ответить, что это командная оболочка, переспросил: «Это цитатник рунета?», ребята посмеялись. Тон беседы был задан. В итоге меня подкупила простота общения с начальством отдела. Начальник и его зам серьезные вопросы могли разбавить шуткой, это как-то настраивает на хороший лад и демонстрировать свои знания/умения становится проще.
Эм, если честно, то не вижу целесообразности в этом действии. Автотесты должны четко знать где и что находится потому что если мы говорим SpiderTest КАКОЙ элемент искать, но не говорим ГДЕ, то он сам прокликивает все дерево и ищет. Но это глупо, если нужных элементов несколько и они находятся в разных директориях, то тест найдет первый и успокоится. Это плохой и неправильный подход.
Ну тут примерно та же беда: автотесту нужно знать, где лежит конкретный элемент.
Пример посмотрел, возможно неплохой инструмент, но лично мне не показался интуитивно понятным.
А в том-то все и дело, что хотелось бы разбавить гегемонию программирования. А то ведь нет доступных инструментов для создания автотестов без скриптов, ладно бы их была куча, тогда бы SpiderTest был бы не нужен.
Какие еще клавиши можно было бы сымитировать?
Ну вот тут не соглашусь, дело тут не в лени. Возможные разные варианты:
1. Оптимизация трудозатрат. Разобраться с каким-нибудь тестовым фреймворком человеку, который никогда не занимался программированием довольно тяжело, а SpiderTest довольно интуитивен и на его освоение уйдет гораздо меньше времени.
2. Ценность тестировщиков, в том, что они не программисты. К ним применимо выражение «голь на выдумку хитра». Их задача написать автотест, который будет работать, а как это сделать: написав код, или собрав сценарий, или записав его в YourFavoriteIDE уже не важно, я считаю. Поэтому ценность тестировщика определяется не столько умением писать код, а сколько в ограниченных рамках (времени, знаний и умений) исхитриться и выполнить работу. Таково мое субъективное мнение.
Спору нет, но если уж мы заговорили о технологиях, которые не требуют инфраструктурной поддержки админа, то к этому можно отнести SpiderTest))
И напоследок, SpiderTest является по сути приложением для написания и отладки тестов, а сами тесты потом можно прикрутить к широко известным CI (дженкинс, бамбу, teamcity). Что же касается остальных CI, то всем не угодишь) Плюс ко всему это приложение разрабатывается одним разработчиком, вернее даже тестировщиком, который изначально писал это приложения для собственных нужд) к тому же это приложение можно сказать в самом начале своего пути. Поэтому любые замечания по функционалу будут восприняты с благодарностью)
И как я понял из этих двух инструментов Ranorex более дружелюбен для тестировщика, чем CodedUI.
К тому же это хорошее подспорье для начинающих тестировщиков, которые ну ни в какую не желают учить программирование и кодить.
Более того, по собственному опыту скажу: проект автотестов перенести с одной машину на другую не всегда просто, нужно такое же окружение настраивать (всякие либы скачивать и гемы нужных версий и т.д.), а тут ничего подобного не надо. Просто скопировал и запустил.
это вы про SpiderTest?
Плюс, не стоит забывать о том, что SpiderTest работает в разных браузерах, а не только в Firefox.
А в следующей статье я расскажу про кроссплатформенность и быструю привязку к CI.
Про производительность. Частично ответил на этот вопрос выше. Когда карта становится огромной, целесообразно ее дробить на части и их поочередно тестировать. Лично мною методика дробления карты опробована и в целом она удовлетворительна.
Надеюсь ответил на ваш вопрос.
По поводу «времени и сил». Вы отчасти правы. Если решить создать MindMap для готового и давно разрабатываемого проекта, то скорее из этого ничего не выйдет. Согласен, не хватит сил и времени. Но если вводить использование интеллект-карт на начальных стадиях проекта, то «тащить» карту несложно. Ну что стоит перед каждым релизом добавить десяток новых веток и убрать/переписать пару старых?
По поводу версионности. Гхм, тут можно изобрести своего рода костыль, когда в одном файле MindMap можно держать несколько разных версий проекта и с каждым билдом добавлять новую. Но тут вы правы, есть загвоздка. Но нужно ли это вообще? Мне кажется достаточно видеть актуальную версию карты с выделенными новыми функциональностями.
Однако, резюмировать бы я хотел так: MindMap для небольших проектов чудо как хорош. Для больших проектов с регулярными билдами MindMap будет не так полезен, возможно нужно рассмотреть что-то другое.
А еще я бы добавил, что соискателя на собеседовании может смутить излишняя суровость интервьюера. Собеседующий должен показать, что помимо интересных задач, карьерного роста и т.д. в колликтиве хороший микроклимат. В свое время, когда я пришел на собеседование на должность QA (не обладая большими знаниями, но стремясь их получить) меня спросили знаю ли я что такой bash, то я вместо того чтобы ответить, что это командная оболочка, переспросил: «Это цитатник рунета?», ребята посмеялись. Тон беседы был задан. В итоге меня подкупила простота общения с начальством отдела. Начальник и его зам серьезные вопросы могли разбавить шуткой, это как-то настраивает на хороший лад и демонстрировать свои знания/умения становится проще.