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

[Ra.]

Введение

Здесь неоднократно поднималась тема про выбор средства управления процессом тестирования (Test management tools - TMT далее)... Возможно, некоторые вопросы, которые я здесь подниму/задам, тоже будут многим полезны...

Предыстория. Когда количество test case в компании стало исчисляться многими десятками, когда появилось несколько тестеров, стали серьёзно тестировать продукты на различных платформах, возникло обоснованное желание отказаться от ведения дел в элементарном Excel, и организовать свою работу на чуть более высоком уровне.

Исходные предпосылки:

1. bug-tracking система есть (куда без нее?). Поэтому
а) Для искомой TMT системы bug-tracking не нужен
б) Но, очень желательна возможность интеграции с bug-tracking системой (в любом виде на начальном этапе)

2. Большинство test case (и других документов: requirements, test plans и т.п.) существуют в виде word-документов. Это значит, что нужна система с развитой поддержкой attachments - чтобы эти документы просто аттачить.

3. Специфика разрабатываемого ПО следующая. Версии появляются не часто. Новые билды - регулярно. Скажем 2-3 в неделю (и чаще). Значит нужно, чтобы при появлении нового билда (в терминологии некоторых ТМТ - версии) не требовалось заново описывать для него весь набор test case'ов (это было бы утомительно), а просто добавить билд, и/или скопировать в этот новый билд весь набор case'ов предыдущего билда.

4. От билда к билду в некоторые тесты меняются. В принципе меняются как правило "результаты". Т.е. последовательность действий остаётся, а вот результаты - становятся другими. (Иногда повышается точность, иногда сам вид результатов и т.п.). Впрочем, это не важно что меняется. Вывод один - требуется версионность в для работы с test case'ами (ес-но что и версионность requirements тоже требуется, ибо тесты определяются требованиями к ПО).

5. Производимое ПО имеется в нескольких редакциях (например: Desktop, Enterprise edition и т.п.)

6. Производимое ПО может работать на нескольких ОС (правда пока одного семейства), например: Windows 2000, ХР и т.п.

7. Абсолютное большинство (для простоты будем считать что ВСЕ) test case'ов должны выполняться с одинаковыми (равными) результатами на любых платформах, в любой редакции ПО и т.п - т.е. функциональность ПО одинаковая (это, понятно, упрощает дело).

Итак, резюмируя, ничего, как мне кажется необычного. А именно, еще раз и кратко:

а) Есть набор test case'ов в виде doc-файлов, которые время от времени изменяются. В общем, набор test case'ов являет собой некоторое множество, каждый элемент которого (тест) должен выполняться на любой комбинации платформа/операционная система/редакция ПО и т.д.

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

в) Собственно результаты тестирования должны храниться а разрезах:
- операционная система (Windows 2000, ХР и т.п.)
- редакция ПО (Desktop, Enterprise edition)
- кто/где выполнил тест. Т.е. как минимум - какой тестер.

Ну чем больше здесь измерений - в принципе тем лучше. На будущее. Можно и платформу еще указать тестовую и т.п. и т.д.

Если еще и custom fields будут - вообще гуд.

г) Для тестов (требований) нужна поддержка версионности. В принципе наличие возможности управления требованиями не так критична. Бог с ними. Требования можно отдельно формировать, и указывать их как часть test case при разработке конкретного теста. Это конечно не идеально, но пока (на год-два, скажем, ближайших) вполне хватит.

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

Ес-но, поход к руководству за деньгами на данное мероприятия начнётся с первого же вопроса руководства: "А почему бы нам не использовать open source software?" Не буду сейчас вдаваться почему и насколько логичен и целесообразен данный подход у руководства. Для моего руководства - логичен. Аксиома. Поэтому буду рассматривать open source test management tools.

В следующих постах добавлю несколько своих наблюдений о разных продуктах. Буду рад, если подобной информацией поделятся те, кто реально использует Test management tools в своей работе - всем будет полезно :))

Начну с QaTraq и завтра напишу свою оценку и вопросы по QaTraq.

[Ra.]

Первым делом таки поставил TestLink 1.7.0

Интерфейс мне понравился. Достаточно продуман.

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

Очень приятно сделано представление Test Case(s) в виде дерева. Я читал в форумах, что дерево это притормаживает. Попробовал на полусотне кейзов - вроде нет. Может в предыдущих версиях тормозило? Кроме того, можно выбрать движок (путем настройки config - файла) которым будет это самое дерево показываться (есть три варианта). Так что здесь ставлю все-таки "+"

Какие возможности есть:

• Project Management - вершина иерхархии, так скажем.
• Test Plan Management - одни и те же тесты могут относится к разным планам и т.п.
• Build Management - в этом продукте можно легко добавить новый билд.
• Custom field management - это очень удобно. Скажем я не нашел поля "приоритет" для Test Case(s) (хотя глянул в БД, которая на MySQL, там вроде эти поля уже имеются, значит скоро и в интерфейсе появятся...)
• Keyword Management - это тоже пригодится, для фильтрации и отчетов в разных срезах.
• Requirement Specification - есть раздел для указания требований

Кроме того,

• для Test Case(s) реализована версионность записей в полном объеме.
• присутствует User Management и Role Management
• практически везде можно делать attachments.
• присутствует возможность интеграции с BUGZILLA, MANTIS, JIRA, TRACKPLUS (на выбор), это здорво!

Казалось бы бери и работай? Однако у меня появилось два вопроса, которые я не могу решить (если вдруг я где торможу, поправьте меня, это было бы здорово!!)

Итак мы имеем работающую систему TestLink. Выполняем очередной тест, записываем фиксируем в системе результат. Все чудно. Далее. С развитием разрабатываемого (пардон за масло маслянное) ПО меняются требования. Возникает первая проблема. А Requirement Specification то не имеет версий. Как же быть? У нас есть результаты тестов предыдущих билдов и т.п. и т.д, если я сейчас поменяю Requirement, я нарушу целостность. Итак это первый вопрос к знающим людям вообще (посоветовать) и к людям работающим на TestLink тем более. Как вы решаете эту проблему?

Вторая проблема (или я не понял?) мне кажется гораздо более серьёзной. Предположим в какой-то момент времени мы меняем Test Case(s), и, т.о., создаём новую версию этого самого Test Case'a. И вот тут у меня случился затык. А как ее привязать к существующему Test Plan'у? Я понял, что для этого из тест плана нужно удалить старый Test Case (и в этот момент потерять всю историю результатов по этому Test Case'у???!!!) и только после этого можно привязать новую версию Test Case'a. Вот это, мне кажется никуда не годится. Значит история выполнения теста хранится до первого изменения Test Case'a? А смысл тогда в версионности? Просто удаляй эту историю тогда да и все. Какой смысл хранить версии тестов, если к ним не хранится история выполнения тестов? Это серьезная проблема №2 .


Господа, ткните меня носом где и чего я не понял. Разубедите, что TestLink - очень хорошая штука, а проблема №2 не в TestLink, а в мой голове? :)) Буду очень признателен, ибо в целом - все очень толково и аккуратно сделано и понравилось.

Если будут еще мысли по TestLink'у - подредактирую этот топик.

[JimR]

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

[Alfa]

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

Фреймы на мой взгляд там не совсем к месту. Например прямого линка на тест кейс из-за этого нет.

Очень приятно сделано представление Test Case(s) в виде дерева. Я читал в форумах, что дерево это притормаживает. Попробовал на полусотне кейзов - вроде нет. Может в предыдущих версиях тормозило? Кроме того, можно выбрать движок (путем настройки config - файла) которым будет это самое дерево показываться (есть три варианта). Так что здесь ставлю все-таки "+"

На 50 оно еще не тормозит а вот на 300 уже заметно, в предидущих версиях тормозило.

Итак мы имеем работающую систему TestLink. Выполняем очередной тест, записываем фиксируем в системе результат. Все чудно. Далее. С развитием разрабатываемого (пардон за масло маслянное) ПО меняются требования. Возникает первая проблема. А Requirement Specification то не имеет версий. Как же быть? У нас есть результаты тестов предыдущих билдов и т.п. и т.д, если я сейчас поменяю Requirement, я нарушу целостность. Итак это первый вопрос к знающим людям вообще (посоветовать) и к людям работающим на TestLink тем более. Как вы решаете эту проблему?

Вторая проблема (или я не понял?) мне кажется гораздо более серьёзной. Предположим в какой-то момент времени мы меняем Test Case(s), и, т.о., создаём новую версию этого самого Test Case'a. И вот тут у меня случился затык. А как ее привязать к существующему Test Plan'у? Я понял, что для этого из тест плана нужно удалить старый Test Case (и в этот момент потерять всю историю результатов по этому Test Case'у???!!!) и только после этого можно привязать новую версию Test Case'a. Вот это, мне кажется никуда не годится. Значит история выполнения теста хранится до первого изменения Test Case'a? А смысл тогда в версионности? Просто удаляй эту историю тогда да и все. Какой смысл хранить версии тестов, если к ним не хранится история выполнения тестов? Это серьезная проблема №2 .

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

Еще могу сообщить что не так давно TestLink был переведен на русский язык(интерфейс и документация). В официальный релиз 1.7.0 перевод не попал, но он есть. Вот тут http://lib.custis.ru...
Проходила дискуссия по терминам и там же написано как получить перевод.

[Ra.]

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

Вторая проблема (или я не понял?) мне кажется гораздо более серьёзной. Предположим в какой-то момент времени мы меняем Test Case(s), и, т.о., создаём новую версию этого самого Test Case'a. И вот тут у меня случился затык. А как ее привязать к существующему Test Plan'у? Я понял, что для этого из тест плана нужно удалить старый Test Case (и в этот момент потерять всю историю результатов по этому Test Case'у???!!!) и только после этого можно привязать новую версию Test Case'a. Вот это, мне кажется никуда не годится. Значит история выполнения теста хранится до первого изменения Test Case'a? А смысл тогда в версионности? Просто удаляй эту историю тогда да и все. Какой смысл хранить версии тестов, если к ним не хранится история выполнения тестов? Это серьезная проблема №2 .

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

Вы возможно не совсем правильно поняли в чем проблема. Как технически обновить версию тест кейса до самой свежей ясно. Но дело в том, что используя интерфейс TestLink'a можно лишь сначала удалить (Remove) старую версию тест кейса из плана тестирования, при этом сразу теряются результаты выполнения тестов по этому тест-кейсу (Причем TestLink честно предупреждает, что результаты предыдущих тестов будут потеряны) и лишь после этого привязать уже новую версию к плану. Таким образом, при изменении версии и привязке новой версии тест кейса результаты тестирования предыдущих версий тест кейса теряются - вот о о чем была речь. (Лирическое отступление. Здесь вообще возникает вопрос - а зачем хранить историю версий test case'ов без истории результатов тестов? Ну зачем, ей богу? Ну это так.) Т.е. нет возможности, скажем так, relink'a, т.е. нет возможности привязать с какого-то момента времени (или с какого-то билда) новую версию тест-кейса взамен старой, и далее тестить уже по новым требованиям (не потеряв старой версии тестов и результатов тестов по этим версиям)

P.S. За ссылку спасибо, гляну обязательно.

[Ra.]

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

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

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

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

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

И, это не полный перечень аргументов еще...

Если же ваши условия работы требуют регулярного обращения к предыдущим версиям, то ищите видимо иной инструментарий или обходные пути. Например, бранчевание версий тестов, как и разрабатываемого ПО

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

Ну это понятно, что буду искать, пока не найду :) просто мне казалось, что если есть версионность тестов, то уж почему бы и не хранить результаты тестов всех версий? Мне казалось это логичным, и я надеялся (надеюсь), что это я где-то не разобрался в TestLink'e...

[SALar]

По моим оценкам, на прошлом проекте у нас было 5-10 тысяч записанных тесткейсов. Но я так и не понял, зачем на таком небольшом количестве нужна специальная система управления. Да и матрицу прослеживаемости там вести необязательно. Все таки это не те объемы.
Вот с чем соглашусь, так это с тем что Excel иногда сильно удобней Word.

[greesha]

По моим оценкам, на прошлом проекте у нас было 5-10 тысяч записанных тесткейсов. Но я так и не понял, зачем на таком небольшом количестве нужна специальная система управления.

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

[SALar]

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

Естественно была такая необходимость. А в чем проблема?

[Darkus]

Excel по-любому удобнее.
Там можно делать и группировки, и общий шаринг, и читабельность в таблице выше, чем сплошной текст.
К тому же по листочкам удобнее группировать.
А иногда требуется автоподсчёт.... и ещё фишки, вроде ссылки на адрес ячейки.

[SALar]

Вордовый документ печатать проще.
Но я согласен, что Excel, с экрана, да еще с человеческим разрешением вроде 1920х1200 выглядит предпочтительней.

[SALar]

Съездив с мужем на рыбалку, жена рассказывает подруге: - Понимаешь, я все делала не так. Говорила слишком громко, топала ногами, взяла не ту наживку, не так насаживала червяка, забрасывала удочку не туда, клевало у меня неправильно, подсекала я то рано, то поздно и вообще поймала рыбы больше, чем он.

[Arkady]

Вы возможно не совсем правильно поняли в чем проблема. Как технически обновить версию тест кейса до самой свежей ясно. Но дело в том, что используя интерфейс TestLink'a можно лишь сначала удалить (Remove) старую версию тест кейса из плана тестирования, при этом сразу теряются результаты выполнения тестов по этому тест-кейсу (Причем TestLink честно предупреждает, что результаты предыдущих тестов будут потеряны) и лишь после этого привязать уже новую версию к плану. Таким образом, при изменении версии и привязке новой версии тест кейса результаты тестирования предыдущих версий тест кейса теряются - вот о о чем была речь. (Лирическое отступление. Здесь вообще возникает вопрос - а зачем хранить историю версий test case'ов без истории результатов тестов? Ну зачем, ей богу? Ну это так.) Т.е. нет возможности, скажем так, relink'a, т.е. нет возможности привязать с какого-то момента времени (или с какого-то билда) новую версию тест-кейса взамен старой, и далее тестить уже по новым требованиям (не потеряв старой версии тестов и результатов тестов по этим версиям)

P.S. За ссылку спасибо, гляну обязательно.

У меня возникла та же проблема. Чтобы обойти её решил каждый раз создавать новый тестплан из уже существующего старого и в новом тест плане заменять старые тест кейсы на новые. Таким образом вся история будет храниться в старом тестплане. Чтобы старый тестплан не захламлял список тестпланов на главной странице - делать ему inactive. Но на практике ещё этого не проверял, может и здесь возникнут проблемы.

[saezar]

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

Присматриваюсь к SpiraTest. Почти идеально. Портит впечатление слабое управление пользователями. Всего 6 предопределённых ролей, отсутствие групп пользователей, невозможность регулирования прав между ролями, Невозможно добавить свои роли, и нельзя в проекте роли совмещать. Но кмуто может подойдёт.

[Alfa]

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

А кто вам мешает все шаги пронумеровать и каждый шаг сопоставить результату. Там же WYSIWYG редактор - пиши что хочешь.
По мне неудобно когда форма тест кейса задана.

Нет поля для указания тестовых данных

В версии 1.7 есть настраиваемые (custom) поля. Этого не достаточно?

[Ra.]

Присматриваюсь к SpiraTest. Почти идеально. Портит впечатление слабое управление пользователями. Всего 6 предопределённых ролей, отсутствие групп пользователей, невозможность регулирования прав между ролями, Невозможно добавить свои роли, и нельзя в проекте роли совмещать. Но кмуто может подойдёт.

Глянул SpiraTest. Интересно, но... Верно говорят, что на вкус и цвет товарищей нет... :)

Мне в SpiraTest не понравилось что тест "жестко" привязан к проекту. Т.е. скажем нельзя описать один тест и использовать ссылку на него в/из разных тест-планов (Само понятие тест-плана отсутствует). Поясню. Скажем у меня есть Standalone и client-server версии выпускаемого ПО. Для Standalone у меня будет один набор функциональных тестов, для client-server вообще говоря будет другой, более широкий набор тестов, связанный с другой архитектурой ПО, но базовую функциональность ПО можно проверять одними и теми же тестами к примеру...

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

[saezar]

Согласен.

тест "жестко" привязан к проекту

- ещё один минус. У меня то же случаются подобные ситуации.

Коллеги, всё таки, передо мной так же стоит этот непростой выбор средства управления тестированием. Очень хотелось бы получить систему, удовлетворяющую моим требованиям. Формулировать требования здесь бессмысленно - никто к ним не прислушается и по заказу систему не изготовит. Единственное что здесь можно сделать - описать минусы систем, которые мы используем. Только это поможет сделать правильный выбор. Для кого то минусы будут несущественными, для кого то они неприемлимы соввершенно.
Я пробовал работать с TestLink и с SpiraTest. Постараюсь в свободное время в блоге описать их минусы.
Однако есть вопрос. Никак не удаётся пощупать ни Rational ни Mercury. Как я понял, у этих производителей целый набор ПО, комбинируя который, можно собрать то что нужно. Мне в частности пока не требуется автоматизированное тестирование.
Какое ПО нужно использовать из этих линеек для управления требованиями, тестированием и багтрекинга? Где о нём можно почитать реальные отзывы? Обязательно ли обучение сотрудников для работы с ним, или можно вникнуть на лету? Насколько оно подойдёт для команды тестеров в 5-7 человек? (разработчиков больше, сразу скажу). И гдеж его взять, в конце концов.

[slat]

Насколько я понимаю тебе бы подошел Mercury Quality Center но у него есть минус он стоит очень много денег :)
А попробовать ты его можешь здесь

[Ra.]

Насколько я понимаю тебе бы подошел Mercury Quality Center но у него есть минус он стоит очень много денег :)
А попробовать ты его можешь здесь

Поставил/посмотрел Mercury QC. Интересно. Но очень дорого :(
Пока смотрел Mercury меня посетило интересное размышление - версионность требований в Mercury QC есть (по-крайней мере есть history, где можно наблюдать чего и как менялось). При этом версионности самих тестов - ... нет. Вот не нашел и все тут :(
А мысль простая меня посетила - если уж в супер дорогом и (наверное? методически правильном с точки зрения по-крайней мере общепринятых западных стандартов) Mercury QC нет версионности тестов, стало быть это и не нужно? (только не пинайте ногами за такой вывод, я просто размышляю):

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

Ну это так. Лирическое отступление.

[YuP]

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