Где найти хорошие шаблоны / примеры тестовых случаев?

Question

Я пытаюсь установить более формальные требования и процедуры тестирования, чем у нас сейчас, но я не могу найти хороших справочных примеров соответствующих документов.

На данный момент, после того, как тестеры замораживания функций "щелкнули по приложению" перед развертыванием, формальной спецификации для тестирования нет.

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

1. форма регистрации пользователя
   1. раскрывающийся список стран (правильно ли выбраны страны с сервера?)
   2. проверка пароля (соблюдаются ли все правила пароля, уведомляется ли пользователь, если пароль слишком слабый?)
2. спасибо, что Вы для регистрации

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

Во-вторых, я думаю о тестовых случаях для тестировщиков, с подробными шагами, такими как:

1. Загрузите форму регистрации пользователя.
2. (Функция 1.1) Проверьте раскрывающееся меню страны.
   1. Заполнен ли список стран странами?
   2. Названия стран локализованы?
   3. Правильный ли порядок сортировки для каждого языка?
3. (Функция 1.2) Введите следующие пароли: "a", "bob", "password", "password123", "password123#". Только последний пароль должен быть принят.
4. Нажмите "ОК".
5. (Функция 2) Проверьте благодарственное письмо.
   1. Текст локализован для каждого поддерживаемого языка?

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

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

В основном это материалы для внутреннего тестирования, которые должны представлять собой пару документов Word/Excel. Я пытаюсь сохранить один цикл тестирования / исправления ошибок до двух дней. Я отслеживаю время программирования, внедрение новых функций и заявок клиентов другими способами (JIRA), это будет в основном тестирование документации. Это жизненный цикл, который я имел в виду:

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

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

Answer 1

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

один для ваших более "стандартных веб-сайтов" (например, бизнес-веб-присутствия):

http://pm4web.blogspot.com/2008/07/quality-test-plan.html

другой я использую для веб-приложений:

http://pm4web.blogspot.com/2008/07/writing-system-test-plan.html

надеюсь, это поможет.

Answer 2

Во-первых, я думаю, что объединение документа требований с документом тестового примера является наиболее целесообразным, поскольку большая часть информации одинакова для обоих, а наличие требований перед тестировщиками и тестовых наборов перед пользователями и разработчиками усиливает требование и предоставляет различные точки зрения на них. Вот хорошая отправная точка для макета документа: http://www.volere.co.uk/template.htm - если вы добавите: шаги для тестирования, результирующие ожидания теста, крайние / связанные случаи - вы должны иметь довольно солидная спецификация требований и спецификаций тестирования в одном.

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

Я также настоятельно рекомендую использовать mindmapping/work-breakdown-structure, чтобы убедиться, что все требования правильно собраны.

Answer 3

На веб-сайте Дэвида Петерсона Concordion есть очень хорошая страница о технике написания хороших спецификаций (а также структура для выполнения указанных спецификаций). Его совет прост и лаконичен.

Также вы можете проверить классическое сообщение Дэна Норта в блоге, посвященное Behavior-DrivenDevelopment (BDD). Очень полезно!

Answer 4

Вам обязательно нужна подробная спецификация перед началом работы; иначе ваши разработчики не знают, что написать или когда они закончили. Джоэл Спольски написал хорошее эссе на эту тему с примерами. Не ожидайте, что спецификация останется неизменной во время разработки: внесите изменения в план.

Meade, выше, рекомендовал объединить спецификацию с тестами. Это известно как разработка через тестирование и является очень хорошей идеей. Он закрепляет вещи так, как это обычно не делает естественный язык, и сокращает объем работы.

Вам также нужно подумать о модульных тестах и ​​автоматизации. Это экономит время и качественный бустер. Тесты на уровне GUI могут быть сложны для автоматизации, но вы должны сделать слой GUI как можно более тонким и иметь автоматические тесты для функций ниже. Это значительно экономит время на этапе разработки, поскольку вы можете тщательно тестировать все приложение так часто, как вам хочется. Ручные тесты дороги и медленны, поэтому существует сильное искушение срезать углы: "мы только изменили модуль Foo, поэтому нам нужно только повторить тесты 7, 8 и 9". Затем клиент звонит, жалуясь, что что-то в модуле Bar сломано, и оказывается, что Foo имеет скрытый побочный эффект на Bar, который пропустили разработчики. Автоматизированные тесты поймают это, потому что автоматизированные тесты дешевы для запуска. Смотрите здесь правдивую историю о такой ошибке.

Если ваше приложение достаточно велико, чтобы определить его, укажите модули, использующие TDD, и превратите эти тесты модулей в автоматизированные тесты.

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

Answer 5

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

Используйте GUI и веб-автоматизацию. Селен, например. Многое может быть автоматизировано, гораздо больше, чем вы думаете. Например, ваш сценарий регистрации пользователя легко автоматизируется. Даже если они должны быть проверены человеком, например, кросс-браузерное тестирование, чтобы убедиться, что все выглядит правильно, тест может быть записан и воспроизведен позже, пока инженер QA наблюдает. Разработчики могут даже записать шаги по воспроизведению сложных для автоматизации ошибок и передать их в QA вместо того, чтобы занимать много времени и часто с ошибками записывать инструкции. Сохраните их как часть проекта. Дайте им хорошее описание цели теста. Свяжите их с билетом. Если графический интерфейс пользователя изменится, чтобы тест больше не работал, и это произойдет, вы можете переписать тест, чтобы охватить его намерения.

Я уточню, что сказал Пол Джонсон о том, чтобы сделать слой GUI как можно более тонким. Отделяйте форму (графический интерфейс или HTML или форматирование) от функциональности (что она делает) и автоматизируйте тестирование функциональности. Есть функции, которые генерируют список стран, тщательно протестируйте. Затем функция, которая использует это для генерации HTML, AJAX или чего-то еще, и вам нужно только проверить, правильно ли она выглядит, потому что функция, выполняющая реальную работу, хорошо протестирована. Логин пользователя. Проверка пароля. Сообщения электронной почты. Все они могут быть написаны для работы без графического интерфейса. Это резко сократит количество медленных, дорогостоящих, некорректных ручных испытаний, которые необходимо выполнить.