среда, 18 января 2012 г.

Что бы я писал в тест плане

Давненько не писал тест план я. Давайте поделюсь тем, что получилось.
Нет, я, конечно, не буду прикреплять сюда что вышло. NDA, сами понимаете. Но вот как я вижу что там надо написать.

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


Кто?
Надо описать команду, роли и какая на каком лежит ответственность. Например,
Тест Аналитик - отвечает за тест дизайн, анализ результатов и отчетность - Петя Ёшкин
И никто не мешает при этом написать, что Тим Лид у вас тоже Петя Ёшкин, но тут другие обязанности. Почему бы со временем не стать тестовым аналитиком другому человеку (или лидером команды, а что?). А роль останется.

Что?
Определяем фронт работ. Что мы будем проверять, а что нет. Причем, второе важнее. Например,
Проверяем:Установку приложения
Доступ к функциям приложения согласно правам доступа
Основную функциональность приложения
   Календарь
   Формы отчетности
   Управление пользователями
   и т.п. штуки
Не проверяем:Управление пользователями (доменный доступ)
Логин в систему (доменный доступ)
Печать отчетов
Было бы еще замечательно добавить тут тестовые приоритеты: что важнее и первоочереднее было бы проверить. А также лучше всего, если вы пишите общий план, то разбить по типам тестирования и писать каждому скоуп и ответ на вопрос "как?".

Как?
Определяем подход к работе. Лучше всего разбивать по типам тестирования.
Окружение, общие сценарии запуска тестов (если необходимо). Например, для производительности:

  1. Ставим приложение на сервер
  2. Разворачиваем нагрузочное окружение
  3. Настраиваем параметры теста
  4. Прогоняем в тестовом режиме
  5. Запускаем
  6. Хватаем результаты и анализируем

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

Когда?
Не просто что сколько займет времени. Нет, этого тут можно не вставлять. Но указать когда планируются какие активности сказать надо. Можно мерить ближайшими итерациями. Можно указывать ориентируясь на события. Например, начнем проверять Календарь как только будет разработана возможность просмотра и добавления событий, но не раньше.

А также.
Описать риски связанные с организацией и процессом тестирования и обеспечения качества.
Описать все термины, которые вы используете. Что подразумеваете под различными профайлами, типами и т.п.
Описать все тестовые конфигурации для окружения.
Дать ссылки на соседние документы.
Не превращать тест план в список тестов.
Не превращать тест план в гайдлайны по развертыванию приложения.
Вписывать все что посчитаете необходимым.

Главное - не думать шаблонами.
Enjoy :)

З.Ы. А еще у меня где-то завалялся шаблон, кажется, RUP'a, который когда-то я бережно сохранил с сайта одного заграничного коллеги. Покопаюсь и как найду, то поделюсь ссылкой или пакетом

5 комментариев:

  1. Тоже считаю шаблон RUP`a более удобным для заполнения и пользования.
    http://www.protesting.ru/testing/plan.html

    ОтветитьУдалить
  2. да, с ним проще всего вырабатывать навыки для создания планов. Потом уже будет само приходить. Часто разные части надо в разной детализации освещать для каждого отдельного проекта

    ОтветитьУдалить
  3. к написанию, кстати, побудило то, что писал план на нагрузочное тестирование. Только на один вид тестирования, а писать всего надо как на проект раньше бывало )

    ОтветитьУдалить
  4. Ничего так. Вполне коррелирует с моим взглядом на тестинг. Зачет.

    ОтветитьУдалить
  5. Спасибо, Дмитро. Хорошо, что разработчики также представляют как можно планировать тестирование.
    И не так уж и не правильно, как оказывается ;)

    ОтветитьУдалить