Как интегрировать системное тестирование в гибкий процесс?[закрыто]

Question

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

Answer 1

Что мешает вам создать свой собственный процесс?Если найдешь что-то, может быть лучше...просто сделай это.Если это работает, продолжайте в том же духе..если нет, попробуй что-нибудь еще.Если вам нужна гибкость, не существует четко установленного процесса.
Чаще употребляется термин «готовый к отправке'код в конце каждой итерации.Это означает, что вы можете передать его конечному пользователю (в виде набора DLL для копирования общего ресурса или лично доставить CD/DVD), и он получит выгоду от его использования.Такой код прошел все юнит-тесты (разработчики) и приемочные тесты (клиенты/QA/аналитики) которые были сочтены необходимыми, чтобы это было «сделано!» Приемные тесты являются сквозными сценариями клиента.

Я не уверен, что вы подразумеваете под «дальнейшим тестированием и проверкой»...Я могу подумать о других «предварительных» мероприятиях.

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

Вы просто складываете его в конец конечной точки последней итерации (если вы такой пессимист, как я..возьмите исторические средние значения..если вы отпустите раньше.Ура!) Итак, если компания решила, что Итерация № 14 ограничивает хороший набор функций, которые могут стать релизом..Это просто «Добавить n недель» после завершения итерации № 14.никакой сложной математики или неопределенности на этом этапе.Ключевой момент в том, что Если вы регулярно взаимодействуете с заинтересованными сторонами/клиентами, учитываете обратную связь и поддерживаете приемлемый уровень качества, сюрпризов в последнюю минуту быть не должно.

При необходимости вы можете даже начать с размаха..то естькоманда обучения приступает к работе, когда команда разработчиков переходит на итерацию №13.Это дает им месяц при условии двухнедельной итерации.и, надеюсь, у вас не будет тонны функций, добавленных в последнюю итерацию..Таким образом, максимум через 2 недели после Итерации № 14 и с учетом всех согласований небесных и организационных структур у вас должно получиться освобождение и заслуженный перерыв.

Answer 2

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

Тогда решение этой проблемы может пойти по одному из двух путей:с автоматизацией или без.Автоматизация на более высоких уровнях тестирования сократит усилия по запуску тестов, снова вписав работу в итерацию, поскольку каждая итерация будет сосредоточена только на постепенном увеличении объема/сложности.Это не всегда достижимо во всех контекстах проекта, даже если мы этого хотим.Переоценка автоматизации тестирования высокого уровня — это ловушка, к которой вам следует отнестись серьезно, другими словами, избегайте недооценки того, что предлагает достаточно опытный исследовательский тестировщик.

Без автоматизации проблема смещается в сторону управления тестированием.Параллельные итерации тестирования со сдвигом по времени — одно из возможных решений.Например, вы можете создать очередь тестирования для задач системного тестирования, которая выполняется с той же частотой, что и итерации разработки, но задерживается или сдвигается по времени на целую продолжительность одной полной итерации.Это позволяет тестировщикам комплексно работать над новыми выпусками в своей «песочнице» и в соответствии со своими приоритетами.

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

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

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

Answer 3

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

Answer 4

Добавьте системное тестирование в свой журнал спринта (в Scrum) или его эквивалент.

То же самое с пользовательской документацией.

Answer 5

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

Один из способов интеграции — создать ночную сборку или непрерывную сборку, которая выполняется постоянно и может занять несколько часов для сборки и запуска всех тестов.Если сборка проходит все тесты (модульный тест + системные тесты), она становится доступной для выпуска, и вы можете доставить этот двоичный файл или снимок исходного кода.Идея состоит в том, чтобы иметь x версий ваших двоичных файлов/снимков кода, проверять их асинхронно и доставлять «зеленые» сборки.Это должно работать как с автоматическими системными тестами, так и с ручными.