Как я могу построить план тестирования нашего отдела QA?

Ответ 1

Лучшая книга, которую я нашел по этому вопросу, Управление процессом тестирования. Автор рассказывает о том, как создать план тестирования.

По моему опыту, основы плана тестирования таковы:

• Описание функции
• Предположения
• Связанная документация
• Контрольная матрица
• Допустимые тесты
• Неверные/ошибки условия
• State Tests (поведение основано на различных состояниях объекта/системы)
• Стресс-тесты
• Тесты производительности
• Показатели производительности
• Необходимые инструменты
• Экологические проблемы (конкретное оборудование, браузер, ОС и т.д.).

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

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

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

Ответ 2

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

Однако, как правило, план тестирования будет разработан группой QA в координации с dev и PM. Если QA не создает план самостоятельно, это звучит так, как ваша команда QA может использовать обновление. По крайней мере, даже если Dev собирает первоначальный план, QA должен предоставить некоторый ввод, так как у них будет другой POV. Чем больше глаз на плане тестирования, тем более полным будет.

Ответ 3

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

если вы хорошо знаете свое программное обеспечение, установили MS Word и имеете хорошие навыки документирования, вы можете пойти

в терминах очень простого, общего протокола протоколирования ошибок, который вы можете использовать, вы можете посмотреть: Журналы Ошибки как Pro < - все это связано с протоколированием ошибок с минимальными усилиями и захватом информации, необходимой для исследования ошибки

- LM

Ответ 4

Попробуйте: Артефакт: План тестирования

Ответ 5

QA должен абсолютно написать план тестирования, как указывает Том Э. Они должны взаимодействовать с клиентом для понимания требований и с командой разработчиков, чтобы понять реализацию, но в конце дня команде с набором тестов для тестирования необходимо владеть планом тестирования.

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

Ответ 6

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

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