IEEE 829.
#1
Отправлено 09 апреля 2008 - 14:54
Предметом интереса стал стандарт 829(Test Documentation). Уверен, что тема обсуждалась не раз, но если есть возможность - давайте еще раз поговорим.
1. Сам стандарт. Четкость его соблюдения. Действительно ли дают ощутимые преимущества? (уровень размаха системы, а также необходимые параметры могу в общих словах сказать)
2. Программное обеспечение.
Что можете посоветовать. Нужно только для стандарта. С учетом возможной интеграции с существующей системой управления проектами и требованиями, а также с учетом возможной доработки в соответствии с принятым на предприятии жизненным циклом продукта.
Я понимаю, что чересчур общие слова, но готов дальше порассказывать, что хотелось бы видеть.
Заранее спасибо.
#2
Отправлено 09 апреля 2008 - 15:07
Здравствуйте. Хотелось бы получить совет, а может узнать что-то новое.
Предметом интереса стал стандарт 829(Test Documentation). Уверен, что тема обсуждалась не раз, но если есть возможность - давайте еще раз поговорим.
1. Сам стандарт. Четкость его соблюдения. Действительно ли дают ощутимые преимущества? (уровень размаха системы, а также необходимые параметры могу в общих словах сказать)
а вы его читали? или просто спрашиваете?
во первых надо понять одну простую вещь:
этот стандарт не определяет строгий список необходимых документов.
он определят только ФОРМУ и СОДЕРЖАНИЕ ОТДЕЛЬНЫХ документов.
т.е. авторы стандарта говорят, что нет строгого единого стандарта который бы вам говорил, какие документы у вас должны быть
но если вы уж хотите иметь тест документацию - вот пожалуйста, пользуйтесь. составляйте тест план, тест спецификации, тест кейсы, тест процедуры, realease notes, инцедент репорт, тест лог и общий итоговый репорт.
#3
Отправлено 09 апреля 2008 - 16:07
По порядку.Здравствуйте. Хотелось бы получить совет, а может узнать что-то новое.
Предметом интереса стал стандарт 829(Test Documentation). Уверен, что тема обсуждалась не раз, но если есть возможность - давайте еще раз поговорим.
...
Я понимаю, что чересчур общие слова, но готов дальше порассказывать, что хотелось бы видеть.
Заранее спасибо.
Наша тестовая документация сделана в соответствии с этим стандартом. Не все предлагаемые сущности и документы, описаные в нем используются. Например, инцидент репорт нам не нужен - есть дефект-трэкер. Пользуемся шаблоном тест плана, тест дизайн спецификаций и тест кейз спецификаций. Остальные документы - наши, такие, как нам удобнее.
Инструменты - раньше писалось в простом HTML файле - это несложно. В последние годы, пишем в XML формате ибо так удобнее - много чего не надо писать по 10 раз. Отображается опять же в HTML. Вся система сбазированая на XML была сделана лично мною и продолжает потихоньку развиваться.
В последнее время все больше задумываюсь о том, чтобы забить на 829 и сделать тестовую документацию более удобной ибо есть много у меня к этому стандарту нареканий. Самое большое из них, что в результате получается много документов и секций внутри них, читать которые никто не будет. Получается уклон в сторону бюрократии, а не удобства использования.
Если у вас предстоит сертификация по СММ, то документация которая сделана по такому известному стандарту будет очень большим плюсом. Если такой надобности нету - то лучше, прочитав стандарт, взять из него самые лучшие идеи (а их там есть) и сделать свои шаблоны, наиболее подходящие к вашим нуждам. Слепо следовать этому стандарту не нужно.
Alexey
#4
Отправлено 09 апреля 2008 - 20:20
а вы его читали? или просто спрашиваете?
во первых надо понять одну простую вещь:
этот стандарт не определяет строгий список необходимых документов.
он определят только ФОРМУ и СОДЕРЖАНИЕ ОТДЕЛЬНЫХ документов.
т.е. авторы стандарта говорят, что нет строгого единого стандарта который бы вам говорил, какие документы у вас должны быть
но если вы уж хотите иметь тест документацию - вот пожалуйста, пользуйтесь. составляйте тест план, тест спецификации, тест кейсы, тест процедуры, realease notes, инцедент репорт, тест лог и общий итоговый репорт.
Конечно, читал. Я понимаю, что стандарт - это не руководство к действию, а лишь подпорка - "Посмотри, как мы советуем, и если хочешь - сделай также. Это удобно."
Вот я и хочу понять, насколько все это удобно. Что можно оставить, а что можно выбросить. Насколько должен быть подробным тест-план, и может лучше более подробно писать в тест-спецификациях.
По порядку.
Наша тестовая документация сделана в соответствии с этим стандартом. Не все предлагаемые сущности и документы, описаные в нем используются. Например, инцидент репорт нам не нужен - есть дефект-трэкер. Пользуемся шаблоном тест плана, тест дизайн спецификаций и тест кейз спецификаций. Остальные документы - наши, такие, как нам удобнее.
Инструменты - раньше писалось в простом HTML файле - это несложно. В последние годы, пишем в XML формате ибо так удобнее - много чего не надо писать по 10 раз. Отображается опять же в HTML. Вся система сбазированая на XML была сделана лично мною и продолжает потихоньку развиваться.
В последнее время все больше задумываюсь о том, чтобы забить на 829 и сделать тестовую документацию более удобной ибо есть много у меня к этому стандарту нареканий. Самое большое из них, что в результате получается много документов и секций внутри них, читать которые никто не будет. Получается уклон в сторону бюрократии, а не удобства использования.
Если у вас предстоит сертификация по СММ, то документация которая сделана по такому известному стандарту будет очень большим плюсом. Если такой надобности нету - то лучше, прочитав стандарт, взять из него самые лучшие идеи (а их там есть) и сделать свои шаблоны, наиболее подходящие к вашим нуждам. Слепо следовать этому стандарту не нужно.
По поводу инструментария - я думал в сторону DocBook'a. Знающие люди немного отговаривают - не нужно всей мощи.
Я видел в идеале это так : по кусочкам все хранится в БД - отдельные шаги, тестовые-кейзы, тестовые сценарии. Хранится в виде, конечно, XML - тут, наверное, сложно что-то придумать более красивое и эффективное - и выгружается с применением таблицы стилей : для составления отчета, для проведения регрессионного тестирования, если какие-то шаги надо повторить, для приемочного тестирования - собственно, как и DocBook, только облегченный вариант. В базе данных это все вяжется между собой - тест-кейсы связываются с сценарием, сценарий с тест-планом, тест-план с требованием. + Дополнительные промежуточные вещи, которые как раз и описывает 829.
Насколько будет оправданным такое хранение? Есть ли какие-то средства? Может TestLink? Объем тест-кейсом - несколько тысяч, может даже 10000.
Инструментарий ведь чем еще плох - надо людей учить им пользоваться. Люди ведь к Ворду привыкли.
PS. Нет, сертификация не предстоит. Пытаюсь лишь улучшить работу подразделения.
#5
Отправлено 10 апреля 2008 - 08:44
Да, на мой взгляд - это тоже самый идеальный вариант. Мы примерно по такому пути и пошли. Но, хочу вас предостеречь, чтобы вы не допустили той же ошибки, что и мы, при таком подходе. Все кусочки у нас сделаны в терминах 829 стандарта. Потом они просто с помощью XSLT собираются в предписаные этим же стандартом документы. Но это не очень хорошо, как оказалось. Лучше чтобы кусочки хранились в любом самом удобном виде, т.е. не надо использовать сущности 829 стандарта для хранения данных. А вот для отображения - можно. До меня поздно дошло, что 829 предписывает выходной формат документации. Если бы понял сразу - сейчас бы было проще....
Я видел в идеале это так : по кусочкам все хранится в БД - отдельные шаги, тестовые-кейзы, тестовые сценарии. Хранится в виде, конечно, XML - тут, наверное, сложно что-то придумать более красивое и эффективное - и выгружается с применением таблицы стилей : для составления отчета, для проведения регрессионного тестирования, если какие-то шаги надо повторить, для приемочного тестирования - собственно, как и DocBook, только облегченный вариант. В базе данных это все вяжется между собой - тест-кейсы связываются с сценарием, сценарий с тест-планом, тест-план с требованием. + Дополнительные промежуточные вещи, которые как раз и описывает 829.
...
Alexey
#6
Отправлено 10 апреля 2008 - 11:52
Да, на мой взгляд - это тоже самый идеальный вариант. Мы примерно по такому пути и пошли. Но, хочу вас предостеречь, чтобы вы не допустили той же ошибки, что и мы, при таком подходе. Все кусочки у нас сделаны в терминах 829 стандарта. Потом они просто с помощью XSLT собираются в предписаные этим же стандартом документы. Но это не очень хорошо, как оказалось. Лучше чтобы кусочки хранились в любом самом удобном виде, т.е. не надо использовать сущности 829 стандарта для хранения данных. А вот для отображения - можно. До меня поздно дошло, что 829 предписывает выходной формат документации. Если бы понял сразу - сейчас бы было проще.
1. А в чем ошибка, чтобы хранить данные в сущностях 829 стандарта?
2. Вы писали свои XSLT таблицы или использовали готовые?
3. И в чем удобней размечать XML, с учетом того, что народ лишь поверхностно знаком с этим, да и желателен интерфейс "Чтобы как в Ворде я мог это набрать без проблем"
#7
Отправлено 10 апреля 2008 - 13:49
Наверное, лучше было бы использовать слово "неудобство", а не "ошибка". Хотя в рамках всей системы документооборота эти неудобства выглядят как недоделки и недодумки - а это уже ближе к ошибке в дизайне, архитектуре. Возможно еще свой отпечаток накладывает специфика продуктов, которые мы тестируем.1. А в чем ошибка, чтобы хранить данные в сущностях 829 стандарта?
Одна из причин почему мы перешли к такому документообороту - избежать дублирования и copy\paste. У нас в год выпускается несколько продуктов, к которым применимы много одинаковых или очень похожих тестов. Раньше из-за copy\paste в тестовой документации было порядочное кол-во ляпов.
Примеры "неудобств":
1) Expected result - часть спецификации TestCasе-а. У нас как-то так получается, что в 80% тестов этот ожидаемый результат одинаков. Очень хочется его вынести в отдельную сущность и ссылаться на нужный ожидаемый результат. Сейчас получается все-тот же copy\paste.
2) У нас есть понятие shared\common TestDesignSpecification. Т.е. одна и таже функциональность (или требования) есть в разных продуктах. Мы пишем тест дизайн один раз и используем во всех продуктах. Соотвественно, все спецификации тест кейзов привязаны к тест дизайн документам. Но как оказалось на практике, функцинальность (или требования) не всегда одинаковы, хотя и очень похожи. Иногда один или больше тест кейзов из такого shared тест дизайн-а неприменимы. Пришлось придумывать механизм exclude-ов. Пример - для одного продукта нужны запуски на медленном тормозном компе, для другого нет.
3) С приоритетами тестов получается тоже не всегда хорошо. В одном продукте тест кейз высокого приоритета, в другом, тот же тест кейз - небольшого. Приходится изгаляться.
4) Хочется делить входные параметры по смыслу - environment (soft and hard) и непосредственно настройки\конфигурация системы. В стандарте нет разделения по таким сущностям. А было бы полезно. У нас одна и та же документация используется как для визуального представления, так и в качестве входных данных для автоматизированных тестов. А настройки(выбор) среды тестирования и настройки самой тестируемой системы - вещи разные. И еще, в этом случае секцию environmental needs не пришлось бы заполнять вручную, а можно былобы сгенерить автоматически :)
На самом деле наверняка есть еще много всяких разных мелочей. Написал, что вспомнилось сразу.
Конечно же сам. Даже не искал готовых. Так же как и XSD для XML-ных файлов. Ведь для того чтобы готовые XSL-ные файлы применить надо иметь XML-ные файлы в том виде, на который заточены эти XSL-тины. А как вы поняли, формат XML-ных документов мы делали сами.2. Вы писали свои XSLT таблицы или использовали готовые?
А вот это проблема. Наверное самая большая-пребольшая. Все недоделки, логические недочеты, "неудобства" о которых я выше написал - все ничто по сравнению с тем, что XML мы пишем ручками в простом текстовом редакторе. Благо, обычно не так много данных надо вбивать в темплейты(специфика тестов такая). Но когда надо много текста, обычно в тест плане, то можно взять любой простой HTML редактор, написать там HTML, а потом код скопировать внутрь XML-ного документа. Специально сделано так, что контент многих элементов(например, scope в тестплане) является HTML-кодом - можно таблички, списки делать итд. Но это, конечно же, не решает проблему редактирования. Есть несколько вариантов - но ни один из них мне не нравится настолько, чтобы его применить.3. И в чем удобней размечать XML, с учетом того, что народ лишь поверхностно знаком с этим, да и желателен интерфейс "Чтобы как в Ворде я мог это набрать без проблем"
Alexey
#8
Отправлено 11 апреля 2008 - 04:55
...
Спасибо за развернутое пояснение :) Буду думать, что можно придумать. Неудобства ясны и возможно мы с ними тоже бы столкнулись.
По поводу редактора - тут вот какая вещь - как объяснить людям(человек 30-40), никогда не размечавшим XML, что это надо делать, что это будет потом удобно в конечном выходном документе? Ведь ключевое слово - "потом", а все хотят сейчас и сразу.
Поэтому подумал, что ведь должен быть какой-нибудь редактор с интуитивно понятным интерфейсом. Выделил фразу "Тестовый случай", нажал кнопку на панели "Курсив" и у тебя стало
<i>Тестовый случай</i>, но при этом внешне это должно выглядеть как обычный текст, без тегов разметки - народ ведь пугаться будет. И чтобы можно было к каждой кнопке привязать свой тег. Т.е новая проблема. Я раньше с этим не сталкивался, потому что сам просто брал, открывал тот же EditPlus и спокойно писал, что было нужно.
И еще тогда вопрос - а создание законченной системы как могли бы оценить в человеко-часах или в другом удобном измерении? Сколько это у вас заняло, если не секрет? И какой уровень специалистов был вовлечен в это дело? И какой выигрыш в итоге получили? (если это не секретная информация :) )
#9
Отправлено 11 апреля 2008 - 08:17
Не секрет. Но оценить тяжело, т.к. система постоянно развивается до сих пор. Темпы разные, то бурно, то вообще никак - только потому что нет времени на доработку, но есть куда развиваться дальше. Первый прототип был сделан очень быстро (пара дней) и совсем не похож на то, что есть сейчас. Я уже говорил, что и раньше документация была сделана на основе 829го, но писалась в простом HTML. Первое, что было сделано - переход от HTML к XML+XSLT без каких-либо значительных изменений. Потом потихоньку стало наращиваться - тесткейзы отделились от тест процедуры(правду сказать с тест процедурами до сих пор не все у нас хорошо), shared тест дизайн-ы появились, кол-во документов увеличилось (раньше был только один тест дизайн, стало много), статусные страницы(для результатов тестирования) ... ну и так далее. По времени от первого прототипа до первой рабочей версии прошло где-то пол-года, не больше. Делал я один (коллеги помогали в обсуждении идеалогии\архитектуры итп) и ессно не было у меня 100% времени на эту задачу. Был проект, для которого я состовлял документацию - к концу проекта первая рабочая версия была готова.И еще тогда вопрос - а создание законченной системы как могли бы оценить в человеко-часах или в другом удобном измерении? Сколько это у вас заняло, если не секрет?
Потом стали применять и в других проектах, постоянно что-то исправляя или добавляя на основании замечаний от коллег.
Да тоже вроде как не секрет. Уровень специалистов у нас высокий. Писать XML - не проблема, но и народу у нас не 30-40 человек, а сильно меньше.И какой уровень специалистов был вовлечен в это дело? И какой выигрыш в итоге получили? (если это не секретная информация :) )
Выйгрыш, например, такой - одна и таже документация поняна и человеку и машине, документация всегда up-to-date. Тесты привязались к функционалу. Сам стандарт тут особо не причем - он использовался до того как я вообще пришел работать, он и остался - для людей вовлеченных в процесс это привычная форма. Но и недостатков много конечно, устраням потихоньку.
Используем 2+года.
Найдете удобный редактор или придумаете, как легко и удобно можно сделать свой редактор - дайте знать :)По поводу редактора - тут вот какая вещь - как объяснить людям(человек 30-40), никогда не размечавшим XML, что это надо делать, что это будет потом удобно в конечном выходном документе? Ведь ключевое слово - "потом", а все хотят сейчас и сразу.
Поэтому подумал, что ведь должен быть какой-нибудь редактор с интуитивно понятным интерфейсом. Выделил фразу "Тестовый случай", нажал кнопку на панели "Курсив" и у тебя стало<i>Тестовый случай</i>, но при этом внешне это должно выглядеть как обычный текст, без тегов разметки - народ ведь пугаться будет. И чтобы можно было к каждой кнопке привязать свой тег. Т.е новая проблема. Я раньше с этим не сталкивался, потому что сам просто брал, открывал тот же EditPlus и спокойно писал, что было нужно.
Alexey
#10
Отправлено 12 апреля 2008 - 20:03
...
Спасибо за консультации :)
У нас проблема еще вот в чем стоит - сейчас тестовая документация представляется собой Word'овские файлы... И перевод всего в что-то другое тоже время займет. Я потому и спрашивал про трудозатраты. К ним надо добавить этот перевод документации в новый формат. И тогда попытки убедить, что стоит все это затевать, могут закончиться крахом.
А насчет редактора - поговорил с коллегами - сказали, что платные есть, причем довольно удобные, документ можно во всех форматах смотреть - и с тегами, и как это будет выглядеть в итоге.
А если писать что-то свое, то, судя по всему, много времени уйдет...
#11
Отправлено 14 апреля 2008 - 09:02
Мы пользуемся для редактирования докбука редактором XMLmind (небесплатным, впрочем).Найдете удобный редактор или придумаете, как легко и удобно можно сделать свой редактор - дайте знать :)
Он хорош ещё тем, что можно настроить для своей схемы документа способ визуализации при редактировании в визивиг-режиме.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#12
Отправлено 05 мая 2008 - 18:26
Найдете удобный редактор или придумаете, как легко и удобно можно сделать свой редактор - дайте знать :)
Алексей, я из общения не уловил - сейчас формат XML уже устоявшийся или ещё нет?
#13
Отправлено 06 мая 2008 - 04:06
XML -- это просто синтаксис, а редактор должен поддерживать семантику тегов, то есть для каждой схемы должен быть свой способ отображения и редактирования тех или иных тегов. Вопрос был про редактор для формата DocBook, то есть вполне конкретной схемы.Алексей, я из общения не уловил - сейчас формат XML уже устоявшийся или ещё нет?Найдете удобный редактор или придумаете, как легко и удобно можно сделать свой редактор - дайте знать :)
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#14
Отправлено 08 мая 2008 - 11:30
Найдете удобный редактор или придумаете, как легко и удобно можно сделать свой редактор - дайте знать :)
Алексей, я из общения не уловил - сейчас формат XML уже устоявшийся или ещё нет?
А что значит, устоявшийся?
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных