Home

Автор: Баз Дийкстра (Bas Dijkstra)

Оригинал статьи: https://techbeacon.com/how-tech-giants-test-software-theres-no-one-way-qa

Перевод: Ольга Алифанова

Команды и организации, стремящиеся наладить (или улучшить) усилия по тестированию своих продуктов, могут извлечь полезные уроки, наблюдая, как тестируют "взрослые" компании. Логично предположить, что такие корпорации, как Google, Microsoft, Amazon не смогли бы добиться успеха, не обращая пристального внимания на качество своих продуктов.

Однако если посмотреть на то, как эти компании подходят к обеспечению качества, можно отметить, что "серебряной пули" не существует. Вот как тестируют пять наиболее известных компаний:

Google: в поисках лучших практик

Как организует свое тестирование компания, создавшая самый популярный в мире поисковик? Это сильно зависит от команды и продукта. К примеру, команда, работающая над поисковиком, поддерживает крупный и сложный фреймворк тестирования. Так как поиск – основной бизнес Google, команда стремится убедиться, что продукт настолько качественный, насколько это вообще возможно, и что никто ничего не испортил.

Чтобы этого добиться, Google использует четырехступенчатый процесс внедрения изменений в поисковик:

1. Тестирование внутренними силами (сотрудники Google).
2. Тестирование на crowdtesting-платформе.
3. Использование продукта сотрудниками Google в повседневной жизни.
4. Бета-тестирование: выпуск продукта для использования небольшой группой конечных пользователей.

Несмотря на то, что процесс выглядит серьезным и логичным, бывший директор Google Джеймс Уиттакер в этом видео говорит о том, что его есть куда улучшать – к примеру, существуют проблемы коммуникации между участниками разных стадий тестирования, что приводит к повторному тестированию каких-то областей, или полному отсутствию их тестирования.

Однако команды, отвечающие за более далекие от основного бизнеса Google продукты, используют куда менее строгие подходы к тестированию. В некоторых случаях тестирует только ответственный за продукт разработчик, без группы поддержки в лице профессиональных тестировщиков.

Как бы то ни было, Google относится к тестированию серьезно. Настолько серьезно, что зарплаты у разработки и тестирования равны – а это большая редкость.

Больше информации о том, как тестируют в Google, можно найти в их блоге о тестировании.

Facebook: тестирование при помощи разработки (Developer-driven)

В Facebook вообще нет тестировщиков как отдельных людей. Вместо них гигант социальных медиа полагается на своих разработчиков, тестирующих как собственную, так и чужую работу. В прошлом это в основном осуществлялось вручную, а сейчас компания использует широкий спектр автоматизированных решений для тестирования. Инструменты, которые используются в Facebook, варьируют от PHPUnit для бэкэнд-юнит-тестирования до Jest (JavaScript-инструмент, разработанный внутри компании), и до Watir для полного тестирования продукта.

Как и Google, Facebook следит за результатами использования приложения сотрудниками в реальной жизни, чтобы убедиться, что ПО можно пользоваться без проблем. Компания также известна тем, что стыдит разработчиков, допустивших промах (сломавших, к примеру, сборку или случайно положивших сайт), публикуя портрет преступника с клоунским носом во внутренней группе Facebook.

Компания признает, что у такого подхода есть свои недостатки, но вместо того, чтобы улучшать процесс, просто принимает эти проблемы как факт, так как социальные сети – не такая уж важная в жизни вещь. Меньший фокус на тестировании позволяет высвободить ресурсы для более важных занятий.

Вместо того, чтобы тщательно тестировать свое ПО от и до, Facebook применяет политику мелких релизов и инкрементального наката исправлений, обновлений и новых возможностей. К примеру, новая фича поначалу может быть доступна только небольшому проценту общего числа пользователей.

Отслеживая использование этой фичи и обратную связь по ней, компания решает, увеличить ли процент пользователей, которым она доступна, или отключить ее, улучшать ее или отказаться от ее внедрения.

Amazon: деплой превыше всего

Как и Facebook, у Amazon нет крупной инфраструктуры обеспечения качества. Раньше даже высказывались предположения, что Amazon вообще не ценит QA как профессию. Соотношение "один тестировщик на семерых разработчиков" также дает понять, что тестирование не считается важной деятельностью для Amazon.

Компания, однако, считает иначе. Для Amazon соотношение тестировщиков и разработчиков – это данные на "выходе", а не на "входе". Иными словами, как только команда замечает, что доходы упали, или что пользователи уходят к конкурентам из-за проблем на сайте, Amazon увеличивает усилия по тестированию.

Amazon считает, что процессы разработки и релиза находятся в настолько зрелом состоянии (компания релизится каждые 11,6 секунд и широко этим известна), что в сложных и глубоких процессах тестирования просто нет необходимости. Она стремится добиться простых релизов и, что не менее важно, простых откатов в случае проблем.

Spotify: отряды, племена и подразделы

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

• Отряды. Отряд – это аналог Scrum-команды с меньшим фокусом на практиках и большим – на принципах. Тезис компании гласит "Правила хороши для старта, но при необходимости их надо нарушать". В некоторых отрядах один или несколько тестировщиков, в некоторых их вовсе нет – все зависит от миссии отряда.
• Племена – это несколько отрядов, сгруппированных в зависимости от бизнес-области. Тестировщик, входящий в отряд, автоматически принадлежит к "племени" этого отряда.
• Подразделы. Компания также использует подразделы для группировки людей со схожими навыками, чтобы развивать обучение и обмен опытом. К примеру, все тестировщики из разных отрядов принадлежат к подразделу тестирования.

Spotify относится к тестированию очень серьезно. Как и программирование, тестирование рассматривается как творческий процесс, который нельзя полностью автоматизировать. В отличие от других упомянутых в статье корпораций, Spotify опирается на профессионалов тестирования, исследующих и оценивающих продукт, а не стремится автоматизировать все по-максимуму.

Что ждет тестирование в Spotify в будущем? Кристиан Карл, тест-менеджер команды и создатель инструмента для тестирования, основанного на моделировании (Graph Walker), говорит следующее:

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

Финальный факт: чтобы сократить усилия и затраты на настройку и поддержку тестовых окружений, Spotify активно тестирует на продакшене.

Microsoft: инженеры и тестировщики – одна команда

Соотношение тестировщиков к разработчикам в Microsoft – что-то около 2:3. Как и в Google, Microsoft платит им одинаково, но не называет их тестировщиками: они инженеры-программисты тестирования (software development engineers in test, SDETs).

Высокое соотношение тестировщиков к разработке объясняется тем, что большая доля доходов компании идет от продуктов, которые устанавливаются на клиентские компьютеры, а не от сайтов и онлайн-сервисов. Так как обновлять эти продукты тяжелее (и зануднее) в случае найденных багов или наката новых фич, Microsoft тратит много времени, усилий и средств на то, чтобы убедиться в качестве ПО до его выхода в релиз.

Чему можно научиться у гигантов отрасли

Если культура, взгляды и процессы тестирования и обеспечения качества так сильно отличаются в пяти крупнейших технических корпорациях в мире, то, возможно, не существует единственно верного способа организации тестирования. Все пятеро разработали свои подходы к тестированию, исходя из того, что будет лучше для продукта, и все пятеро крайне успешны. Наверное, что-то в их подходах есть, не так ли?

Однако нечто применимое к любым процессам тестирования из их опыта все-таки можно вынести:

• Существует "спектр ответственности за тестирование", варьирующий от "у нас работают профессиональные тестировщики, отвечающие в основном за прогон тестов" до "все отвечают за тестирование одинаково". Выберите подход, наилучшим образом соответствующий навыкам вашей команды.
• Есть также спектр "важности тестирования", варьирующий от "Ничто не выходит в релиз непротестированным" до "Мы релизим все подряд, а затем тестируем на проде, если вообще тестируем". Куда отнести ваш продукт и вашу компанию, зависит от рисков неудачи и легкости, с которой вы можете откатиться назад и исправить возникшие проблемы.
• Автоматизация тестирования широко представлена во всех пяти корпорациях. Масштабы ее внедрения различаются, но все компании применяют инструменты для оптимизации своих тестовых усилий. Возможно, и вам следует этим заняться.

Обсудить в форуме