Собеседование QA — что спрашивают о CI/CD

Устал от 3-часовых мок-интервью на Youtube? Дай ушам отдохнуть! Вот 32 вопроса на собеседовании QA, касающихся CI/CD.

Вопросы по тестированию

• Какое отношение имеет тестирование к CI-процессам?
• Нужно ли всегда автоматизировать тестирование?
• Какие тесты чаще других применяют в CI-процессах?
• Сколько тестов может быть в проекте?
• Что такое flaky-тест?
• Причины flaky-тестов
• Что такое TDD?
• Что такое BDD? Чем отличается BDD от TDD?
• Что такое тестовое покрытие?
• Должно ли тестовое покрытие быть 100%?
• Как оптимизировать тесты в CI?
• В чем разница между сквозным и приемочным тестированием?

Вопросы по управлению версиями и Git

Эти вопросы задают в первую очередь.

Что такое управление версиями / система контроля версий?

Управление версиями (контроль версий, система управления версиями) — это набор практик и инструментов для управления динамично изменяющейся кодовой базой, то есть тем объемом кода, который нужен для сборки приложения. 

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

Внимание: баг-трекинг (управление и контроль багов) — это другое! И об этом тоже надо почитать перед собеседованием.

Что такое Git?

Творение легендарного человека Линуса Торвальдса, создавалась как средство распределенной разработки первой операционной системы Linux. Сейчас Git —  это №1 система управления версиями. Построена на модели распределенных репозиториев, поэтому подходит для проектов какого угодно масштаба.

Что такое репозиторий Git?

Git-репозиторий — это место хранения всех файлов проекта. По сути, это каталог всех файлов (и изменений в файлах). Позволяет разработчику (и тестировщику) найти любое прошлое состояние файлов проекта.

Системы контроля версий — какие бывают, кроме Git?

• Mercurial, возможно лучший конкурент Git
• Subversion (SVN), кое в чем лучше чем Git
• Олдовая Concurrent Versions Systems (CVS), можно знать только название
• Централизованная Perforce для специфических нужд
• Нестандартный Bazaar 
• Устаревающий Bitkeeper
• Fossil, вопреки названию, это не ископаемая, а перспективная “инди”-система гибридного типа

Что такое ветка Git?

Ветка Git (гит-бренч) — это отдельное, независимое направление разработки в проекте для исправления бага или добавления/изменения функциональности.

Что такое мердж?

Мердж — это слияние, то есть объединение веток Git. 

Оно делается, например, когда разработчики «объединяют» внесенные ими изменения в коде, из фича-бренча (feature branch) с главной веткой (main branch или master branch). Здесь подробнее о ветвлениях и слияниях — это фундаментальное.

Что такое Trunk Based Development (TBD)?

В некоем смысле, это одна из базовых вещей в CI/CD; так что, от этого вопроса не “отпетлять” на собеседовании, возможно даже на позицию junior QA. 

(В некоторых компаниях предпочитают называть “магистральной разработкой”, или просто TBD).

TBD — это модель, в которой почти вся разработка ведется в одном “транке”, именуемом обычно trunk, master или main. В этот транк отправляют свои мерджи все разработчики.

Это достаточно популярная модель, потому что в ней проще управление версиями; транк получается “единственной опорной магистралью разработки”; TBD-модель минимизирует конфликты при слияниях веток.

Что такое Gitflow, чем отличается от TBD?

Gitflow — это рабочий процесс в Git, очень активно задействующий ветвление. Gitflow — это когда новый код передается (мерджится) в develop-ветку, а не main-ветку; main-ветка служит только для сокращенной версии истории проекта.

Отдельные функции пишутся в выделенных для них “фича-бренчах” (стандартно называемых feature/… например: feature/OC-19-add-submit-button); таким же образом релизы находятся в release/…-ветках (например release/2022-01-10).

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

Сколько времени “живет” ветка Git в TBD?

То есть сколько времени ветка остается активной. При правильной непрерывной интеграции ветки соответствуют лучшим практикам TBD, то есть должны быть “короткоживущими”. В идеале, ветка при TBD-разработке “живет” несколько часов, или пару дней, не более.

Вопросы по CI/CD

На собеседовании спросят базовые определения и концепции.

Что такое непрерывная интеграция (CI)?

CI (continuous integration) — это практика разработки ПО, когда программисты отправляют свой код в main-ветку несколько раз в день, следуя TBD-модели.

CI-методология предполагает активное применение автоматизированных тестов; а билд-сервер (он же CI-сервер) — запускает автотесты при каждом обновлении кода. Поэтому ошибки, если они есть, проявляются сразу же — и исправляются сразу же. Этим и выгодно.

Как связаны непрерывная интеграция (Continuous Integration — CI) и управление версиями (Version Control — VC)?

Каждое изменение в коде должно “триггерить” процесс непрерывной интеграции. То есть CI-сервер должен быть подключен к Git-репозиторию, и автоматически определять, когда приходят изменения/обновления кода (пуш), и тогда запускаются автотесты с учетом последней версии кода.

Непрерывная интеграция, непрерывная доставка, непрерывное развертывание — суть CI/CD. А как они связаны?

• Непрерывная интеграция (Continuous Integration — CI) — выполнение последовательных этапов билда и тестирования проекта. CI запускается автоматически при каждом изменении, отправленном в репозиторий. Так разработчики получают быстрый фидбек (могут быстро понять ошибки и исправить их).

• Непрерывная доставка (Continuous Delivery — CD) — это как бы “расширение”, продолжение непрерывной интеграции. Цель непрерывной доставки — по возможности автоматизировать каждый этап разработки вплоть до релиза софта. И на выходе нашего “непрерывно движущегося” CD-конвейера (или чаще “пайплайна”) получаем нужный бинарник/пакет/контейнер нашего приложения.

• Непрерывное развертывание (деплой) — это опциональное расширение предыдущего процесса (непрерывной доставки). Это некий процесс, принимающий стабильный, протестированный код из CD-пайплайна и передающий его на продакшн-сервер, где он уже доступен пользователям.

Какая польза от CI/CD?

• Снижение рисков. Автоматизация тестов и постоянное тестирование снижают риски ошибок. 
• Чаще релизы. Автоматизация в сочетании с CI/CD позволяет выпускать релизы по несколько раз в день.
• Продуктивность. Меньше ручной работы с билдами и тестированием — а значит у разработчиков и тестировщиков остается больше времени на творческие задачи!
• Качество кода. CI/CD не пропускает откровенно плохой код на релиз.
• Лучше дизайн. Сама по себе итеративная, пошаговая природа CI-процессов, разделенная на небольшие, хорошо контролируемые этапы — дает простор для экспериментов, а значит инноваций и красоты.

Какими качествами должна обладать правильная CI/CD-платформа?

• Надежность. Команда во всем зависит от CI, что касается QA и деплоя, поэтому CI-платформа должна быть надежной; иначе остановится весь процесс CI/CD.
• Скорость. Достаточно быстрая и масштабируемая — выдает результаты за несколько минут, быстро расширяется.
• Воспроизводимость результатов. Один и тот же код должен выдавать всегда один и тот же результат.
• Простота работы. То есть простота настройки, управления, обслуживания.

Что происходит на этапе билда (build stage)?

На этапе билда создается бинарник, контейнер, или ехе-шник. На этом этапе проверяют, может ли приложение “собраться” без ошибок.

В чем разница между локальной и облачной платформой CI/CD?

• Локальный CI-сервер может обслуживаться как любой другой сервер — надо его установить, настроить, и обслуживать. Нужны будут обновления и патчи безопасности. NB: отказ локального CI-сервера блокирует тестирование, разработку и деплой.

• Облачному CI-серверу не требуется обслуживание — это обязанность его владельца. Ничего особо не нужно ставить и настраивать, можно пользоваться сразу. Все вычислительные мощности обеспечивает владелец платформы — так что и с расширяемостью нет проблем. Отсутствие проблем с сервером гарантируется SLA-договором с владельцем.

Сколько времени нужно на билд?

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

Насколько важна безопасность в CI-CD? 

Понятно, что CI/CD-платформы имеют доступ ко всем чувствительным данным. Это могут быть API-ключи, репозитории, базы данных, даже имена-пароли. Некорректно настроенный CI/CD-сервер — находка для злоумышленников, и они 100% воспользуются уязвимостью — в основном чтобы выложить взломанный продукт в открытый доступ, или продавать его самим, или шантажировать владельца/пользователей. Платформа должна иметь проверенные механизмы хранения чувствительных данных, контролировать доступ к логам и репозиториям.

Какие бывают стратегии релиза/деплоя?

• Стандартный релиз/деплой. Обычный релиз софта, софт сразу доступен клиентам.
• Canary-релиз, или “канареечный”. Применяется, когда есть риск крупного отказа в софте; релиз выдается небольшой части пользователей (например 1%). Разработчики постепенно переводят пользователей на последний релиз.
• Blue-green релиз. Выпускаются два экземпляра приложения одновременно — стабильная версия, и последний релиз. Пользователи переходят на стабильный релиз все одновременно. Это безопаснее, чем регулярный релиз: если есть проблема, пользователи сразу могут откатиться к предыдущей версии.
• Dark launch. Новые функции релизятся без предварительного оповещения пользователей. Функции активируются постепенно и по мере необходимости, активацией так называемых feature flags.

Подробный материал по CI/CD — здесь.

Вопросы по тестированию

(Здесь краткий туториал для новичков)

Какое отношение имеет тестирование к CI-процессам?

Процесс тестирования неотделим от непрерывной интеграции и является частью того самого “конвейера”. Вся суть — в постоянном фидбеке и быстром устранении проблем. Разработчики настраивают тесты в CI и убеждаются, что код приложения работает правильно. Без постоянного тестирования нет фидбека, а значит нет уверенности, что приложение пригодно к релизу.

Нужно ли всегда автоматизировать тестирование?

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

Какие тесты чаще других применяют в CI-процессах?

• Юнит-тесты. Проверка функций и классов — работают ли как положено.
• Интеграционные. Проверка компонентов — корректно ли работают в связке между собой.
• Сквозные (end-to-end, E2E). Симуляция работы пользователя с приложением.
• Статические. Поиск дефектов в коде без его запуска.
• Тесты безопасности. Проверка зависимостей в приложении на безопасность; поиск известных уязвимостей.
• Смоук-тесты (Smoke-тестирование). Быстрая проверка общей работоспособности — запускается ли, готова ли инфраструктура к деплоям.

Сколько тестов может быть в проекте?

Нет четкого ответа. Зависит от проекта. 

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

Что такое flaky-тест?

Flaky-тест (надмозг. “хлопчатый”, на жаргоне тестировщиков — “мигающий”, правильнее “нестабильный”) выдает ошибку без внятной причины, а затем не выдает — и невозможно понять закономерность. В CI-процессах это чаще всего значит, что тест прошел (pass) на локальной машине, однако на CI-сервере выдал ошибку (fail). Такие “хлопчатые” тесты сложны для отладки и вызывают у тестировщиков головную боль.

Причины flaky-тестов:

• Проблемы с параллельно выполняемыми тестами.
• Зависимость выполнения тестов от порядка их запуска в сьюте.
• Небрежно составленные тесты.
• Недетерминированный код — сам алгоритм способен выдавать разные результаты при одном и том же вводе.
• Изменилось тестовое окружение (см. выше).

Обширный материал по этой проблеме (с которой ты будешь сталкиваться практически каждый день) — по ссылке.

Что такое TDD?

TDD — это Test-Driven Development, то есть “разработка через тестирование”. TDD — это практика, принятая в программировании, в которой разработчик пишет тесты еще до написания кода. Таким образом, разработчик оперирует в понятиях вводов/выводов как тестировщик, лучше “видит” свой код свой код с точки зрения QA, поэтому код изначально получается удобнее для тестирования.

TDD-цикл состоит из 3 этапов:

1. Красный. Пишется тест, который “падает”.
2. Зеленый. Пишется минимальный объем кода, который пройдет тест.
3. Рефакторинг. Код совершенствуют, делают более “абстрактным”, читабельным, оптимизированным.

Что такое BDD? Чем отличается BDD от TDD?

BDD (behavior-driven-development) — это “разработка через поведение”. Как и в TDD, в BDD-методике все начинается с написания тестов, но тесты в BDD — это сценарии, описывающие, как система отвечает на действия пользователя.

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

Что такое тестовое покрытие?

Тестовое покрытие — это показатель, в какой мере код “покрыт” тестами. 100%-ное тестовое покрытие означает, что тесты покрывают каждую строчку кода хотя бы один раз.

Должно ли тестовое покрытие быть 100%?

Нет. Тестовое покрытие не должно достигать 100%. Существует ошибочное мнение, что 100%-ное тестовое покрытие автоматически означает полное отсутствие багов. А такого не бывает. Никаким , сколько угодно длительным и тщательным тестированием нельзя гарантировать абсолютную “чистоту от багов”. Упорное стремление достичь обязательно 100% покрытия рассматривается как плохая практика в QA. Она приводит к ложному чувству уверенности в качестве кода. Это потом заставляет делать лишнюю работу — рефакторить.

Как оптимизировать тесты в CI?

Порядок оптимизации тестов в CI: определить самые медленные тесты и изменить их. 

Общие правила:

• Разделять большие тесты на мелкие
• Удалять не особенно нужные и просроченные
• Рефакторинг, с удалением “тормозящих” зависимостей
• Параллельное выполнение

В чем разница между сквозным и приемочным тестированием?

Сквозное (end-to-end) тестирование подразумевает тестирование через его интерфейс, имитируя работу пользователя с приложением. Для этого нужно запускать приложение в продакшен-окружении, так что сквозное тестирование — неплохой способ проверить, что приложение правильно работает в целом.

Приемочное тестирование (acceptance testing) представляет собой проверку критериев приемки по соответствующему документу (Product Design). В нем описываются правила и поведение приложения, с точки зрения пользователей. 

Приемочное тестирование проверяет критерии приемки во время сквозного тестирования. То есть приемочное тестирование состоит из серий сценариев сквозного тестирования, которые имитируют условия и поведение, описанные к критериях приемлемости.

Источник