Публикации ElenaF

#31491 Регламент передачи кода на тестирование

Отправлено автор: ElenaF 08 августа 2006 - 13:17 в Управление тестированием

У нас проблема похожая. ТОлько всё уже усугубляется тем, что есть жесткие сроки выпуска очередной версии... Практически всё время на выпуск версии съедает разработка, поэтому тестировщики, чтобы не подвести всю проектную группу перед выпуском работают со значительной перегрузкой. Что естественно, не может не сказываться на том, насколько внимательно, то есть качественно, проверяют.
Мы пробовали делать так: по плану разработки с такой-то даты должно начаться финальное тестирование, а разработка еще не завершена -> тогда мы начинаем тестирование всё равно, но при получении каждого нового билда на тестирование вместе с ним мы получаем отчет об изменениях в проекте с анализом того, на что эти изменения повлияли -> на основе этого отчета решаем, что из протестированного функционала надо перетестировать, а что нет. Это помогает. Но не для всех проектов. Так как такая вот работа с изменениями - это дополнительная нагрузка на руководителя проекта. а на это идет не каждый.
Поэтому мы вот тоже думаем, как бы так организовать процесс разработки, чтобы не съедалось время выделенное на тестирование, чтобы как-то отделить планы по разработке от планов по тестированию... Но, поскольку, тестирование - это часть цикла разработки, то резать по живому не получается...

#31489 DevTrack

Отправлено автор: ElenaF 08 августа 2006 - 13:00 в Инструменты управления тестированием ПО

А какая у вас версия DevTrack установлена?
Насколько я помню, начиная с версии 5.5 (а может и раньше), у них появилась возможность в программе администрирования менять кодировку (это касается e-mail сообщений и истории).
Для того, чтобы в отчетах всё было хорошо надо руками в Crystal Reports поменять используемые ими шрифты на кириллические.

#22801 Кто должен делать сборку

Отправлено автор: ElenaF 14 декабря 2005 - 08:41 в Управление тестированием

На мой взгляд за сборку должен быть назначен отдельный ответственный. Он отвечает за:
1. написание сборочных скриптов,
2. сохранность конфигурации для сборки и ее документированность,
3. за соблюдение единой технологии при сборке разных проектов (например, положение каталогов Temp, Out, Lib в структуре дерева с исходными текстами),
4. за поддержку сборочных скриптов (в случае добавления новых собираемых модулей),
5. за выполнение сборки и инициализацию разбора, в случае, если билд не собрался.

#22755 Кто должен делать сборку

Отправлено автор: ElenaF 13 декабря 2005 - 13:15 в Управление тестированием

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

#22577 Что использует служба поддержки

Отправлено автор: ElenaF 08 декабря 2005 - 16:19 в Управление тестированием

Хотелось бы узнать, какие средства для работы с клиентами используют службы поддержки? Например, HP HelpDesk или что-то еще?
Инегрируются ли эти софтинки с вашими BugTracking Systems? Если да, то с какими?

#21685 Purify и драйвера

Отправлено автор: ElenaF 16 ноября 2005 - 14:42 в IBM Rational - Functional Testing

Доброго времени суток!
Знает ли кто-нибудь можно ли, а, если можно, то как, использовать Purify для проверки драйверов, служб, или, например, Gina?

#21078 Требования к описаниям проблем

Отправлено автор: ElenaF 28 октября 2005 - 13:43 в Управление тестированием

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

#21002 Требования к описаниям проблем

Отправлено автор: ElenaF 27 октября 2005 - 13:26 в Управление тестированием

Например, потребовать от тестировщика убедиться в повторяемости проблемы можно. А вот потребовать у клиента снова уронить боевой сервер...
Да, с внешними немного по-другому.
Если у клиента проблема повторится, он сам вам об этом с удовольствием сообщит.
А вы тем временем добьетесь повторения на своей площадке. Главное - суметь собрать максимум доступной информации.

Вот в том-то и задача: сформулировать для клиентов списко того, что они должны нам предоставить для облегчения диагностики и воспроизведения проблемы у нас.
Понятно, что необходимы сведения об операционке, о конфигурации железа, об установленном ПО. Нужно подробное описание проблемы, того, что делали.
А этого достаточно? Или есть что-то, лежащее на поверхности. nxj я упустила?

#20818 Требования к описаниям проблем

Отправлено автор: ElenaF 24 октября 2005 - 09:24 в Управление тестированием

Спасибо за ссылки.
Эти статьи я читала.
Дело в том, что я не уверена, что все требования по описанию проблемы, сформулированные для тестировщика, применимы к "внешним" пользователям.
Например, потребовать от тестировщика убедиться в повторяемости проблемы можно. А вот потребовать у клиента снова уронить боевой сервер...

#20817 DevTrack

Отправлено автор: ElenaF 24 октября 2005 - 09:21 в Инструменты управления тестированием ПО

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

Построение структуры выполняется в разделе Document View. Структура - дерево. Первый уровень - запросы на изменение (доработку), второй уровень - для каждого из запросов на изменение - список поручений (в Вашей треминологии).
Затем переходите в основной вид, там выбираете создание нового запроса и перед Вами появляется созданная Вами структура. Дальше только расставляете птички на нужны "Поручения", задаете ответственного, заполняете те поля, которые нужны - и у Вас готово задание на тестирование изменений.
Это то, что вы хотели?

#20767 Требования к описаниям проблем

Отправлено автор: ElenaF 21 октября 2005 - 13:29 в Управление тестированием

Стоит задача формализовать требования к описанию проблемы, произошедшей у конечного пользователя. Описание проблемы будет делать представитель Hotline, например, то есть сотрудник фирмы-разработчика.
Формализация требований нужна для того, чтобы "внешний" запрос сразу содержал максимальное количество информации, полезной для диагностики проблемы.
Занимался ли кто-либо чем-то подобным? Буду благодарна за помощь и совет.

#20765 DevTrack

Отправлено автор: ElenaF 21 октября 2005 - 13:18 в Инструменты управления тестированием ПО

У DevTrack есть поддержка двух типво проектов: проектов для управления разработкой и проектов для управления тестированием. Выбор возможен только на этапе создания проекта в DevTrack. Может 'fn возможность Вам поможет?