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

Question

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

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

ИЛИ

1. Вывести диалог открытия файла
2. Открыть файл y

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

В качестве альтернативы, напишите свои планы испытаний в виде коротких исследовательских таблиц. Вы можете, например, дать руководство, например: «Пользователи Callcentre будут использовать рабочие станции без мыши. Изучите процесс получения заявки от имени клиента, чтобы убедиться, что все действия можно выполнить только с помощью сочетаний клавиш». Скорее всего, это приведет к тому, что ваши тестеры обнаружат дефекты, а не произнесут «Tab in field 1. Введите« Жалоба на качество линии ». Tab в поле 2. Выберите« Phone call »из выпадающего меню. Tab to .... field 68. "

Answer 4

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

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

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

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

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

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

- LM

Answer 5

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

Answer 6

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

Test Suite представляет собой набор тестов

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

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

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

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

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

Answer 7

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

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

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

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

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

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