Доработка по результатам тестирования

Основная цель данного этапа — устранить замечания, возникшие в результате тестирования на контрольном примере, и при необходимости осуществить дополнительные настройки и доработки модулей системы. Как уже было сказано, на данном этапе важно разделять требования, критичные для успешной работы с системой, и дополнительные {nice-to-have) пожелания пользователей-экспертов, которые можно будет включить в следующие итерации работы и версии системы.

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

Так как при smoAe-тестировании в максимально короткие сроки покрывается максимально широкий объем функциональных возможностей, то существует и другой вид тестов, дополняющих первый (функции проверяются скорее «вглубь», с максимально тщательным тестированием каждого аспекта). Это обусловлено тем, что при проведении любого рода изменений необходимо обеспечивать их корректность и отсутствие негативного влияния на работоспособность и эффективность приложения.

С этой целью проводится регрессионное тестирование (regression testing), один из наиболее известных видов которого получил название sanityтестирования. Это тестирование определенных участков кода, проводимое по результатам внесенных изменений. Его основная задача — удостовериться в том, что внесенные изменения не затронули работоспособность системы и не послужили причиной новых ошибок. К примеру, проверяется, действительно ли исправленные ранее ошибки исправлены, не приводят ли сделанные изменения к нейтрализации исправлений старых ошибок (регрессия багов, англ, hug regression) и есть ли новые ошибки.

В результате должны быть:

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