А что там в цунге такое клёвое в рекордере? Типичный прокси, как и в джиметре.
Что касается селениума — это да, для аякс-приложений делать генератор нагрузки на джиметре или подобном инструменте это жесть. Однако для селениума ферма нужна вообще здоровенная, на одной машине больше десятка браузеров (то есть фактически виртуальных пользователей) не запустишь. Хотя можно использовать BrowserMob вместо фермы, генерировать нагрузку из облака, но для интранет-приложений такой способ не катит.
Влад, вроде бы тема для обсуждения была задана другая — зачем это работодателю?
Сотрудник потом в сообществах тусит, ему хорошо. А компании что с того? Его там опять таки схантить могут. Или вообще прибавку попросит, объясняя тем, что он «активный участник сообщества».
На конференциях есть две достаточно заметные группы — 1) люди, которые приезжают постоянно, их немного, но это действительно «для тусовки», 2) люди, которые приехали впервые, их большинство (больше половины), и для них это вовсе не «пленум КО». Не факт, что они всему научатся, это больше похоже на то, что распахнулась дверь, а за ней ужас как много всего незнакомого.
Кстати, проплаченных докладов обычно бывает один-два на всю конференцию. Спонсоры нынче не слишком щедры.
Selenium 2.0 имеет поддержку браузера для Andriod.
На странице загрузки code.google.com/p/selenium/downloads/list ищите android-server-xxx.apk
Клиентская часть обычная, как для десктопных браузеров.
Во-вторых, он немного не оправдал возложенных на него надежд, обновляется слишком, слишком редко.
И вообще как-то не пошло коллективное творчество, большинство тестировщиков, кто активно пишет, предпочитает делать это в личных блогах.
Сейчас думаем, как вдохнуть в эту идею новую жизнь.
Если возможностей 1.0 хватает — пока можете попробовать только из любопытства. Продуктивные тесты переводить на WebDriver ещё рано.
Движок для IE переписывается в каждой очередной бете чуть менее чем полностью. Движок для Chrome косячит при заполнении форм. Движок для Safari вообще ещё не сделан. Движок для Opera не запускается на Vista и Win7. В общем, всё ещё сырое. Ну, если только на Firefox надо тестировать — тогда можно, там всё уже достаточно стабильно работает.
Так что всё, что было — осталось. Но добавился новый движок для управления браузером, через нативные API. Рекомендуется использовать там, где Se 1.0 не справляется.
В новой версии Selenium 2.0, которая использует движок WebDriver, тоже сделали «прозрачно», так некоторые теперь жалуются на это, мол хотим, чтобы можно было отдельные ивенты «вручную» создавать :)
Ладно, оставим терминологические споры, в конце концов заметка была не про это, а про то, что цель важнее плана. Про что, что составив план и действуя в соответствии с ним, если вдруг вы понимаете, что он уводит вас от цели — менять надо план, а не цель. Про то, что план лишь средство для достижения цели. Про что, что плана вообще может не быть, но если нет цели… Тогда, как говорил Чеширский Кот, всё равно куда идти.
Что касается непонимания менеджерами чаяний тестировщиков, мне помнится, мы в Вами уже спорили по этому поводу где-то в другой теме :) И я приводил ровно тот же аргумент — если менеджер чего-то не понимает, это не потому, что он тупой, может быть просто ему про это никто никогда не говорил. Если менеджер не знает, как правильно ставить цели тестировщикам, не умеет этого делать — надо не обижаться на него за это, а взять и объяснить!
Давайте Вы приведёте ссылки на статьи упомянутого Джеймса Баха про то, что «это тот вид тестинга, который как правило не включается в тест планы, который не оценивают вначале проекта, но на него тратят время», приведёте ссылки на описание того направления, о котором говорите Вы.
А я со своей стороны дам ссылку на статью тоже же автора «Heuristic Test Planning»: www.satisfice.com/tools/satisfice-cm.pdf
Это статья как раз про стратегическое планирование, про планирование и управление «по целям», а не «по планам».
На самом деле это интересно — почему тестировщикам цель «не ставится в лоб»? Может быть стоит ставить цели чётко, а? А тестировщикам, со своей стороны, прояснять цели? Иначе получается диалог типа «потестируйте тут что-нибудь» — «мы тут кое-что потестировали, вот нашли кое-какие дефеты» :)
Любое тестирование должно отвечать на вопрос «а что, если...»
Что касается «интуитивного тестирования» — не надо этим термином называть что-то другое. Вы дали Ваше объяснение того, что представляет собой «интуитивное тестирование» в Вашем понимании.
Я придерживаюсь следующего определения «тестирования методом свободного поиска» (exploratory testing), которое можно найти в трудах людей, развивающих это направление тестирования: «одновременное осознание, проектирование и выполнение тестов». Это же определение приведено в Википедии, так что можно считать его достаточно общепринятым.
Взгляд сбоку или сверху тут ни при чём, этот подход прекрасно работает и при взгляде спереди. А также когда ещё не пройдены основные сценарии. А также если цель не в тумане. Это неважно. Принципиально другое — разделены ли во времени действия по осознанию, проектированию и выполнению тестов, или же все эти три деятельности выполняются одновременно.
Совершенно верно, поэтому я и написал, что сторонники exploratory testing ратуют за отказ от тактического планирования, и при этом очень уважительно относятся к стратегическому планированию.
В области тестирования (как и во многих других молодых и развивающихся областях) терминология пока неустоявшаяся, это создаёт серьёзные проблемы для меня, когда я провожу тренинги. Поэтому я записал этот слайдкаст, в котором я рассказал о том, что я подразумеваю под теми или иными понятиями. Это облегчает дальнейшее взаимопонимание.
Конечно же моё мнение во многом совпадает со мнением других, уважаемых мною авторов, написавших те или иные книги и статьи о тестировании. Да-да, я не всё это сам придумал :) А местами, возможно, с чем-то не совпадает, но они и сами между собой не всегда во всём согласны.
Кроме того, моё мнение во многом (хотя может быть и не полностью) разделяют другие, уважаемые мною тестировщики, например, автор этого поста. Поэтому в определённой степени его можно считать общепринятым :)
Моя практика общения с тестерами (и даже немного координации их работы, да) говорит, что степень подробности тестов прямо пропорциональна количеству тестеров, которые потенциально будут гонять тесты.
В общем, итог — количество слов в описании теста обратно пропорционально потенциальной квалификации тестера.
Эти два утверждения не очень связаны между собой.
Что будет, если у нас те же 40 тестировщиков, но высококвалифицированные? Согласно второму тезису можно писать мало, а согласно первому — много.
А что, если у нас всего 2 низкоквалифицированных тестировщика?
Может быть, Вы хотели сказать своим комментарием, что чем больше тестировщиков, тем выше вероятность того, что среди них будут низкоквалифицированные?
Или хотя бы разрыв в квалификации будет достаточно большим?
Второе, скорее всего, верно. НО! Написание инструкций квалифицированными тестировщиками и исполнение их неквалифицированными не способствует росту квалификации последних. Поэтому я считаю такой подход пагубным, он консервирует существующее неблагоприятное положение дел, не решая проблему низкой квалификации части сотрудников.
Раздел 16.6
Что касается селениума — это да, для аякс-приложений делать генератор нагрузки на джиметре или подобном инструменте это жесть. Однако для селениума ферма нужна вообще здоровенная, на одной машине больше десятка браузеров (то есть фактически виртуальных пользователей) не запустишь. Хотя можно использовать BrowserMob вместо фермы, генерировать нагрузку из облака, но для интранет-приложений такой способ не катит.
Сотрудник потом в сообществах тусит, ему хорошо. А компании что с того? Его там опять таки схантить могут. Или вообще прибавку попросит, объясняя тем, что он «активный участник сообщества».
Кстати, проплаченных докладов обычно бывает один-два на всю конференцию. Спонсоры нынче не слишком щедры.
А ещё есть и другие конференции, с другими форматами.
Но это не официально поддерживаемый драйвер, так что надо проверять.
На странице загрузки code.google.com/p/selenium/downloads/list ищите android-server-xxx.apk
Клиентская часть обычная, как для десктопных браузеров.
devpoint.ru/
Во-вторых, он немного не оправдал возложенных на него надежд, обновляется слишком, слишком редко.
И вообще как-то не пошло коллективное творчество, большинство тестировщиков, кто активно пишет, предпочитает делать это в личных блогах.
Сейчас думаем, как вдохнуть в эту идею новую жизнь.
Движок для IE переписывается в каждой очередной бете чуть менее чем полностью. Движок для Chrome косячит при заполнении форм. Движок для Safari вообще ещё не сделан. Движок для Opera не запускается на Vista и Win7. В общем, всё ещё сырое. Ну, если только на Firefox надо тестировать — тогда можно, там всё уже достаточно стабильно работает.
Так что всё, что было — осталось. Но добавился новый движок для управления браузером, через нативные API. Рекомендуется использовать там, где Se 1.0 не справляется.
Что касается непонимания менеджерами чаяний тестировщиков, мне помнится, мы в Вами уже спорили по этому поводу где-то в другой теме :) И я приводил ровно тот же аргумент — если менеджер чего-то не понимает, это не потому, что он тупой, может быть просто ему про это никто никогда не говорил. Если менеджер не знает, как правильно ставить цели тестировщикам, не умеет этого делать — надо не обижаться на него за это, а взять и объяснить!
А я со своей стороны дам ссылку на статью тоже же автора «Heuristic Test Planning»: www.satisfice.com/tools/satisfice-cm.pdf
Это статья как раз про стратегическое планирование, про планирование и управление «по целям», а не «по планам».
На самом деле это интересно — почему тестировщикам цель «не ставится в лоб»? Может быть стоит ставить цели чётко, а? А тестировщикам, со своей стороны, прояснять цели? Иначе получается диалог типа «потестируйте тут что-нибудь» — «мы тут кое-что потестировали, вот нашли кое-какие дефеты» :)
Что касается «интуитивного тестирования» — не надо этим термином называть что-то другое. Вы дали Ваше объяснение того, что представляет собой «интуитивное тестирование» в Вашем понимании.
Я придерживаюсь следующего определения «тестирования методом свободного поиска» (exploratory testing), которое можно найти в трудах людей, развивающих это направление тестирования: «одновременное осознание, проектирование и выполнение тестов». Это же определение приведено в Википедии, так что можно считать его достаточно общепринятым.
Взгляд сбоку или сверху тут ни при чём, этот подход прекрасно работает и при взгляде спереди. А также когда ещё не пройдены основные сценарии. А также если цель не в тумане. Это неважно. Принципиально другое — разделены ли во времени действия по осознанию, проектированию и выполнению тестов, или же все эти три деятельности выполняются одновременно.
В области тестирования (как и во многих других молодых и развивающихся областях) терминология пока неустоявшаяся, это создаёт серьёзные проблемы для меня, когда я провожу тренинги. Поэтому я записал этот слайдкаст, в котором я рассказал о том, что я подразумеваю под теми или иными понятиями. Это облегчает дальнейшее взаимопонимание.
Конечно же моё мнение во многом совпадает со мнением других, уважаемых мною авторов, написавших те или иные книги и статьи о тестировании. Да-да, я не всё это сам придумал :) А местами, возможно, с чем-то не совпадает, но они и сами между собой не всегда во всём согласны.
Кроме того, моё мнение во многом (хотя может быть и не полностью) разделяют другие, уважаемые мною тестировщики, например, автор этого поста. Поэтому в определённой степени его можно считать общепринятым :)
В общем, итог — количество слов в описании теста обратно пропорционально потенциальной квалификации тестера.
Эти два утверждения не очень связаны между собой.
Что будет, если у нас те же 40 тестировщиков, но высококвалифицированные? Согласно второму тезису можно писать мало, а согласно первому — много.
А что, если у нас всего 2 низкоквалифицированных тестировщика?
Может быть, Вы хотели сказать своим комментарием, что чем больше тестировщиков, тем выше вероятность того, что среди них будут низкоквалифицированные?
Или хотя бы разрыв в квалификации будет достаточно большим?
Второе, скорее всего, верно. НО! Написание инструкций квалифицированными тестировщиками и исполнение их неквалифицированными не способствует росту квалификации последних. Поэтому я считаю такой подход пагубным, он консервирует существующее неблагоприятное положение дел, не решая проблему низкой квалификации части сотрудников.