Кто должен написать план тестирования?

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

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

1. Нажмите на кнопку A .
2. Ключ в XYZ в кнопку поля формы и нажмите кнопку B .
3. Вы должны увидеть поведение C .

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

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

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

Спасибо заранее.

С уважением,
CK

План тестирования НЕ должен быть написан разработчиками. Часть плана тестирования состоит в том, чтобы проверить, правильно ли разработчик интерпретировал требование. Разработчик не может эффективно написать план тестирования для кода, который он собирается написать. Планы тестирования должны составлять люди, которые будут проводить QA, или бизнес-аналитики. Если разработчики должны написать планы, никогда не назначайте кого-то, кто будет писать план для той части программы, которую он собирается написать.

Обратите внимание, что это отличается от разработки модульных тестов, которые должны быть написаны разработчиком, поскольку он должен тестировать код, который он написал, чтобы увидеть, выполняет ли он то, что он ожидает. Но планы тестирования состоят в том, чтобы проверить, работает ли приложение так, как оно ожидалось, и это должен сделать кто-то, кто не знает, как приложение было разработано с технической точки зрения, чтобы быть эффективным.

Команда QA должна написать и выполнить план тестирования.

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

Ответ Scrum: Если вы хотите определить «Определение выполненного», вы заметите, что наличие плана тестирования быстро становится одним из пунктов. Как еще можно описать историю, которую предстоит сделать, если она не была проверена.

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

Кто команда? Любой человек, заинтересованный в реализации продукта, должен быть членом команды.

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

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

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

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

Автоматизируйте ваши проверки приемки и показывайте их на экране.

http://pragprog.com/magazines/2009-12/automating-screencasts

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

Он также предоставляет способ реального выполнения требований - вы сталкивались с исполняемыми спецификациями Gojko Adzic? Посмотрите здесь: http://gojko.net/2010/08/04/lets-change-the-tune/ Если вы думаете об этом как о способе перенести требования в исполняемую форму для демонстрации вашим клиентам тогда это внезапно кажется намного менее бессмысленным.

Теперь, надевая шляпу тестера, я с честью должен отметить, что если снимок экрана снимется, это позволит вам / вашим заинтересованным сторонам провести некоторое надлежащее тестирование - то есть попробовать крайние случаи и тесты, которые фактически бросают вызов приложению , а не просто подтверждающие требования. Я бы посоветовал вам предоставить скриншоты вместе с короткими вопросами или предложениями для областей, о которых вы хотите получить больше отзывов, например:

1) Вот наша новая форма регистрации - посмотрите этот скринкаст, чтобы увидеть, как он работает!

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

Т.е. вы представляете хороший скринкаст, а затем запрашиваете обратную связь, формулируете его, не слишком конкретизируя, заставляя их думать о потенциальных проблемах, а не просто подтверждать их. Заставьте их задуматься , вместо того, чтобы просто слепо щелкнуть план тестирования. Вы в основном пишете чартер для них. (Если вы посмотрите на Agile Testing Quadrants , это будут тесты в Quadrant 3).

Возьмите ремонт вашего дома в качестве примера. Примете ли вы контрольный список, составленный вашим подрядчиком, с просьбой проверить, что он для вас сделал? Или вы бы подготовили свой собственный контрольный список и проверили, сделал ли подрядчик то, что ВЫ указали?

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

Разработчик, однако, должен иметь свой собственный контрольный список и убедиться, что проведено надлежащее внутреннее тестирование и устранены ошибки перед обработкой приложения. для UAT. В идеале разработчик должен автоматизировать большинство этих тестов в форме тестовых сценариев. Помните TDD? В идеале тестовые сценарии (в данном случае, модульные тесты) должны быть написаны для тестирования компонентов приложений. Затем должен быть написан набор тестов, чтобы объединить эти тестовые примеры для выполнения интегрированных и впоследствии регрессионных тестов.

План приемочных испытаний для конечного пользователя обычно составляется клиентами или деловыми партнерами в компании, которая представляет клиента. Предполагается, что он представляет функции, которые хочет клиент, и дополняет интеграционное тестирование QA. Ни QA, ни Development не могут эффективно планировать приемочные тесты пользователей, так как одна из основных целей приемочных тестов пользователей состоит в том, чтобы гарантировать, что то, что QA и Development думали, что клиент хотел, было действительно точным.