Quality Assurance Plan

Набрел на форуме на мысль, которую надо записать, а потом выполнить. Я думаю, это будет относиться к заметкам на полях.


Во-первых, поищите в инете примеры "SQA PLan" или "Software Quality Assurance Plan". Есть такой IEEE стандарт 730.
В нем они рекомендуют иметь следующие секции(на 1998год, есть редакция от 2002го):
a) Purpose;
b) Reference documents;
c) Management;
d) Documentation;
e) Standards, practices, conventions, and metrics;
f) Reviews and audits;
g) Test;
h) Problem reporting and corrective action;
i) Tools, techniques, and methodologies;
j) Code control;
k) Media control;
l) Supplier control;
m) Records collection, maintenance, and retention;
n) Training;
o) Risk management.


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

1. Контракт с другими командами, которые работают над проектом (разработчики, менеджемент, билд-инженеры итд). Включить в этот пункт информацию о том, чем именно ваша команда тестирования занимается(т.е. сервисы вашей команды) и чем не занимается. Например: делаем Smoke тестирование, автоматизируем тестирование GUI. Не делаем: Unit-тестирование, поддержку билд-процедуры и анализ падений билдов во время билд-процедуры. Итд Итп.

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

3. Критерии окончания тестирования.

4. Пропишите свои обязательства по услугам, котрые оказывает команда тестирования. Например, верификация high-priority дефектов должна проходить на том же билде, где это было починено итд.

5. Определите, порядок обращения за услугами. Оговорите, что все запросы на какое-либо тестирование должны идти через руководителя группы тестирования. Иначе может получиться так, что разработчики будут напрямую приходить к тестерам и просить что-то сделать (а они будут!), не задумываясь о том, что у каждого есть ворох задач и спланированый график их выполнения.
Сюда же можно отнести сроки, за которые желательно предупреждать о предстоящем тестировании.

6. Опишите, как вообще процесс тестирования встраивается в общий процесс разработки. На какой стадии начинается, что требуется от других команд итд.

7. Определите те проверки, которые не зависят от проекта и которые обязательно должны быть выполнены в каждом проекте. Например, проверка копирайтов вашего продукта.

8. Определите стратегию распределения ресурсов, в случае более одного проекта. В основном про людей, но и про оборудование тоже, особенно если оно какое-то уникальное.

9. Опишите что не включено в данный документ, и где это можно найти . Дайте ссылки на некоторые нормативные документы, описания процессов. Например, процесс обработки дефектов.

10. Определите виды тестирования; порядок и частоту, с которой каждый вид тестирования будет производиться. Это конечно зависит от проектов сильно, но если они у вас типичные, то можно и добавить.

11. Определите как ваша команда отчитывается перед руководством. Какие документы, когда, как и зачем должны быть предоставлены до, во время и по окончанию работы.

©LeshaL (Пост)