Перейти к содержимому

Фотография

IEEE 829.


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 13

#1 Румата

Румата

    Новый участник

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Поплавский Илья Витальевич

Отправлено 09 апреля 2008 - 14:54

Здравствуйте. Хотелось бы получить совет, а может узнать что-то новое.

Предметом интереса стал стандарт 829(Test Documentation). Уверен, что тема обсуждалась не раз, но если есть возможность - давайте еще раз поговорим.

1. Сам стандарт. Четкость его соблюдения. Действительно ли дают ощутимые преимущества? (уровень размаха системы, а также необходимые параметры могу в общих словах сказать)
2. Программное обеспечение.
Что можете посоветовать. Нужно только для стандарта. С учетом возможной интеграции с существующей системой управления проектами и требованиями, а также с учетом возможной доработки в соответствии с принятым на предприятии жизненным циклом продукта.

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

Заранее спасибо.
  • 0

#2 Nadya Kochetova

Nadya Kochetova

    Новый участник

  • Members
  • Pip
  • 66 сообщений
  • ФИО:Kochetova Nadya
  • Город:London, UK

Отправлено 09 апреля 2008 - 15:07

Здравствуйте. Хотелось бы получить совет, а может узнать что-то новое.

Предметом интереса стал стандарт 829(Test Documentation). Уверен, что тема обсуждалась не раз, но если есть возможность - давайте еще раз поговорим.

1. Сам стандарт. Четкость его соблюдения. Действительно ли дают ощутимые преимущества? (уровень размаха системы, а также необходимые параметры могу в общих словах сказать)


а вы его читали? или просто спрашиваете?

во первых надо понять одну простую вещь:
этот стандарт не определяет строгий список необходимых документов.
он определят только ФОРМУ и СОДЕРЖАНИЕ ОТДЕЛЬНЫХ документов.

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

#3 LeshaL

LeshaL

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 09 апреля 2008 - 16:07

Здравствуйте. Хотелось бы получить совет, а может узнать что-то новое.

Предметом интереса стал стандарт 829(Test Documentation). Уверен, что тема обсуждалась не раз, но если есть возможность - давайте еще раз поговорим.
...
Я понимаю, что чересчур общие слова, но готов дальше порассказывать, что хотелось бы видеть.

Заранее спасибо.

По порядку.
Наша тестовая документация сделана в соответствии с этим стандартом. Не все предлагаемые сущности и документы, описаные в нем используются. Например, инцидент репорт нам не нужен - есть дефект-трэкер. Пользуемся шаблоном тест плана, тест дизайн спецификаций и тест кейз спецификаций. Остальные документы - наши, такие, как нам удобнее.
Инструменты - раньше писалось в простом HTML файле - это несложно. В последние годы, пишем в XML формате ибо так удобнее - много чего не надо писать по 10 раз. Отображается опять же в HTML. Вся система сбазированая на XML была сделана лично мною и продолжает потихоньку развиваться.
В последнее время все больше задумываюсь о том, чтобы забить на 829 и сделать тестовую документацию более удобной ибо есть много у меня к этому стандарту нареканий. Самое большое из них, что в результате получается много документов и секций внутри них, читать которые никто не будет. Получается уклон в сторону бюрократии, а не удобства использования.
Если у вас предстоит сертификация по СММ, то документация которая сделана по такому известному стандарту будет очень большим плюсом. Если такой надобности нету - то лучше, прочитав стандарт, взять из него самые лучшие идеи (а их там есть) и сделать свои шаблоны, наиболее подходящие к вашим нуждам. Слепо следовать этому стандарту не нужно.
  • 0
Regards,
Alexey

#4 Румата

Румата

    Новый участник

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Поплавский Илья Витальевич

Отправлено 09 апреля 2008 - 20:20

а вы его читали? или просто спрашиваете?

во первых надо понять одну простую вещь:
этот стандарт не определяет строгий список необходимых документов.
он определят только ФОРМУ и СОДЕРЖАНИЕ ОТДЕЛЬНЫХ документов.

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


Конечно, читал. Я понимаю, что стандарт - это не руководство к действию, а лишь подпорка - "Посмотри, как мы советуем, и если хочешь - сделай также. Это удобно."
Вот я и хочу понять, насколько все это удобно. Что можно оставить, а что можно выбросить. Насколько должен быть подробным тест-план, и может лучше более подробно писать в тест-спецификациях.


По порядку.
Наша тестовая документация сделана в соответствии с этим стандартом. Не все предлагаемые сущности и документы, описаные в нем используются. Например, инцидент репорт нам не нужен - есть дефект-трэкер. Пользуемся шаблоном тест плана, тест дизайн спецификаций и тест кейз спецификаций. Остальные документы - наши, такие, как нам удобнее.
Инструменты - раньше писалось в простом HTML файле - это несложно. В последние годы, пишем в XML формате ибо так удобнее - много чего не надо писать по 10 раз. Отображается опять же в HTML. Вся система сбазированая на XML была сделана лично мною и продолжает потихоньку развиваться.
В последнее время все больше задумываюсь о том, чтобы забить на 829 и сделать тестовую документацию более удобной ибо есть много у меня к этому стандарту нареканий. Самое большое из них, что в результате получается много документов и секций внутри них, читать которые никто не будет. Получается уклон в сторону бюрократии, а не удобства использования.
Если у вас предстоит сертификация по СММ, то документация которая сделана по такому известному стандарту будет очень большим плюсом. Если такой надобности нету - то лучше, прочитав стандарт, взять из него самые лучшие идеи (а их там есть) и сделать свои шаблоны, наиболее подходящие к вашим нуждам. Слепо следовать этому стандарту не нужно.


По поводу инструментария - я думал в сторону DocBook'a. Знающие люди немного отговаривают - не нужно всей мощи.
Я видел в идеале это так : по кусочкам все хранится в БД - отдельные шаги, тестовые-кейзы, тестовые сценарии. Хранится в виде, конечно, XML - тут, наверное, сложно что-то придумать более красивое и эффективное - и выгружается с применением таблицы стилей : для составления отчета, для проведения регрессионного тестирования, если какие-то шаги надо повторить, для приемочного тестирования - собственно, как и DocBook, только облегченный вариант. В базе данных это все вяжется между собой - тест-кейсы связываются с сценарием, сценарий с тест-планом, тест-план с требованием. + Дополнительные промежуточные вещи, которые как раз и описывает 829.

Насколько будет оправданным такое хранение? Есть ли какие-то средства? Может TestLink? Объем тест-кейсом - несколько тысяч, может даже 10000.

Инструментарий ведь чем еще плох - надо людей учить им пользоваться. Люди ведь к Ворду привыкли.

PS. Нет, сертификация не предстоит. Пытаюсь лишь улучшить работу подразделения.
  • 0

#5 LeshaL

LeshaL

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 10 апреля 2008 - 08:44

...
Я видел в идеале это так : по кусочкам все хранится в БД - отдельные шаги, тестовые-кейзы, тестовые сценарии. Хранится в виде, конечно, XML - тут, наверное, сложно что-то придумать более красивое и эффективное - и выгружается с применением таблицы стилей : для составления отчета, для проведения регрессионного тестирования, если какие-то шаги надо повторить, для приемочного тестирования - собственно, как и DocBook, только облегченный вариант. В базе данных это все вяжется между собой - тест-кейсы связываются с сценарием, сценарий с тест-планом, тест-план с требованием. + Дополнительные промежуточные вещи, которые как раз и описывает 829.
...

Да, на мой взгляд - это тоже самый идеальный вариант. Мы примерно по такому пути и пошли. Но, хочу вас предостеречь, чтобы вы не допустили той же ошибки, что и мы, при таком подходе. Все кусочки у нас сделаны в терминах 829 стандарта. Потом они просто с помощью XSLT собираются в предписаные этим же стандартом документы. Но это не очень хорошо, как оказалось. Лучше чтобы кусочки хранились в любом самом удобном виде, т.е. не надо использовать сущности 829 стандарта для хранения данных. А вот для отображения - можно. До меня поздно дошло, что 829 предписывает выходной формат документации. Если бы понял сразу - сейчас бы было проще.
  • 0
Regards,
Alexey

#6 Румата

Румата

    Новый участник

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Поплавский Илья Витальевич

Отправлено 10 апреля 2008 - 11:52

Да, на мой взгляд - это тоже самый идеальный вариант. Мы примерно по такому пути и пошли. Но, хочу вас предостеречь, чтобы вы не допустили той же ошибки, что и мы, при таком подходе. Все кусочки у нас сделаны в терминах 829 стандарта. Потом они просто с помощью XSLT собираются в предписаные этим же стандартом документы. Но это не очень хорошо, как оказалось. Лучше чтобы кусочки хранились в любом самом удобном виде, т.е. не надо использовать сущности 829 стандарта для хранения данных. А вот для отображения - можно. До меня поздно дошло, что 829 предписывает выходной формат документации. Если бы понял сразу - сейчас бы было проще.


1. А в чем ошибка, чтобы хранить данные в сущностях 829 стандарта?

2. Вы писали свои XSLT таблицы или использовали готовые?

3. И в чем удобней размечать XML, с учетом того, что народ лишь поверхностно знаком с этим, да и желателен интерфейс "Чтобы как в Ворде я мог это набрать без проблем"
  • 0

#7 LeshaL

LeshaL

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 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 не пришлось бы заполнять вручную, а можно былобы сгенерить автоматически :)
На самом деле наверняка есть еще много всяких разных мелочей. Написал, что вспомнилось сразу.

2. Вы писали свои XSLT таблицы или использовали готовые?

Конечно же сам. Даже не искал готовых. Так же как и XSD для XML-ных файлов. Ведь для того чтобы готовые XSL-ные файлы применить надо иметь XML-ные файлы в том виде, на который заточены эти XSL-тины. А как вы поняли, формат XML-ных документов мы делали сами.

3. И в чем удобней размечать XML, с учетом того, что народ лишь поверхностно знаком с этим, да и желателен интерфейс "Чтобы как в Ворде я мог это набрать без проблем"

А вот это проблема. Наверное самая большая-пребольшая. Все недоделки, логические недочеты, "неудобства" о которых я выше написал - все ничто по сравнению с тем, что XML мы пишем ручками в простом текстовом редакторе. Благо, обычно не так много данных надо вбивать в темплейты(специфика тестов такая). Но когда надо много текста, обычно в тест плане, то можно взять любой простой HTML редактор, написать там HTML, а потом код скопировать внутрь XML-ного документа. Специально сделано так, что контент многих элементов(например, scope в тестплане) является HTML-кодом - можно таблички, списки делать итд. Но это, конечно же, не решает проблему редактирования. Есть несколько вариантов - но ни один из них мне не нравится настолько, чтобы его применить.
  • 0
Regards,
Alexey

#8 Румата

Румата

    Новый участник

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Поплавский Илья Витальевич

Отправлено 11 апреля 2008 - 04:55

...


Спасибо за развернутое пояснение :) Буду думать, что можно придумать. Неудобства ясны и возможно мы с ними тоже бы столкнулись.

По поводу редактора - тут вот какая вещь - как объяснить людям(человек 30-40), никогда не размечавшим XML, что это надо делать, что это будет потом удобно в конечном выходном документе? Ведь ключевое слово - "потом", а все хотят сейчас и сразу.
Поэтому подумал, что ведь должен быть какой-нибудь редактор с интуитивно понятным интерфейсом. Выделил фразу "Тестовый случай", нажал кнопку на панели "Курсив" и у тебя стало
<i>Тестовый случай</i>
, но при этом внешне это должно выглядеть как обычный текст, без тегов разметки - народ ведь пугаться будет. И чтобы можно было к каждой кнопке привязать свой тег. Т.е новая проблема. Я раньше с этим не сталкивался, потому что сам просто брал, открывал тот же EditPlus и спокойно писал, что было нужно.

И еще тогда вопрос - а создание законченной системы как могли бы оценить в человеко-часах или в другом удобном измерении? Сколько это у вас заняло, если не секрет? И какой уровень специалистов был вовлечен в это дело? И какой выигрыш в итоге получили? (если это не секретная информация :) )
  • 0

#9 LeshaL

LeshaL

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 11 апреля 2008 - 08:17

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

Не секрет. Но оценить тяжело, т.к. система постоянно развивается до сих пор. Темпы разные, то бурно, то вообще никак - только потому что нет времени на доработку, но есть куда развиваться дальше. Первый прототип был сделан очень быстро (пара дней) и совсем не похож на то, что есть сейчас. Я уже говорил, что и раньше документация была сделана на основе 829го, но писалась в простом HTML. Первое, что было сделано - переход от HTML к XML+XSLT без каких-либо значительных изменений. Потом потихоньку стало наращиваться - тесткейзы отделились от тест процедуры(правду сказать с тест процедурами до сих пор не все у нас хорошо), shared тест дизайн-ы появились, кол-во документов увеличилось (раньше был только один тест дизайн, стало много), статусные страницы(для результатов тестирования) ... ну и так далее. По времени от первого прототипа до первой рабочей версии прошло где-то пол-года, не больше. Делал я один (коллеги помогали в обсуждении идеалогии\архитектуры итп) и ессно не было у меня 100% времени на эту задачу. Был проект, для которого я состовлял документацию - к концу проекта первая рабочая версия была готова.
Потом стали применять и в других проектах, постоянно что-то исправляя или добавляя на основании замечаний от коллег.

И какой уровень специалистов был вовлечен в это дело? И какой выигрыш в итоге получили? (если это не секретная информация :) )

Да тоже вроде как не секрет. Уровень специалистов у нас высокий. Писать XML - не проблема, но и народу у нас не 30-40 человек, а сильно меньше.
Выйгрыш, например, такой - одна и таже документация поняна и человеку и машине, документация всегда up-to-date. Тесты привязались к функционалу. Сам стандарт тут особо не причем - он использовался до того как я вообще пришел работать, он и остался - для людей вовлеченных в процесс это привычная форма. Но и недостатков много конечно, устраням потихоньку.
Используем 2+года.

По поводу редактора - тут вот какая вещь - как объяснить людям(человек 30-40), никогда не размечавшим XML, что это надо делать, что это будет потом удобно в конечном выходном документе? Ведь ключевое слово - "потом", а все хотят сейчас и сразу.
Поэтому подумал, что ведь должен быть какой-нибудь редактор с интуитивно понятным интерфейсом. Выделил фразу "Тестовый случай", нажал кнопку на панели "Курсив" и у тебя стало

<i>Тестовый случай</i>
, но при этом внешне это должно выглядеть как обычный текст, без тегов разметки - народ ведь пугаться будет. И чтобы можно было к каждой кнопке привязать свой тег. Т.е новая проблема. Я раньше с этим не сталкивался, потому что сам просто брал, открывал тот же EditPlus и спокойно писал, что было нужно.

Найдете удобный редактор или придумаете, как легко и удобно можно сделать свой редактор - дайте знать :)
  • 0
Regards,
Alexey

#10 Румата

Румата

    Новый участник

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Поплавский Илья Витальевич

Отправлено 12 апреля 2008 - 20:03

...


Спасибо за консультации :)

У нас проблема еще вот в чем стоит - сейчас тестовая документация представляется собой Word'овские файлы... И перевод всего в что-то другое тоже время займет. Я потому и спрашивал про трудозатраты. К ним надо добавить этот перевод документации в новый формат. И тогда попытки убедить, что стоит все это затевать, могут закончиться крахом.

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

А если писать что-то свое, то, судя по всему, много времени уйдет...
  • 0

#11 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 14 апреля 2008 - 09:02

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

Мы пользуемся для редактирования докбука редактором XMLmind (небесплатным, впрочем).
Он хорош ещё тем, что можно настроить для своей схемы документа способ визуализации при редактировании в визивиг-режиме.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#12 CheckiSt

CheckiSt

    Новый участник

  • Members
  • Pip
  • 25 сообщений
  • ФИО:Воробьев Михаил
  • Город:Москва

Отправлено 05 мая 2008 - 18:26

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


Алексей, я из общения не уловил - сейчас формат XML уже устоявшийся или ещё нет?
  • 0
Был бы код, а баг найдётся.

#13 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 06 мая 2008 - 04:06

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

Алексей, я из общения не уловил - сейчас формат XML уже устоявшийся или ещё нет?

XML -- это просто синтаксис, а редактор должен поддерживать семантику тегов, то есть для каждой схемы должен быть свой способ отображения и редактирования тех или иных тегов. Вопрос был про редактор для формата DocBook, то есть вполне конкретной схемы.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#14 Румата

Румата

    Новый участник

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Поплавский Илья Витальевич

Отправлено 08 мая 2008 - 11:30

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


Алексей, я из общения не уловил - сейчас формат XML уже устоявшийся или ещё нет?


А что значит, устоявшийся?
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных