Что бы такого учесть при оценке трудозатрат на АТ.

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

 На мой выпуклый военно-морской в затратах на автоматизацию следует в том числе учитывать:

- людей: кто, когда, с какой мотивацией и под какой стимуляцией будет всё это делать, развивать и поддерживать;

- документированность: насколько быстро можно получить ответы на внезапные вопросы,

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

- архитектуру и структуру. Проистекает из вопроса "что покрываем?". Навскидку:

 а. микросервисы или монолит;

 б. сервисы на основе бинарных протоколов или РЕСТ какой-нибудь;

 в. нужно воздействовать на одну систему или несколько.

- технологии тестируемого: есть ли вообще инструменты позволяющие это автоматизировать (пример - мордочки на флеше которые не всякий популярный инструмент возьмёт);

- технологии тестового решения. Например использовать Селениум или Сикули это две большие разницы в затратах и на разработку и на поддержку;

- данные: стабы, моки или живые данные? Как генерировать и валидировать тестовые данные(особенно в случае критических систем(медицина, авиация))? Если моки-стабы, то есть ли что-то готовое или нужно будет писать своё?

- безопасников - дадут ли доступ и добро на манипуляции с системой, тестовые сборки с "дополнительными"(отладочными) функциями?

- среды: всяко-разные, начиная от где это запускать и где разворачивать тестируемое. Далеко не всегда можно получить стенды вот так сразу, возможно придётся подождать годик-два;

- СИ: строить с ноля или интегрироваться в существующее решение?

- 3-и стороны: не всем наши усилия могут нравиться, некоторые могут посчитать, что отбиваем хлеб, забираем масло и плюём в душу. А уж палки в колёса ставить могут просто рефлекторно.

Вышеперечисленное конечно же требует творческого расширения, углубления и всяческого дополнения. На то она и затравка.

Ссылки россыпью:

http://bytextest.ru/2017/06/20/autotest-vs-reality/#more-5727

https://pikabu.ru/story/post_2_yeffektivnost_avtomatizatsii_testirovaniya_3974390

http://www.a1qa.ru/blog/otsenka-effektivnosti-avtomatizatsii-testirovaniya/

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

Содержание.

Что это?
В плоскости автоматизации тестирования это что-то, что помогает найти элемент на странице или на форме: 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

[5] http://code.google.com/p/selenium/

[6] http://habrahabr.ru/search/?q=selenium

[7] http://selenium.googlecode.com/svn/trunk/docs/api/java/overview-summary.html

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".

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

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

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

Содержание.

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


Содержание.

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


Содержание.

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

Об английском и переписке или с какой буквы писать слово F... .

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

В целом — без английского тяжко, ибо простого человеческого мата буржуи не понимают, а уж до смысловых тонкостей перлов навроде двойного утверждения «да конечно» им так же далече как нам до всестороннего вникания в «He's a bit of a Battle-cruiser» или до «marriage» в контексте ремонта двигателей. К тому же, плохо разговаривающих детей считают недоразвитыми, а бекающие и мекающие взрослые вызывают внутреннее отторжение и сомнение в их компетентности.

И вот возникает стандартная ситуация, характерная не только для ИТ и английского, но и для деловой переписки вообще — молодой специалист становится чуть менее молодым и ему доверяют (хруст клавиш в фоне) написание письма с просьбой или вопросом кому-то «на той стороне». И вот он, краса и надежда половины проекта, пишет и, промурыжив всё это дело четыре часа, отсылает... А ответа что-то нету, а и есть, так не прочесть. Ибо чаще всего первые полмиллиона писем содержат либо все, либо хоть одну из стандартных «отморочек» (см. ниже). Редко какую птицу действительно учат в школе или высшем учебном техникуме писать деловые письма, задавать вопросы так, чтобы получать внятные ответы и просто извергать из себя более пяти связных предложений. И уж совсем редчайшие соколы долетают до прочтения книжек-методичек о вкусной и здоровой переписке.

Книг, книжек, статей о том как и что надо писать, какие типичные ошибки, как их избегать и заводить друзей - великое множество есть, горка ссылок приведена в конце. Здесь же хочется в 7,4 слова перечислить то, с чем сталкивался «в живую».

Отморочки:

• Нет темы письма. В пылу работы бывает. Хуже когда каждое второе письмо такое. В результате «Входящие» всех людей в переписке забиваются письмами-безымянками и их потомками «На: », «Re: » и «Fwd: ». Пара-тройка таких подборок, и быстро что-то найти, глянув на тему, уже невозможно. Зато вполне вероятно сломать чей-то автофильтр. Главное, чтобы не было другого фильтра, отправляющего безымянки в корзину;

• В теле письма вписано find enclosed («всё как учили в той синей книжке»), да вот только никакого прицепа нет, забыли прикрепить. Хотя, если пользоваться почтой от Корпорации Добра и не выпендриваясь писать see attached, то при отправке такого письма выскочит диаложек «А не забыли ли вы чего прицепить, уважаемый?»;

• В связи с повышением градуса интимности уже можно писать вместо «Dear Sir» — «Dear Bill» или даже «Hello Billy». Можно-то можно, да вот предательская клавиша не нажалась и вышло «Hell Bil». Мелочь, а человек может не понять;

• Письмо написано, но ни «Hello» в начале, ни «Bill», а прямо сразу — стремительным домкратом слова и выражения изливаются на ошарашенного Билли. Пожалейте его, ему ж потом вам отвечать;

• Hello bill. Неуважительно как-то. А вдруг он комплексует из-за малого роста, так к нему теперь ещё и со строчной буквы обращаются;

• В копии письма(писем) никто не поставлен или поставлены совсем не те люди. Скользкая ситуация. Наличие правильных людей в копии повышает шансы на успех как с письмом, так и при последующем разбирательстве. Неправильные люди в копии могут загубить всё и всех;

• Отличное письмо, толково описана проблема, подробнейше выписаны варианты, слог изыскан до жути. Только забыто одно предложение, одна строчка — к чему это всё? Какие действия ожидаются от получателя? Что сделать, кому помочь, причём он тут вообще?

• Не письмо — роман. Три страницы убористого шрифта, море деталей, океан пояснений. Смысла только нет, получатель теряется в этом накате слов, в этом сумбуре.

• И т.д. и т.п. Читайте книжки, там ещё и не такое написано.

А как можно было бы:

• Составьте хороший шаблон письма: с «Dear/Hello» в начале, «Best Regards» и т.д. в конце. А ещё лучше — несколько шаблонов, в зависимости от уровня формальности письма или дня недели;

• Перечитывайте письма перед отправкой, стараясь представить себя на месте получателя: всё ли чётко, все ли детали есть, ясно ли, что требуется сделать?

• Перечитывая — замечайте ошибки, описки, которые не заметила проверка орфографии (doe вместо does и т.д.);

• Хорошо если почтовая система позволяет отменить отправку письма в течение 30-60 секунд. Чтоб было ещё лучше - перечитывайте письма сразу после отправки;

• Заведите привычку проверять основные пункты перед отправкой письма: получатели, тема, прицепы, имена. Со временем такая проверка должна стать рефлекторной;

• Если проблема сложная, слов много, то смело бейте на части, используйте нумерованные списки, выделение жирным, разбивку на абзацы. Никто никогда даже не попытается вникнуть в смысл «Анны Карениной» набранной в один абзац;

• Меньше сложных предложений и слов XIII-го века. Короче фразы, слова из справочника по допросу пленных — и вас поймут с большей вероятностью;

• Знайте разницу между «Could you please» и «Can you please». Знайте и пользуйтесь;

• Прочитайте в конце концов 2 (две) книжки по деловой переписке. По мере прочтения — используйте!

Ссылки:

1. Карепина Саша. «Искусство делового письма». Изд. Манн, Иванов и Фербер. http://mann-ivanov-ferber.ru/books/mif/idp/

2. Emmerson P. «E-mail English». Изд. Macmillan.