Стратегия тестирования — это схема, описывающая подход к тестированию цикла разработки программного обеспечения . Целью стратегии тестирования является предоставление рационального вывода из организационных, высокоуровневых целей в фактические действия по тестированию для достижения этих целей с точки зрения обеспечения качества. Создание и документирование стратегии тестирования должно осуществляться систематическим образом, чтобы гарантировать, что все цели полностью охвачены и поняты всеми заинтересованными сторонами. Она также должна часто пересматриваться, оспариваться и обновляться по мере развития организации и продукта с течением времени. Кроме того, стратегия тестирования должна также быть направлена на согласование различных заинтересованных сторон обеспечения качества с точки зрения терминологии, уровней тестирования и интеграции, ролей и обязанностей, прослеживаемости, планирования ресурсов и т. д.
Стратегии тестирования описывают, как риски продукта заинтересованных сторон смягчаются на уровне тестирования, какие типы тестирования должны выполняться и какие критерии входа и выхода применяются. Они создаются на основе документов по проектированию разработки. В первую очередь используются документы по проектированию системы, а иногда могут упоминаться документы по концептуальному проектированию. Документы по проектированию описывают функциональность программного обеспечения, которая будет включена в предстоящем выпуске . Для каждого этапа проектирования разработки должна быть создана соответствующая стратегия тестирования для тестирования новых наборов функций.
Стратегия тестирования описывает уровень тестирования, который должен быть выполнен. В основном существует три уровня тестирования: модульное тестирование , интеграционное тестирование и системное тестирование . В большинстве организаций по разработке программного обеспечения разработчики отвечают за модульное тестирование. Отдельные тестировщики или группы тестировщиков отвечают за интеграционное и системное тестирование.
Роли и обязанности руководителя тестирования, отдельных тестировщиков и менеджера проекта должны быть четко определены на уровне проекта в этом разделе. Это может не иметь связанных имен, но роль должна быть очень четко определена.
Стратегии тестирования должны быть рассмотрены разработчиками. Они также должны быть рассмотрены руководителями для всех уровней тестирования, чтобы убедиться, что покрытие является полным, но не перекрывается. И менеджер по тестированию, и менеджеры по разработке должны одобрить стратегию тестирования до начала тестирования.
Требования к среде являются важной частью стратегии тестирования. Она описывает, какие операционные системы используются для тестирования. Она также четко информирует о необходимых уровнях исправлений ОС и требуемых обновлениях безопасности. Например: определенный план тестирования может потребовать установки Windows 8.1 в качестве предварительного условия для тестирования.
Существует два метода, используемых при выполнении тестовых случаев: ручной и автоматизированный . В зависимости от характера тестирования, обычно наилучшим методом тестирования является сочетание ручного и автоматизированного тестирования.
Любые риски , которые повлияют на процесс тестирования, должны быть перечислены вместе с мерами по их смягчению. Документируя риск, можно предвидеть его возникновение задолго до его возникновения. Можно предпринять упреждающие действия, чтобы предотвратить его возникновение или смягчить его ущерб. Примерами рисков являются зависимость от завершения кодирования, выполненного субподрядчиками, или возможности инструментов тестирования.
План тестирования должен включать оценку того, сколько времени потребуется для завершения фазы тестирования. Существует множество требований к завершению фаз тестирования. Во-первых, тестировщики должны выполнить все тестовые случаи хотя бы один раз. Кроме того, если был обнаружен дефект, разработчикам необходимо будет исправить проблему. Затем тестировщики должны повторно протестировать неудавшийся тестовый случай, пока он не начнет работать правильно. И последнее, но не менее важное: тестировщики должны провести регрессионное тестирование ближе к концу цикла, чтобы убедиться, что разработчики случайно не сломали части программного обеспечения, исправляя другую часть. Это может произойти в тестовых случаях, которые ранее работали правильно.
График тестирования также должен документировать количество тестировщиков, доступных для тестирования. Если возможно, назначьте тестовые случаи каждому тестировщику.
Часто бывает трудно сделать точную оценку графика тестирования, поскольку фаза тестирования включает в себя много неопределенностей. Планировщики должны учитывать дополнительное время, необходимое для решения непредвиденных проблем. Один из способов сделать это приближение — посмотреть на время, необходимое для предыдущих версий программного обеспечения. Если программное обеспечение новое, умножение первоначального приближения графика тестирования на два — хороший способ начать.
Когда определена конкретная проблема, программы отлаживаются, и исправление применяется к программе. Чтобы убедиться, что исправление работает, программа будет снова протестирована по этому критерию. Регрессионные тесты уменьшат вероятность того, что одно исправление создаст некоторые другие проблемы в этой программе или в любом другом интерфейсе. Поэтому набор связанных тестовых случаев может быть повторен, чтобы проверить, влияет ли конкретное исправление на что-либо еще. Как это будет выполняться, должно быть подробно описано в этом разделе.
При выборе регрессионных тестовых случаев учитывайте различные уровни тестирования. Хорошими кандидатами являются тестовые случаи для модулей, интеграционных и системных тестов. Выберите случаи, которые напрямую связаны с исправлением, а также включите несколько критически важных для бизнеса случаев, которые доказывают, что базовые бизнес-сценарии все еще работают. Помните также, что нефункциональное тестирование (безопасность, производительность, удобство использования) играет важную роль в доказательстве продолжения бизнеса.
В некоторых компаниях при каждом исправлении ошибки в одном модуле все тестовые случаи для этого модуля будут повторяться.
Из списка требований мы можем определить связанные области, функциональность которых схожа. Эти области являются тестовыми группами. Например, в системе бронирования железнодорожных билетов все, что связано с бронированием билетов, является функциональной группой; все, что связано с генерацией отчетов, является функциональной группой. Таким же образом мы должны определить тестовые группы на основе аспекта функциональности.
Среди тестовых случаев нам нужно установить приоритеты. При тестировании программных проектов определенные тестовые случаи будут рассматриваться как самые важные, и если они не пройдут, продукт не может быть выпущен. Некоторые другие тестовые случаи могут иметь меньшую функциональную важность или даже быть косметическими , и если они не пройдут, мы можем выпустить продукт без особого ущерба для функциональности. Эти уровни приоритета должны быть четко указаны. Они также могут быть сопоставлены с тестовыми группами.
При выполнении тестовых случаев руководитель тестирования и менеджер проекта должны знать, где именно находится проект с точки зрения тестовых мероприятий. Чтобы знать, где находится проект, входные данные от отдельных тестировщиков должны поступать руководителю тестирования. Это будет включать в себя, какие тестовые случаи выполнены, сколько времени это заняло, сколько тестовых случаев пройдено, сколько не удалось и сколько невыполнимо. Также должно быть четко указано, как часто проект собирает статус. В некоторых проектах будет практика сбора статуса ежедневно или еженедельно.
При выполнении тестовых случаев важно отслеживать детали выполнения, например, когда они были выполнены, кто это сделал, сколько времени это заняло, каков результат и т. д. Эти данные должны быть доступны руководителю тестирования и менеджеру проекта, а также всем членам команды в центральном месте. Они могут храниться в определенном каталоге на центральном сервере , и в документе должны быть четко указаны местоположения и каталоги. Также должно быть указано соглашение об именовании документов и файлов.
В идеале программное обеспечение должно полностью удовлетворять набору требований. Начиная с проектирования, каждое требование должно быть рассмотрено в каждом отдельном документе в процессе разработки программного обеспечения. Документы включают HLD , LLD , исходные коды, тестовые случаи модуля, тестовые случаи интеграции и тестовые случаи системы. В матрице прослеживаемости требований строки будут содержать требования. Столбцы представляют каждый документ. Пересекающиеся ячейки помечаются, когда документ рассматривает конкретное требование с информацией, связанной с идентификатором требования в документе. В идеале, если каждое требование рассматривается в каждом отдельном документе, все отдельные ячейки имеют действительные идентификаторы разделов или заполненные имена, то мы знаем, что каждое требование рассмотрено. Если какие-либо ячейки пусты, это означает, что требование не было правильно рассмотрено.
Высшее руководство может захотеть иметь сводку теста на еженедельной или ежемесячной основе. Если проект очень критический, им может потребоваться даже ежедневно. В этом разделе должно быть указано, какие отчеты о сводке теста будут подготовлены для высшего руководства, а также с какой частотой.
Стратегия тестирования должна давать четкое представление о том, что будет делать команда тестирования для всего проекта на протяжении всего срока. Этот документ может быть представлен клиенту, если необходимо. Человек, который готовит этот документ, должен быть функционально силен в области продукта, с очень хорошим опытом, так как это документ, который будет направлять всю команду для проведения тестовых мероприятий. Стратегия тестирования должна быть четко объяснена членам команды тестирования в самом начале проекта.