Пара вопросов по TestLink

Добрый день!
В процессе ознакомления с инструментом возникли пара вопросов, может кто поделится опытом эксплуатации:
1) Я предполагаю, что на каждый заведенный в багтрекинге баг будут создаваться тест кейсы, прилепляемые к тест плану. Т.е. главная сущность тут будет тест план. Так вот мне кажется или в Тест линке довольно ущербный поиск тест планов? Кроме выпадающего списка справа(Current Test Plan) ничего пока не нашел. За то хорошо развит поиск спецификаций требований:)
2) Правильно ли я понимаю структуру работы с Тест Линком? Допустим есть проект по тестированию калькулятора. В Тест спецификации создаются всевозможные тест кейсы по тестированию калькулятора в целом, упорядоченные в тест комплекты. При появлении задачи по тестированию функции умножения, создается тест план, в который помещаются тесты из спецификации, касающиеся проверки умножения. Этот принцип я понял из мануалов.
Если так, то в реалиях большого проекта мне кажется не будет создаваться спецификация на все приложение в целом. Но если создавать тесты в спецификации под конкретный баг/задачу, спецификация на мой взгляд выступает пятым колесом. Проще было б сразу пихать тест кейсы в тест план без использования спецификации. Или же в крупных проектах с большой командой тестировщиков такой подход все же удобнее?
В общем интересно кто как использует инструмент, т.к. мне кажется у многих свои понимания и способы применения спецификаций, проектов и планов. Спасибо.

Привет,
Из опыта работы с тестлинком на примере небольшого проекта (5 программистов, 2 тестера, 1 год, за год количество функциональных тестов > 1500, UI > 500).
(!) "тестплан" ниже означает "тест план" в понятии тестлинка, т.е. набор тестов для выполнения. Для себя я его называла execution test plan.

Наиболее эффективный путь работы с тестлинком в итоге выглядел так.

В проекте было несколько активностей по тестированию, которые отличались подходом к созданию тестов, выполнению, итд.
Тестовая активность, в основном, шла от типа тестирования (FN/UI), но были проекты и под Acceptance тесты, в том числе отдельный проект для тестов под баги (так и назывался Bug Trash :) ). При этом функциональные тесты могли прогоняться несколько раз (это не было регрессионным тестированием, под повторный прогон подпадали тесты, которые еще ни разу не проходили успешно).

Мне нужно было получать информацию по прогонам в двух направлениях:
* сколько сделано из необходимого
* сколько сделано за определенный период

Итоговая структура тестлинка:
Под каждую тестовую активность создавался отдельный проект (т.е. их там было чтото 5 штук в итоге).

Схема работы по функциональным тестам (наиболее объемная деятельность).
ФТ создавались в тестовой спецификации со структурой уровня
Компонент -> Юнит требования (у нас были Features) -> Test Case
Тест кейс маркировался кейвордом, равным номеру спринта, в котором фича была имплементирована.

Все тест кейсы добавлялись в один тестплан в этом проекте (с условным названием "Функциональные тесты").
При выполнении действовали какие-то глобальные правила вроде "в такой-то период надо пройти все тесты для фич, имплементированных в спринте [кейворд]".
В результате всю нужную статистику я получала прямо в разделе Test Execution, не уходя в репорты, поскольку Test Execution тоже позволяет фильтровать по кейвордам.

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

Как итог:
* декомпозировать работу на большие куски для меня удобнее на этапе создания тестов(test specification), выполнение уже привязывается к этим кускам
* возможность фильтрации "на лету" тестов по аттрибутам для меня удобнее предварительного ручного создания наборов тестов

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

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

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

Есть руководитель проекта, который говорит - этот продукт создан для "Австралии" (это пример), поэтому самым важным для него явяется:
1. Корректная работа с локализацией.
2. Работа на типичном австралийком сервере, а у него такие характеристики: ...
3. Всё остальное неважно (остальное проверялось другими людьми)

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

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

Тесты выполняются в TestLink, при этом оформляются замечания, и создаётся связь между ссылками за замечания и TestLink-ом.
Раз в неделю формируется отчет - сколько тестов выполнено, и сколько осталось.
В конце тестирования формируется отчет чтобы узнать сколько тестов принесло дефекты и где проблемные места, а где все нормально.

Резюмирую: вся работа по подготовке производится вне TestLink. TestLink нужен только чтобы отразить факт прогона теста и связь с оформленным замечанием + прогнать тест по новой, когда замечание исправлено (там в отчёте видно по статусу замечания - пора прогонять тест снова или пока рано).