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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сбор и отчетность о статусах испытаний

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

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

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

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

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

Итог теста

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

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

См. также

Ссылки

Амманн, Пол и Оффатт, Джефф. Введение в тестирование программного обеспечения. Нью-Йорк: Издательство Кембриджского университета, 2008 г.
Бах, Джеймс (1999). «Стратегия тестирования» (PDF) . Проверено 31 октября 2011 г.
Дассо, Аристид. Верификация, валидация и тестирование в разработке программного обеспечения. Херши, Пенсильвания: Паб Idea Group, 2007 г.