Файл: 1 Стадии испытаний программного продукта 1 Оценка плана разработки и состояния проекта.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 22.11.2023
Просмотров: 16
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
1 Стадии испытаний программного продукта
1.1 Оценка плана разработки и состояния проекта
Предварительный этап, в котором задействуются верификация, валидация (здесь подробнее) и план тестирования (здесь подробнее). На этом этапе тестировщики, со своей точки зрения, оценивают полноту и корректность плана разработки, включая тестирование. Основываясь на расширяемости и полноте плана проекта, тестировщики оценивают количество ресурсов, которые будут выделять на тестирование в этом проекте.
1.2 Разработка плана тестирования
Создание плана тестирования вполне стандартный процесс, не выходящий за рамки общего паттерна планирования программных продуктов. Структура плана тестирования описывается стандартом IEEE, контекст зависит от проекта, и от скиллов команды.
1.3 Сбор требований
Неполные, неточные, несогласованные требования вызывают, возможно, большинство проблем в программных продуктах. Неспособность получить качественно сформулированные требования на 3-м этапе значительно увеличивает стоимость продукта и вызывает задержки. Тестировщики во время верификации требований должны гарантировать, что требования точные, полные, и не противоречат друг другу.
1.4 Тест-дизайн
Этап оценки как «внешнего», так и «внутреннего» дизайна, главным образом это техники верификации. QA-команда позаботится, чтобы планирование было эффективным, особенно что касается окружения и аппаратной части.
1.5 Тестирование билда
Метод, выбранный для билда продукта во внутреннем дизайн-документе, будет определять тип и объем тестирования, количество привлеченных тестировщиков. Если автоматизация внедрена в больших масштабах, понадобится меньше ручного тестирования на этом этапе. Если продукт делается по модели водопада, он довольно уязвим к ошибкам и должен будет проходить дополнительные верификации. В целом, значительно дешевле обнаруживать и устранять дефекты на раннем этапе разработки, чем на более позднем, во время динамического тестирования.
1.6 Выполнение тестов и фиксация результатов
Тестирование кода при его выполнении (то есть динамически). Подходы, методы, и инструменты, изложенные в плане тестирования, будут задействованы сейчас и покажут свою эффективность. Происходит проверка, соответствует ли выполняемый код требованиям, и структурным спецификациям.
1.7 Приемочное тестирование
Этап приемочного тестирования: конечные пользователи оценивают работоспособность и полезность приложения при выполнении его основных функций. Продукт проверяется с точки зрения пользователя, что может немного отличаться от задокументированных требований.
1.8 Репорты и результаты тестов
Репорты, то есть отчеты и промежуточные результаты в процессе тестирования, поступают постоянно. Репорт может быть как письменным, так и устным. Важно, чтобы дефекты и/или уточнения по продукту были зафиксированы как можно раньше, а значит корректировки были сделаны как можно раньше — это экономия времени и усилий.
1.9Установка продукта
QA-команда подтвердила, что продукт готов к передаче в продакшен, тогда переходят к установке и тестированию в прод-окружении (в реальных условиях). Идет тестирование продукта в операционной системе, уточняется взаимодействие со связанными продуктами, и другие стандартные процедуры в реальном окружении.
1.10 Корректировки
Этап обслуживания/поддержки готового продукта, в том числе maintenance-тестированием. Требования к продукту могут изменяться/совершенствоваться и на этом позднем этапе, поэтому в тест-план могут вноситься изменения; корректировки/совершенствования продукта должны быть протестированы и оценены QA-командой.
1.11 Оценка эффективности тестирования
Финальный этап: оценка эффективности QA-команды на этом проекте. Оценивают сами тестировщики (точнее лиды), а еще лучше, если работу команды оценят разработчики, пользователи, и специалисты по качеству (QC), если такая должность есть в организации.
1.1 Оценка плана разработки и состояния проекта
Предварительный этап, в котором задействуются верификация, валидация (здесь подробнее) и план тестирования (здесь подробнее). На этом этапе тестировщики, со своей точки зрения, оценивают полноту и корректность плана разработки, включая тестирование. Основываясь на расширяемости и полноте плана проекта, тестировщики оценивают количество ресурсов, которые будут выделять на тестирование в этом проекте.
1.2 Разработка плана тестирования
Создание плана тестирования вполне стандартный процесс, не выходящий за рамки общего паттерна планирования программных продуктов. Структура плана тестирования описывается стандартом IEEE, контекст зависит от проекта, и от скиллов команды.
1.3 Сбор требований
Неполные, неточные, несогласованные требования вызывают, возможно, большинство проблем в программных продуктах. Неспособность получить качественно сформулированные требования на 3-м этапе значительно увеличивает стоимость продукта и вызывает задержки. Тестировщики во время верификации требований должны гарантировать, что требования точные, полные, и не противоречат друг другу.
1.4 Тест-дизайн
Этап оценки как «внешнего», так и «внутреннего» дизайна, главным образом это техники верификации. QA-команда позаботится, чтобы планирование было эффективным, особенно что касается окружения и аппаратной части.
1.5 Тестирование билда
Метод, выбранный для билда продукта во внутреннем дизайн-документе, будет определять тип и объем тестирования, количество привлеченных тестировщиков. Если автоматизация внедрена в больших масштабах, понадобится меньше ручного тестирования на этом этапе. Если продукт делается по модели водопада, он довольно уязвим к ошибкам и должен будет проходить дополнительные верификации. В целом, значительно дешевле обнаруживать и устранять дефекты на раннем этапе разработки, чем на более позднем, во время динамического тестирования.
1.6 Выполнение тестов и фиксация результатов
Тестирование кода при его выполнении (то есть динамически). Подходы, методы, и инструменты, изложенные в плане тестирования, будут задействованы сейчас и покажут свою эффективность. Происходит проверка, соответствует ли выполняемый код требованиям, и структурным спецификациям.
1.7 Приемочное тестирование
Этап приемочного тестирования: конечные пользователи оценивают работоспособность и полезность приложения при выполнении его основных функций. Продукт проверяется с точки зрения пользователя, что может немного отличаться от задокументированных требований.
1.8 Репорты и результаты тестов
Репорты, то есть отчеты и промежуточные результаты в процессе тестирования, поступают постоянно. Репорт может быть как письменным, так и устным. Важно, чтобы дефекты и/или уточнения по продукту были зафиксированы как можно раньше, а значит корректировки были сделаны как можно раньше — это экономия времени и усилий.
1.9Установка продукта
QA-команда подтвердила, что продукт готов к передаче в продакшен, тогда переходят к установке и тестированию в прод-окружении (в реальных условиях). Идет тестирование продукта в операционной системе, уточняется взаимодействие со связанными продуктами, и другие стандартные процедуры в реальном окружении.
1.10 Корректировки
Этап обслуживания/поддержки готового продукта, в том числе maintenance-тестированием. Требования к продукту могут изменяться/совершенствоваться и на этом позднем этапе, поэтому в тест-план могут вноситься изменения; корректировки/совершенствования продукта должны быть протестированы и оценены QA-командой.
1.11 Оценка эффективности тестирования
Финальный этап: оценка эффективности QA-команды на этом проекте. Оценивают сами тестировщики (точнее лиды), а еще лучше, если работу команды оценят разработчики, пользователи, и специалисты по качеству (QC), если такая должность есть в организации.