При создании оценок времени для билетов следует ли включать время, затраченное на тестирование (QAs), в оценку билетов? Раньше мы всегда оценивали время без тестеров, но мы говорим о том, чтобы всегда его включать. Это имеет смысл для нашего текущего спринта, последнего перед выпуском, так как мы должны знать общее время, которое займёт одна неделя.

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

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

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

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

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

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

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

Решительно да

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

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

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

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

Это, конечно, может стать нечетким, когда вы начнете использовать сюжетные очки, поскольку разница между dev-only 5 и dev-only 8 будет довольно пропорциональна dev-and-QA 5 по сравнению с dev-and-QA 8.

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

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

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

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

Если это все одна команда, но с раздельными ролями «разработчики» и «тестировщики», то это может означать, что у вас есть много заявок, над которыми может работать только одна сторона деления, и ваша (возможно, полностью гипотетическая) диаграмма Ганта выглядит точно так же, как будет выглядеть график для двух отдельных команд. Этот факт расстроит некоторые методологии больше, чем другие, и вам, возможно, было бы лучше разделить планирование из-за этого, но если вы не разделите его, то вам придется рассчитывать и оценивать все, что нужно команде, иначе ваши прогнозы будут безнадежными ,

Если целью оценок является нечто иное, чем предсказание и планирование, например, «потому что мы бездумно следуем пустому ритуалу, который включает их», или «потому что руководство использует их как палку, чтобы побить нас, чтобы вырвать у нас сверхурочные», или «потому что мы должны сделать ставку с фиксированной ценой, а цифры переходят в огромную формулу» (спасибо Джону Ву), тогда будет сложнее понять, что они должны включать ;-)

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

Мы закончили, когда мы готовы к производству .

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

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

Рабочее программное обеспечение является основной мерой прогресса.

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

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

Вот кое-что очень важное: все оценки должны сопровождаться допущениями и исключениями .

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

Если вы предоставляете оценочный документ руководителю проекта, он собирается преобразовать этот документ в рабочее задание или техническое задание для клиента или (если это внутренний проект) для PMO . Они могут иметь установленные формулы для добавления накладных расходов (например, некоторые проекты могут добавить X% для покрытия QA, затем добавить Y% для покрытия управления и управления проектами), которые устанавливаются по контракту или устанавливаются опытным путем. И вы не хотите удваивать счет. С другой стороны, они могут не добавлять их автоматически.

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

Время должно быть включено в оценку, но вы не должны оценивать время тестеров, вместо этого тестеры должны оценивать свое время .

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

Инкапсуляция

Я собираюсь подойти к этому с точки зрения разработки программного обеспечения и языка.

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

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

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

1. Сколько это будет стоить?
2. Мы уже закончили?

Предоставление бизнес-пользователю информации о внутреннем процессе вашей команды - плохое управление; Сродни предоставлению publicдоступа к внутреннему состоянию.

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