Представьте, что самое важное программное обеспечение вашей компании внезапно сломалось — что произойдет? Заказы могут потеряться, сроки могут быть сорваны, но клиенты определенно будут жаловаться.
Этого кошмарного сценария можно избежать: внедрив непрерывный и строгий процесс тестирования, который выявляет проблемы до того, как они вызовут хаос. Но внедрение такого процесса в вашей организации — это легче сказать, чем сделать.
В этой статье вы узнаете все, о чем следует подумать, приступая к тестированию в своей компании, и как вы можете извлечь пользу из тестирования в долгосрочной перспективе.
Тестирование лучших практик для продуктовых команд
В первой части статьи описывается процесс внедрения тестирования в ваш рабочий процесс.
Внедрите культуру тестирования в своей команде
Успешное внедрение тестирования в вашей команде требует, чтобы все разделяли общее мышление и рассматривали качество не как бремя, а как инвестицию. Это процесс, который, как и любой другой культурный сдвиг, требует времени и последовательности.
Одной из вещей, которая может помочь сформировать эту культуру, являются регулярные встречи для обсуждения дефектов, их влияния, откуда они взялись и что потребовалось для их устранения. Это помогает создать понимание того, почему полезно предотвращать такие дефекты в первую очередь.
Наличие в команде преданного человека, который контролирует и направляет усилия, может значительно повысить шансы на успех. Тот, кто определяет руководящие принципы для команды или даже для всей организации, собирает лучшие практики и делится ими, а также выступает за усилия на всех уровнях.
Другим полезным инструментом может стать ротация роли поддержки вашего продукта. Получение информации из первых рук, неотфильтрованной информации от ваших клиентов и изучение повседневных проблем, с которыми они сталкиваются при использовании вашего продукта, может стать ценным опытом для менеджеров по продукту, дизайнеров и разработчиков.
Цель состоит в том, чтобы все в вашей команде понимали, что качество — это функция, такая же важная, как и любая другая функциональность, которую вы создаете для своего продукта. Как только все примут этот образ мышления, естественным шагом станет понимание того, что тесты — это тоже функция. Потому что тесты — это то, что обеспечивает качество поставки.
Пошаговый процесс тестирования
Как только будет достигнуто согласование между различными командами, участвующими в разработке продукта, вы сможете дополнительно формализовать существование и использование тестов.
Сделайте тесты частью «Определения готовности»
Добавляя тесты в качестве требования к функции, вы заявляете, что функция не готова к выпуску, пока она не будет должным образом и автоматически протестирована.
Регулярно проводите тесты
После внедрения автоматизированные тесты могут стать вашей защитой на каждом этапе процесса разработки. Они не требуют вмешательства человека и могут запускаться на каждом критическом этапе конвейера разработки. Например:
- На каждом коммите.
- При каждом запросе на включение изменений.
- После каждого полного выпуска или изменения среды.
Если вы полагаетесь на сторонние сервисы в своей производственной среде, может иметь смысл даже запустить тесты на производственной среде, чтобы убедиться, что сторонние API ведут себя ожидаемым образом.
Определите и соберите показатели
Определение набора метрик важно для измерения эффективности ваших тестов и влияния рабочих процессов тестирования на ваш бизнес. Вот несколько примеров метрик, которые вы можете использовать:
- Релизов в месяц : большее количество релизов в месяц может указывать на более гибкий процесс разработки. Автоматизированное тестирование играет здесь ключевую роль, гарантируя, что релизы могут продолжаться с уверенностью.
- Сообщения об ошибках : тенденция к снижению количества сообщений об ошибках может быть положительным признаком того, что ваши процессы тестирования (и разработки) эффективны.
- Тестовое покрытие : Хотя покрытие никогда не является точной метрикой, оно может быть хорошим индикатором того, насколько глубоко вы тестируете критические варианты использования.
Обратите внимание, что на эти показатели также влияют другие факторы, которые могут их исказить. Например, количество ваших релизов может снизиться в праздничный сезон, а количество отчетов об ошибках возрастет. Поэтому не полагайтесь только на несколько показателей и обязательно сопоставляйте их с другими данными, доступными вашей команде.
Когда вы успешно реализуете эти шаги с вашей командой, здоровье вашего продукта определенно выиграет в долгосрочной перспективе. Но вы можете сделать еще больше!
Тестирование лучших практик для системных администраторов
Команды по продуктам не могут работать самостоятельно. Они полагаются на оборудование, инструменты и инфраструктуру, поддерживаемые системными администраторами. Хотя системные администраторы обычно не вносят прямого вклада в разработку продукта, они все равно могут влиять на рабочий процесс разработки в лучшую сторону. Например, активно управляя версией браузера, используемой определенными группами пользователей в компании.
Во второй части статьи объясняется, как это работает, с использованием каналов Chrome и корпоративных политик.
Каналы выпуска Chrome
По умолчанию Chrome автоматически обновляется, чтобы гарантировать, что каждый пользователь использует последнюю, самую стабильную и безопасную версию Chrome, включая все новейшие функции — версию Chrome, выпущенную на стабильном канале.
Как компания, разрабатывающая веб-продукт, вы можете захотеть использовать браузер перед стабильным каналом, чтобы дать вашим командам по продукту время адаптировать ваш продукт к изменениям веб-платформы.
Для этого варианта использования Chrome предлагает в общей сложности четыре канала выпуска, предназначенных для разных групп пользователей.
В случае Chrome существуют различные каналы выпуска, которые вы можете использовать, чтобы предвидеть будущие изменения браузера и тестировать новейшие функции до того, как они станут широко доступны:
- Стабильный канал : Здесь находится большинство пользователей. Стабильный канал автоматически обновляется при появлении нового релиза Chrome , что происходит ежемесячно.
- Бета-канал : эта версия станет стабильной через четыре-шесть недель, что даст вам возможность предварительно ознакомиться и протестировать предстоящий стабильный релиз, а также подготовиться к нему.
- Dev channel : Этот канал получает новую версию Chrome раз в неделю и включает все последние исправления, которые в конечном итоге перейдут в бета-версию. Как следует из названия канала, он находится в разработке и поэтому может неожиданно сломаться, но он также включает новейшие функции, иногда задолго до того, как они попадут в стабильную версию. Это делает dev channel отличным инструментом для создания прототипов и передовой разработки.
- Канал Canary : Самый экспериментальный канал, содержащий все новейшие функции, но без особого тестирования. По крайней мере, выпускается ежедневно.
Если вы хотите узнать больше о каналах Chrome, посмотрите соответствующий эпизод Chrome Concepts .
Использование каналов в образцовой организации
Структура команд по продуктам различается в разных организациях, поскольку не существует универсального подхода к разработке программного обеспечения. В качестве примера мы предположим команду со следующими ролями: управление продуктом, UX и UI, инжиниринг, операции и поддержка.
Для такой организации можно рассмотреть следующее разделение каналов:
- Product Management : PM обычно могут быть на стабильном канале, чтобы использовать ту же версию, что и большинство пользователей. Иногда они могут использовать бета-канал или канал dev, если они работают над функцией, требующей API, который еще не был запущен.
- Инженерное дело и UX : части этих команд могут быть включены в канал разработки , что даст им доступ к новейшим функциям, таким как View Transitions , даже до того, как они появятся в стабильной версии.
- Операции : Возможно, это будет бета-версия , чтобы предвидеть возможные сбои, которые могут повлиять на пользователей в будущем.
- Поддержка : можно оставаться на стабильном канале, чтобы убедиться, что они взаимодействуют с продуктом через тот же браузер, что и большинство ваших клиентов.
Используйте корпоративные политики для управления каналами
Вместо того, чтобы давать указания и оставлять решение о том, какой канал использовать, Chrome также предлагает корпоративные и административные инструменты для активного управления тем, какой канал в конечном итоге использует каждый пользователь. Это полезно, поскольку это немедленно увеличивает поверхность тестирования с нескольких отдельных лиц до детерминированного набора пользователей, что помогает выявить поломку как можно раньше и прослеживаемым образом.
Если вы хотите использовать этот уровень контроля, вот конфигурация, которую мы рекомендуем:
- Сотрудники (пользователи приложения) : чтобы свести к минимуму риск сбоев, большинство сотрудников должны использовать стабильный канал, который был полностью протестирован командой тестирования Chrome. Кроме того, небольшой процент пользователей (от 5 до 10%) может использовать бета- канал. Этот канал получает 4–6-недельный предварительный просмотр стабильной версии и может помочь администраторам обнаружить возможные проблемы с выпуском, давая больше времени для решения проблем до того, как выпуск будет развернут для всех остальных.
- ИТ-отдел : сотрудники ИТ-отдела, включая системных администраторов, могут участвовать в бета- или dev- каналах, чтобы получить предварительную версию стабильной версии Chrome на 4–6 или 9–12 недель.
Долгосрочные каналы выпуска
Разработка продукта может идти не так быстро, как планировалось, а ежемесячный каденс выпуска Chrome может оказаться слишком высоким. Для этого варианта использования Chrome предоставляет расширенный стабильный канал, который позволяет получать обновления функций реже, но при этом получать исправления безопасности. Этот канал обновляется каждые восемь недель.
На следующей диаграмме показано, как различные этапы проходят через различные каналы выпуска Chrome :
- И стабильная, и расширенная стабильная версии поставляются в одних и тех же версиях в течение первых четырех недель, после чего они расходятся.
- Расширенного бета-канала нет; вместо этого стандартный четырехнедельный бета-цикл используется для стабилизации как стабильной, так и расширенной стабильной версии. Предприятия, которые решили выбрать восьминедельную расширенную стабильную версию, должны продолжать использовать бета-канал, как они это делают сегодня, чтобы заранее выявлять проблемы, которые могут повлиять на их среду.
Заключение
Тестирование является важнейшей частью деятельности компаний-разработчиков программного обеспечения, позволяющей гарантировать качество их продуктов, а также важным шагом для системных администраторов, позволяющим предоставить сотрудникам организации доступ к высококачественному программному обеспечению и избежать нарушения бизнес-процессов.
Чтобы добиться успеха при внедрении процесса тестирования в вашей организации, важно, чтобы все разделяли общее мнение о том, что качество и, следовательно, тестирование являются важной характеристикой.
В этой статье мы рассмотрели различные способы интеграции передовых методов тестирования в вашу организацию. Подробный обзор существующих инструментов тестирования можно найти в нашей статье Инструменты Chrome для бесперебойного автоматизированного тестирования .
Для практического руководства по тестированию от начала до конца ознакомьтесь также с нашим последним курсом Learn Testing и передовыми методами автоматизации тестирования на web.dev.