Эта дорожная карта автоматизации — часть модели, которая разделяет большую тему автоматизации тестирования на пять майндсетов. В этой статье рассматривается корпоративный майндсет. Статья является частью большого рассказа о дорожной карте автоматизации, начало здесь.
Комплаенс
Итак, вы автоматизируете небольшую, но очень важную часть контроля качества (QC) для нескольких отделов или даже всей (глобальной) корпоративной организации. С помощью этих тестов вы обеспечиваете соблюдение комплаенса в организации. Как правило, вы фокусируетесь на соблюдении требований безопасности, законодательства и внутренних правил компании. Внутренний комплаенс включает в себя все, что важно для конкретной организации, и может быть достаточно обширным.
Важное
В идеале каждый тест должен выполняться централизованно, без участия команд, к которым относятся эти тесты; обычно команды уже заняты созданием и поддержкой тестов в своих более мелких областях.
Ваши тесты могут себе позволить быть медленными, если они невидимы на других уровнях и не блокирующие. Вы не будете блокировать релизный пайплайн из-за того что «центральный» тест долго выполняется или упал. Если команде нужно что-то изменить, потому что упал ваш тест корпоративного уровня, это должно быть организовано через руководство, а не навязано на уровне кода.
Однако если ваши тесты быстрые (менее ~10 секунд), им можно позволить быть видимыми и блокирующими. Но эти блокеры могут быстро стать сложными. При блокировке всегда нужно предусмотреть способ обойти ее с помощью изменений конфигурации, обработки исключений, и т. д. В любом случае вы столкнетесь с проблемами, связанными с легаси, сторонними приложениями и перегруженными работой командами.
Важной частью создания тестов в таком майндсете является обмен знаниями с командами, в которых они применяются. Вы рассказываете всем, зачем существуют эти тесты, как они работают и как интерпретировать результаты. Вы сообщаете всем о важных изменениях. Особенно если эти изменения могут привести к тому, что команда перестанет соответствовать правилам комплаенса. Несоответствие никогда не должно заставать другие команды врасплох.
Проблемы
Техническая сторона тестов на уровне корпорации обычно очень сложна. Для создания тестов команде потребуются серьезные скиллы программирования. Поскольку большинство тестировщиков ими не обладают, часто вместо них тесты пишут разработчики (или SDET).
А «человеческая часть» задачи еще сложнее. Как заставить другие команды выполнять тесты? Как заставить команды своевременно устранять баги?
Из-за многочисленных хард- и софт-проблем на этом уровне, скорее всего, понадобится выделенная команда для создания тестов и управления всем что с ними связано. Специальная команда, разумеется, требует значительных вложений, которые нужно обосновать. Вы не сможете эффективно внедрять корпоративный майндсет QA без явного одобрения свыше.
Инструменты и подходы
Тестирование на основе рисков — это то, с чего следует начинать, поскольку оно требует больших денежных и временных затрат. Никто не разрешит тратить много средств на тесты, которые приносят мало пользы.
Как только вы определили, что хотите тестировать, сообщайте об этом четко, громко и часто, чтобы привлечь как можно больше внимания. Общение с командами имеет решающее значение, скилл коммуникации критически важен.
Общие советы:
- Максимально упрощайте любой тест, который вы создаете. Это поможет как с технической стороны, так и с точки зрения коммуникации.
- Статический анализ кода — отличный способ обеспечить его соответствие требованиям безопасности. Репозитории исходного кода содержат ценные данные для статического тестирования, которые можно использовать для проверки соответствия требованиям безопасности. Этот подход хорошо масштабируется.
- Анализ данных для обнаружения проблем с соблюдением требований к пользовательским данным. Анализ баз данных поможет и в обеспечении комплаенса (например GDPR). С его помощью можно обнаружить неполные данные, дубликаты и подобное.
- Придерживайтесь статического анализа определенного типа. Излишне разносторонний подход плохо масштабируется.
- По умолчанию используйте планируемые пайплайны. Тесты, блокирующие релиз, обычно являются частью пайплайна непрерывной интеграции, или встраиваются во «внутренности» (например, API-шлюз).
- Когда используете блокирующие релиз тесты, есть смысл позволять командам «обойти» часть ваших тестов без вашего вмешательства.
- Должен применяться самый простой способ выполнить ту или иную задачу. При необходимости создавайте препятствия, но не ставьте заслоны.
Положение в модели
В корпоративном майндсете вы автоматизируете лишь часть тестов. Но вы делаете это в больших масштабах. Вы фокусируетесь на том, чтобы принести максимальную пользу как можно большему числу команд, сохраняя при этом минимальную техническую и коммуникационную сложность. Единственный способ добиться этого — строго ограничивать усилия по тестированию. Рисунок показывает, что чем больше тестов, тем меньше команд удается включить в процесс.
Пример из реального мира
Краткая история о том, как команда использовала корпоративный майндсет в компании с численностью сотрудников около 45000 человек (по данным LinkedIn). Отдел интеграции отвечал за создание платформ, соединяющих все приложения в организации.
Отдел хотел, чтобы каждый новый API был ориентирован на дизайн в первую очередь (design-first). Сначала команда пишет Schema OpenAPI (то есть Swagger). На основе Schema OpenAPI они реализуют API. Поэтому каждый API должен быть документирован схемой OpenAPI.
Но все пошло не так: многие команды игнорировали этот подход. Это привело к появлению плохо спроектированных и недокументированных API.
В то же время используемый организацией API-шлюз был признан вендором устаревшим. При поиске нового API-шлюза для перехода на него отдел искал способы отклонения новых API на основе результатов тестов. Таким образом, они требовали, чтобы все мигрируемые API имели Schema OpenAPI. Однако они не обеспечивали полноту схем. Из-за этого некоторые схемы оказались неполными.
Следующим шагом для этого отдела было «ужесточение» тестов. Таким образом, они смогли постепенно повышать качество схем OpenAPI и, следовательно, качество документации по API.
Резюме
Корпоративный майндсет автоматизации — это в первую очередь тестирование комплаенса. Такие тесты требуют большой технической сложности, а «человеческая» сложность еще выше. Поэтому понадобится специальная команда с большими полномочиями и ответственностью.
