В настоящее время мы готовим наш отдел тестирования к новой версии нашего последнего проекта. Мы, очевидно, хотели бы, чтобы они следовали тщательному плану тестирования нашего программного обеспечения и гарантировали, что ошибки будут переданы нам (команде разработчиков) перед выпуском.
Существуют ли какие-либо хорошие инструменты или методологии для создания этого плана тестирования?
Лучшая книга, которую я нашел на эту тему, — это Управление процессом тестирования. . Автор рассказывает, как создать план тестирования.
По моему опыту, основы плана тестирования следующие:
Если вы сможете это заполнить, команда сможет довольно хорошо провести тестирование.
Одно из решений, которое вам нужно принять, — насколько способна команда тестировщиков? Я предпочитаю, чтобы план тестирования был алгоритмом для получения всех тестовых случаев. Опишите виды случаев, но не обязательно каждый случай подробно. Если команда менее компетентна, вам может потребоваться подробно описать каждый случай.
Последнее предостережение. Избегайте зова сирены быть слишком подробным. План, который нельзя удержать в чьей-то голове, вряд ли будет реализован. Если ваш план тестирования состоит из 25 страниц, возможно, вы написали слишком много.
И давайте не будем забывать, никогда не будет достаточно времени, чтобы провести все тесты, которые вы хотите провести. Таким образом, тесты в вашем плане должны быть приоритетными. Я часто нахожу, что расставлять приоритеты по степени риска — лучший способ.
Однако обычно план тестирования разрабатывается группой обеспечения качества в сотрудничестве с разработчиком и проектным менеджером. Если QA не создает план самостоятельно, похоже, что вашей команде QA может понадобиться обновление. По крайней мере, даже если разработчик составляет первоначальный план, отдел контроля качества должен предоставить некоторую информацию, поскольку у них будет другая точка зрения. Чем больше внимания будет уделено плану тестирования, тем полнее он будет.
эй, павликс, я не знаю, насколько простым вы хотите это, но если вы хотите что-то упрощенное и легкое в использовании, взгляните на эту статью: Написание планов тестирования системы
если вы хорошо знаете свое программное обеспечение, у вас установлен MS Word и вы хорошо разбираетесь в документации, вы готовы к работе
с точки зрения очень простого, общего протокола регистрации ошибок, вы можете взглянуть на: Профессиональное ведение журнала ошибок ‹ – это регистрация ошибок с минимальными усилиями и сбор голой информации, необходимой для исследования ошибки.
-- LM
QA обязательно должен писать план тестирования, как указывает Том Э. Они должны взаимодействовать с заказчиком, чтобы понять требования, и с командой разработчиков, чтобы понять реализацию, но, в конце концов, команда с мышлением, ориентированным на тестирование, должна владеть планом тестирования.
Единственная ситуация, которую я могу придумать, когда может потребоваться написать план тестирования для группы контроля качества, — это когда у вас есть аутсорсинговая команда, занимающаяся контролем качества, которая еще не знакома с вашим продуктом. В этом случае я бы рекомендовал, чтобы один или два старших члена команды работали вместе с вами во время проектирования и разработки; это помогает им намного быстрее набрать скорость, и они могут передать эти знания остальной команде.
Модульное и интеграционное тестирование должно выявлять множество проблем на уровне кода, но они не подходят для проверки поведения системы с точки зрения пользователя.
Как только вы узнаете, что должна делать функция и как узнать, работает она или нет, автоматизируйте этот тест (там, где это, очевидно, имеет смысл), используя что-то вроде TestComplete, SmarteScript. Эти тесты легко запускать и автоматизировать, поэтому они всегда будут выполняться стабильно, не беспокоясь о том, что что-то ускользнет.
