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

10

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

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

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

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

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

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

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

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

ckng
источник
1
Единственный вклад в это должны иметь разработчики, предлагая области и, возможно, некоторые крайние случаи, которые должны быть проверены (и не забыты). Но они не должны давать пошаговые подробности о том, как именно тестировать.
CaffGeek

Ответы:

10

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

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

HLGEM
источник
Это то, что я говорил годами на одной работе.
Дэвид Торнли
1
Хорошо до последнего предложения, но тестирование никогда не должно ограничиваться проверкой приложения в соответствии с ожиданиями (но также должно охватывать неожиданное!), И знание хотя бы немного о том, как приложение было разработано технически ВСЕГДА, помогает мне как тестировщику определить трещины, в которые я могу проникнуть ломом моего тестера, чтобы открыть вещь. ;) Это старомодное представление, что тестерам лучше ничего не знать о реализации.
testerab
1
Точно, @testerab. Незнание внутренних компонентов помогает спроектировать некоторые типы тестовых случаев, в то время как знание внутренних помогает в тестировании «серого ящика», например, я знаю область риска в коде, мне просто нужно доказать, что приложение достигает этого кода.
dzieciou
7

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

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

Крис Кард
источник
3
Возможно, с помощью разработчиков, но в основном команда QA.
Захари К
Что если у нас нет команды QA? Должна ли эта задача ложиться на просителей? Из ответов здесь, это было бы наиболее логичным.
ckng
Если вы движетесь в сторону Agile, попробуйте нанять несколько человек, которые специализируются на тестировании, в вашу текущую команду разработчиков. (Примечание: сначала ознакомьтесь с различными школами тестирования, некоторые из них несовместимы с гибким подходом - redcanary.mypublicsquare.com/view/hiring-software )
testerab
2
Если у вас нет команды QA, вам нужно будет прийти вместе с запросчиками, чтобы принять это решение. С одной стороны, разработчикам не нужно составлять планы тестирования. С другой стороны, многие / большинство бизнес-клиентов не знают, что такое тестирование, и вы потратите МНОГО ВРЕМЕНИ НА ОБУЧЕНИЕ И ХОЛДИНГ. Мы попробовали это однажды, и бизнес-клиенты боролись изо всех сил. Обычные случаи не имели большого значения, но когда дело дошло до подробных случаев и особенно негативных случаев тестирования, они боролись. Лучше было бы назначить или назначить специалиста по обеспечению качества или бизнес-аналитика, чем назначать клиентов.
sdek
4

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

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

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

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

Rudi
источник
2

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

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

koenmetsu
источник
2

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

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

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).

testerab
источник
Отличный ответ, отличный способ избавить разработчиков от скучной монотонности, получая отзывы клиентов. И отличные ссылки.
Этель Эванс
1

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

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

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


источник
1

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

Этель Эванс
источник
en.wikipedia.org/wiki/… для получения дополнительной информации.
Этель Эванс
+1 за указание на то, что пользовательские приемочные тесты должны быть разработаны пользователем. Хотя в моем ответе я предложил альтернативный подход (поскольку не похоже, что у них действительно есть какой-либо ресурс QA), приемное тестирование пользователей не может быть эффективно проведено не пользователями. В этой ситуации кажется, что и dev, и пользователи находятся в некотором тупике, поэтому я думаю, что dev должен попытаться как-то это сломать.
testerab