Презентация на тему Lesson 04. Планирование тестовых испытаний

качества, не стараются предположить проектные риски, не заботятся о

критериях качества и тд.
Тестировать нужно не только разные версии программы. Приступать к тестированию следует уже на этапе сбора требований. И тестировать далее на последующих этапах вплоть до выхода продукта. Частенько продукт продолжают тестировать и на этапе поддержки.

Введение

контексте тестирования и планирования тестовых испытаний проще всего рассматривать

следующую упрощённую модель:
Начало (inception).
Уточнение (elaboration). 
Разработка (construction).
Передача  заказчику (transition).

Связь планирования тестовых испытаний с жизненным циклом ПО

->
написаны функциональные требования;
Б) анализ требований для создания архитектуры и

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

Жизненный цикл ПО

тестировщики
Проводят модульное тестирование и интеграционные тесты
В) обе группы

специалистов
активно уточняют/дорабатывают требования и дизайн

Жизненный цикл ПО

активность)
Б) тестировщики
тестируют функциональность на всех уровнях тестирования (пиковая активность

в конце фазы)
В) работа с требованиями
сокращается, в конце фазы уже невозможно внести серьезные изменения

Жизненный цикл ПО

Б) сторонние тестировщики
проводят приемочное тестирование
В) тестировщики/программисты
активность спадает

Жизненный цикл ПО

стандарта качества
разработка спецификаций тестов
Разработка и выполнение тестов
создание ручных и

автоматизированных тестов
выполнение тестов
управление билдами (оценка состояния проекта)
Отчеты по тестам
сообщить проектной группе о качестве продукта
отслеживать состояние дефектов

Области ответственности тестировщиков:

весь объем работ по тестированию, начиная с описания объекта,

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

Тестовый план

тестирования конкретного продукта в конкретном проекте;
что, когда, кем и

как будет тестироваться;
компоненты тестирования;
команду тестировщиков;
стратегию и методы тестирования;
критерии качества и риски тестирования;
график работ.

Планирование и тестовый план

829


Тест план

работает и для чего он нужен
Понять, как продукт будет

использоваться
Хорошо изучить требования к продукту
Решить какие части продукта будут тестироваться и как
Убедиться, что выбранные области в полном объеме покрыты тестами
Решить, какие из методов и техник тестирования наиболее эффективны для проверки нашего продукта
Определить критерии качества продукта
Определить и приоритизировать риски, то есть ситуации, которые приведут к ухудшению качества программного продукта. А также подумать о том, как  предотвратить  возникновение  подобных  ситуаций,  и  как  из  них выйти
Выводы по всем вышеперечисленным пунктам попадают в тест-план, который нужно утвердить и разослать  всем  заинтересованным лицам
Создать такое тестовое окружение, которое будет максимально приближено к условиям, в которых продукт будет эксплуатироваться (production environment)

Необходимые действия на стадии планирования

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

отдельный раздел;
запрос на выделение тестового оборудования.

Артефакты, создаваемые на стадии планирования

Всегда  будут  возникать какие-то сложности или непредусмотренные ситуации во

время работы. Будут  возникать  ситуации,  когда  будет  трудно  расставить  приоритеты  той или иной деятельности: например, какие тесты выполнить в первую очередь, а  какие  выполнять  необязательно, (или  выполнить,  если  останется  время); какие  виды  тестирования  более  приоритетны,  а  какие – менее;  какая функциональность более  важна,  а какая – менее.
Также будут  возникать различные  ограничения,  которые  невозможно 
контролировать  или  на  которые  невозможно повлиять.
Однако,  всегда  можно  попросить  помощи  у  менеджера,   заказчика, группы разработчиков. Также, если видно, что что-то будет мешать тестированию, следует проинформировать об этом менеджера и заказчика и добиться понимания ситуации от них, а также согласовать действия, которые будут предприняты в данной ситуации.
Пример. В  процессе  подготовки  очередного  билда  программисты столкнулись  с  трудностями  и  выпустили  билд  на два дня позже  запланированного срока. В результате график тестирования тоже сместился и у тестировщиков будет меньше времени, чтобы выполнить свою работу. Следует согласовать заранее свои действия в этом случае.

Сложности планирования

вызванных этим событием.
Думая о рисках,  следует думать о  том, 

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

Пример. В продукте разрабатывается несколько приложений. Для того, чтобы  протестировать функциональность  приложения A,  требуется  использовать функциональность приложения B.  Разработчики  запланировали реализовать сначала функциональность приложения A, а только затем приложения B.

Риски

и оценка качества процесса
Оценка рисков
Документация и письма
Тестовая стратегия
Ресурсы
Метрики
Расписание
Ключевые точки


Секции

тестового плана

подвергаться тестированию. Здесь же может быть перечень компонентов или

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

Перечень работ (scope of work)

фирмой. Ограничение тестирования состоит в том, что мы не

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

Пример

будет приниматься заключение об уровне качества продукта и возможности

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

Критерии качества и оценка качества процесса (quality criteria and process assessment)

рисках (негативных ситуациях), которые могут возникнуть в процессе работы

над проектом и помешать (негативно повлиять) на тестирование продукта. Кроме описания самого риска, следует указать вероятность его возникновения и степень влияния на проект. Производная этих двух величин даёт показатель, который может рассматриваться как степень серьёзности риска. Чем выше этот показатель, тем больше внимания нужно уделить этому риску: обдумыванию последствий, составлению плана его предотвращения или выхода из ситуации, если риск наступит. Если риск случился (т.е. ситуация наступила), возникает реальная проблема («issue», «hot issue»), которую необходимо решить.

Оценка рисков (risk assessment)

Например:
тест план;
тестовые сценарии;
тестовые автоматические скрипты;
дефект-репорты;
отчеты о результатах тестирования.

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

Документация и письма (test documentation and deliverables)

плана.
Здесь расписывается стратегия тестирования, методы и типы тестов,

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

Тестовая стратегия (test strategy)

тестирования
Уровни тестирования
Отслеживание ошибок
Использование метрик

Тестовая стратегия (test strategy)

проекта, представители заказчика, лидер команды разработчиков и т.д.), список

тестировщиков с их ролями на проекте, а также с зонами ответственности.
Аппаратные ресурсы (hardware): сюда входит перечень тестовых серверов и рабочих станций, инструментов, используемых для тестирования или для вспомогательных работ, описание тестового окружения.
Программные ресурсы (software): операционные системы, СУБД, серверы приложений, веб-серверы и т.д.

Ресурсы (resources)

или иной аспект программного продукта или процесса в целом. Например:

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

Метрики (metrics)

есть хотя бы один Critical или High баг, либо

5% функционала не простестировано или имеет Medium или Low баги.

Правило

с графиком выпуска билдов и проектным планом, который разрабатывается

менеджером проекта.
Сюда же включаются основные даты (milestones): например, даты окончания промежуточных фаз работы над проектом.
График тестирования нужен для того, чтобы чётко понимать, когда и что следует делать, ничего не пропустить, ничего не забыть и т.д. Он же упрощает контроль за ходом работ по тестированию, а также позволяет оценить текущую ситуацию, определить, всё ли выполнено из того, что было запланировано.

Расписание и ключевые точки (schedule and milestones)

подход, стратегия, методы, виды тестирования.  Запланированный подход должен быть

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

Критерии хорошего тестового плана

окружение, программное обеспечение. – Должен быть определён график тестирования,

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

Критерии хорошего тестового плана

распланированный, систематизированный подход позволяет достичь лучших результатов работы, а

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

Преимущества хорошего тестового плана