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

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

  • С помощью мыши откройте меню файла
  • Выберите "Открыть файл..." в меню файла
  • В открывшемся диалоговом окне открытого файла перейдите к x и дважды щелкните документ с именем y

ИЛИ

  • Откройте диалоговое окно открытия файла
  • Откройте файл y

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

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

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

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

  • люди, выполняющие тесты, не могут задать вам вопросы.
  • люди, выполняющие тесты, не знакомы с вашим продуктом.

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

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

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

Ответ 4

Разделите Test Plan и Test Suites:)

Test Suite - это набор самих тестов

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

Хорошо, чтобы оба варианта (подробный и "грубый" ) описаны в тестовой документации, просто поместите подробные и "грубые" тесты в разные документы и расставьте приоритеты этих документов.

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

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

Плохая сторона: вам нужны "дубликаты" документов

Ответ 5

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

Ответ 6

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

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

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

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

У меня есть статья, в которой я углубляюсь в эту тему: Написание плана тестирования системы

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

- LM

Ответ 7

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

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

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

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

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

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

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