Документация обычно содержится в тестпланах
 Скачать 270.2 Kb.
|
Управление тестированиемТестовый отчет может быть связан с одной или несколькими задачами. Таким образом вы можете назначать работу на тестировщиков. В каждой задаче указываются плановые трудозатраты, исполнитель и фактические трудозатраты. Назначенные тестировщику задачи отображаются в списке "Мои задачи" и в верхней части приложения, в списке ближайших задач. Распределение задач по команде, итерациям удобно осуществлять на доске задач. Зафиксируйте фильтр по типу задач, чтобы показывать доску задач тестирования. На основе плановых трудозатрат можно просматривать загрузку участника и выявлять свободные ресурсы или определять перегрузку, с учетом вовлеченности тестировщиков в нескольких проектов. На основе фактических трудозатрат можно строить план/факт анализ. Автоматизированное тестированиеРезультаты выполнения автоматических тестов могут быть импортированы в систему на одном из этапов подготовки и выпуска сборки. Обычно этим занимаются сборочные серверы (или сборщики), такие как Jenkins или TeamCity. Команда для импорта тестового отчета указана в подсказке в модуле "Тестовые отчеты". Для проверки возможности импорта вашего отчета используйте действие "Импортировать отчет". Помимо стэка вызова и другой отладочной информации, в отчет по тестированию удобно вставлять скриншоты приложения. Такие скриншоты формируют контекст для анализа и воспроизведения дефектов. Включение скриншота в отчет осущствлятся средствами вашего инструмента запуска автотестов. Например, для случая Selenium, это небольшой кусочек кода. Разрабатывайте функциональные и интеграционные автотесты на основе тестовой документации. Затем, после реализации соответствующего тест-класса или тест-метода, добавьте аннотацию Description, в которой укажите идентификатор автоматизированного сценария. Таким образом, в результатах тестирования вы сможете просмотреть как текст сценария, так и результат его тестирования. @Test(description="S-1685") public void myTestMethod() { // ... } Это позволит связать автотест с исходным сценариев. Так куда удобнее анализировать проблемы, поскольку в тексте отчета будет виден исходный текст сценария. Применение BDDBDD (Behavior Driven Development) - практика разработки кода на основе приемочных сценариев (так называемых исполняемых спецификаций). Приемочный сценарий пишется на специальном языке (Gherkin), который позволяет автоматически создавать заглушки программного кода. Эти заглушки реализуют программисты, вызывая при этом программный код. Получаются такие автотесты, сценарии по которым пишут не программисты, а реализуют их программисты. Существует много фреймворков для реализации этого подхода, под разные языки программирования. Сложность у всех одна: кто и где пишет эти самые сценарии, где они хранятся, как отслеживается их актуальность в соответствии с требованиями. Devprom ALM позволяет разрешить эту проблему. Приемочные сценарии на языке Gherkin пишутся в рамках разработки тестовой документации. При разработке и перед запуском таких автотестов, акуальная версия сценариев выгружается из системы и виде набора файлов (сценариев). Программисты используют эти файлы для разработки новых тестов или исправления сломаных. Сборщик использует эти файлы для запуска тестов через фреймворк. Для бесшовной интеграции можно систематически сохранять изменения в используемой системе контроля версий. Графики, метрики и отчетыВ процессе тестирования программных продуктов образуется большой объем полезной информации, которую можно использовать для анализа процесса, качества продуктов и измерения продуктивности работы команды. В Devprom ALM реализованы наиболее полезные метрики, которые команды используют в своей работе: Таблица ошибок - используйте график для анализа прогресса решения критичных ошибок, выявления этапов процесса, на которых сосредотачивается наибольшее количество критичных ошибок. История обнаружения ошибок по неделям - используйте отчет для выявления дисбаланса в скорости обнаружения ошибок тестировщиками. При значительном количестве обнаруженных ошибок стоит вернуть сборку разработчикам для стабилизации. При снижении общего количества обнаруженных ошибок прогнозируйте дату выхода релиза. Распределение пожеланий по приоритетам - с помощью этого графика можно, например, увидеть динамику появления критичных ошибок в проекте в целом или в рамках конкретного релиза. График сходимости дефектов - график сходимости позволяет оценить динамику заведения новых дефектов, исправления дефектов, а так же визуализировать общее количество дефектов, находящихся в состояниях добавлено и выполнено. Производительность тест-дизайна - используйте отчет для анализа объема изменений в тестовой документации, для выявления моментов разработки тестовой документации, для сравнения продуктивности тест-дизайнеров. График разработки тестовой документации - используйте график для контроля за подготовкой тестовой документации в релизе или проекте. Перед началом тестирования очередного релиза продукта требуемые разделы тестовой документации должны быть уже подготовлены. |