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

Question

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

- LM

Answer 4

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

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

Answer 5

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

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

Answer 6

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