Планы тестирования и как лучше всего записать им

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

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

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

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

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

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

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

То, что Вы описываете выше, является просто рядом тестов.

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

Давайте отличим План тестирования и Наборы тестов :)

Набор тестов является набором тестов самим

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

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

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

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

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

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

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

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

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

у меня есть статья, где я более подробно останавливаюсь на этой теме: Writing a System Test Plan

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

-- LM