Coded UI родной со студии. Более чем ок. Если об этом речь. Для остального там инструменты тоже ок вполне.

Тестирование должно быть :)

Кому должно?

Ой. У меня вообще SDET написано. Как дальше жить?

Трудовая книжка в наше время это такой совковый рудимент который ни о чем не говорит.

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

Это рудимент полицейского государства. Как прописка, например. Или то что у вас единственное удостоверение личности это паспорт, на котором важен номер, а не фото. Вне постсоветского пространства аналогов тащемта не очень много. Мои взаимоотношения с работодателем фиксирует контракт. В контракте пишут другие вещи. Но тут наше законодательство тоже весьма отстойное.

Каждый выбирает для себя .....
если нравится жить вне правового поле - то никто и не заставляет.


Интересно просто - а в каком документе "У меня вообще SDET написано" ?

Ок, в трудовой "Инженер Разработчик по Тестированию", кажется. На прошлой работе не помню что, но тоже мягко говоря ничего не говорящая надпись. SDET это, кажется, в головном офисе в японии я по документам так прохожу.

А правовое поле... ну смешно, да. Если я фрилансом займусь у меня вообще пустота в трудовой будет. Я получается тестировщик-никто?

До ваших переходов по факультетам никому нет дела. У нас есть парень, который в принципе - археолог, однако адекватно тестирует и не парит себе самосознание.

Я знаю как минимум одного филолога из тайги который в NativeDriver репы коммитит...

Другое дело, что многие начальства почему-то убеждены что в IT можно только технарям.

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

Чем-то напоминает старое доброе:

Здраствуйте. Я, Кирилл. Хотел бы чтобы вы сделали игру, 3Д-экшон суть такова...

А зачем менять ip клиента? Request lib в руки и копать.

Робинсон навеял пару идей, хоть и довольно тривиальных:

Робинсон вообще классный и у него есть чего еще на сайте пошарить. В принципе все что вы тут про графы написали у него там есть и даже больше :). И что самое примечательное, то большая часть "умных" тестов по моему личному опыту довольно простые и в техническом плане и идея сама (хотя идея очень часто не очевидна, тут ньюанс, да).

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

Ну просто далеко не все могут позволить себе собирать такую статистику с пользователей/бета-тестеров. Просто потому что их еще нет, например, а риски выпустить не очень хороший билд даже в бету довольно серьезные. Но это обычно узкоспециализированный софт или всякие карты/поиски и т.п. как у Робинсона (хотя это уже вопрос тестирования UX скорее).
Опять же - поведение разных юзеров может сильно отличаться. Бывает что то что делают бетатестеры совсем не похоже на то что в итоге они будут делать с релизной версией. Да, баги они найдут. Может буть. Но оценить их полезность бывает весьма сложно, потому что "эндюзер хочет странного от продукта".
Ну и для десктопных приложений зачастую довольно затруднительно собирать статистику, поскольку прямого подключения у вас нет, а любой честный буржуй от таких предложений обычно начинает сильно параноить.

UPD: Заодно и Леше ответил)

Не соглашусь. 10+ лет назад я начинал работать тестером в компании Тугезерсофт. Делали UML/CASE тул (кстати никто еще лучше так и не сделал). В программе был специальный механизм для отсылки фидбека, если выскочил java exception.
Присылали и много. Мой коллега даже написал автосабмитер таких багов, который конечно дупликаты умел находить. Фиксили их кстати тоже, а не забивали.
Причем иногда до интересного доходило, разработчик видя стэк-трейс мог рассказать как баг воспроизвести можно. А иногда никто не понимал почему программа вырабатывала исключение в месте, где его не ожидалось.

Ну это немного не то). Такое есть и в общем-то практически повсеместно. Сами похожее используем (даже какую-то логику накрутили чтобы оно автоматом сотни дубликатов не плодило в багтрекере). Но статистику толком так собрать не получится. И опять же:
1. Unhandled Exception'ы такие штуки не ловят. То есть если мы где-то что-то недозавернули, то мы об этом можем никогда и не узнать, а у пользователя случится ой и он будет ругаться в саппорт.
2. Мы так можем получить только баги которые явно приводят к ошибке. Косяки бизнес-логики когда приложение ошибок не выдает, но работает некорректно мы так отловить не сможем.
3. Мы себя ограничиваем сильно по компонентам программы. Для инстоллера придется писать свою, да и то врятли получится. Если компонент куча, то не всегда есть возможность собирать со всех информацию в кучу, а баг случается на взаимодействии часто.
4. Это все же не статистика. Это какая-то довольно странная выборка, хоть и в определенном смысле интересная.

Ненене. Я про всякие oracle based тесты и прочее. Как у Робинсона про тестирование карт и подсказок поиска.

Есть еще нормальная тема про тестирование верстки и автоматизацию UX тестов. Harthy недавно очень годный доклад на эту тему читал про то как они на ибее это запилили.

Html5 тоже решаемо для кроулеров.
Ну и обычный кроулер делает не базовое тестирование верстки (даже не по чеклисту, кроулеры нынче умные и некоторые даже JS пускать могут по поводу и без), а тупое сравнение DOM (до и после), а это совсем не торт.

Про робинсона и Harthy вот например:
http://www.harryrobi...mation-CAST.pdf
http://blog.betterso...ttachment_id=24

UPD: А вообще оба предложения от вас в этом топике пока сводятся к записи за бета-тестерами. Меня это несколько настораживает.

Ну давай про автоматизацию exploratory тестов, чо

Ну а мы ему в ответ: "Это свойство системы. Именно такой она и разрабатывалась."

Главное чтобы это было желаемое (кем?) и ожидаемое (кем?) свойство системы. Иначе это проблема, причем, возможно, очень серьезная.

While condition и regex extractor. Я так, на память, т.к. под рукой нет

Тесты на php, откуда там TestNG :)

php биндинги на TestNG <_<

Присоединяюсь к предыдущему вопросу. Все равно раньше лета никак не смогу ничем серьезным заняться)

Ну и в контексте топика все равно упираемся в вопрос:
- а какие же наши цели?
- какие тесты хотим писать?
- куда в конечном итоге хотим прийти?

Эти вопросы к выбору языка отношения не имеют (хотя сами по себе полезные, да).

Если коротко по выбору языка, то:
1. Выбирать надо то что лучше знаешь.
2. Если ничего не знаешь, то выбирать то, что проще учить (python/ruby, имхо).

Под веб сейчас во всех языках уже столько ништяков готовых есть, что сравнивать их наличие/отсутствие занятие бесполезное.

В остальном все такие метания и топики это наглядная демонстрация Парадокса Эрроу. Другими словами - пустая трата времени.

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

Без браузера нет JS. Так что палка о двух концах.

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

Это быстро, особенно если надо только для себя. К тому же весьма небесполезное знание.

ЗЫ: Топикстартеру пофиг, флудим дальше.

не ерунда , увы)
на практике проверено и не единожды.)

Я к тому что:
1. В половине случаев это тестирование чужого сервера/клиента вашими письмами (как правило HTML формат и все такое).
2. В другой половине случаев это проверка интернетов.
Выполнять надо соответственно. Регистрация совсем не обязательна, достаточно письма отправлять.

Для тестирования того что ваша софтина работает корректно сама по себе достаточно локального почтового сервера (можно и без него, но тут объяснять дольше).

А в чем смысл? Получать по этим адресам много почты или что?
Можно поднять свой почтовый сервер - дешево и сердито.
Если получать ничего не надо, то и создавать ничего не надо - просто слать письма с разными мылами и все.

вы сможете гарантировать что пользователи отправившие запрос на регистрацию в яхо, яндекс, рамблер и пр получат письма? -нет
что там корректно распознается текст?- нет
что там корректно сработает переход по ссылке ?-нет
что приложенные изображения корректны, и открываются? - нет
что письмо пришло через Х секунд а не Х часов? -нет

Это, простите меня, ерунда полная.
POP3 как был POP3 так им и останется. И локальный это сервер или сервер Яндекса - ничего не изменится.
А все остальные ваши страхи проверять кроме как с продакшен ноды смысла нет - потому что интернет роутинг такой интернет роутинг. Кстати, пытаясь ответить на большую часть этих вопросов проверять вы будете в именно его. Но это сомнительное развлечение на долгосрочную перспективу, т.к. Сеть меняется не уведомляя вас и ведет себя плохо тоже без спросу.

на моей практике была ситуация когда на почте 15 (именно 15-ое) отправленное письмо приходило через 24 часа.
проверить это можно было только создав 15,30, 45 и + ящиков на данной почте к примеру.

Это была ваша проблема или проблема чужого сервера?

получение ответов каких то писем, рассылок, исходя из моей практики нужно тестировать именно вручную "наживо" в Х почтах и ящиках.

При этом работающее приложение вам в принципе не нужно для этого, т.к. фактически вы проверяете thirdparty клиенты (имеет смысл, наверное) и сервера + как до них идет ваша почта.