Будет ли мне интересен этот вебинар, если я уже прошла тренинг?

Да, полезным точно будет. На тренинге мы не рассматривали маппинг в деталях. Эта тема в курсе по подходам в автоматизации немного out of scope. На этом вебинаре я расскажу и покажу в деталях обычный маппинг, extended mapping, маппинг по child-объектам и работу с функциями поиска FindChild и FindAllChildren с обертками над этими методами для удобной работы.

Если не найдете для себя ничего нового - можно ведь отключиться от вебинара :)

Приходите :)

Как вы думаете, какой способ лучше? Или где балланс?

Как по мне, киворды "низкого уровня" (типа кликнуть по кнопке или выбрать пункт в списке) нужны, но пользоваться ими надо пореже, по мере крайней необходимости. А в остальном пользоваться кивордами более высокого уровня.

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

Имхо, понятие баланс - размыто. Все зависит от целей тестирования и текущей ситуации: насколько нужен KDT, перспективы, покрытие и проч.

Верно. Баланс выбирается в зависимости от проекта и задач. Но общие параметры для его выбора есть и их можно формализовать. Часто это помогает на начальных этапах проекта, чтобы выбрать оптимальный подход.

От меня требуется написание тестов как позитивных, так и негативных. Сделать отдельным параметром тип теста (позитив/негатив), в зависимости от этого параметра обрабатывать ошибочные сообщения там где надо. Т.е. если тест - негатив, то несохранившаяся сущность из-за незаполненности обязательных параметров - это, к примеру, успешный тест.

Я похожую задачу буду рассматривать на тренинге, но немного с другой стороны и с другим подходом

Набор данных у меня пока хранится в Dictionary, в сам тест передается именно словарь с набором данных. Далее я рассматриваю 2 варианта - таблица (excel) или XML.
Пока не знаю насколько все реально.

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

Ну видите как здорово, уже почти раскрыли тему =)
Хотел бы я посмотреть все же на KDT. С TestComplete что идет в связке? Excel? В табличном редакторе пишется последовательность функций (сценарий), мб тестовый набор, разветвление..?

Я буду показывать на примере Excel. Хотя можно где угодно это хранить. В реальных проектах это часто интегрируется с тест-менеджмент системами и эти тесты из кейвордов пишутся прямо там. В этом есть и плюсы, и минусы.
Это больше последовательность кейвордов, а не функций. Да, они потом трассируются на функции в скриптах. Но не один к одному.
Ветвления в кейворд-тестах не желательны. Их можно реализовать (тот же кейворд по сути), но это может добавить путаницу.

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

Да, все верно, это и есть одна из целей KDT. Но реализовать ее можно многими способами и с разным уровнем детализации.
Будет слишком детально - по сути ничем не будет отличаться от написания скрипта (по сути работа по написанию KDT в холостую). Зато можно написать любой тест.
Будет слишком верхнеуровнево - не все тесты можно будет написать, будет не хватать кейвордов или отдельных методов.

Как вы думаете, какой способ лучше? Или где балланс?

Раз уж тема живая, давайте пообсуждаем :)

а также
http://www.slideshar...riven-framework

Это ближе всего к тому, что я буду показывать на тренинге в рамках KDT. Только в упрощенной форме и на простых примерах. TAF - отличный инструмент, у меня была возможность на него посмореть (поскольку работаем с Мишей в одной компании), пример правильно реализованного KDT подхода.

Коллеги, может раскроете тайну что же это за подходы такие ODT и KDT? :)
Я про них почти ничего и не знаю, видимо :\

Где можно почитать?

Как я писал в ODT и KDT в TestComplete: миф или реальность?, ODT (object-driven testing) - это внутренний термин TestComplete. Нигде больше он не встречается. В мире за пределами TestComplete ближе всего к этому - DSL (domain specific language). Это если рассматривать как подход. Если как модуль - то это просто модуль инструмента, который предоставляет какую-то возможность работать с объектами.
DSL гораздо легче гуглится :)

KDT (keyword-driven testing) - популярный подход, и, как писал Гена, уже довольно старый. Просто его применять достаточно тяжело и не для всех случаев он подходит. За последний год я этот подход начинаю видеть все чаще и чаще. В основном, на больших проектах, а также учитывая тот факт, что разница в зарплатах ручных тестировщиков и автоматизаторов довольно существенная, и KDT как раз помогает разделить тестирование и автоматизацию между ними: на тех, кто пишет фреймворк под KDT и поддерживает его; и на тех, кто составляет тесты (не имея опыта автоматизации).

Есть еще DDT, который многие знают. Но то, что это подход и вынесение тестовых данных за пределы скриптов не есть DDT - уже знают не все. Написать полноценный DDT-loop, поддерживающий перенос логики проверок различных вариантов в файл с данными (на моей практике) могут единицы.
То есть, если копнуть глубже, то этот подход позволяет делать очень хорошее покрытие определенных (поддающихся DDT) модулей приложения. В сумме с ODT(DSL) и хорошим фреймворком микс этих подходов дает много возможностей.

Цель моего тренинга - рассказать об этих подходах и показать, как это делать на практике (в TestComplete)

Это не то http://it-conf.ru/ru...t/524.htm#TOC-7 ?

Да, это оно (KDT)

Привет Гена,

Идея тренинга и возникла именно потому, что инструмент хороший, но подходы ODT и KDT в нем реализованы странно и неудобно, и из-за этого вносят путаницу в понятия. У каждого подхода (ODT, DDT, KDT) свое применение и свои задачи. С неправильным пониманием подходов (DDT и, особенно часто, KDT) я тоже сталкиваюсь.

Этот тренинг предполагает наличие базовых знаний в TestComplete (либо практика, либо самостоятельно изученные основы, либо твой тренинг "Автоматизация тестов с использованием TestComplete").

Аналогично, поставил KDT в конец, потому что он - самый тяжелый. И без подготовленного фреймворка после ODT-занятий его показать просто невозможно даже на самом базовом уровне.

На AT Days жду твоего доклада, интересно послушать твое видение и пообщаться в кулуарах :)
Мой доклад на ATDays более абстрактный, но, надеюсь, не менее полезный

Дмитрий, спасибо, что отписались :)
Я понял свое заблуждение. Но имхо нет какого-то общего фреймворка, который бы подходит для всех. Подходы для каждого вида ПО должны быть разными, особенно различая тестирование ПО и тестирование веба. Даже не так. Не "должны быть", а могут быть. Функционал также влияет на подход, в зависимости от целей автоматизации выбирается подход.

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

Rebz,
Отвечая на Ваши вопросы:

от неизвестных до селе авторов

Согласен насчет "неизвестных до селе авторов", надеюсь, в скором времени это изменится :)

Автора тренинга я уже где-то видел... да, точно, стратоплан: http://www.stratopla...t-testcomplete/

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

кто использует в своем фреймворке ТестКомплита Keyword testing и ODT?

На моей практике, Keyword testing часто используют, когда не хватает экспертизы писать код. И иногда используют для регресионных тестов. Я не сторонник этого модуля TestComplete, о чем в статье написал. На тренинге не будет этого Keyword testing, там будет "правильный" KDT, модуля TestComplete вообще касаться не будем.
ODT испольуют частенько и ничего плохого в этом нет. Проблемы начинаются, когда кода становится больше и проект разрастается. По сути разницы большой нет - использовать классы JScript или классы ODT. Везде есть свои минусы и плюсы. На моей практике плюсов в JScript больше.

Вопрос связан с целесообразностью подобного курса. Название громкое, но вот подходы не очень..

На тренинге будут не модули инструмента, а реализация подходов. Модуль ODT будем использовать ограниченно (как я писал в статье - класс для шаблона данных и Data для хранения тестовых данных), модуль Keyword testing использовать вообще не будем, вместо этого напишем "движок" для полноценного KDT. Для DDT также будет свой "движок" на базе фреймворка и классов, которые уже будут готовы после занятий по "ODT".
Цель тренинга - на практических задачах разобрать по косточкам эти подходы и дать понимание сути и реализации, чтобы при возникновении проектных задач тестировщики могли выбрать подходящий подход и грамотно его реализовать.
Кто это уже умеет делать и умеет проектировать и писать полноценный фреймворк - наверное, этот тренинг слишком простой для них.

Почему возникла идея этого тренинга? Об этих подходах многие говорят, но на моей практике где-то 10% могут реализовать это в коде (остальные знают, что это такое в теории, но как это сделать - не всегда понимают или умеют). Возможно, мои данные не репрезентативны, не отрицаю этого. Время покажет :)

XXX,

Keyword testing даже не пытался осваивать, сразу стал использовать Script.

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

Спасибо,
Дмитрий Марков