Кодирование и тестирование в одном и том же спринте

Как тестирование обрабатывается в том же спринте, что и кодирование, если все или большая часть кодирования не выполняется до конца спринта? (Я имею в виду разработку "супа к орехам" и тестирование одного PBI в спринте.)

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

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

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

Я уверен, что я не первый человек, который имеет эту дилемму.

В прошлом я занимался конвейером: в текущем спринте команда тестирования тестирует функции, которые были реализованы во время предыдущего спринта. На моей нынешней работе премьер-министр называет этот подход «водопадом» и, как таковой, недопустим.

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

Один из принципов бережливости (Agile не заканчивается Scrum) гласит: «Качество встроено». Что-то делается, только если оно соответствует критериям качества, которые вы определяете. Очень важно иметь реальный гибкий процесс, завершение весны с нулевым значением или отдельное тестирование от разработки - это признаки большой проблемы.

Есть много вещей, которые вы можете сделать:

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

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

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

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

Решите эту проблему, и у вас не будет этой проблемы и возможно более эффективной команды.

Один способ, который работал для меня в прошлом, заключался в том, чтобы предлагать кодировщикам и тестировщикам объединяться в истории с явной задачей создания полностью проверенной истории. Вместе с этим я стер все формы мышления "dev complete": нет столбцов "dev complete" на доске scrum / kanban / trello, нет отношения "dev done" со стороны кодировщиков.

Что случилось было:

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

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

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

• Некоторые люди расстроились.

• Истории в среднем доставлялись быстрее, потому что цикл code-commit-pull-test стал практически мгновенным

Конечно, это только мой анекдотический опыт, но вы можете попробовать это сами, если сможете.

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

Это проблема общения , а не проворная проблема. Принятие гибкой методологии просто делает это очевидным. Команды Silo'd являются известным анти-паттерном управления , поэтому в этом случае используйте гибкость agile!

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

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

• Во время спринта:

  1. Команда разрабатывает дизайн новой функции и влияние на фактическую базу кода.

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

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

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

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

Я считаю, что ваши настоящие проблемы следующие:

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

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

если все или большая часть кодирования не сделано до конца спринта?

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

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

Второй вариант заключается в том, чтобы QA управлял спринтом за персоналом разработчиков, таким как ваш личный ненавистник. Мне также не нравится это. Это исключает концепцию «выпускаемого продукта» в конце спринта, даже если у вас есть процесс эскалации ваших выпусков. Хуже того, разработчики будут сосредоточены на «новых» вещах, когда QA приходит к ним с вопросами или ошибками от тестирования. Разработчики также вряд ли будут исправлять ошибки в этой схеме. Но я видел, что это производит качественное программное обеспечение вовремя.

Руководство Scrum требует, чтобы команды были кросс-функциональны. Все члены команды считаются разработчиками, независимо от их индивидуальной специализации. Отдельные игроки (программист, тестировщик, QA, UX и т. Д.) Бесполезны в Scrum. Члены команды помогают друг другу везде, где могут. Не существует понятия «передача предмета в ка».

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

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

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

Тестирование и кодирование идут рука об руку. Вы можете запланировать это модуль за модулем. Как только модуль закончен, вы можете предоставить его тестерам. Весь этот сценарий также зависит от того, над какой фазой тестирования вы работаете. Спиральная SDLC модель выглядит хорошо. При этом одновременное тестирование и кодирование удобно. Другим подходом может быть V модель .

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

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

Я поднял цитату, чтобы подчеркнуть часть «взаимодействия с внешним миром»: вы хотите, чтобы тестирование проводилось в пользовательском интерфейсе, так как он выводится на экран («[начать тестирование] на самом деле невозможно, так как вам обычно нужен функционал»). Пользовательский интерфейс для записи или создания автоматизированных тестов из ").

Другие ответы говорят вам, чтобы автоматизировать это «приемочное тестирование», чтобы оно могло произойти быстро. Это правильно, но не полностью решает вашу первоначальную проблему: что, если для написания этих приемочных тестов не хватает времени?

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

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

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

Считать пользовательский интерфейс «чужой территорией» на самом деле правильной точкой зрения, поскольку вам не нужно проверять логику библиотеки, которую вы не предоставили, и, что удивительно, это реалистическая точка зрения: действительно ли вы ожидаете ли вы когда-нибудь протестировать этот вызов, например, соответствует MyWidget.draw()ли ваш уровень ожидания уровню одного пикселя?

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