В настоящее время я просматриваю некоторые артефакты тестовых случаев для различных проектных групп, стандартизированных нашей организацией. Тем не менее, я немного потрясен, обнаружив, что большое количество контента фиксируется в документах и приводит к напрасным усилиям.
Каковы некоторые рациональные способы захвата/документирования описаний тестовых случаев, которые, как вы видели, успешно применялись, чтобы «все были довольны» (т. Е. Никто не жалуется на то и то отсутствие).
В настоящее время вот схема того, что мы фиксируем только для одного тестового случая:
Конечно, идентификатор/элемент тестового случая по большей части генерируются автоматически. Но это еще много, чтобы захватить. Мы фиксируем наши требования в виде пользовательских историй, но нам все еще нужны некоторые детали для наших тестовых случаев. Я просто беспокоюсь, что деталей может быть слишком много. Есть и другие детали, такие как тип тестового примера, оценка времени/усилий и т. д.
Итак, каковы некоторые предложения по созданию «бережливой» документации тестового примера, чтобы устранить/уменьшить накладные расходы на документацию? (В нашей организации неприемлемо просто записывать тестовые примеры на обратной стороне карточек с историями . Приветствуются предложения по инструментам и форматам. В основном это идеи, помогающие уменьшить нагрузку на документирование тестовых случаев.)
Во-первых, современный инструмент тестирования может значительно повысить производительность. Microsoft Test Manager, когда он полностью интегрирован в установку Team Foundation Server, является моим личным фаворитом. Однако есть и другие, которые, вероятно, дадут вам очень похожие результаты.
При этом пункты 1-9 в вашем списке кажутся причудливым способом сказать «что вам нужно сделать, чтобы запустить этот тест». Если это так, то если вы планируете проводить регрессионное тестирование с какой-либо мерой повторяемости, вам, вероятно, потребуется зафиксировать все это.
10, однако, следует фиксировать только при неудачных тестах, так как это пустая трата усилий для прохождения тестов.
«Итак, каковы некоторые предложения по созданию «бережливой» документации тестового примера, чтобы устранить/уменьшить накладные расходы на документацию?»
Основываясь на этой цитате, я полагаю, что вы, возможно, упускаете суть бережливой разработки программного обеспечения. Является ли документация тестового примера, которую вы в настоящее время фиксируете, узким местом в потоке ценности через вашу систему? Оптимизировали ли вы размеры партий, чтобы они соответствовали существующему процессу? Есть ли у вас ограничения WIP, которые вы можете изменить, чтобы настроить поток?
Кроме того, «сделать всех счастливыми» никогда не должно быть целью. Вам нужно беспокоиться о своей экономике.
Эндрю Клир
кандидат наук