2013-11-02

Самотренинг по автоматизации. Локаторы элементов.

Содержание.

Что это?
В плоскости автоматизации тестирования это что-то, что помогает найти элемент на странице или на форме: id, name ... .

Какие локаторы хороши?
  • Простые и понятные;
  • Устойчивые/гибкие и универсальные;
  • Быстрые;
  • При необходимости позволяющие задавать сложные условия поиска («3-й сверху во второй таблице слева...»).
Какие бывают?


Проще, лучше, быстрее найти элемент по id или name. Предполагается, что id/name уникально, хотя так и бывает не всегда. Чуть менее надёжно искать по другим атрибутам: классу, типу и т.д.. Сложнее потому что гарантий уникальности много меньше. Более изощрённый подход- использование CSS Selector-ов, а уж совсем вершина вершин - XPath.


Ссылки.
[1] http://www.georgehernandez.com/h/xComputers/XML/XSL/XPath.asp
[2] http://www.w3schools.com/xpath/default.asp
[3] http://www.zvon.org/xxl/XPathTutorial/General_rus/examples.html
[4] Набор шпаргалок. Очень ценно на практике - http://extract-web-data.com/5-best-xpath-cheat-sheets-and-quick-references/
[5] Кое-какие откровения на тему посика элементов в таблицах -  http://autotestgroup.com/ru/blog/85.html
[6] Видеолекция по CSS selector + XPath http://www.youtube.com/watch?v=ahhaMbjqrxM

Самотренинг по автоматизации. Введение в Луний.

Содержание.

Что это?
Луний он же Selenium, он же WebDriver, он же Selenium2.0, он же Selenium WebDriver это:
  • Библиотека;
  • API для управления браузером;
  • Стандарт W3C.
... и с учётом всего этого он/она/оно вовсе не инструмент автоматизации тестирования.

Что умеет?
Довольно много:
  • Находить элементы: By.Id, By.Name, By.Xpath, By.TagName, By.ClassName, By.CssSelector, By.LinkText, By.PartionalLinkText;
  • Нажимать кнопки, изымать текст, выбирать из списков; 
  • Поддерживает: FF, IE, Chrome, HtmlUnitDriver, ... ;
  • Ждать: Explicit Waits, Implicit Waits;
  • Много чего ещё … .
Достаточно ли этого для автоматизации? Это огромное подспорье, но наш каркас для тестирования требует ещё механизмов структуризации кода, запуска и останова, журналирования, генерации отчётов и т.д. Всё это обеспечивается уже не Лунием, а вещами вроде Maven/Gradle, TestNG/JUnit/NUnit и пр. и пр:

Ссылки
Нет смысла писать ещё одну статью, их за годы скопилась огромная масса. Крайне рекомендую перелопатить немного МежСеть самостоятельно и "сформировать картинку".

[1] http://docs.seleniumhq.org/
[2] http://bugscatcher.net/archives/1232
[3] http://habrahabr.ru/post/152971/
[4]http://refcardz.dzone.com/refcardz/getting-started-selenium-20
[6] http://habrahabr.ru/search/?q=selenium

2013-10-20

Cамотренинг по автоматизации. Подходы: модельный и гибридный.

Содержание.

Модельный подход.
Основная идея этого подхода - разработать и применять некую модель тестируемой системы, которая представляет собой набор требуемых поведений / функций этой системы. В идеале такая модель предоставляет готовые тестовые случаи, которые при минимальных усилиях превращаются в авто-тесты. Звучит фантастически, особенно учитывая то, что разработка такой модель может быть значительно сложнее разработки самой системы. Чуть больше подробностей сообщает педекивия.

Гибридный подход.
Гибридный подход, как следует из названия, это смесь того, этого и ещё вот того самого. Это то, что чаще всего встречается на реальных проектах и имеет практическую ценность. Это означает, что по мере надобности и в силу рациональных причин авто-тесты используют элементы различных подходов (функциональная декомпозиция, объектный, тесты управляемые данными и т.д.). В таком случае часто невозможно однозначно сказать, какой же именно из подходов превалирует - все они используются в разных тестах в той мере, в которой это целесообразно.

Cамотренинг по автоматизации. Подходы: объектный.

Содержание.

Объектный подход.
 ООП уже многие годы стандарт де-факто в разработке ПО. Объекты в программировании служат отражением объектов реального мира, а объекты в автоматизации отражают элементы тестируемого приложения: формы, страницы, т.е. части графического интерфейса. Однако   "отражают" означает не только наличие таких же полей, но предоставление неких сервисных методов, например logout(). "This reduces the amount of duplicated code and means that if the UI changes, the fix need only be applied in one place."

Пример: класс LoginPage моделирует(отражает) страницу входа в систему. Соответственно этот класс должен обеспечивать доступ к полям "имя" и "пароль" или даже предоставлять метод по авторизации в системе. Очень наглядный пример объектного подхода это шаблон "PageObject".

"За".
+ Структурированное и расширяемое решение, что ведёт к снижению стоимости поддержки;
+ Все "плюшки" ООП.

"Против".
- Надо знать и применять ООП;
- Чрезмерное увлечение программированием может привести к "коду ради кода".

2013-10-15

Yet another traffic lights - CI status indicator.


 Nowadays Continuous Integration is popular and almost a “must-have” on a serious project. The only question is - what is your current CI status? How to make it visible? E-mails are good, but let’s be honest, nobody reads all those tons of “build failed/back to normal” messages. There is a need for some funny and unobtrusive way to let anybody know what’s the status in a, say, second. So, we’ve got “Traffic Lights CI status indicator”:

- visible;
- funny;
- it has DIY appearance(look at that fastening adhesive tape all over it!);
- a bit environmental - an old colour music box was reused;
- portable (about 1 kg, it’s really light);
- inexpensive (~25 pounds).

The workflow is simple: homemade client application checks CI status and sends “turn on red and turn off green” like messages to the microcontroller, the microcontroller turns on/off corresponding bulbs. As for the colours: “green” means everything is good, “blue(yellow)” means we’ve got some test(s) failed and “red” means that it’s time to hurry up since something is completely broken. That’s all.





2013-03-23

Cамотренинг по автоматизации. Подходы: ключесловный и поведенческий(keyword-driven, behaviour-driven).

Содержание.

Тесты на основе ключевых слов(кeyword-driven).
 Практически всегда автоматизированное тестирование это штука дорогая и сложная, а "экономика должна быть экономной". Автотесты на основе ключеслов (keyword-driven testing) это как раз та техника, что призвана снизить стоимость за счёт привлечения к написанию собственно тестов технически слабоподготовленных лиц разнообразной национальности.

Ключесловное тестирование (называемое також "чрезтабличное", "на основе действий", "деесловное"(table-driven, action-driven or action-word)) очень схоже с тестированием управляемым данными, является в какой-то степени его продолжением и расширением. Основная идея - разделить автоматизацию тестирования на две неравные по времени и стоимости части: написание собственно тестов в виде последовательности ключевых действий и реализацию(создание инфраструктуры).




 Написание тестов подразумевает описание тестовых сценариев в табличном виде, где каждая строка состоит из ключевого слова описывающего некое действие и каких-либо данных. Возможны, естественно, вариации: нет данных, добавлены комментарии и пр.. Такую задачу могут выполнять технически слабые специалисты, знакомые с предметной областью тестируемого приложения. За счёт этого написание собственно тестов становится относительно недорогим.

 Создание инфраструктуры заключается в
  1. написании реальных классов, методов, скриптов тестирующих приложение;
  2. трансляции ключевых слов из просто текста в вызовы тех методов, запуск нужных скриптов и т.д. .
Эта часть подхода требует технически грамотных (читаем "дорогих") сотрудников. Зато таких "грамотеев" нужно много меньше, чем писателей тестов.

Таким образом получаются две условно независимые части: тесты в виде таблиц и код, который собственно "нажимает кнопки" и проверяет результаты.


Тесты на основе поведений (behaviour-driven).
 Дальнейшее развитие это техники, которое всё больше набирает популярность это тестирование на основе поведений(behaviour-driven). Всё практически то же самое, только тесты не только в виде таблиц, но и в виде структурированного текста. Например:

Test Case
  Valid Login
Step
  Given login page is open
  When valid username and password are inserted
  and credentials are submitted
  Then welcome page should be open [9]

Given, When, Then - фактически зарезервированные слова, определяющие структуру, описывающее то самое поведение.

Тесты теперь могут писать вообще кто угодно, например аналитики, главное чтоб соблюдали структуру.


"За".
+ Можно быстро создавать новые тесты(при наличии инфраструктуры);
+ "Не-технари" могу писать тесты, что снижает стоимость и теоретически ускоряет процесс;
+ благодаря популярности этих подходов появилось приличное количество практически готовых к немедленному использованию инструментов. С ними создание инфраструктуры упрощается на порядки.

"Против".
- Создание гибких решений может быть трудным;
- Те немногие технари, пишущие инфраструктуру, должны быть достаточно сильны в программировании.


С помощью чего?
1. FitNesse - уже ветеран ключесловного тестирования от ветеранов же тестирования и разработки.
2. RobotFramework - каркас для ключесловного, на основе поведений и т.д. тестирования. Рождён на сумрачных берегах не менее снежной Финляндии.
3. Cucumber - подозрительно пафосный каркас для тестов на основе поведений.
4. JBehave - ещё один поведенческий каркас.



Ссылки.
[1] http://www.automatedtestinginstitute.com/home/index.php?view=article&id=%2066&option=com_content&Itemid=1000
[2] http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&catid=45:2nd-generation-frameworks&id=65:data-driven
[3] http://softwarequalitysource.com/AutomationTypes.html
[4] http://en.wikipedia.org/wiki/Model-based_testing
[5] http://www.slideshare.net/nashjain/test-automation-strategies-for-agile
[6] http://en.wikipedia.org
[7] http://code.google.com/p/selenium/wiki/PageObjects
[8] В поисках качества кода: Знакомство с Behavior Driven Development (BDD)
[9] Пример поведенческого теста: http://robotframework.googlecode.com/hg/doc/userguide/RobotFrameworkUserGuide.html?r=2.7.6#different-test-case-styles

Содержание.

2013-03-18

Cамотренинг по автоматизации. Подходы: данные правят(data-driven).


Тесты управляемые данными (data-driven).
Представьте, что пишете тест для странички входа в систему. Какие шаги в этом тесте? Скорее всего что-то в духе:
1. Open Login Page;     
2. Type in %username% in the @usernamField     
3. Type in %password% in the @passwordField     
4. {Verify} Current page is the expected one.

Это обобщённое описание, т.е. на шаге 4 ожидаемой может быть домашняя страница(если имя/пароль были верными) или страница с ошибкой, если имя/пароль были неверны. Шаги одни и те же, только вводимые символы и ожидаемые результаты разные - разница в данных. Логично разделить код (шаги) и данные, чтобы можно было один и тот же тестовый скрипт прогонять для разных входных и выходных значений - тест будет управляться данными.


Для таких тестов (data-driven tests) обычно существует некий источник данных (Экселевский файл, БД, CSV-шный файл и т.д.) и параметризованный скрипт/тест, которому данные из источника "скармливаются"  строчка за строчкой (по факту 1 строка = 1 тест ).

Самый яркий пример использования этой техник - в модульной тестировании. Например, есть метод, делящий одно число на другое. Модульный тест рационально написать "ведомым", подавая на вход 3 значения: делитель, делимое и ожидаемый результат.

"За".
+ один и тот же код для множества случаев - легко поддерживать;
+ легко изменить(увеличить или уменьшить) покрытие, надо лишь изменить таблицу с данными, обычно не требуется даже компилировать код тестов.

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

С помощью чего?
1. TestNG и JUnit: http://blog.varunin.com/2011/10/data-driven-testing-using-junit-and.html

2. NUnit начиная с версии 2.5.0 поддерживает некоторое количество полезных атрибутов:  http://nunit.org/index.php?p=testCaseSource&r=2.6.1



Ссылки.
[1] http://www.automatedtestinginstitute.com/home/index.php?view=article&id=%2066&option=com_content&Itemid=1000
[2] http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&catid=45:2nd-generation-frameworks&id=65:data-driven
[3] http://softwarequalitysource.com/AutomationTypes.html
[4] http://en.wikipedia.org/wiki/Model-based_testing
[5] http://www.slideshare.net/nashjain/test-automation-strategies-for-agile
[6] http://en.wikipedia.org
[7] http://code.google.com/p/selenium/wiki/PageObjects


Содержание.


Cамотренинг по автоматизации. Подходы: функциональная декомпозиция.

Содержание.

Функциональная декомпозиция.
"Термин 'функциональная декомпозиция' описывает процесс выделения модульных компонентов(функций определяемых пользователем) при котором авто-тесты создаются преимущественно комбинированием уже существующих компонентов."[1].

Функции-модули это строительные блоки, "кирпичики", из которых собираются новые тесты. Т.е. не стоит в каждый скрипт, класс и т.д. "напихивать" один и тот же код(да, да, любимый шаблон разработки "скопировать/вставить" использовать вредно). А стоит выделять переиспользуемые функции/процедуры(registerAUser(), login()) которые напрямую соотносятся с функциями тестируемого приложения. А уже авто-тесты будут состоять из вызовов этих процедур в требуемой последовательности.

Различают:
- Утилитные(вспомогательные) функции/скрипты - повторно используемые подпроцедуры, используемые более чем одним авто-тестом. Например процедура login() скорее всего будет использоваться большинством тестов;
- Навигационные скрипты - набор подпроцедур вида “goToPage/Screen()”. По большому счёту это те же вспомогательные функции, только узкоспециализированные;
- Процедуры проверки(верификации) - содержат код для проверки(верификации) бизнес-логики;
- "Водители"(Driver scripts) - вспомогательные функции, которые не относятся к тестированию напрямую, но обеспечивают собственно прогон тестов: инициализацию, выполнение пред- и пост-условий, выполнение других скриптов/шагов в требуемом порядке.

"За" и "против":
+ повторно используемый код;
+ независимость скриптов (сами тесты независимы и не переиспользуются).

- технически сложнее, чем "записал/выполнил";
- смешиваются данные и код.

Ссылки.
[1] http://www.automatedtestinginstitute.com/home/index.php?view=article&id=%2066&option=com_content&Itemid=1000
[2] http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&catid=45:2nd-generation-frameworks&id=65:data-driven
[3] http://softwarequalitysource.com/AutomationTypes.html
[4] http://en.wikipedia.org/wiki/Model-based_testing
[5] http://www.slideshare.net/nashjain/test-automation-strategies-for-agile
[6] http://en.wikipedia.org
[7] http://code.google.com/p/selenium/wiki/PageObjects


Содержание.

2013-03-09

Cамотренинг по автоматизации. Подходы, техники и каркасы.

Содержание.

Подходы.
Два основных глобальных подхода к автоматизации тестирования:

- На уровне кода/Программного интерфейса приложения (Code-driven/API based);
- Посредством ГИП (GUI-based).

Первое (тестирование на уровне кода) подразумевает использование того или иного вида доступа к классам, модулям, сервисам и т.д. для ввода исходных данных и получения результатов с последующей их проверкой. Примером может служить модульное тестирование (unit testing), позволяющее "определить работают ли различные части исходного кода так как ожидается в различных условиях.". Другой пример - тестирование веб-сервисов путём вызова открыто доступных методов  этих сервисов.

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

Автоматизированное тестирование через графический интерфейс часто "легколомаемо" и чувствительно к изменениям в самом графическом интерфейсе.  Недостаточно хорошо спроектированный тест может потребовать полной переделки при казалось бы пустяковом изменении названия кнопки.

Каркасы.
В историческом разрезе множество вещей в технике проходит путь от хаоса к какой-либо системности. Разработка ПО идёт той же тропой - от хаоса первых попыток к более-менее логически и практически обусловленной системе. Каркасы (frameworks) широко применяются в разработке собственно ПО и имеет смысл следовать этому же подходу в автоматизации тестирования, так как по сути последняя есть разработка программного обеспечения особого сорта. Что такое "каркас"? Согласно педевикии: “...a software framework is an abstraction in which software providing generic functionality can be selectively changed by user code, thus providing application specific software. It is a collection of software libraries providing a defined application programming interface (API).”. Далее, "каркас автоматизированного тестирования это набор концепций, предположений и инструментов который обеспечивает поддержку автоматизированного тестирования.". Также, каркас в автоматизации позволяет ускорить и/или упростить разработку новых тестов и поддержание уже существующих в актуальном состоянии.

Каракас должен обеспечивать:
- механизм для организации и структурирования тестов: пред- и пост-условия, зависимости и прочее;
- механизм контроля тестируемого приложения или механизм доступа к этому приложению (запуск, останов и т.д.);
- механизм выполнения самих тестов;
- механизм проверки полученных результатов;
- механизм логирования/журналирования и генерации отчётов.

Известны несколько методологий автоматизации тестирования и построения каркаса:
 - Запись-и-Воспроизведение (Record & Playback) - НИКОГДА не используйте на реальных проектах;
 - Функциональная декомпозиция (или Разбиение на модули);
 - На основе данных (Data-driven);
 - На основе ключевых слов (Keyword-driven);
 - Объектный подход;
 - На основе моделей;
 - Смешанный подход.

Ссылки.
[1] http://www.automatedtestinginstitute.com/home/index.php?view=article&id=%2066&option=com_content&Itemid=1000
[2] http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&catid=45:2nd-generation-frameworks&id=65:data-driven
[3] http://softwarequalitysource.com/AutomationTypes.html
[4] http://en.wikipedia.org/wiki/Model-based_testing
[5] http://www.slideshare.net/nashjain/test-automation-strategies-for-agile
[6] http://en.wikipedia.org
[7] http://code.google.com/p/selenium/wiki/PageObjects


Содержание.


2013-03-03

Cамотренинг по автоматизации. Что, почему, зачем, где, когда и как.

Содержание.

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

Некоторые разновидности автоматизации:



Почему.
Будем честны - люди ленивы и склонны становится всё менее внимательными при выполнении одних и тех же действий изо дня в день, снова и снова. Таким образом идея сделать некоего "робота", который будет делать всю нудную и рутинную работу вместо человека - такая идея звучит очень и очень привлекательно.

Зачем.
Успешная автоматизация тестирования решает сразу несколько задач:
 - Уменьшение времени на тестирование (чаще всего речь идёт о регрессионном тестировании);
 - Делает тестирование более заметным и прозрачным (например можно легко получать замечательно оформленные отчёты по прогону тестов каждый день и таким образом постоянно "держать руку на пульсе" качества продукта);
 - Увеличение тестового покрытия (авто-тесты позволяют покрыть большее количество комбинаций за то же время и с возможностью одновременно отслеживать такие параметры как потребление памяти, процессорного времени, дискового пространства и пр.);
 - Тестировщики уделяют больше времени сложным сценариям и исследовательскому тестированию;
 - Исключение некоторых человеческих ошибок при прогоне тестов.

Где и когда.
Об автоматизации стоит задуматься когда:
 - процесс тестирования включает строго определённые последовательности часто повторяемых действий, которые выполняются шаг за шагом без особых изменений и при этом требуют относительно много времени;
 - у вас огромное количество сборок и версий для тестирования (например  планируется выпустить 64 версии в течении 10 лет);
 - необходимо протестировать/изучить поведение системы при определённых условиях(например при 100 000 активных пользовательских сессиях);
 - у вас нет ГИПа.

Автоматизация может принести нулевой результат когда:
 - процессы тестирования неопределенны и/или хаотичны;
 - бизнес-логика недостаточно определена или выверена;
 - ГИП нестабилен;
 - набор функций системы ещё не определён(разработка прототипа);
 - лица принимающие финансово-технические решения до конца не понимают структуру стоимости автоматизации и какие ресурсы для неё необходимы.

Как.
По определению, автоматизация тестирования производится с помощью ПО. Это могут быть внешние библиотеки, компоненты и инструменты или инструменты разработанные внутри проекта или фирмы. Говоря о непосредственно тестировании в рамках автоматизации, существует два больших класса: специализированные инструменты (такие как QTP, TestComplete, LoadRunner)  и коммерческие или открытокодовые библиотеки/компоненты(xUnit-ы, Selenium, JMeter). Каждый из классов имеет свои "за" и "против".

Специализированные инструменты:
 - в большинстве случаев крайне дороги;
 - требуют специального обучения;
 - разработанные тесты может быть трудно поддерживать и развивать из-за отсутствия у всех членов команды нужного опыта (например разработчикам может быть трудно быстро начать писать авто-тесты по причине незнакомого языка, среды и т.д.);
 - возможны трудности в обновлении/расширении функций таких инструментов (отдельные лицензии например).

 + обычно отличная тех. поддержка со стороны производителя;
 + обученным людям необязательно иметь навыки программирования.

Библиотеки/компоненты:
 - требуют навыков программирования;
 - документация часто плохая или отсутствует;

+ очень расширяемы - почти всегда можно дописать недостающую функциональность самостоятельно;
+ могут использоваться практически всеми членами проектной команды;
+ часто с открытым кодом и бесплатны.

 Ссылки:
[1] http://en.wikipedia.org/wiki/Automated_testing

[2] http://ru.wikipedia.org/wiki/%D0%90%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D0%B7%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

[3] http://openquality.ru/software-testing/automation.php

[4] http://automated-testing.info/


Содержание.

Заказчика надо держать в курсе...

 ... . И в ежовых рукавицах :).

Вводная. Самотренинг по автоматизации функционального тестирования.

Содержание:
1. Cамотренинг по автоматизации. Что, почему, зачем, где, когда и как.
2. Cамотренинг по автоматизации. Подходы, техники и каркасы.
3. Cамотренинг по автоматизации. Подходы: функциональная декомпозиция.
4. Cамотренинг по автоматизации. Подходы: данные правят(data-driven).
5. Cамотренинг по автоматизации. Подходы: ключесловный и поведенческий(keyword-driven, behaviour-driven).
6. Cамотренинг по автоматизации. Подходы: объектный.
7. Самотренинг по автоматизации. Подходы: Модельный и гибридный.
8. Практические заметки.
9. Типовая структура проекта.
10. Самотренинг по автоматизации. Локаторы элементов.
11.  Самотренинг по автоматизации. Введение в Луний.
12. Практические задания.

О чём и для чего?
 Число желающих что-нибудь заавтоматизировать в тестировании растёт, а с чего начать и куда копать чаще всего неясно. Огромное количество платных тренингов порождает проблему выбора и не даёт уверенности в результатах. Данный самотренинг это набор "выучись сам" - желающему предоставляются набор материалов для самостоятельного изучения, выполнения заданий и т.д. . Никаких разжёвывания и сверх-детальных объяснений, расчёт на инженерный подход, способность мыслить и самообучаться. Ожидается, что после выучивания инженер сможет участвовать в реальном проекте по автоматизации тестирования в качестве младшего специалиста.

 Самотренинг состоит из краткой теоретической части(конспекты), набора указаний для практики, а также простого веб-приложения для тестирования и зародыша проекта автоматизации на базе Selenium 2.0 WebDriver.

 Материалы(как текст, так и исходный код) предоставляются "как есть" и бесплатно для личного обучения. При цитировании или использовании в любых проектах по разработке ПО (открытых, коммерческих, некоммерческих и т.д.) - имейте совесть и ставьте ссылки на источник. Если есть желание попользоваться материалами как-то ещё или улучшить код - добро пожаловать в комментарии.


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

Предполагается, что изучающий имеет/знает:
- 2-4 года опыта в ручном тестировании ПО;
- принципы и концепции тестирования;
- знания и опыт применения базовых техник тест-дизайна (классы эквивалентности, граничные значения и т.д.);
- начальные навыки в программировании. Желательно ООП.

Ссылки.
Исходники проекта автотестов +"варка" тестируемого приложения

[1] http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&id=1093&Itemid=76