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

Question

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

На данный момент после тестеров функции замораживания «нажмите приложение» перед развертыванием, однако нет формальной спецификации, что нужно протестировать.

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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#anchor326763 - если вы добавите: шаги для тестирования, ожидаемые результаты теста, граничные/связанные случаи - у вас должна быть довольно прочная спецификация требований и спецификация тестирования в одном.

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

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

Answer 3

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

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

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

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

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

Answer 4

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

Возможно, вы также захотите ознакомиться с classic blog post от Dan North: «Поведение-DrivenDevelopment» (BDD). Очень полезно!

Answer 5

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

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

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