Планы испытаний и как их лучше всего написать

Question

Мы пытаемся найти лучший способ написать тесты в нашем плане тестирования. В частности, при написании теста, предназначенного для использования кем-либо, включая персонал QA, должны ли шаги в тесте быть очень конкретными или более широкими, давая тестеру больше возможностей в том, как задача может быть выполнена. В качестве простого примера, если вы тестируете открытие документа в текстовом редакторе документ, следует тест следующим образом:

1. С помощью мыши откройте меню Файл
2. Выберите «Открыть файл ...» в файл меню
3. в диалоге открытия файла, который появляется, перейдите к й и дважды щелкните документ называется у

ИЛИ

1. Брин г до файла открытого диалога
2. Открыть файл у

Теперь я понимаю, один ответ, вероятно, будет «это зависит от того, что вы пытаетесь проверить», но я пытаюсь ответить на более широкий вопрос здесь: Если шаги тестирования слишком специфичны, мы рискуем a) сделать процесс тестирования трудоемким и утомительным и, что более важно, б) мы рискуем потерять что-то, потому что мы написали слишком конкретный путь для достижения цели. В качестве альтернативы, если мы сделаем это широко, мы слишком зависем от прихотей тестера в то время и проиграем решающее тестирование путей, которые чаще встречаются у клиентов/клиентов?

Answer 1

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

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

Если существует несколько способов достижения цели, вам необходимо описать каждый путь, чтобы добраться туда.

Answer 2

Я не тестировщик, но, на мой взгляд, важно документировать «маршрут UI», который должен пройти тест, чтобы избежать путаницы.

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

Answer 3

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

Если вы действительно находитесь в положении, когда вы пишите тесты для других людей, есть некоторые соображения.Вы хотите, болезненный уровень детализации, если:

• людей, работающих тесты не могут прийти задавать вам вопросы
• люди, работающие тесты не знакомы с продуктом

You могут избежать некоторых деталей, если они неверны. Тем не менее, это все еще зависит :)

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

Что вы описали выше, это просто набор тестов.

Answer 4

Давайте различать план тестирования и наборы тестов :)

Test Suite является набор тестов сам

План тестирования является [часть] Test Suite + доступные ресурсы (люди, оборудование, время, ...).

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

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

хорошая сторона: вы можете выбрать, как проверить продукт

плохая сторона: вам нужно «дублировать» документы

Answer 5

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

Answer 6

theres за и против обрабатывать ваш тестер, как будто они не знают о системе или компьютерах в целом.

Если вы изложите мелкие детали (например, «из меню файла, выберите« Открыть »...»), чем вы можете использовать подрядчиков, которые знакомы с вашей системой. но это займет у вас больше времени, чтобы написать, как этот

если вы пропустите много деталей (например, «открыть файл документа ...»), чем тот, кто использует ваш план испытаний, скорее всего, застревают, и чем прервать вас для уточнения.но это намного быстрее, чтобы написать

это может быть ложная экономия думать его быстрее, если вы делаете оживленную версию, если вы в конечном итоге просто тратить дополнительное время, объясняя систему к Qa человеку

У меня есть статья, где я углубился в эту тему: Writing a System Test Plan

В этой статье я хотел бы получить более подробный подход. но я уже разрабатывало «середину» между этими двумя подходами в последнее время (так называемый план тестирования ВОЗМОЖНОСТЬ), но им не в точке, где ее достаточно зрелой, чтобы поделиться еще

- LM

Answer 7

Совершенно прекрасно, если нужно, чтобы кто-то обнаружил проблему, точные, подробные, повторяющиеся шаги. Но если вы напишете свои планы тестирования таким образом, вы рискуете столкнуться с следующими проблемами:

1) Inattentional blindness - Я наблюдал за тем, как люди выполняли подробный процедурный тестовый сценарий, послушно прогуливаясь и записывая каждый шаг тщательно, и ПОЛНОСТЬЮ НЕПРАВИЛЬНО Ошибка перед ними. Потому что это «не было в скрипте». Их внимание было сосредоточено на всех этих тонких тестах, которые они буквально не могли видеть перед собой.

2) Вы пропустите ВСЕ те ошибки, которые находятся всего в одном шаге от вашего очень подробного, очень конкретного пути. Когда клиенты получат ваш продукт, они не будут следовать подробному плану тестирования. Они будут перемещаться по вашему приложению различными способами. Они передумают. У них будут имена длиннее или короче, чем вы считали вероятными или возможными. Они получат половину сделки и откажутся от нее. Они будут блуждать. Они не будут придерживаться одного пути. И каждый раз, когда кто-то повторяет тест, они снова пропустят эти ошибки.

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

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

Держите ваши планы испытаний широкими и позволяйте людям, проводящим тестирование, выполнять свое мнение. Если у вас есть информация об определенных сценариях использования, которые должны быть протестированы, или о том, как целевая группа пользователей захочет работать, затем дайте это тестерам вместе с планами тестирования - возможно, в форме пользовательских персонажей, возможно, только в форма использования. Если вам нужны определенные вещи, отметьте флажок, используйте контрольный список. (Для получения дополнительной информации см. Превосходную презентацию Cem Kaner www.kaner.com/pdfs/ValueOfChecklists.pdf).

В качестве альтернативы, напишите ваши планы испытаний как короткие исследовательские уставы. Например, вы можете дать такие рекомендации, как: «Пользователи Callcentre будут использовать рабочие станции без привязки к мыши». Изучите процесс сбора билета от имени клиента, гарантируя, что можно выполнять все действия только с помощью сочетаний клавиш ». Это гораздо более вероятно приведет к тому, что ваши тестеры найдут дефекты, чем говорят «Вставить в поле 1. Ввод« Жалоба на качество линии ». Вкладка в поле 2. В раскрывающемся меню выберите« Телефонный вызов ». 68.»