Сообщений в теме: 23

[daniel]

Как организовать Acceptance tests для XP проекта?
Поделитесь опытом плиз!

[barancev]

А чем в данном контексте XP-проект отличается от не-XP-проекта?

Иначе говоря, автор вопроса умеет организовать acceptance testing (приёмо-сдаточные испытания) для не-XP-процесса, но столкнулся с определёнными трудностями, пытаясь сделать то же самое для XP-процесса.

Или вопрос стоит более широко - "Как организовать Acceptance tests?"

А как, в самом деле?

[daniel]

:)

буду благодарен за любые советы и ссылки в плане организации acceptance tests вообще.

в данном случае менеджер xp проетка настаивает на том, чтобы заказчик мог писать и исполнять приемочные тесты сам. причем язык должен быть более простым, чем JS или VB.

я знаю, что обычно в xp проетках у буржуев заказчик работает либо в непосредственной близости с разработчиками и все процессы наблюдает сам, либо нанимает независимую команду, которая ему пишет скрипты для приемочных тестов.
для оффшора ни то, ни другое не подходит.

буду рад узнать ваше мнение.

Спасибо!

newbie is not dummy :)

[barancev]

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

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

Далее, в XP проекте, согласно традиционной трактовке, приёмные тесты (acceptance tests) разрабатываются на основании так называемых сюжетов (user stories), которые пишет заказчик.

После этого задача исполнителя состоит в том, чтобы для каждого сожета написать ТАКОЙ тест (или несколько), чтобы заказчик поверил, что этот тест действительно проверяет, что данный сюжет реализован а) правильно и б) полностью.

Это чисто "чёрный ящик", в отличие от тестов, которые пишутся в процессе разработки и для целей разработки, а не для тестирования.

Ну, а техническая сторона дела зависит от того, какие у Вас сюжеты. Если в терминах GUI - берите "робот" или "раннер" или руками пишите. Если в терминах API - берите JTest или UniTesK. Короче, ориентируйтесь по ситуации, на то и экстрим.

Ну и на всякий случай - ссылочка на первоисточники: http://www.extremepr...ionaltests.html

[daniel]

Спасибо за ответ!

Да, по этой ссылке я уже все. что можно прочитал :)

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

Спасибо!

[barancev]

Покажите пример сюжета (user story), если они не секретные, и тогда будем обсуждать техническую сторону дела - как скрипты писать, как их исполнять.

[Green]

Если в терминах API - берите JTest или UniTesK.

На этом форуме уже обсуждались вопросы о месте и роли юнит тестов (Unit Tests) в жизни тестировщика.

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

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

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

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

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

[barancev]

На этом форуме уже обсуждались вопросы о месте и роли юнит тестов (Unit Tests) в жизни тестировщика.

Заметьте, не я первый сказал слово юнит-тест :)

Более того, я вовсе не их имел в виду, а именно приёмные тесты, но в териминах API. Не все программные системы имеют GUI или WebUI. Бывают компиляторы, библиотеки и прочее ПО без визуального пользовательского интерфейса. Вот о них и речь.

Кстати, иногда доходит до смешного - я видел на QAForums предложение сделать GUI специально для тестирования (!), чтобы можно было использовать робот для тестирования библиотеки. А как бы Вы предложили тестировать такую систему?

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

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

[daniel]

2 barancev:

user story не секретна, ее просто нет :)

есть общие пожелания в плане функциональности :)
т.е. в камне ничего не высечено.

команда хр сама проводит юнит тесты.
в принципе, мы сами в состоянии проводить тестирование функциональности для каждой итерации и успешно это делаем, но это это ж не совсем acceptance tests. или я ошибаюсь?

вопрос в том, как продемонстрировать заказчику исполнение тестов и их реальность?

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

[barancev]

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

Словo XP вызывает вполне определённые ассоциации - "взаимодействие с заказчиком", "user stories", "TDD", "парное программирование". Может быть, если Вы не пишете сюжеты, Вы программмируете в парах и практикуете общественное владение кодом? Или тесты разрабатываете вперёд реализации (ну, теперь и моя очередь помянуть unit-тесты, благо здесь им самое место).

Нет? А хотите? Или Вы хотите взять от XP только идею построения приёмных тестов? Можно и так, описанный процесс - не канон, а руководство к действию. Если Вы не удовлетворены тем, что можно найти в литературе, может быть Вам просто нужен тренер, который поможет начать, а дальше само пойдёт. Пишите приватной почтой, договоримся :)

Что касается языка программирования - нет, не бывает детских языков. И уж если пользователь не может изложить требования неформально на естественном языке, вряд ли у него получится сделать это на языке программирования. Не зря же в XP стали использовать сюжеты - чтобы заказчика не напрягать сверх меры.

Кроме того, что он будет описывать на языке программирования, если у него и у Вас только "общие пожелания", которые к тому же почти наверняка отличаются? :)

[Green]

На этом форуме уже обсуждались вопросы о месте и роли юнит тестов (Unit Tests) в жизни тестировщика.

Заметьте, не я первый сказал слово юнит-тест :)

to barancev

Если Вам не сложно, объясните, пожалуйста, отличие технологии UniTesK от технологии Unite Testing.

И если можно, то попроще, а то пришлось перечитать почти все материалы на вашем сайте, что бы расшифровать, то что написано в разделе "Технология" (http://unitesk.com/ru/method/).

Заранее благодарен.

[barancev]

На этом форуме уже обсуждались вопросы о месте и роли юнит тестов (Unit Tests) в жизни тестировщика.

Заметьте, не я первый сказал слово юнит-тест :)

to barancev

Если Вам не сложно, объясните, пожалуйста, отличие технологии UniTesK от технологии Unite Testing.

Всё очень просто:

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

- UniTesK - это технология тестирования на основе моделей, с одной стороны, позволяющая использовать подход, назвыаемый Design by contract, а с другой стороны предлагающая специальную технику для динамической генерации тестовых послеовательностей (потому что тестировать отдельные операции для систем с состоянием затруднительно - приходится состояние формировать вручную).

То есть я хочу сказать, что для unit-тестирования можно применять различные технологии и инструменты, в том числе UniTesK. И наоборот, тот же UniTesK можно применять не только для тестирования методов и классов, но и для тестирования, например, web-сервисов, web-приложений, мы его используем даже для тестирования GUI, хотя пока скрываем, что это можно делать :)

Опять же, практически никто не может ответить на вопрос - что такое unit, которого тестирование? Это метод? класс? компонент (типа CORBA, COM, web-service)? модуль проверки орфографии в редакторе MSWord? весь редактор (у которого есть программный интерфейс)? Где граница?

Знаете, что отвечают люди после минут 10-15 обсуждения термина "unit-тестирование"? Начинают они тоже с того, что это технология, а заканчивается чем попало, от догматичного "разработка отдельных test-case для отдельных операций" и заканчивая "это тестирование, которое выполняется не тестировщиками, а разработчиками в процессе разработки". (Впрочем, и те и другие по своему правы...)

Да, у нас есть проблема с названием UniTesK, оно так исторически сложилось ещё до того, как unit-тестирование приобрело такую популярность. А потом началась путаница, хотя Uni в его названии означает вовсе не unit, а uniform, потому что используется универсальная для всей линейки продуктов архитектура тестового набора. У нас даже была мысль сменить бренд, но пока держимся :)

[Green]

- unit-тестирование - это не технология

Если верить Большому энциклопедическому словарю, то Unit Testing это все же технология, так как является элементом единой технологической цепочки (в рамках XP), "частью общего производственного процесса".

"ТЕХНОЛОГИЯ (от греч. techne-искусство, мастерство, умение и... логия), совокупность методов обработки, изготовления, изменения состояния, свойств, формы сырья, материала или полуфабриката, осуществляемых в процессе производства продукции; научная дисциплина, изучающая физические, химические, механические и др. закономерности, действующие в технологических процессах. Технологией называют также сами операции добычи, обработки, транспортировки, хранения, контроля, являющиеся частью общего производственного процесса."

[Green]

- UniTesK - это технология тестирования на основе моделей, с одной стороны, позволяющая использовать подход, назвыаемый Design by contract, а с другой стороны предлагающая специальную технику для динамической генерации тестовых послеовательностей (потому что тестировать отдельные операции для систем с состоянием затруднительно - приходится состояние формировать вручную).

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

Интересно, какова методика работы с вашей программой?
В общем, возможно, это выглядит следующим образом, а как в деталях?
Разработка спецификаций -> проектирование -> генерация тестовых данных -> тестирование

Может ли программа применяться без связи с разработкой и кодированием ПО (т.е. когда программирует одна контора, а тестирует другая и программисты не владеют технологией UniTesK)? Насколько она эффективна в таком случае?

[barancev]

- unit-тестирование - это не технология

Если верить Большому энциклопедическому словарю, то Unit Testing это все же технология, так как является элементом единой технологической цепочки (в рамках XP), "частью общего производственного процесса".

Не всё, что есть "часть производственного процесса", называется технологией.

Например, написание пользовательской документации - это часть процесса разработки ПО. Но это не технология, а задача, которую в рамках этого производстенного процесса нужно решить, используя для этого некоторую технологию написания документации (скажем, MSWord или Windows Help или HTML).

Я склоняюсь к трактовке unit-тестирования как задачи, потому что это не описание КАК разрабатывать, а указание ЧТО должно быть разработано - тесты для отдельных операций. А для разработки их можно выбрать любую технологию, какая позволит достичь цели. (Например, технологию ручной разработки, в просторечии называемую JUnit в честь одноимённого инструмента :))

[barancev]

Ну, это уже пошли ответы на вопросы про UniTesK, как-то мы отдалились от исходной темы - Acceptance Tests. На уже сформулированные вопросы я, конечно, отвечу, но если ответы покажутся недостаточно удовлетворительными, предлагаю дальнейшее обсуждение вынести в отдельную тему.

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

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

Интересно, какова методика работы с вашей программой?
В общем, возможно, это выглядит следующим образом, а как в деталях?
Разработка спецификаций -> проектирование -> генерация тестовых данных -> тестирование

Есть два способа разработки - сверху вниз и снизу вверх (возможно способов гораздо больше, просто мы про них не знаем :)):

1. Сверху вниз: разработка спецификаций (модели поведения) -> привязка к реализации -> разработка тестовых сценариев (последовательностей)
2. Снизу вверх: разработка тестовых сценариев (в терминах реализации) -> выделение контракта и разработка спецификаций -> повышение уровня абстрактности спецификаций и привязка к реализации

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

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

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

Может ли программа применяться без связи с разработкой и кодированием ПО (т.е. когда программирует одна контора, а тестирует другая и программисты не владеют технологией UniTesK)? Насколько она эффективна в таком случае?

Конечно может. Разработка тестов по технологии UniTesK основывается на контрактном подходе. Не обязательно иметь доступ к исходному коду (если, конечно, его покрытие не является одной их метрик, которую Вы собираетесь измерять при тестировании), достаточно иметь доступ к интерфейсам.

Вопрос эффективности зависит от многих параметров, гораздо более важных, чем распределение работы по конторам :)
Кроме того, если я скажу, что очень, очень эффективна, Вы мне поверите? ;)

Тем не менее, короткий ответ: у нас есть оценка, основывающаяся на опыте собственных сервисов по тестированию - снижение затрат на тестирование с 40% до 25% от стоимости проекта. Другая оценка: если затраты на тестирование составляют менее 5% бюджета проекта и качество заказчика устраивает - использовать UniTesK нет смысла.

Подробный ответ: переносим дискуссию в отдельный топик и обсуждаем, что влияет на эффективность и как.

[Green]

- unit-тестирование - это не технология

Если верить Большому энциклопедическому словарю, то Unit Testing это все же технология, так как является элементом единой технологической цепочки (в рамках XP), "частью общего производственного процесса".

Не всё, что есть "часть производственного процесса", называется технологией.

Например, написание пользовательской документации - это часть процесса разработки ПО. Но это не технология, а задача, которую в рамках этого производстенного процесса нужно решить, используя для этого некоторую технологию написания документации (скажем, MSWord или Windows Help или HTML).

Я склоняюсь к трактовке unit-тестирования как задачи, потому что это не описание КАК разрабатывать, а указание ЧТО должно быть разработано - тесты для отдельных операций. А для разработки их можно выбрать любую технологию, какая позволит достичь цели. (Например, технологию ручной разработки, в просторечии называемую JUnit в честь одноимённого инструмента :))

В данной трактовке полностью с Вами согласен.

Хотя лично для себя, я не разделяю задачу создания юнит тестов и средство реализации этой задачи (обращаю внимание но то, что речь идет о ПРОЦЕССЕ разработки ПО). Если у вас на предприятии используются юнит тесты, то волей не волей вы будете вынуждены применять какой то тул, для реализации поставленной задачи. Их сочетание и дает технологию для конкретного предприятия.

Говорить о задаче написания юнит тестов в отрыве от средств их реализации возможно только в одном случае - при изложении или обсуждении теоритических основ данного метода. Если же речь зашла о ПРАКТИКЕ применения данной задачи, то ее реализация не возможна без привязки к какому-нибудь средству реализации.

Что касается вопроса "как разрабатывать", то здесь я совсем не согласен.
Если рассматривать процесс создания ПО только с точки зрения написания кода, то - да. Юнит тесты в этой деятельности не принимают участия.

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

[daniel]

я хотел бы напомнить вопрос с которого я начал :)

с Unit Tests все понятно, оно есть, хоть и нет четко определенных User Story.

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

Есть хр проект (работа в парах, TDD и тд). Нет написанных кастомером User Story, но, в принципе, понятно, что ему нужно.

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

Условие.
Кастомер - человек не компьютерный.

Внимание, вопрос! :)
Какими средствами вы бы постарались решить эту задачу?

[barancev]

Что касается вопроса "как разрабатывать", то здесь я совсем не согласен.
Если рассматривать процесс создания ПО только с точки зрения написания кода, то - да. Юнит тесты в этой деятельности не принимают участия.

Читать здесь: Test-Driven Development Is Not About Testing и здесь: Opinion: Test-Driven Development Is Not About Testing.
"Экстремалы" считают, что unit-тесты принимают участие именно в разработке, то есть написании кода, а не в тестировании :)

Я же привык подходить к разработке ПО комплексно. Это технологический процесс (у одних больше, у других, правда, меньше) который имеет одну цель - выпуск качественного программного продукта.

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

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

Вот с этим не соглашусь. То есть не совсем соглашусь. Если из XP-процесса извлечь указанный элемент, он может быть и станет неполноценным. А может быть просто перестанет быть XP-процессом и станет чем-то другим. Особенно если добавить что-нибудь взамен извлечённого.

[Green]

Какими средствами вы бы постарались решить эту задачу?

На мой взгляд таких средств нет (бесплатных, что бы быстро, наглядно и любой тест).


Если речь идет о ВЫПОЛНЕНИИ приемочных тестов, то возможны два варианта:
1. Кастомер сам руками проверяет каждый тест, который включен в перечен приемочных.
2. Кого-нибудь нанимает для выполнения работы по пункту 1.

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