Стратегия тестирования - Test strategy

Сравнить с План тестирования

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

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

Уровни тестирования

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

Роли и обязанности

Роли и обязанности руководителя тестирования, отдельных тестировщиков и менеджера проекта должны быть четко определены на уровне проекта в этом разделе. Это может не иметь связанных имен, но роль должна быть очень четко определена.

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

Требования к окружающей среде

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

Инструменты для тестирования

При выполнении тестовых случаев используются два метода: руководство и автоматизированный. В зависимости от характера тестирования, как правило, лучшим методом тестирования является сочетание ручного и автоматического тестирования.

Риски и смягчение

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

График испытаний

А план тестирования должен оценить, сколько времени потребуется для завершения фазы тестирования. Для завершения этапов тестирования существует множество требований. Во-первых, тестировщики должны выполнить все тестовые примеры хотя бы один раз. Кроме того, если дефект был обнаружен, разработчикам необходимо будет устранить проблему. Затем тестировщики должны повторно протестировать неудачный тестовый пример, пока он не будет работать правильно. И последнее, но не менее важное: тестировщик должен провести регрессионное тестирование ближе к концу цикла, чтобы убедиться, что разработчики случайно не сломали части программного обеспечения при исправлении другой части. Это может произойти в тестовых примерах, которые ранее работали правильно.

В расписании тестирования также должно быть указано количество тестировщиков, доступных для тестирования. Если возможно, назначьте тестовые примеры каждому тестировщику.

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

Подход к регрессионному тестированию

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

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

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

Тестовые группы

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

Приоритеты тестирования

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

Сбор данных о статусе тестирования и создание отчетов

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

Ведение протоколов испытаний

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

Матрица прослеживаемости требований

В идеале программное обеспечение должно полностью удовлетворять набору требований. Начиная с дизайна, каждое требование должно быть учтено в каждом отдельном документе в процессе разработки программного обеспечения. Документы включают HLD, LLD, исходные коды, модульные тестовые примеры, тестовые примеры интеграции и системные тестовые примеры. В требованиях матрица прослеживаемости, строки будут иметь требования. Столбцы представляют каждый документ. Пересекающиеся ячейки отмечаются, когда документ обращается к определенному требованию с информацией, связанной с идентификатором требования в документе. В идеале, если каждое требование рассматривается в каждом отдельном документе, все отдельные ячейки имеют действительные идентификаторы или имена разделов, то мы знаем, что каждое требование выполнено. Если какие-либо ячейки пусты, это означает, что требование не было выполнено правильно.

Резюме теста

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

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