Yarilo

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

Caliber в этом плане больше подходит? Вы его используете?

Caliber - удобный инструмент для управления требованиями, мне в нем больше всего пригодились функции группировки требований, представление требований в виде дерева и подсистема публикации - можно настроить Word - шаблон и на его основе сделать экспорт требований в формате Word - документа.

Привет!

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

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

--таким образом нельзя провести smoke test

Вот это я не поняла - что значит нельзя провести smoke test? По какой причине нельзя провести?

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

--функциональность продукта (работа по назначению)- описать таким способом не получится.

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

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


p.s. поздно заметила ответы в теме - прошу прощения за запоздалый ответ :)

Кажется я поняла :rolleyes:

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

Я описала только подход к планированию и документации тестирования - минимальная документация при ОПРЕДЕЛЕННЫХ условиях (которые для некоторых проектов и, возможно даже, компаний не соблюдаются).

Видимо все недоразумения из-за этого :huh:

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

Я не предлагаю в чек листе писать "что именно это должно произойти", чек лист лишь предъявляет требование, которое должно быть КАКИМ-ЛИБО образом протестировано (для разных проектов по-разному). А как именно протестировано - вот это "что именно это должно произойти", и это тестировщик сам определяет как тестировать (для этого необходимым условием является знание тестировщиком корректного поведения системы, что и было оговорено :) ). При наличии времени на описание можно написать как тестировать каждое требование из чек листа для конкретного проекта (это уже будет тест процедура).

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

p.s. поздно заметила ответы в теме - прошу прощения за запоздалый ответ :)

Обычное дело :)

Пыталась как-то недавно внедрить данный принцип работы с чек-листами. Стандартные, часто тестируемые функции описаны отдельно. При тестировании указывается ссылка на чек-лист. Но на практике получилось так:
--всех реально тестируемых функций не охватишь - будет очень большая таблица
--таким способом можно описать лишь ОСНОВНЫЕ, часто встречаемые аспекты
--и они (часто встречаемые аспекты) иногда в соответствии со спецификацией продукта довольно изменчивы
--таким образом нельзя провести smoke test
--неудобно хранить инфу о прохождении тестов - надо постоянно переключаться на другой файл для просмотра что же мы тестировали
--функциональность продукта (работа по назначению)- описать таким способом не получится.

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

Попробовать внедрить все равно стоит -на разных предпрятиях по разному процессы уживаются.

Привет! Немного комментариев для Doveangel :)

--таким способом можно описать лишь ОСНОВНЫЕ, часто встречаемые аспекты

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

--и они (часто встречаемые аспекты) иногда в соответствии со спецификацией продукта довольно изменчивы

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

--таким образом нельзя провести smoke test

Вот это я не поняла - что значит нельзя провести smoke test? По какой причине нельзя провести?

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

Это точно :)

--функциональность продукта (работа по назначению)- описать таким способом не получится.

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

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

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

"... а еще мне петь охота.
За кружок по рисованию
тоже все голосовали."

Doveangel,
Вам повезло в одном - Вы получите представление о всех перечисленных Вами видах деятельности.

Green, вы не могли бы пояснить, что вы хотели сказать этим постом?