Процесс взаимодействия с заказчиком и тестирования

Рабочие продукты:

• Тест-план
• Тест - отчет
• Чек-листы/тест-кейсы/юз-кейсы
• Регламент составления документации для функционального и регрессионного тестирования ОТС

___________________________________________________________________________________________________________________________

ЧАСТЬ 1. Определение целей и задач тестирования

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

• Какие результаты хочет получить заказчик?
• Какие результаты наиболее приоритетные?
• Причины, побудившие обратиться к молодежи?
• Кто пользуется тестируемым ПО?

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

Обозначить планы по запуску продукта:

• какие этапы включают в себя подготовку процесса к запуску на стороне заказчика,
• определить, как этапы тестирования ПО в ОТС будут согласовываться с процессами работ на стороне заказчика
• укажите даты старта и выполнения этих этапов,
• Рекомендации по назначению
• бюджет

Составить стратегию тестирование и время:

• Разбить тестируемый функционал на блоки по ; объем, критичность
• Оценить риски
• Сформировать предполагаемую стратегию
• Предложить альтернативу
• Прописать последствия от ускорения или отказа от выполнения работ
• Оценка времени работы/критерии старта и проведения тестирования/план-график тестирования

Входные рабочие продукты и инструменты, которые необходимо получить от заказчика:

• требования к тестируемому блоку (документ, описывающий, что именно реализовано в тестируемом блоке, как он работает, какие задачи решаются)
• юз-кейсы (если есть),
• API,
• багтрекер,
• доступ к каналам связи с заинтересованными сторонами
• Техническое обеспечение (доступ к оборудованию, серверам и пр.)
• Особенности в тестируемом модуле. Например: требования к ПП, количественные (объемы строк, записи, весовые файлы и пр.)

Составить тест-план:

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

Структура документа:

 

ЧАСТЬ 2. Процесс выполнения тестирования

Погружение

Процесс погружения начинается, когда у тестировщика появляется доступ к соответствующим продуктам от заказчика (см. ЧАСТЬ 1). На данном этапе тестировщик должен визуально ознакомиться с интерфейсом доработки/разработки, знать, где и какие настройки выбрать, куда и какие данные надо ввести, какой результат в итоге мы должны получить и где его взять.

Планирование 

        1. Определение целей тестирования, объема тестирования, тестирования ресурсов, тестирования графики, результатов тестирования и участников тестирования (международная сторона тестирования). (см. ЧАСТЬ 1)

        2. Определить риски и оценить степень серьезности и критичности риска. Определить подходы к устранению риска (предупреждающие, корректирующие, смягчающие)

Возможные факторы для анализа риска:

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

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

        3. Определить критерии старта и завершить тестирование.

Набор вариантов зависит от того, когда именно решено приступить к тестированию (возможны варианты в зависимости от уровня оснащенности приложения: когда приложение еще не разработано, в процессе разработки, разработка завершена).

Возможные критерии старта тестирования:

• Определены и приоритезированы цели и задачи тестирования. 
• Определенный круг близких лиц
• Заинтересованные лица, знакомые с планами по запуску продукта
• Заказчик все рабочие продукты и инструменты, необходимые для внедрения
• Готовность документации, составление требований к тестируемому модулю
• Готовность тестируемого модуля
• Готовность план-графического тестирования
• Готовность тестирования окружения (подключение к удаленным сервисам, смс-сервисам, дополнительному оборудованию, веб-серверу, подключению к удаленным ресурсам и т.д.)
• Тестировщик визуально знаком с интерфейсом доработки/разработки, знает, где и какие настройки конфигурации, где и какие данные надо вводить, какой результат в итоге мы должны получить, и где его взять.

Возможные критерии завершения тестирования:

• Готовность тестируемого модуля
• Готовность рабочей продукции (чек-листы/кейсы/юз-кейсы)
• Готовность автоматических тестов и инструкций по их сопровождению и запуску
• Пройдены все кейсы, выполнены все запланированные тесты (если не пройдены, укажите почему)
• Закрыты/Отложено/Отменены все заведенные дефекты
• Есть понимание степени покрытий тестами

        4. Сформировать стратегии тестирования, альтернативы и время:

• Разбить тестируемый функционал на блоки по ; объем, критичность
• Сформировать предполагаемую неожиданность

Подходы к выбору стратегии функционального и регрессионного тестирования могут основываться на:

1. использованный ресурс: время/люди/бюджет
2. модель ЖЦ разработки ПО
3. тестирование ресурсов (доступность тестирования ресурсов, включая инструменты тестирования,
   инфраструктуру тестирования, окружения разработки и технологий, а также наличие
   дополнительных специалистов по тестированию и их навыков)
4. риски
5. уровни тестирования (интеграционное, системное, приемочное)
6. по изменению модулей и частей приложения
7. требования к продукции
8. особенности, наличие особенностей в предметной области
9. пользовательские настройки
   

• Предложить альтернативу
• Прописать последствия от ускорения или отказа от выполнения работ
• Оценка времени работы для плана-графика работ (см. структуру тест-плана ЧАСТЬ 1)

Мониторинг

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

Метрики:

1. Требования к покрытию - % покрытых/непокрытых на данный момент времени. Скорость проверки покрытий - сравнение с показателями на предыдущем контроле;
2. Покрытие риска - % пострадавших/непокрытых на момент времени. 
3. План-факт по времени тестирования. (сравнение запланированного и затраченного времени на обучающие задачи)
4. Процент выполненных тестовых проявлений/кейсов по приложениям к запланированным (с учетом последствий: пройден, не пройден, заблокирован, отложен).
5. Количество устраненных дефектов при осмотре зафиксированным.
6. Фактическое количество случаев проведения запланированных испытаний по сравнению с проведением запланированных испытаний.
7. Выявление новых рисков и план корректировки в соответствии с этим.

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

Анализ тестирования

На этом этапе тестировщик определяет ЧТО должно быть протестовано. Подход описан в регламенте составления документации для тестирования ОТС

Проектирование тестов

На данном этапе тестировщик определяет, КАК будет проводиться тестирование. Подход описан в регламенте составления документации для тестирования ОТС

Реализация тестов

Если стоит задача автоматизации, на данном этапе происходит создание автоматических сценариев тестирования.

Выполнение тестов

Ручное выполнение заданных кейсов. Запуск автотестов.

Активность завершения тестирования

• Составление и утверждение отчета о завершении тестирования

Тест-отчет составляется в текстовом редакторе с возможность отслеживать историю изменений документа. Структура итогового тест-отчета:

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