Перейти к содержимому

saveug

Регистрация: 23 сен 2009
Offline Активность: 27 июн 2013 07:19
-----

Мои сообщения

В теме: Visual-Studio 2010 -Не запускается нагрузочное тестирование

18 июня 2012 - 14:39

Тут вот какие возможны проблемы:

1. В студии не прописана строка подключения к БД, где будут храниться результаты нагрузочного тестирования ( Tests -> Manage Tests Controllers -> Load tests results store )
2. База для результатов нагрузочного тестирования не создана.

В теме: Помогите с поиском системы для сбора статистики

19 апреля 2012 - 12:08

Описанные отчеты довольно специфичные, но вся информация для их построения имеется в системе http://devprom.ru и система эта а) бесплатная и б) повторяет в большей степени FogBugz.
Подробнее о возможностях можно почитать здесь

В теме: Test Managment Tools

03 апреля 2012 - 07:10

Роман, привет!

Могу поделиться возможностями инструмента, который не входит в исходный список

  • Requirements storage (хранение требований)
  • Test Plan storage (хранение тест плана)
  • Traceability test cases and bug reports (трассировка тест кейсов с тест репортами)
  • Traceability test cases and test plan (трассировка тест кейсов с планом)
  • Traceability test cases and requirements (трассировка тест кейсов с требованиями)
  • Traceability test plan and requirements (трассировка тест плана с требованиями)
  • Tracking changes in test cases, test plan or requirements (трекинг изменений в тест кейсах, в тест плане или требованиях)
  • Ability to create versions for test cases, test plan and requirements (возможность создать версионность для тест кейсов, тест плана и требовний)
  • Ability to create platforms (возможность организации процесса под несколько платформ, кросс-платформеность)
  • Ability to create assemblies (возможность отследить сборки)
  • Estimation of testing coverage (оценка покрытия тестирования)
  • Reports storage (хранение репортов)
  • Limitation of storing information (ограничение на объем хранимой информации)
  • Transferring test cases (импорт\експорт тест кейсов)
  • Integration with bug tracking systems (интеграция с разл баг трекинг системами)
  • Price (цена)


1. Встроенная поддержка автоматизации управления требованиями
2. Формирование тест планов из разделов тестовой документации
3. Все перечисленные виды трассируемости (на баги, на планы, на требования)
4. Аудит изменений всех объектов в системе, обсуждение по всем объектам системы
5. Поддержка различных платформ (через описание и использование перечня окружений), поддержка работы со сборками
6. Покрытие тестирования можно контролировать по списку фичей (эпиков), баклогу продукта, релиза или итерации.
7. Хранятся репорты выполненные вручную или сформированные автоматизированной тулой
8. Встроенный баг-трекер.
9. Бесплатно, без ограничений.

В текущей версии не поддерживается: версионность тест-кейсов, планов и требований. Но хорошая новость в том, что это фича следующей версии.
Импорт/экспорт можно выполнить через API, но можно и предложить разработчикам доработку.

Вы можете подробнее познакомиться с функциональными возможностями на сайте инструмента: http://devprom.ru
Там же есть описание вариантов решения типовых задач по организации тестирования или управления требованиями.

В теме: Когда фича протестирована в Ajile?

17 января 2012 - 12:56

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

Поскольку сами по себе требования к качеству выражаются специфическим образом для каждого проекта или продукта, то вряд ли кто-то сообщит внятный их список и язык, на котором их формулировать.
Для начала исследования этой темы я бы предложил Вам начать с чего-то простого и почитать вот эту простенькую методологию тестирования:
http://code.google.c...ki/AccExplained

Она совсем прям в стиле Agile, как Вы и хотите.

В теме: Программисты отдают на тестирование программы работающие менее чем нап

08 сентября 2011 - 12:29

Я бы донес проблему до лица, ответственного за принятие соответствующих решений: функциональное тестирование покрывает <50% требований, в этом я вижу серьезный риск для качества продукта.

Анализ причины: ресурсов для тестирования явно не достаточно (+ обоснование, что действительно недостаточно).

Предложение: снизить количество актов смоук-тестирования с X до 1, путем введения правила: тестировщики не принимают в работу релиз, который не проходит хотя бы один тест из набора смоук-тестов.

Уже проходили это - работает, а если не сработает, значит то качество, которого Вы добиваетесь, никому не нужно. А вот с этим что делать - решать Вам лично :)