В гибкой разработке, кто должен писать контрольные примеры?
У нашей команды есть система задач, в которой мы публикуем небольшие дополнительные задачи, назначаемые каждому разработчику.
Каждая задача разрабатывается в своей собственной ветви, а затем каждая ветка проверяется перед объединением в магистраль.
Мой вопрос: как только задача будет выполнена, кто должен определить контрольные примеры, которые должны быть выполнены для этой задачи?
В идеале, я думаю, что сам разработчик задачи лучше всего подходит для этой работы, но у меня было большое сопротивление со стороны разработчиков, которые считают, что это пустая трата времени, или что им просто не нравится это делать.
Причина, по которой мне не нравится, когда мои сотрудники QA делают это, в том, что мне не нравится идея, что они создают свою собственную работу. Например, они могут пропустить вещи, которые просто слишком много работают для тестирования, и они могут не знать технических деталей, которые необходимы.
Но аналогичным образом, недостатком разработчиков, выполняющих тестовые случаи, является то, что они могут не учитывать то, что, по их мнению, сломается. (возможно даже подсознательно)
Как руководитель проекта, я сам написал тестовые примеры для каждой задачи, но мое время облагается налогом, и я хочу это изменить.
Предложения?
РЕДАКТИРОВАТЬ: Под тестовыми примерами я подразумеваю описание отдельных задач QA, которые должны быть выполнены для ветви, прежде чем она должна быть объединена с внешней линией. (Черный ящик)
16 ответов
Команда.
Если дефект попадает к клиенту, это вина команды, поэтому команда должна писать контрольные примеры, чтобы гарантировать, что дефекты не дойдут до клиента.
Руководитель проекта (PM) должен понимать домен лучше, чем кто-либо в команде. Их знание предметной области жизненно важно для того, чтобы иметь контрольные примеры, которые имеют смысл в отношении предметной области. Они должны будут предоставить примеры входных данных и ответить на вопросы об ожиданиях относительно неверных входных данных. Они должны предоставить, по крайней мере, контрольный пример "счастливого пути".
Разработчик (и) будет знать код. Вы предполагаете, что разработчик может быть лучшим для этой задачи, но вы ищете тестовые случаи черного ящика. Любые тесты, которые придумывает разработчик, являются тестами белого ящика. В этом преимущество того, что разработчики создают контрольные примеры - они знают, где находятся швы в коде.
Хорошие разработчики также будут приходить в личку с вопросами "Что должно произойти, когда...?" - каждый из них является контрольным примером. Если ответ сложный: "Если a, то x, но если b, то y, кроме четвергов" - есть несколько тестовых случаев.
Тестеры (QA) знают, как тестировать программное обеспечение. Тестировщики, скорее всего, придумают тестовые случаи, о которых ПМ и разработчики не подумают, поэтому у вас есть тестеры.
Я думаю, что руководитель проекта или бизнес-аналитик должны написать эти контрольные примеры.
Затем они должны передать их специалисту по контролю качества для проверки и тестирования.
Таким образом вы гарантируете отсутствие пропусков между спецификацией и тем, что на самом деле проверено и доставлено.
Разработчики не должны этого делать, так как они будут тестировать свои юнит-тесты. Так что это пустая трата времени.
Кроме того, эти тесты обнаружат ошибки, которые разработчик никогда не обнаружит, так как они, вероятно, связаны с недоразумением в спецификации или с особенностями или маршрутом в коде, который не был продуман и правильно реализован.
Если вы обнаружите, что у вас недостаточно времени для этого, наймите кого-то другого или назначьте кого-то на эту роль, поскольку это является ключом к созданию превосходного продукта.
Из прошлого опыта нам очень повезло, когда мы определяли тесты на разных уровнях для тестирования немного разных вещей:
1-й уровень: на уровне кода / класса разработчики должны писать атомарные модульные тесты. Цель состоит в том, чтобы максимально протестировать отдельные классы и методы. Эти тесты должны выполняться разработчиками по мере их кодирования, предположительно перед архивированием кода в систему контроля версий, и сервером непрерывной интеграции (автоматизированным), если он используется.
2-й уровень: снова на уровне интеграции компонентов разработчики создают модульные тесты, которые проверяют интеграцию между компонентами. Цель состоит не в том, чтобы тестировать отдельные классы и компоненты, а в том, как они взаимодействуют друг с другом. Эти тесты должны запускаться вручную инженером-интегратором или автоматизироваться сервером непрерывной интеграции, если он используется.
3-й уровень: на уровне приложения команда QA проводит свои системные тесты. Эти контрольные примеры должны основываться на бизнес-предположениях или документах с требованиями, предоставленных менеджером по продукту. По сути, тестируйте, как если бы вы были конечным пользователем, выполняя действия, которые должны выполнять конечные пользователи, в соответствии с задокументированными требованиями. Эти контрольные примеры должны быть написаны командой QA и менеджерами по продукту, которые (предположительно) знают, чего хочет клиент и как они должны использовать приложение.
Я чувствую, что это обеспечивает довольно хороший уровень охвата. Конечно, уровни 1 и 2, описанные выше, в идеале должны выполняться перед отправкой встроенного приложения команде QA. Конечно, вы можете адаптировать это к тому, что соответствует вашей бизнес-модели, но это хорошо сработало на моей последней работе. Наш сервер непрерывной интеграции отправит электронное письмо команде разработчиков, если один из модульных тестов также не пройден во время процесса сборки / интеграции, если кто-то забудет запустить свои тесты и отправит испорченный код в исходный архив.
Мы экспериментировали с парой разработчика с QA-персоной с довольно хорошими результатами. Как правило, они "держали друг друга честно", и, поскольку у разработчика были модульные тесты для обработки кода, он / она был довольно близко знаком с изменениями. QA человек не был, но пришел на это со стороны черного ящика. Оба были привлечены к ответственности за полноту. Часть текущего процесса проверки помогла выявить недостатки модульных тестов, и поэтому было не так много инцидентов, о которых я знал, когда кто-то намеренно избегал написания X-теста, потому что это, вероятно, доказало бы наличие проблемы.
Мне нравится идея сопряжения в некоторых случаях, и я думаю, что она работала довольно хорошо. Возможно, это не всегда работает, но взаимодействие этих игроков из разных областей помогло избежать менталитета "брось через стену", который часто случается.
Во всяком случае, надеюсь, что это как-то полезно для вас.
Причина, по которой мне не нравится, когда мои сотрудники QA делают это, в том, что мне не нравится идея, что они создают свою собственную работу. Например, они могут пропустить вещи, которые просто слишком много работают для тестирования, и они могут не знать технических деталей, которые необходимы.
Да, тебе нужно больше доверять своему отделу контроля качества или лучше. Я имею в виду, представьте, что вы сказали: "Мне не нравится, когда мои разработчики разрабатывают программное обеспечение. Мне не нравится идея, что они создают свою собственную работу".
Как разработчик, я знаю, что при написании моих собственных тестов есть риски. Это не значит, что я этого не делаю (особенно, если я делаю TDD), но у меня нет иллюзий по поводу покрытия тестами. Разработчики собираются написать тесты, которые показывают, что их код делает то, что, как они думают, делает. Не слишком многие собираются писать тесты, применимые к конкретному бизнес-сценарию.
Тестирование - это навык, и, надеюсь, ваш отдел обеспечения качества или, по крайней мере, руководители этого отдела хорошо разбираются в этом навыке.
"Разработчики, которые думают, что это пустая трата времени, или что им просто не нравится это делать". Тогда вознаградите их за это. Какая социальная инженерия необходима, чтобы заставить их создавать тестовые случаи?
Может ли QA просмотреть код и контрольные примеры и произнести "Не достаточно покрытия - нужно больше случаев". Если это так, то программистом, у которого сразу "достаточно" покрытия, будет Большой Кахуна.
Итак, мой вопрос: как только задача будет выполнена, кто должен определить цель "достаточного количества" тестовых случаев для этой задачи? Когда вы знаете "достаточно", вы можете назначить программистов ответственными за заполнение "достаточно", а QA - за то, чтобы убедиться, что "достаточно" проведено тестирование.
Слишком сложно определить "достаточно"? Интересно. Вероятно, это коренная причина конфликта с программистами в первую очередь. Они могут чувствовать, что это пустая трата их времени, потому что они уже сделали "достаточно", а теперь кто-то говорит, что этого "недостаточно".
Специалисты по обеспечению качества совместно с "заказчиком" должны определить тестовые случаи для каждой задачи [здесь мы действительно смешиваем терминологию], а разработчик должен написать их. первый!
Я редко слышал или видел, чтобы руководители проектов писали контрольные примеры, за исключением небольших команд. В любом большом, сложном программном приложении должен быть аналитик, который действительно знает приложение. Я работал в ипотечной компании в качестве премьер-министра - должен ли я понимать субстандартное кредитование, процентные ставки и тому подобное? Может быть, на поверхностном уровне, но настоящие эксперты должны были убедиться, что все это работает. Моя работа состояла в том, чтобы поддерживать здоровье команды, защищать гибкие принципы и искать новые возможности для работы в моей команде.
Agile canon заключается в том, что у вас должно быть (как минимум) два уровня тестов: тесты для разработчиков и пользовательские тесты.
Тесты для разработчиков написаны теми же людьми, которые пишут производственный код, предпочтительно с использованием разработки, управляемой тестами. Они помогают придумать хорошо отделенный дизайн и гарантируют, что код делает то, что думают разработчики, даже после рефакторинга.
Клиентские тесты указываются клиентом или доверенным лицом клиента. Фактически они являются спецификацией системы и должны быть написаны так, чтобы они были исполняемыми (полностью автоматизированными) и понятными для деловых людей. Довольно часто команды находят способы, чтобы клиент мог даже написать их с помощью специалистов по обеспечению качества. Это должно произойти, пока - или даже раньше - функциональность не будет разработана.
В идеале, единственной задачей, которую QA должен выполнить непосредственно перед слиянием, является нажатие кнопки для запуска всех автоматических тестов и выполнения дополнительного исследовательского (= незашифрованного) тестирования. Вы также захотите запустить эти тесты снова после слияния, чтобы убедиться, что интеграция изменений ничего не нарушает.
Мое предложение состоит в том, чтобы кто-то еще просмотрел контрольные примеры перед объединением кода для обеспечения качества. Конечно, это может означать, что разработчик упускает из виду работу другого разработчика, но этот второй взгляд может уловить то, что изначально не было замечено. Начальные тестовые случаи могут быть выполнены любым разработчиком, аналитиком или менеджером, а не тестером.
QA не должен писать тестовые случаи, так как это могут быть ситуации, когда ожидаемый результат не был определен, и к этому моменту может быть трудно иметь кого-то, кто будет судить между QA и разработкой, если каждая сторона считает, что их интерпретация правильная. Это то, что я видел много раз и хотел бы, чтобы это происходило не так часто, как это происходит.
Я свободно разбиваю свои тесты на тесты "для разработчиков" и "заказчики", последние из которых будут "приемочные тесты". Первые - это тесты, которые пишут разработчики, чтобы убедиться, что их код работает правильно. Последующие тесты написаны кем-то кроме разработчиков, чтобы убедиться, что поведение соответствует спецификации. Разработчики никогда не должны писать тесты соответствия, потому что их создание программного обеспечения, которое они тестируют, предполагает, что они поступили правильно. Таким образом, их приемочные тесты, вероятно, собираются утверждать, что разработчик уже знал, чтобы быть правдой.
Приемочные тесты должны определяться спецификацией, и если они написаны разработчиком, они будут управляться кодом и, следовательно, текущим поведением, а не желаемым поведением.
Выберите (а не просто выберите случайно) одного или двух тестеров, и пусть они напишут контрольные примеры. Обзор. Это также может быть полезно, если разработчик, работающий с задачей, просматривает контрольные примеры для задачи. Поощряйте тестировщиков предлагать улучшения и дополнения к тестовым наборам - иногда люди боятся исправить то, что сделал начальник. Таким образом, вы можете найти кого-то, кто хорош в дизайне тестов.
Сообщите тестировщикам о технических деталях - я думаю, что все в гибкой команде должны иметь доступ для чтения к коду и любой доступной документации. Большинство тестировщиков, которых я знаю, могут читать (и писать) код, поэтому они могут найти полезными модульные тесты, возможно, даже расширить их. Убедитесь, что разработчики тестов получили полезные ответы от разработчиков, если им нужно что-то узнать.
Тестовый пример начинается первым в карточке истории.
Целью тестирования является устранение дефектов влево (в начале процесса разработки программного обеспечения, когда они дешевле и быстрее устраняются).
Каждая карта истории должна включать критерии принятия. Владелец продукта соединяется с аналитиком решения, чтобы определить критерии приемлемости для каждой истории. Этот критерий используется для определения того, была ли достигнута цель карты истории.
Критерии приемлемости сюжетной карты будут определять, какие автоматические юнит-тесты должны быть закодированы разработчиками в процессе разработки, управляемой тестами. Он также будет управлять автоматизированным функциональным тестом, реализованным автоматическими тестировщиками (и, возможно, с поддержкой разработчика, если используются такие инструменты, как FIT).
Не менее важно то, что критерии приемлемости будут определять автоматизированные тесты производительности и могут использоваться при анализе профилирования приложения разработчиками.
Наконец, пользовательский приемочный тест будет определяться критериями приемки в карточках историй и должен быть разработан деловым партнером и / или пользователями. Следуйте этому процессу, и вы, вероятно, выпустите с нулевыми дефектами
Системный аналитик должен проверить все тестовые случаи и их правильную связь с вариантами использования. Кроме того, аналитик должен выполнить окончательный UAT, который также может быть основан на тестовых примерах. Таким образом, аналитик и специалист по качеству проводят своего рода экспертную оценку.
Качество проверяет варианты использования, когда он создает тестовые наборы, а аналитик просматривает тестовые примеры после того, как они написаны, и пока он выполняет UAT.
Конечно, БА является экспертом в области, а не с технической точки зрения. BA понимает требования, и контрольные примеры должны быть сопоставлены с требованиями. Разработчики не должны быть людьми, которые пишут тестовые примеры для проверки их кода. QA может написать подробные этапы испытаний в соответствии с требованиями. Но человек, который пишет требование, должен диктовать, что должно быть проверено. Кто на самом деле пишет тестовые случаи, мне все равно, если тестовые примеры можно отследить до требований. Я думаю, что имеет смысл, что BA руководит направлением или областью тестирования, а QA пишет детальные планы тестирования.
Нам нужно эволюционировать от того, "как это было сделано или должно быть сделано в менталитете", оно терпит неудачу и терпит неудачу постоянно. Лучший способ решить проблему написания плана / кейсов тестирования - это когда тестовые кейсы должны быть написаны в doc требований в водопаде или в истории пользователя в agile, когда пишутся эти требования / истории пользователей. Таким образом, нет никаких сомнений в том, что нужно тестировать, и команды QA и UAT могут выполнить тестовые сценарии и сконцентрировать время на реальном тестировании и устранении дефектов.