В гибкой, как разработка, кто должен писать тестовые примеры?

Ответ 1

Команда.

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

• Менеджер проектов (PM) должен понимать домен лучше, чем кто-либо из команды. Их знание домена жизненно важно для того, чтобы иметь тестовые примеры, которые имеют смысл в отношении домена. Им нужно будет предоставить пример ввода и ответить на вопросы о ожиданиях на недопустимые входы. Они должны предоставить по крайней мере тестовый пример "счастливого пути".

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

  Хорошие разработчики также придут к премьеру с вопросами "Что должно произойти, когда...?" – каждый из них является тестовым. Если ответ сложный "Если a тогда x, но если b, то y, кроме четверга" – существует несколько тестовых случаев.

• Тестеры (QA) знают, как тестировать программное обеспечение. Тестеры, вероятно, придумают тестовые примеры, которые PM и разработчики не подумали бы о – поэтому у вас есть тестеры.

Ответ 2

Я думаю, что менеджер проекта или бизнес-аналитик должны написать эти тестовые примеры.
Затем они должны передать их персоналу QA, чтобы выдать и проверить.

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

Разработчик должен определенно не делать этого, поскольку они будут тестировать свои модульные тесты. Так что это пустая трата времени.

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

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

Ответ 3

Мы экспериментировали с сопряжением разработчика с человеком QA с довольно хорошими результатами. Они, как правило, "держали друг друга честными", и поскольку разработчик имел модульные тесты для обработки кода, он/она был очень интимным с изменениями уже. Человек QA не был, но пришел к нему со стороны черного ящика. Оба были привлечены к ответственности за полноту. Часть текущего процесса обзора помогла уловить недостатки unit test, и поэтому было не так уж много инцидентов, что я знал, где кто-то намеренно избегал писать X-тест, потому что это, вероятно, докажет, что возникла проблема.

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

Во всяком случае, надеюсь, что это вам поможет.

Ответ 4

Из прошлого опыта у нас было довольно удачное определение тестов на разных уровнях, чтобы протестировать несколько разные вещи:

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

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

3-й уровень: на уровне приложения, команда QA проведет свои системные тесты. Эти тестовые примеры должны основываться на бизнес-допущениях или документах требований, предоставляемых менеджером продукта. В принципе, проверяйте, как будто вы являетесь конечным пользователем, делаете то, что должны делать конечные пользователи, как документированные запросы. Эти тестовые примеры должны быть написаны командой QA и менеджерами продуктов, которые (предположительно) знают, чего хочет клиент, и как они должны использовать приложение.

Я чувствую, что это обеспечивает довольно хороший уровень охвата. Конечно, уровни 1 и 2 выше в идеале должны быть выполнены перед отправкой встроенного приложения в команду QA. Конечно, вы можете адаптировать это к тому, что подходит вашей бизнес-модели, но это очень хорошо работало на моей последней работе. Наш сервер непрерывной интеграции вышвырнул бы электронное письмо команде разработчиков, если бы один из модульных тестов не удался во время процесса сборки/интеграции, если кто-то забыл запустить их тесты и прервал код в исходном архиве.

Ответ 5

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

Может ли QA просматривать код и тестовые примеры и произносить "Недостаточно охвата - нужны дополнительные случаи". Если это так, то программист, у которого есть "достаточный" охват сразу, будет Большой Кахуна.

Итак, мой вопрос: как только задача будет выполнена, кто должен определить цель "достаточно" тестовых примеров для этой задачи? Как только вы знаете "достаточно" , вы можете заставить программистов отвечать за заполнение "достаточного количества" и QA, ответственных за обеспечение того, чтобы "достаточно" тестирование было выполнено.

Слишком сложно определить "достаточно" ? Интересно. Вероятно, это первопричина конфликта с программистами. Они могут чувствовать, что это пустая трата времени, потому что они уже сделали "достаточно" , и теперь кто-то говорит, что это не "достаточно" .

Ответ 6

люди QA в сочетании с "клиентом" должны определять тестовые примеры для каждой задачи [мы действительно смешиваем терминологию здесь], и разработчик должен их написать. первый!

Ответ 7

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

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

Как разработчик, я знаю, что есть риски, связанные с написанием собственных тестов. Это не значит, что я этого не делаю (особенно, если я делаю TDD), но у меня нет иллюзий относительно охвата тестированием. Разработчики собираются написать тесты, которые показывают, что их код делает то, что они считают. Не слишком много собираются писать тесты, которые относятся к фактическому деловому делу.

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

Ответ 8

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

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

Ответ 9

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

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

Ответ 10

Я свободно нарушаю свои тесты на тесты "разработчика" и "клиентские" тесты, последним из которых будут "приемочные испытания". Первые - это тесты, которые разработчики пишут, чтобы убедиться, что их код работает правильно. Позже это тесты, которые кто-то, кроме разработчиков, пишет, чтобы убедиться, что поведение соответствует спецификации. Разработчики никогда не должны писать тесты accepatance, потому что их создание программного обеспечения, которое они тестируют, предполагает, что они поступали правильно. Таким образом, их приемочные тесты, вероятно, будут утверждать, что разработчик уже знал, чтобы быть правдой.

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

Ответ 11

Agile canon состоит в том, что вы должны иметь (по крайней мере) два уровня тестов: тесты разработчика и тесты клиентов.

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

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

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

Ответ 12

Тест-сценарий начинается сначала в карточке истории.

Цель тестирования - привести дефекты влево (ранее в процессе разработки программного обеспечения, когда они дешевле и быстрее исправляются).

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

Критерии приема карточной карты определяют, какие автоматические модульные тесты должны быть закодированы разработчиками, так как они выполняют Test Driven Development. Он также будет управлять автоматическим функциональным тестом, реализованным автоматными тестерами (и, возможно, с поддержкой разработчика, если вы используете такие инструменты, как FIT).

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

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

Ответ 13

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

Ответ 14

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

Качество анализирует прецеденты, когда он строит тестовые примеры, и аналитик анализирует тестовые сценарии после их написания и пока он выполняет UAT.

Ответ 15

Конечно, BA является экспертом в области, а не с технической точки зрения. BA понимает требования, и тестовые примеры должны быть сопоставлены с требованиями. Разработчики не должны быть лицами, которые записывают тестовые примеры для проверки своего кода. QA может написать подробные этапы тестирования на каждое требование. Но человек, который пишет это требование, должен диктовать то, что нужно протестировать. Кто на самом деле пишет тестовые примеры, я не забочусь слишком много, пока тестовые примеры можно отнести к требованиям. Я бы подумал, что имеет смысл, что BA руководствуется направлением или областью тестирования, а QA записывает подробные планы тестирования.

Ответ 16

Нам нужно эволюционировать от "так, как это было сделано или нужно сделать менталитет", он терпит неудачу и терпит неудачу. Лучший способ разрешить вопрос о плане тестирования/случае - это то, что тестовые примеры должны быть написаны на основе требований doc в водопаде или истории пользователей в гибкой ситуации, когда записываются истории reqs/user. Таким образом, нет никаких сомнений в том, что нужно тестировать, а команды QA и UAT могут выполнять тестовые примеры и время фокусировки на фактическое тестирование и разрешение дефектов.