еще раз о документации

Здравствуйте! Бегала сегодня по форуму в поисках чего-то для меня важного, что я еще не до конца понимаю и наткнулась на топик"Составление Тест Планов., Это к тестировщику?" , в частности меня заинтересовал ответ Сергея, который Green. Вот выдержка:
"Помимо тест плана на проекте оформляются:
- тест кейсы;
- матрица тестовых конфигураций;
- еженедельный отчет о состоянии проекта;
- могут готовиться чек листы.
"
Я бы хотела у вас спросить в какой форме удобнее всего составлять тест кэйсы, чек-листы (а заодно и что это такое, т.е. что в них должно содержаться и какая форма недельного отчета используется у вас в компаниях). А что такое матрица тестовых конфигураций?

У меня сейчас как раз поиск идей как лучше составить документацию для тестирования. я составила в Excelе тест-кэйсы, не уверена только, что они верно составлены. Интуитивно чувствую, что можно их существенно улучшить или даже изменить, только не знаю еще как. А еще у меня в планах составить какой-нибудь документ для автоматического тестирования. Можете ли Вы, уважаемые форумчане, мне что-нибудь посоветовать?

На Сергея равнение держать и писать всё, что у них есть в документооброте -- себе дороже. Потому что у них CMM Level 5 :)

Alinabagi,

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

Проверили на конкретной странице работу конкретной функциоаньности с определенным наборов входных данных - записали результат. Если прошел тест - "Pass", если нет - "Fail" и баг в баг треккинговую систему. Результат сводите в 4-ю таблицу - таблицу проведения тестов.

Тест кейс - это набор таблиц. Каждая таблица описывает один тест. Состоит из двух частей.
1. Общие данные - номер тест кейса, название теста/ссылка на требование к системе, покрываемое тест кейсом, имя тестировщика, дата проведения теста, пред-условия теста, пост-условия теста, может еще чего - уже не помню.
2. Сам тест.
Таблица из 7 столбцов:
а. номер шага
б. объект системы или окно/страница приложения - например, веб страница Login
в. элемент объекта или элемент окна/страницы - элемент Text
г. действия по отношению к элементу - вводим имя пользователя и нажимаем кнопку Enter
д. результат системы на действия пользователя - после перезагрузки страница Login отображается с сообщением об ошибке "Не указан пароль"
е. ячейка для проставления Pass/Fail
ж. иногда выделяют дополнительную ячейку для указания номера бага (из баг треккинговой системы).

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

А я сделала свои тест кэйсы так: есть общая информация о тесткэйсе (номер, название, статус теста (например "не начат", имя тестера, дата) и конкретная информация о последовательности действий (номер шага, название шага, действие, Input-информация, ожидаемый результат, failed/passed, номер ошибки в багтрекинговой системе и комментарий), внизу еще есть поле для более подробного описания ошибки/ошибок и поле для предложений по улучшению). Вот.
А еще я подумала, что пока у нас нет Тула для ведения документации, то было бы целесообразно вести документацию с.о:
создается структура папок, в которой и находятся все документы для соответствующих релизов данного приложения и всегда есть один TestCasesTemplate для данного приложения, где прописаны все Тесткэйсы, а по нему потом и создаются уже вариации для каждой конкретной версии.
Про чек-листы я пока не думала. А можно обойтись вообще без них, именя только тесткэйсы?
в документе для Тесткэйса я сделала отдельную таблицу, в которой автоматически отслеживается состояние каждого конкретного кэйса и самая важня инфо о нем.

Давайте попробуем понять, когда упоминаемые чек-листы и описания тест-кейсов нужны, а когда -- нет.

Если тестирование производится вручную, то без них не обойтись.

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

Делать ли в этой табличке ссылки на зарегистрированные описания дефектов или нет -- дело вкуса. Сергей предлагает делать. Я предпочитаю не делать, а иметь отдельную таблицу, описывающую соответствие дефектов и тестов, которые их обнаруживают. Более того, если завести в трекинговой системе соответствующие поля (сессия и идентификатор теста), то такая табличка может быть легко сгенерирована, так зачем её заполнять руками?

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

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

Но это всё относится только к ручному тестированию!

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

Поэтому я считаю, что действительно необходимая документация -- это план тестирования, дизайн системы тестов (описание идей, на основании которых строится система тестов) и "пользовательская" документация, то есть информация о том, как тесты запускать. И всё.

Ну, плюс ещё отчёты начальству, но это можно и в устной форме, если всё идёт хорошо :)

Zdravstvujte, spasibo bolshoe za otvety!
Podskazhite, pozhalujsta, kakie est' Tools dlja vedenija dokumentacii.
Predlagala segodnja rukovoditelju svoi idei, a on skazal, chto eto, konechno, xorosho, chto u menja est' idei, no ochen' by xotelos' posmotret', kakaja struktura xranenija dokumntov (i kakix) v professional'nyx reshenijax. Koroche teper' ja v poiskax.
Konkretno, on ne znaet kak optimal'nee vsego organizovat' svjaz' testcasov s Checklistami i voobsche nado li eto delat', a kak ja dumala, chto dlja etogo nam nuzhen Excel-file testcasov i Excel-file cheklist, emu eto ne ponravilos'.

Для начала тест-кейсы в MS Word, таблица прогонов в MS Excel со ссылками на тест-кейсы -- идеальное решение.

Если есть деньги и желание, можно приобрести ПО типа Mercury TestDirector для управления, правда, не документацией, а всем, что относится к тестированию.

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

В "совсем профессиональных" решениях используется тяжёлый софт типа IBM Lotus или подобный. Но, я уже об этом писал, для маленькой команды это резко снизит эффективность коммуникаций.

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

Alexei, a mozhno ja vam na mail poshlju obrazec togo, chto ja sdelala, a vy mozhet posovetuete mne cho-nibud' po uluchsheniju, ja chto-to ne mogu pridumat' kak sovmestit' zhelanija rukovoditelja i celesoobraznost' vmeste? Prosto emu xochetsja chtoby vse bylo otobrazheno v odnom file, na odnoj stranice i so ssylkami drug na druga

Можно, конечно, пишите.

Что касается "всего на одной странице", то это как раз таки крайне непрофессионально. Представьте, что завтра вы наймёте ещё одного человека в отдел тестирования. Вопрос -- как вы будете вдвоём одновременно работать с этим файлом?

Если вдвоём садитесь прогонять тесты, открываете описанную выше табличку Excel в режиме синхронного доступа и ставите там статус выполнения теста. Это получится. А вот писать вдвоём более серьёзный документ уже сложно. Тем более перекрёстные ссылки ставтить. Проще иметь несколько файлов и делать ссылки между файлами, если нужно. В конце концов, сделайте всё в HTML и выложите в виде мини-сайта. Чем это хуже, чем цельный документ?

Если вдвоём садитесь прогонять тесты, открываете описанную выше табличку Excel в режиме синхронного доступа и ставите там статус выполнения теста. Это получится. А вот писать вдвоём более серьёзный документ уже сложно. Тем более перекрёстные ссылки ставтить. Проще иметь несколько файлов и делать ссылки между файлами, если нужно. В конце концов, сделайте всё в HTML и выложите в виде мини-сайта. Чем это хуже, чем цельный документ?

В расшареном Excel линки не проставишь, это так к слову.

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

Как это сделано у нас (после долгих поисков средства для автомазации ;) )
Один большой чеклист в расшаренном Excel. В первой колонке название папочки, во второй номер кейса.
сверху в колоночках название User Functional Point (New, Edit...). Если этот поинт нестандартный - в колоночку Misс.
Расставляем в местах, где есть UFP буковки "о"
Теперь самое интересное - пишем макросы (макросы нужно будет писать до расшаривания документа)
макрос №1 - создание тесткейса по правилам - если стоим на букве "о" - открыть темплейт, назвать его - номер+UFP, сохранить в соответствующую папочку - поставить в этой ячейке буковку "х".
макрос №2 - открытие существующего тесткейса - если стоим на ячейке с буковкой "х" - открываем тесткейс с названием №+UPF из указанной папочки.
макрос №3 - если стоим на "х" открываем тесткейс - пробегаем по закладкам, и коллекционируем состояние различных Test Flow - если хоть один свалился - Failed, иначе - если хоть один Incomplete - Incomplete - иначе - если все Pass - Pass,
закрываем тесткейс и раскрашиваем ячейку в нужный цвет - красный, серый или зеленый.
макрос №4 - то-же, что макрос №3, но по всему документу.

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

ЗЫЖ финальный мазок - в формате ячеек с буковками "о" и "х" ставим фонт Wingdings - у получаем пустые квадратики, и зачеркнутые. А также - выделяем верхнюю строку и ставим ей автофильтр.

Идея я думаю понятна.

Мне кажется, что потом всю ветку надо будет поместить в FAQ.
Как пример/образец/etc...

Что касается "всего на одной странице", то это как раз таки крайне непрофессионально. Представьте, что завтра вы наймёте ещё одного человека в отдел тестирования. Вопрос -- как вы будете вдвоём одновременно работать с этим файлом?

Если вдвоём садитесь прогонять тесты, открываете описанную выше табличку Excel в режиме синхронного доступа и ставите там статус выполнения теста. Это получится. А вот писать вдвоём более серьёзный документ уже сложно. Тем более перекрёстные ссылки ставтить. Проще иметь несколько файлов и делать ссылки между файлами, если нужно. В конце концов, сделайте всё в HTML и выложите в виде мини-сайта. Чем это хуже, чем цельный документ?

Вот недавно пришлось внедрять удаленно фриварную систему управления тесткейсами. :D
https://sourceforge....jects/testlink/

Для нескольких проектов вполне приемлимо, позволяет достаточно легко вводить тесткейс и делать по ним проход.
Принцип простой:
1. Создается продукт с категорими тестов и самими тестами.
2. Создается OS и Устройство на котором должно проводиться тестирование.
3. Из имеющихся наборов тестов формируется "тестплан".
4. В "тестплане" создается билд.
5. Назначается тестировщик, и он проходит указанный "тестплан".
6. Идет сверка результатов с предыдущими билдами ("сравнение метрик").

Написано не очень хорошим PHP-кодом. Но впринципе легко приспосабливается под свои нужды.
Для небольших компаний, особенно для ручного тестирования, вполне приемлимо.
Например если есть продукт и нужно провести конфигурационное тестирование на множестве устройст. Хотя можно делать и одну OS, один Device, и множество билдов. Вариантов масса.

Самый большой плюс. Что если несколько команд, то ексельками не очень удобно обмениваться, какие бы хорошие макросы не были (особенно если тест команды разбросаны по всему миру и порой это отдельные личности). А этот продукт "TestLink" дешевый и доступный.

Если кто-то все-таки глянет хорошо бы услышать его мысли.

Мы в нашей компании расположили структуру тестовых документов сл. образом:
У нас система поделена на бизнес апликацию и бизнес компоненты.
Главная директория - Lib_Tests, далее разделение на каталог - BA (Business Apllication) и BK (Business Component).
Под каждой из этих директорий разделение на типы тестов - unit, functional, system, integration. И уже под ними сама папка с сценарием тестов - в которой сам сценарий, папка для хранения нужной д-ции, конфигурации, входных тестовых данных.
И так далее... + соответсвующие папки для результатов тестов и для автоматизации.

У нас есть нарисованная картинка всей структуры. Если кого интересует могу прислать.

Плюс ко всему прочему вся эта система хранится в CVS, поэтому статус кейса и ошибки мы добавляем прямо в сценарий. А на следующую версию делаем отдельную ветку и пишем новые результаты. Только в CVSe неудобно хранить документы, нельзя сравнить изменения. Мы перешли на html.

Привет)
Если не ошибаюсь - то вы, Алина, пишите диплом по теме ведения процесса тестирования. Странный конечно ваш руководитель - все-то ему не нравится. Или он время пытается тянуть.. чтоб вам всегда было чем заниматься. Сам процесс ведения документации устанавливается уже в ходе работы в конкретной команде.. на конкретном предприятии. Идеализировать процесс конечно можно, но поработав некоторое время процесс обязательно изменится -под нужды самих тестировщиков, специфики тестируемого продукта.
Например опишу вкраце путь, пройденный мной и командой в которой я работаю (4 тестировщика): начиналось все с MS Word - по книгам создавали тест-кейсы. Пользовались этим мало, т.к. смычла не видели - т.к. у нас есть одна БОЛЬШАЯ ПРОБЛЕМА: у нас НЕТ аналитика и разработчики сами рещают как им писать код.. т.е по написанноме коду, по работающей программе (готовой версии) начинает проводиться тестирование!! Конечно - это неправильно.. но - надо как-то уживаться и работать и и такими условиями))). Ворд вымер. Следующим шагом стали Ексел таблицы. Сначала удобно... но почему-то и они вымерли)) И тут появился Ратионал. Долго я его крамсала, и , так как команда тестирования небольшая.. то остался нужным Робот, Менеджер и Маньюал. Подтянулся Кристалл Репортс - я настроила его так как нам удобно.. создает красивые отчеты.
Вобщем я считаю, что Ратионал для небольших компаний - это все равно, что молотком по муравью. Может здесь играет роль так же специфика продукта - банковское ПО. Оно достаточно часто модифицируется, т.к. замечания и указы по банкам публикуются довольно часто. Потому писать тест-кейсы для регрессионного тестирования не эффективно.
Мы ещё в поиске. Ищем удобство, простоту и в то же время эффективность ведения процесса тестирования. Не знаю - грустно как-то. А level 5 CMM - это конечно круто...

А вот иметь верхнего уровня документ, который описывает все, что есть на более нижнем - мысль более чем здравая - одно дело лазить по папочкам, которые
[ГРЫЗЬ]
Что мы имеем в результате? автоматизированную систему управляющую тесткейсами, и по этим результатам раскрашивающую чек лист, без излишней потери денег и времени.

ЗЫЖ финальный мазок - в формате ячеек с буковками "о" и "х" ставим фонт Wingdings - у получаем пустые квадратики, и зачеркнутые. А также - выделяем верхнюю строку и ставим ей автофильтр.

Идея я думаю понятна.

Документ, о котором я упоминал

Откроется при помощи Excel 2003, (когда сообразил - уже все залито было) в документе верхнего уровня есть макросы - на вирусы сами проверяйте, я стопроцентной гарантии не дам никогда.

В общем - жду комментариев, пожеланий а еще лучше - добавления новых фич или улучшений этого примера. :)

2 Case: Можно выкладывать в портфель, если есть желание конечно ;)

2 Guriy
Посмотрела. Тест кейс шаблон является собратом -близнецом одной разработки, на которую давал ссылку Баранцев (ссылку точно не помню) - но там было удобнее то, что в одной книге сразу было много страниц - одинаковых шаблонов. Понятно, что тут тоже можно их размножить - но лучше чтоб в самом шаблоне они были. Потом легче удалить ненужные. Дальше: как прогонять один тест-кейс много раз? Т.е. осуществлять и документировать регрессионное тестирование - копированием листов - и заменой дат?
На каждый тест-кейс по одной книге или вы подразумеваете по листу?
Также необходимо добавить связь между темплейтом и статусом - ведь у вас получается что статус надо полностью заполнять ручками. Хотя бы даже добавить связь Имя тестера и Результат прохождения. Или не подразумевается. что одной строке в чек-листе соответствует одна один тест-кейс?

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

Документ, о котором я упоминал

Несколько замечаний из своей практики.

TestCaseTemplate

1. Для каждого тест кейса я измерял время прохождения и добавлял этот показатель как минимальное время - Time min. К Time min добавлял время на запись одного - трех багов в систему (один баг - ошибка выполнения тест кейса, второй и третий - ошибки интерфейса, не влияющие на работу функциональности). Это было максимальное время выполнения тест кейса - Time max. Вычислял рассчетное время выполнения каждого тест кейса: Time = (Time min + Time max)/2. Расчетное время использовал для вычисления времени на выполнение запланированных тест кейсов на день/неделю/месяц.

2. В свой тест кейс я добавлял еще две колонки "Object" и "Subobject". К каждому объекту привязывался action, а уж затем - "expected results".

3. Нет необходимости делать три колонки для результатов каждого шага. Он может быть только успешным или нет. Если на каком-то шаге тест падает - дальше тестировать смысла нет, т.к. нет уверенности в корректность результатов.

Check List

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

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

Я не совсем понял, что означает QA в Chtck List.

Хелло Алл! Пример checklist который бросали еще живой?, ссылка не отвечает, может у кого есть пример чек-листа, в какой-то из веток форума был вордовский документ...

2 Guriy
Посмотрела. Тест кейс шаблон является собратом -близнецом одной разработки, на которую давал ссылку Баранцев (ссылку точно не помню) - но там было удобнее то, что в одной книге сразу было много страниц - одинаковых шаблонов. Понятно, что тут тоже можно их размножить - но лучше чтоб в самом шаблоне они были. Потом легче удалить ненужные. Дальше: как прогонять один тест-кейс много раз? Т.е. осуществлять и документировать регрессионное тестирование - копированием листов - и заменой дат?
На каждый тест-кейс по одной книге или вы подразумеваете по листу?
Также необходимо добавить связь между темплейтом и статусом - ведь у вас получается что статус надо полностью заполнять ручками. Хотя бы даже добавить связь Имя тестера и Результат прохождения. Или не подразумевается. что одной строке в чек-листе соответствует одна один тест-кейс?

Ну, это все-таки ехель, а не специализированный тул, поэтому с историей выполнения тяжеловато. Да и делалось это на коленке за час времени (можно конечно выделить какой нибудь скрытый воркшит для хранения результатов выполнения, да лениво). По поводу того кто и когда его выполнял, можно макросы подшаманить, но опять-же лениво. Если нужен такой фукционал, то нужно писать полноценное приложение, или использовать фришное, или покупать таковое (что тоже есть вариант)
Один поинт чеклиста подразумевает набор флоу, объединенных в воркбуке. Напримет операция редактирования - один тесткейс, флоу - смок, дизайн, валидация значений, локинг данных (совместная работа с одним объектом) и т.д.
ИМХО Такое разделение себя оправдывает, так как например только на логин форму у меня присутствует 6 флоу.