Смета качества

С чего начать тестирование?
Тестирование – это процесс решения задачи, а как учили нас в школе – любую задачу надо и можно разложить на входящие условия и искомый результат. Прежде чем приступить к тестированию нового продукта, модуля или небольшого улучшения необходимо оговорить объёмы проверок с владельцем продукта. Для этого предлагаю составлять матрицу требуемого качества, заполнять её с двух сторон заинтересованности и считать её соглашением о выполняемых работах.
Согласительная матрица тестирования должна состоять из трёх колонок: объём работ, необходимость и возможность. В первую колонку "объём работ" заносим все виды тестирования: функциональное, интерфейсное, системное, защита данных и так далее, но желательна максимальная детализация для конкретного продукта или модуля. Вторую колонку "необходимость" заполняет владелец продукта значениями "надо", "можно", "лишнее". Значения третьей колонки "возможности" могут варьироваться уровнями "справимся собственными силами – можем подучиться или переквалифицироваться – надо привлекать сторонних специалистов" или ценами "время на выполнение работ - денежные суммы". Если же у тест-менеджера есть данные цен для каждого уровня (своими силами – подкачаться – внешние силы), то лучше сразу показать владельцу продукта затраты на каждый из трёх вариантов выполнения работ. Итого, матрица определяет входящие условия и ожидаемый результат не только для группы тестирования, но и для владельца продукта. Тест-менеджеру легко и просто составить план тестирования, распределить специалистов, выявить слабые места команды, подсчитать возможный доход. Владелец продукта такую матрицу может подписать как приложение к контракту с подробностями о выполняемых работах, увидеть расходы на тестирование, просчитать уровень качества выпускаемого продукта.

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

Виды тестирования	Необходимость	Возможность (часов/рублей)
		сами (500руб. за час)	с обучением (750руб. за час)	внеш.спец. (1000руб. за час)
1. Документация (наличие, функционирование, полноценность, грамотность)
1.1. Online Help	надо	1/500	1/750	0,5/500
1.2. Hints for UI elements	надо	0,5/250	0,5/375	0,25/250
1.3. Instant Help	лишнее	1/500	1/750	0,5/500
2. Интерфейс
2.1. Соответствие внутренним стандартам	можно	0,25/125	0,25/190	0,25/250
2.2. Соответствие описанию задачи	лишнее	0,25/125	0,25/190	0,25/250
3. Функциональность
3.1. Smoke-test for each build	лишнее	0,1/50	0,1/75	0,2/200
3.2. Smoke-test for publishing builds	можно	0,1/50	0,1/75	0,2/200
3.3. Приёмочное по описанию	надо	40/20000	40/30000	40/40000
3.4. Негативное	лишнее	2/1000	2/1500	4/4000
3.5. Исследовательское	можно	10/5000	10/7500	20/20000
4. Системное
4.1. Инсталляция, обновление	можно	0,1/50	0,1/75	0,1/100
4.2. Настройки модуля, продукта	можно	1/500	1/750	1/1000
4.3. Интеграционное	надо	4/2000	4/3000	6/6000
4.4. Защищённость, проникновение	можно	4/2000	4/3000	8/8000
4.5. Нагрузочное	можно	4/2000	4/3000	16/16000
4.6. Стресс-тесты, негативное	лишнее	4/2000	4/3000	8/8000
5. Код
5.1. Unit-testing	лишнее	0,25/125	0,25/190	0,1/100
5.2. Code Review by task description, internal structure and metrics standards	можно	0,25/125	0,25/190	0,1/100
6. Usability
6.1. Usability by internal standards	лишнее	4/2000	4/3000	8/8000
6.2. Usability from known vendors	лишнее	4/2000	4/3000	8/8000
7. Регрессионное	лишнее	2/1000	2/1500	2/2000

Таким образом, отдел тестирования отработает около 70 часов, работодатель не повысит квалификацию своих подопечных, но оплатит один рабочий день стороннего профессионала. Учтите, что за выявленные конечным пользователем проблемы ваш внутренний отдел качества не отвечает, и претензии можно будет предъявить только тому временному специалисту. При планировании сметы не стесняйтесь пояснить владельцу продукта последствия его отказа от тестирования того или иного вида, особенно негативного, которое не редко случается уже на стороне пользователя. Баги из числа "можно" при оформлении должны быть с более низким приоритетом.
Дополнительно оговорите список пунктов, проверяемых перед передачей продукта конечному пользователю (иными словами – чек-лист выпускаемого билда), с уточнёнными уровнями качества:
а) интерфейс;
б) сохранение/восстановление опций;
в) первоначальная инсталляция;
г) апдейт предыдущих версий/билдов;
д) благополучное исполнение основных пользовательских алгоритмов, шагов;
е) соответствие лицензионному соглашению и офертным системным требованиям;
ж) отсутствие фатальных и критичных багов;
з) и т.д.

Да, на заполнение такой матрицы требуется время, но ведь на планирование оно отводится. И именно его надо использовать на этом этапе, тем более что после оформления меморандума качества для каждого нового модуля тест-менеджер вместе с владельцем продукта сразу делают несколько дел: планируют объём работ тестировщиков и смету; имеют документ, защищающий права обоих и подтверждающий необходимость отдела тестирования; видят слабые места команды и направления её развития. Ещё раз повторюсь, не удаляйте пункты, которые владелец продукта посчитал лишними. Это позволит вам отказаться от сверх-задач, а сэкономленное время потратить на более глубокое тестирование (пункты "можно" заменить на "надо") или собственное развитие. Например, в компании Conquest Software Solutions существует только устный закон (читай "Меморандум качества") в разрезе продуктов:
- ClearDB обязан иметь идеальный интерфейс и генерить красивые выходные доки, а наличие AV-ошибок (критичные функциональные) не является блокером выпуска;
- в SQLDetective абсолютно не важны интерфейсные глюки, но не должны случаться критичные и фатальные ошибки в выпускаемом билде (иначе в недельный срок будет перевыпуск);
- ClearSQL можно выпускать как с интерфейсными проблемами, так и с функциональными, лишь бы показать видимость фикса бага от конечного пользователя.
Поэтому тестировщикам сложно доказать руководству, что обнаруженный на стороне пользователя баг не является пропуском в работе QA, а лишь следствие планирования.
Так что, друзья, если хотите стабильности и покоя, то составляйте меморандумы качества для каждого новшества, улучшения, изменения.