Пребываю в жутком бешенстве.
У нас случился затык с организацией автоматизации тестирования. Может быть, потом расскажу, что и как (много специфики), но сейчас мне ПОЗАРЕЗ нужна информация о том, как дизайнить тесты, и особенно в области регрессионного тестирования.
Практика запуска автотестов что в общем режиме (запустил, отошел, вернулся и прочитал логи), что в вспомогательном режиме (в нужный момент запустил что-то типа “быстро сделай такое-то состояние системы”) привела не к ускорению тестирования, а к отвлечениям на их правку и перезапуск. Вопрос “Да что же ты, Макарена ламбадная, не работаешь как надо-то?” в последнее время появляется чаще, чем нужно. Плюс гребанный AJAX.
Это уже раздражает.
Это уже ОЧЕНЬ СИЛЬНО раздражает.
Рррыыыыыыыыыы!
Нужно тесты организовать как-то иначе. Нужно их дизайнить.
Об этом предупреждали товарищи Канер с Бахом в Lessons learned in software testing в уроках 125 ‘Avoid complex logic in your test scripts‘ и 126 ‘Dont’t build test libraries simply to avoid repeating code‘. Единственное предложеное ими решение – грамотный дизайн.
Хорошо. Дизайн тестов – та еще область знаний. Мне ее, судя по затыку, не хватает. Вроде начитался, но результат фиговый.
И начинает раздражать ограниченность Кишинева в этой области. Где тут учиться тест-дизайну?
В Москве и СПб – хоть на икру намазывай – и у Баранцева, такой тренинг, конечно, есть, и у Александрова, и у Панкратова (ладно, он в Киеве, но все-таки). И по деньгам они доступны, хоть вдвойне заплати. И описано все так, что аж скулы сводит в букву “Зю”.
Например, программа тренинга у Баранцева:
- Построение карты функций приложения и проектирование тестов по этой карте. (это я уже сделал, хоть и не знаю, если в правильно формате).
- Разделение областей данных на поддомены (классы эквивалентности), эвристики выбора представителей. (примерно готово.)
- Способы проектирования тестов для цепочек функций.
- Проектирование тестов на основе вариантов использования.
- Проектирование тестов на основе гипотез об ошибках.
- Подход к тестированию, основанный на анализе рисков.
- Комбинирование различных эвристик.
- ** Особенности проектирования тестов для регрессионного тестирования.
- ** Особенности проектирования тестов для автоматизации их выполнения.
- ** Особенности проектирования тестов различных уровней (модульные, интеграционные, системные).
Уааууу! Ну, валяется же все как на блюде.
Но всё это не семинары, это, балин, очные ТРЕНИНГИ! Интерактивные! По 8 часов! В сеть их выстаскивать нереально – это ни в звук записать, ни на слайды положить.
Аааааа!
Аааааааааа!
Аааааааааааааа!
Тысяча Боярских!
Мне снова тестно и неуютно в этой угандийской Молдове!
Ехать самому в Москву, или Баранцева с Панкратовым в Кишинев заманивать, конечно, решение, но очень гусарское.
Кто-нибудь видит решение проблемы?
Алексей, хочу обратить внимание на то, что здесь смешаны два понятия:
1) дизайн (архитектурный) автоматизированных тестов, то есть способ организации программного кода тестов,
и
2) дизайн тестов вообще, то есть формирование представления о том, какие тесты надо выполнить, чтобы можно было считать тестирование достаточно полным.
Конечно автотесты надо сначала “сдизайнить по-тестерски” в смысле придумать, какие именно тесты мы будем делать, а потом “сдизайнить по-программистски”, то есть придумать, как всё это запрограммировать, чтобы уменьшить затраты на сопровождение и устранение косяков.
На тренинге “Программирование для тестировщиков” я рассказываю про первое, и не рассказываю про второе. А на тренинге про “Тест-дизайн” — в точности наоборот. Для гармоничного развития тестировщику-автоматизатору надо принимать и то и другое в равных дозах
Что касается падающих скриптов — рекомендую ещё раз повторить материал занятия, где я рассказывал о том, как сделать операции фреймворка устойчивыми и независимыми от состояния, в котором они выполняются
Ок.
Значит, мне еще надо разобраться в том, с чем именно я столкнулся, чтобы не копать сразу во все стороны
Получается, что у меня слабость в «сдизайнить по-программистски»?
Вот тут : http://code.google.com/p/design-of-selenium-tests-for-asp-net/ я попытался собрать опыт накопленный в области UI тестирования. Правда там все сделано с “программистской” точки зрения
Надеюсь пригодится.
Вот это да!
Спасибо!
Вышеописанная проблема чаще всего возникает тогда, когда тестировщики полностью сами занимаются автоматизацией тестирования, причем речь идет именно о фреймворках, при использовании которых нужно писать код. Код обычно получается замысловатый и действительно при каждом малейшем изменении в приложении, а иногда и без изменений, начинает себя вести неподобающим образом. И тут проблема не в тест-дизайне, и уж точно не в рисках, эвристиках и поддоменах, которыми вы так восторгаетесь.
Все дело в банальном коде, который тестировщики к сожалению пишут хуже программистов. Совет у меня для такой ситуации один – программисты помогают построить доменный язык с использованием низкоуровнего фреймворка и занимаются его поддержкой, а тестировщики пользуются им для написания тестов. При этом происходит обязательное ревью кода разработчиками для КАЖДОГО написанного теста. Тогда тесты приносят много-много пользы. 
Хорошо, что у кого-то руки доходят описать плоды своего труда…
но что-то никак… точнее дока какая-то есть, но показывать её на людях пока стыдно, а кидать голый код в массы не прилично…
Я уже где-то год рожаю идею написания документа или серии статей по поводу автоматизации тестирования, паттернов, фреймоворков и т.д.
Yauheni – respect!
ой, аналогично… я вот начинаю автоматизировать, помогать некому
, и вместе с радостями много слез. Начиная с проблемы эффективного использования времени (написать/отладить/оптимизировать автотест или протестировать вручную важный модуль) до возни с поддержкой, конфигурацией, запуском автотестов…
Для себя пути решения еще не определила. Думаю можно делать выездные сессии “на поучиться”, организовать кружок по интересам…
>> Об этом предупреждали товарищи Канер с Бахом в Lessons learned in software testing в уроках 125 ‘Avoid complex logic in your test scripts‘ и 126 ‘Dont’t build test libraries simply to avoid repeating code‘. Единственное предложеное ими решение – грамотный дизайн.
При всем уважении, товарищи просто не знали, что кроме программирования “в лоб” можно делать это на композитной основе. Аналогия – слои в фотошопе. Каждый слой в отдельности достаточно прост. Их наложение дает сложную картину.
Я использую следующие общеизвестные “слои” (то бишь – модули): GUI recognition, GUI interaction, DB interaction, FSO interaction, data management, data model, verification rules, reporting.
Дополнительно я использую test flow driver и test scenario driver модули.
Для сложных случаев пришлось сделать (и успешно работает) event based driver.
Для максимального возможного расширения покрытия используются элементы Fuzzy Logic, для анализа рантайм параметра Fail Severity.
Сами тесты пишутся на простом, декларативном, домен-независимом языке функционального моделирования. Допускается многоуровневая иерархия, за счет вызова суб-кейсов, использования циклов и условных операторов. XML используется как контейнер и интерфейс, что позволяет создавать дерево теста в режиме визуального программирования, и дает возможность автодокументации (с использованием XSL). Да, тест-репорт тоже генерируется в XML, и может быть показан как веб страница с линками и картинками, или сконвертирован в Ворд или Эксел.
Короче, это hybrid keyword/data driven framework with model-based test language.
Дизайн тестов основывается не на статических тест кейсах, а на динамическом test flow (черт, как же это по-русски?
)
В общем, это “дерево” возможных действий и проверок тестера, с одной точкой входа (обычно, home page или login page) и неограниченным количеством точек выхода, циклы и “движение назад” допускаются. При таком подходе, в принципе, на одно приложение нужен только один тест – “дерево”, но удобнее все же иметь несколько, по одному на бизнес-модуль. (Поэтому отдельные тесты называются Business Logic Components).
Проверка производится через оценку состояния объекта, state model описывается тестером, через константы или параметры, сохраненные в XLS, XML, TXT, или в базе данных. События тоже могут быть параметризованы, поэтому negative tests, которые “укладываются” в “дерево”, не требуют отдельной реализации – по сути, это просто “досрочные” точки выхода.
В заключение хочу сказать, что задачи автоматизации, с которыми я работаю, часто выходят за рамки Web UI automated testing, а потому я использую такие платформы как WinRunner, QTP, или TestComplete для создания решений на базе вышеописанной фреймворк. Но если предложенный метод тест-дизайна кто-то успешно адаптирует для Selenium – буду благодарен за подробности.
Спасибо.
(в панике ищет валокордин)
Алексей, не паникуй, если не спасуешь — скоро у тебя будет звучать всё так же красиво
Только не забывай делать домашние задания
Да вот надо ли, на самом деле, чтобы каждый тестер, или даже каждая компания, создавали automation framework с нуля, мучительно проходя все этапы эволюции оных?
Я бы сказал, мощность и подход к автоматизации должны зависеть от контекста. Самое слабое место – GUI recognition. Если дизайн окон или логика действий пользователя постоянно меняются, то надо писать тесты на уровне API calls (как учит BJ Rollison). Можно Майкрософт воркшоп использовать, или TestComplete. Еще Ranorex подобное вроде хорошо обеспечивает, но с этим тулом я не работал.
Так вот, это же просто неразумно заставлять опытного специалиста, собаку съевшего на черном ящике и эвристиках, да еще со знанием предметной области, изучать си-шарп или скрипт-язык с нуля, дабы начать внедрять автоматизацию.
Зайдем с другой стороны. Уже сейчас многие программы (например, Great Plains) имеют такой сложный протокол коммуникации, что никакой load testing tool не в состоянии подменить клиентскую часть. AJAX тоже выходит на этот уровень. Получается, чтобы выполнять нагрузочное тестирование, придется выходить на уровень GUI? Или ограничиваться самыми примитивными тестами? Насколько мне известно, Microsoft и Google пошли по первому пути… Но не всякая компания в состоянии содержать виртуальный пул из сотен (или тысяч??) компов. Использовать сервис, подобный BrowserMob? Непонятно, как будут решаться вопросы безопасности. И опять-таки, не на тест департмент это же все вешать.
1) К слову об изменениях.
У меня как раз трабла в том, что есть несколько сценариев, в которых изменений нет на протяжении уже многих релизов. Проблема в том, что сервер отдает страницы не прямолинейно, и почти постоянно есть опасение, что загрузка страницы превысит пресловутые 30 секунд, что по-умолчанию в Selenium вписаны.
Пока вижу выход такой простой: при превышении положеного времени Selenium должен не бежать дальше, а перегрузить страницу. Зверство, но пока такое вот видение.
2) Заставлять – да, неразумно. Меня, например, никто не заставлял
(1)
Как насчет waitForCondition() в разных вариациях ?
(Sample: http://wiki.openqa.org/display/SEL/waitForCondition)
Google еще такое дело предлагает: http://googletesting.blogspot.com/2008/10/gui-testing-dont-sleep-without.html
На QTP я использую следуюшую логику
http://automation-beyond.com/2009/08/20/gui-object-synchronization-custom-function/
В любом случае, некоторые страницы невозможно загрузить повторно (например, если это был http Post), так что команду на перезагрузку я бы не отдавал. Если сам браузер ушел в таймаут – это уже проблема.
(2)
Да-аа. Охота пуще неволи. Правда, потом жена ругается “и на работе за компом, и вечером за компом, и ночью за компом”. Хотя нет, иногда я вместо этого на рыбалку уезжаю
Почему бы это и не вешать на тест департамент, если в нем работают Software Developers or Software Engineers in Test? (Во многие конторы, где я проходил интервью в последнее время, требуются в первую очередь знания и опыт разработки, а уже потом тестирования). С другой стороны, если ресурсов не хватает на таких людей, то я думаю, что элементарно записанные и параметризованные скрипты уже смогут облегчить жизнь. (Во всяком случае избавят от некоторых рутинных операций). Но не стоит сразу бросаться писать бешенные фреймворки, тем более не имея в этом опыта. Начинайте с простого и постепенно, набираясь опыта, переходите к сложному!!! И может лет через 5-7 вы напишите свой собственный селениум
Ну и конечно же, перед принятем решения о внедрении какой-либо автоматизации нужно много думать и считать деньги, а то можно влететь в копеечку, не получив никакой выгоды…
Вот.
@Alexey Bulat
Про “вешать”.
Я имел в виду принятие решений о пользовании сервисами 3rd party companies, такими, как BrowserMob. А также юридическую составляющую этих вопросов, вкупе с обеспечением безопасности данных и сохранения интеллектуальной собственности. Здесь не помогут ни Software Developers, ни Test Engineers, если только они попутно не обладают юридическими степенями и связами. Да и с CEO надо быть на короткой ноге, чтобы влегкую утверждать расходы на такое.
У нас в индустрии (т.е. – North America и Торонто в частности), кстати, тоже упор делают на программирование и знание тулов, но я не раз наблюдал, что без знания тестирования такие люди городят трехэтажный код, который дефекты – не находит толком, не обнаруживает где мог и должен был. Я уж не говорю про robustness и maintainability.
А вот насчет Selenium – не соглашусь. Ибо не должна автоматизация сидеть в манежике веб браузера и агукать через fireevent. Пусть лучше это будет седой(больше 10 лет оттрубил! Это эпоха для IT) и бородатый (старый добрый необъектный C) WinRunner в телогрейке десятков патчей, с которым мы любые десктоп приложения держали за интересные места, автоматизировали терминальные окна, цепляли javascript и парсили HTML DOM.
Ну а если брать его преемника QTP, то тут и вовсе раздолье – ибо COM поддерживается.
Практически единственный недостаток таких тулов как QTP и TestComplete – это пошлейший record-playback ориентированный фреймворк, который, впрочем, неоспоримое достоинство для начинающих.
И пошла-поехала эволюционная кривая, о которой я уже говорил (могу повторить: http://www.slideshare.net/agidale/evolving-test-automation-qa-qtp-winrunner-vbscript-presentation)
В общем, эти бесконечные повторения напоминают мне ранние 90-е, когда в каждой конторе сидели программеры и ваяли свои уникальные окошки и кнопки для VGA режима в MS-DOS…
На счет Селена, что да то да… сыроват он еще и до реального Инструмента с большой буквы этого слова – рановато… но ведь и Москва не сразу строилась… Правда если ваш чудо проект – это набор статик HTML то нет смысла в покупке чего-то дорого, хватит и селена
В конце концов, решать как глубоко автоматизировать тестирование должны менеджеры, которые понимают, во что это может вылиться – в какую копейку…
Для автоматизции через GUI не требуется особого сильных зананий в программировании, при автоматизации через API приложения, уже нужно шарить в коде, и уровень тестеров-девелоперов должен быть выше.
Недавно мне расказали, как проходит интервью в гугле для Software Engineer in Test
я поулыбался 
инстурменты автоматизации – НЕ ВАЖНЫ, важно, чтобы ты мог написать аналогичный тул сам 
т.е. придешь ты интервью, а тебе в качестве тест задания дадут написать Selenium или Htmlunit какой-нить… 
состоит оно из двух частей:
1. понимание процесса тестирования, целей и тест дизайна.
2. девелопмент
Но это уже лирика
Вывод одни: “Каждый должен заниматься свои делом!”
Вот…
>> На счет Селена, что да то да… сыроват он еще и до реального Инструмента с большой буквы этого слова – рановато…
Селен хорошо решает ОДНУ задачу, это хороший надёжный драйвер WebUI (со своим делом он справляется гораздо лучше, кстати, чем те же упомянутые коммерческие продукты производства HP Mercury).
Другие задачи — построение модели данных, работа с СУБД, работа с файлами, работа с почтой, работа с API (в том числе через COM или CORBA или WebServices или ещё что угодно) — это всё решается другими средствами, потому что тесты мы программируем на стандартных языках программирования и поэтому имеем возможность использовать любые доступные способы.
Это путь развития некоммерческих инструментов — не комбинирование всего в одном продукте, а построение комплексной системы из модулей от разных производителей.
@Alexei Barantsev
>> Это путь развития некоммерческих инструментов — не комбинирование всего в одном продукте, а построение комплексной системы из модулей от разных производителей.
Кто этим должен заниматься? Программисты? А кто основной проект писать будет?
Или тестеры? А кто основной проект тестировать будет?
Единственный ответ: энтузиасты или тест-консультанты. А здесь уловка в том, что расходы на девелопмент В ИТОГЕ ПРЕВЫШАЮТ стоимость покупки готового тула, который все равно мощнее, и имеет техподдержку. Сравните OpenSTA и NeoLoad, например.
Что Selenium может и не может, сравнивая с другими тулами:
http://knol.google.com/k/test-automation-tools-comparison-matrix
Захотелось привести некоторую аналогию…
есть ОС Windows, где практически все есть и работает стабильнее всех, но денег стоит…
есть OCи на базе UNIX, где есть много чего, но все собирать надо. Занете ли такой конструктор “собери меня сам” (причем не факт, что детали из одного набора)… зато бесплатно…
Вот перед пользователем и стоит вечная делема: “чем пользоваться?”
И выбор делает уже на основе личных предпочтений…
@Alexei Barantsev
>> Селен хорошо решает ОДНУ задачу, это хороший надёжный драйвер WebUI (со своим делом он справляется гораздо лучше, кстати…
Ну это очень спорный вопрос.
XPath-based recognition – это сплошной хардкодинг, который сильно повышает затраты на содержание скриптов. А что насчет динамического распознавания GUI? Pop-up dialogs которые не часть Web GUI, но часть Web Application’s GUI?
Selenium – это метод автоматизации “в лоб”. Простенький и поверхностный, не рассчитанный на долгосрочное пользование.
XPath-based recognition — это личный выбор каждого, не хотите не пользуйтесь, идентифицируйте CSS-локаторами, или по именам/идентификаторам элементов, если они есть. Или используйте расширения UI-Element или Tellurium. Или напишите собственную библиотеку локаторов, наконец.
Хардкодить локаторы тоже никто не заставляет — вынесите карту элементов в конфигурационный файл, на нормальном языке программирования же пишете, в чём проблема?
Никогда не сталкивался с проблемой динамического распознавания GUI, может быть имеется в виду AJAX?
Что касается “нативных” диалогов — ещё раз хочу повторить: Selenium хорошо решает ОДНУ задачу, это хороший надёжный драйвер WebUI, остальные интерфейсы доступны через другие библиотеки.
Selenium — это не метод автоматизации, и даже не инструмент, это всего лишь библиотека-фреймворк, позволяющая организовать взаимодействие программного кода с браузером. Не надо ожидать от него, что он ещё будет петь и плясать.
А долгосрочность определяется тем, что и как пишет тестировщик, а не тем, какими инструментами он пользуется. Я видал не один десяток мертвых тестовых наборов, написанных с использованием как коммерческих, так и бесплатных инструментов. И что поразительно — практически во всех случаях в качестве оправдания использовалась фраза, что мол это нам инструмент такой плохой достался, а вот если бы мы использовали XXX, вот тогда бы мы сделали огого! Увы, смена инструмента не поможет.
@Alexei Barantsev
>> А долгосрочность определяется тем, что и как пишет тестировщик
Пожалуй, это и есть единственный момент, где я действительно не согласен.
Что прелесть open source в том, что можно все сделать и переделать – согласен. Что Selenium (в связке с другими средствами) может достичь какой угодно мощности – согласен, и знаю примеры. “Инструмент плохой попался” – детское объяснение, согласен.
Но вот насчет того, что тестировщики должны писать библиотеки, расширения, и фреймворки – не согласен.
Тестировщики должны писать (дизайнить) ТЕСТЫ. Использовать результаты авто-тестов (и не тратить время на подпинывание хромающих скриптов).
Вся вот эта (хотя и нужная, и важная) рутина (модель данных, репортинг, маппинг, и пр., и пр.) – не должна отвлекать от главной работы – тестирование ПРОДУКТА.
> Но вот насчет того, что тестировщики должны писать библиотеки, расширения, и фреймворки – не согласен.
Альберт, этот Ваш комментарий, на мой взгляд, явно противоречит самому первому, про “hybrid keyword/data driven framework with model-based test language”
@Alexei Barantsev
Почему?
Вот как раз “model-based test language” к работе тестировщика и относится. А “hybrid keyword/data driven framework” относится к работе инженера по автоматизации, или же консультанта, который всегда “и жнец, и швец, и на дуде игрец”.
Скажем, работая в должности Regression & Automation Lead, я имел в отделе 4 QA аналитика, все они писали тесты на метаязыке, и только одна из них помогала в расширении фреймворк. Regression testing представлял из себя прогон скриптов после каждого билда (smoke test), и прогон скриптов на входе-выходе билда из каждого test environment (sanity test). Найденные проблемы, естественно, изучались вручную, равно как и свежие багфиксы. ПЕРЕД автоматизаций нового дерева логики осуществлялся эксплоратори тестинг бизнес-функции, в процессе которого и создавался новый тест.
Остальные 12 QA в других отделах, равно как и наши коллеги в UAT, не писали ни фреймворки, ни тесты. Они настраивали под свои нужды и запускали (автоматические) тест планы, расширяли набор тест данных, пользовались результатами, и давали заявки на новое покрытие. Сам проект двигался в Waterfall, автоматизация, естественно, в схеме Agile. Вообще, при автоматизации, быстрый фидбэк тестеров – главное дело.
Таким образом, на 20-30 человек, занятых в тестинге, непосредственно с тулом и кодом работало двое, и еще двое активно участвовали в тест дизайне. Они и продолжают работать по внедренной мной схеме, благо фреймворк создан, отточен в процессе интенсивного использования на 3 релизах, и нового кода писать не требуется. Только тест-дизайн.
Когда работаешь консультантом, ситуация несколько иная. Клиент ждет решения конкретной задчи. Здесь приходится работать, как правило, одному и поэтапно: изучение проблемы, выбор средств, внедрение фреймворка, создание тестов и выдача результатов. Как правило, на двух последних этапах подключаются штатные QA-BA, осваивают ИСПОЛЬЗОВАНИЕ системы, участвуют в тест-дизайне и создании базы тест-данных. Поскольку к тому времени автоматизация уже активно используется в проекте, все компоненты проходят необходимую обкатку, сотрудники приобретают навыки работы (с автоматизацией), проект получает полезную отдачу (от автоматизации), а менеджер – уверенность (в автоматизации).
PS. Вышеописанные примеры относятся к функциональному тестированию.
Автоматизация задач на бэк-энде, нагрузочное тестирование, API / Unit тесты – имеют свою специфику и циклы, и реализуются по-другoму.
Значит мы просто по разному называем роли. Вы тяготеете к тому, чтобы “инженера по автоматизации” не называть тестировщиком, а с моей точки зрения все, кто имеют целью своей работы не создание продукта, а создание тестов — тестировщики, в широком смысле этого слова.
Но конечно же я не могу не согласиться, что разделение по специализации внутри команды тестирования возможно и зачастую необходимо. И не только по видам тестирования, но и разделение на “труэ тестировщиков” и “toolsmiths” (http://www.satisfice.com/blog/archives/15)
Ну вот, только вроде достигли согласия во всем
Цитата из Баха.
“…think of test tools as any tool that may help (especially cheap or free tools). Avoid expensive tools…”
Дело в том, что время зачастую все-таки гораздо дороже, чем деньги, и это главная проблема cheap free tools. С ними всегда нужно слишком многое строить с нуля. Да, Loadrunner тянет на десятки тысяч долларов, но с ним можно выдать все решающие тесты за неделю. Если сам проект имеет бюджет в сотни (или больше) тысяч долларов, а релиз через полгода – некогда огород городить.
Вторичная проблема при построении с нуля – тяжело поддерживаемый код. Настолько тяжело, что зачастую приходится его выбрасывать и начинать по новой. Никакого проджект-менеджера это не обрадует, и все это идет в минус автоматизации.
PS. Есть еще одна уловка в той цитате. Месячная оплата дорогого консультанта может запросто превысить стоимость лицензии коммерческого тула – с использованием которого процесс автоматизации может быть сокращен вдвое, а результаты будут весомее.
Согласия в чём?
Я не собираюсь переходить к обсуждению вопроса “платные против бесплатных” (хотя всем, думаю, понятно, на какой я стороне).
Я говорю конкретно за Selenium и могу повторить ещё раз: Selenium хорошо решает ОДНУ задачу, это хороший надёжный драйвер WebUI, остальные интерфейсы доступны через другие библиотеки.
Поэтому бессмысленно называть его словом “инструмент” и сравнивать с другими “инструментами”.
Платформа для написания тестов с использованием Selenium — это Java или .Net или ещё один из почти десятка доступных языков программирования. Вот на этом уровне и надо сравнивать. Включая средства разработки и отладки. Включая возможность запуска в различных окружениях. Включая возможность использования и наличие готовых библиотек.
Я не забываю. Я не успеваю вовремя. Стыднее стыдного
Выход из рекурсии
Вот здесь небольшой клад закопан: http://www.io.com/~wazmo/qa/
Особенно рекомендую следующие статьи оттуда.
“Intelligent Test Automation” http://www.scribd.com/doc/9131590/Intelligent-Test-Automation
“Seven Steps to Test Automation Success”
http://www.io.com/~wazmo/papers/seven_steps.html
“When Should a Test be Automated?” http://www.visibleworkings.com/papers/automate.pdf
Cheers!
К теме – великолепная статья от Гойко Адзич.
“How to implement UI testing without shooting yourself in the foot”
http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/
Обратите внимание на линк: Robot Framework.
>>Ехать самому в Москву, или Баранцева с Панкратовым в Кишинев заманивать, конечно, решение, но очень гусарское.
Кто-нибудь видит решение проблемы?
==
А в чём проблема вызвать того же Панкратова в Кишинёв? Насколько я помню “стоимость”, что-то окол 1000-1500 $/E
Это за 8 часовой тренинг, насколько мне не изменяет, опять таки, моя память.
Найти 10-15 человек готовых потратить 100 у.е. в Кишинёве сложно? Лично я бы потратил, при условии что тематика будет меня интересовать.
Немножечко сложно. Поэтому проблема.
Но я проблему уже решил, затащив лично Баранцева в скайп.
Мне одному опять кажется, что этот пост — реклама тренингов Алексея баранцева?
Или мне уже лечить параною?
Какая уж там реклама.
Просто неровное брюзжание на тему “заколебался жить в Молдове, вдали от всего интересного и происходящего”.
Довольно информативный тред – What are your Selenium challenges?
http://www.softwaretestingclub.com/forum/topics/what-are-your-selenium
Участники обозначили проблемные области и делятся своими решениями.
(в сторону) я ж говорил, data-driven testing невозможно без встроенной модели данных с полной поддержкой сервис-методов.