ХАОС (порядок автотестов)

ХАОС – хорошие автоматизированные общие скрипты

Тестировщик в Agile команде – это в первую очередь автоматизатор, поскольку процессы на всех стадиях разработки программного обеспечения скоростные. В быстрых проектах роли объединяются и замещаются, а поэтому ресурсы должны быть обще-доступны, понятны, просты в применении.

ЧТО

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

ГДЕ

Очевидно, что скрипты авто-тестов необходимо хранить в той же Системе Контроля Версий (СКВ), что и исходники выпускаемого продукта. Опыт показывает, что наиболее удобно выделять место под авто-тесты в рамках конкретного продукта или модуля. В дереве СКВ одноимённые подпапки "Авто-тесты" упрощают поиск при их запуске в CI (Continuous Integration) среде. Наличие скриптов в СКВ способствует более корректному их редактированию в зависимости от версии выпускаемого продукта.

КАК

Хотя скрипты авто-тестов и будут хранится в непересекающихся местах, но к их именованию также необходимо применить общие правила: уникальность в рамках проекта и модуля (префиксы по имени продукта, модуля), аббревиатура авто-теста (или использовать расширение имени файла, если их запуск отличен от основного приложения), для CI не эффективен постфикс версии, но краткое назначение скрипта должно быть в имени файла (примечание: нумерация порядка исполнения или версий продукта в имени файла малоэффективна, потому что привносит излишнюю уникальность в быстроменяющемся проекте). Содержимое скриптов должно удовлетворять всем принятым правилам кодирования в конкретной команде: именование переменных, использование глобальных параметров, наличие и объём комментариев, форматирование, использование достаточных команд без избытка кода по прямому назначению. Правила кодирования должны быть однозначно прописаны во внутренней документации, их пополнение и корректировка производится после очередного совместного обсуждения кода (public code review).


Команда, соблюдающая правила, непременно побеждает.

"В чём сила, Брат? В правде!" (С*)