6 простых шагов — Академия Яндекса

A/B-тестирование — это неотъемлемая часть процесса работы над продуктом. Это эксперимент, который позволяет сравнить две версии чего-либо, чтобы проверить гипотезы и определить, какая версия лучше. Должны ли кнопки быть черными или белыми, какая навигация лучше, какой порядок прохождения регистрации меньше всего отпугивает пользователей? Продуктовый дизайнер из Сан-Франциско Лиза Шу рассказывает о простой последовательности шагов, которые помогут провести базовое тестирование.

Кому нужно A/B-тестирование

• Продакт-менеджеры могут тестировать изменения ценовых моделей, направленные на повышение доходов, или оптимизацию части воронки продаж для увеличения конверсии.
• Маркетологи могут тестировать изображения, призывы к действию (call-to-action) или практически любые другие элементы маркетинговой кампании или рекламы с точки зрения улучшения метрик.
• Продуктовые дизайнеры могут тестировать дизайнерские решения (например, цвет кнопки оформления заказа) или использовать результаты тестирования для того, чтобы перед внедрением определить, будет ли удобно пользоваться новой функцией.

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

1. Определите цели 

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

Пример: Допустим, вы менеджер продукта в «компании X» на стадии стартапа. Руководству нужно добиться роста количества пользователей. В частности, компания стремится к росту количества активных пользователей (метрика DAU), определяемых как среднее количество зарегистрированных пользователей сайта в день за последние 30 дней. Вы предполагаете, что этого можно добиться либо путем улучшения показателей удержания (процент пользователей, возвращающихся для повторного использования продукта), либо путем увеличения числа новых регистрирующихся пользователей.

В процессе исследования воронки вы замечаете, что 60% пользователей уходят до завершения регистрации. Это означает, что можно повысить количество регистраций, изменив страницу регистрации, что, в свою очередь, должно помочь увеличить количество активных пользователей.

2. Определите метрику 

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

Пример: В нашем примере в качестве метрики вы выбираете долю зарегистрированных пользователей (registration rate), определяемую как количество новых пользователей, которые регистрируются, поделенное на общее количество новых посетителей сайта.

3. Разработайте гипотезу 

Затем нужно разработать гипотезу о том, что именно поменяется, и, соответственно, что вы хотите проверить. Нужно понять, каких результатов вы ожидаете и какие у них могут быть обоснования.

Пример: Допустим, на текущей странице регистрации есть баннер и форма регистрации. Есть несколько пунктов, которые вы можете протестировать: поля формы, позиционирование, размер текста, но баннер на главной странице визуально наиболее заметен, поэтому сначала надо узнать, увеличится ли доля регистраций, если изменить изображение на нём.

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

Нужно определить две гипотезы, которые помогут понять, является ли наблюдаемая разница между версией A (изначальной) и версией B (новой, которую вы хотите проверить) случайностью или результатом изменений, которые вы произвели.

• Нулевая гипотеза предполагает, что результаты, А и В на самом деле не отличаются и что наблюдаемые различия случайны. Мы надеемся опровергнуть эту гипотезу.
• Альтернативная гипотеза — это гипотеза о том, что B отличается от A, и вы хотите сделать вывод об её истинности.

Решите, будет ли это односторонний или двусторонний тест. Односторонний тест позволяет обнаружить изменение в одном направлении, в то время как двусторонний тест позволяет обнаружить изменение по двум направлениям (как положительное, так и отрицательное).  

4. Подготовьте эксперимент 

Для того, чтобы тест выдавал корректные результаты сделайте следующее:

• Создайте новую версию (B), отражающую изменения, которые вы хотите протестировать.
• Определите контрольную и экспериментальную группы. Каких пользователей вы хотите протестировать: всех пользователей на всех платформах или только пользователей из одной страны? Определите группу испытуемых, отобрав их по типам пользователей, платформе, географическим показателям и т. п. Затем определите, какой процент исследуемой группы составляет контрольная группа (группа, видящая версию A), а какой процент — экспериментальная группа (группа, видящая версию B). Обычно эти группы одинакового размера.
• Убедитесь, что пользователи будут видеть версии A и B в случайном порядке. Это значит, у каждого пользователя будет равный шанс получить ту или иную версию.
• Определите уровень статистической значимости (α). Это уровень риска, который вы принимаете при ошибках первого рода (отклонение нулевой гипотезы, если она верна), обычно α = 0.05. Это означает, что в 5% случаев вы будете обнаруживать разницу между A и B, которая на самом деле обусловлена случайностью. Чем ниже выбранный вами уровень значимости, тем ниже риск того, что вы обнаружите разницу, вызванную случайностью.
• Определите минимальный размер выборки. Калькуляторы есть здесь и здесь, они рассчитывают размер выборки, необходимый для каждой версии. На размер выборки влияют разные параметры и ваши предпочтения. Наличие достаточно большого размера выборки важно для обеспечения статистически значимых результатов.
• Определите временные рамки. Возьмите общий размер выборки, необходимый вам для тестирования каждой версии, и разделите его на ваш ежедневный трафик, так вы получите количество дней, необходимое для проведения теста. Как правило, это одна или две недели.

Пример: На существующем сайте в разделе регистрации мы изменим главную страницу — это и будет нашей версией B. Мы решаем, что в эксперименте будут участвовать только новые пользователи, заходящие на страницу регистрации. Мы также обеспечиваем случайную выборку, то есть каждый пользователь будет иметь равные шансы получить A или B, распределенные случайным образом.

Важно определить временные рамки. Допустим, ежедневно на нашу страницу регистрации в среднем приходит трафик от 10 000 новых пользователей, это означает, что только 5000 пользователей могут увидеть каждую версию. Тогда минимальный размер выборки составляет около 100 000 просмотров каждой версии. 100 000/ 5000 = 20 дней — столько должен продлиться эксперимент.

5. Проведите эксперимент 

Помните о важных шагах, которые необходимо выполнить:

• Обсудите параметры эксперимента с исполнителями.
• Выполните запрос на тестовой закрытой площадке, если она у вас есть. Это поможет проверить данные. Если ее нет, проверьте данные, полученные в первый день эксперимента.
• В самом начале проведения тестирования проверьте, действительно ли оно работает.
• И, наконец, не смотрите на результаты! Преждевременный просмотр результатов может испортить статистическую значимость. Почему? Читайте здесь. 

6. Анализируйте результаты. Наконец-то самое интересное 

Вам нужно получить данные и рассчитать значения выбранной ранее метрики успеха для обеих версий (A и B) и разницу между этими значениями. Если не было никакой разницы в целом, вы также можете сегментировать выборку по платформам, типам источников, географическим параметрам и т. п., если это применимо. Вы можете обнаружить, что версия B работает лучше или хуже для определенных сегментов.

Проверьте статистическую значимость. Статистическая теория, лежащая в основе этого подхода, объясняется здесь, но основная идея в том, чтобы выяснить, была ли разница в результатах между A и B связана с изменениями или это результат случайности или естественных изменений. Это определяется путем сравнения тестовых статистических данных (и полученного p-значения) с вашим уровнем значимости.

Если p-значение меньше уровня значимости, то можно отвергнуть нулевую гипотезу, имея доказательства для альтернативы.

Если p-значение больше или равно уровню значимости, мы не можем отвергнуть нулевую гипотезу о том, что A и B не отличаются друг от друга.

A/B-тестирование может дать следующие результаты:

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

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

• Версия B выигрывает. A/B-тест подтвердил вашу гипотезу о лучшей производительности версии B по сравнению с версией A. Отлично! Опубликовав результаты, вы можете провести эксперимент на всей аудитории и получить новые результаты.

Заключение

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

Словарь тестировщика | BYTEX BLOG

Андерклокинг — снижение частоты работы оборудования.

Баг (дефект) — недостаток компонента или системы, который может привести к отказу определенной функциональности.

Приоритет багов — важность той или иной ошибки в ПО:

• Trivial — косметическая малозаметная проблема.
• Minor — очевидная, незначительная проблема.
• Major — значительная проблема.
• Critical — проблема, нарушающая работу c ключевыми функциями ПО.
• Blocker — проблема, нарушающая функционирование ПО.

Баг-репорт — документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Валидация — определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.

Верификация — процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа.

Спецификация — детальное описание того, как должно работать ПО.

Система отслеживания ошибок (англ. bug tracking system) — программа учета и/или контроля багов:

• Atlassian JIRA
• Bugzilla
• YouTrack
• Redmine
• etc.

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

Обеспечение качества (Quality Assurance, QA) — совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения

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

Ошибка (англ.Error) – действие, которое порождает неправильный результат.

Сбой (англ.Failure) – несоответствие фактического результата работы компонента или системы ожидаемому результату.

Классификация по типу тестирования:
Мобильное тестирование — тестирование мобильных приложений.
Консольное тестирование — тестирование приложений предназначенных для консолей.
Web-тестирование (Браузерное тестирование) — тестирование браузерных приложений.

Классификация по запуску кода на исполнение:
Статическое тестирование (англ.Static testing) — тестирование без запуска кода на исполнение.
Динамическое тестирование (англ. Dynamic testing) — тестирование с запуском кода на исполнение.

Классификация по доступу к коду и архитектуре ПО:
Черный ящик (англ. Black box) — тестировщику не известно как устроена тестируемая система.
Белый ящик (англ. White box) — тестировщику известно все детали реализации тестируемой системы.
Серый ящик (англ. Grey box) — тестировщику известно только некоторые особенности устройства тестируемой системы.

Классификация по степени автоматизации:
Ручное тестирование (англ. Manual testing) — тестирование ПО будучи его пользователем.
Автоматизированное тестирование (англ. Automated testing) — тестирование ПО при помощи специальных программ.

Классификация по принципу работы с приложением:
Позитивное тестирование (англ. Positive testing) — тестирование ПО на то, как оно должно работать.
Негативное тестирование (англ. Negative testing) — тестирование ПО на то, как оно не должно работать.

Классификация по уровню детализации приложения:
Интеграционное тестирование — тестирование взаимодействия и связей нескольких компонентов приложения.
Системное тестирование — это тестирование всего приложения от начала и до конца.
Модульное тестирование — тестирование на уровне отдельного функционального компонента приложения.

Классификация по целям и задачам:
Функциональное тестирование — проверка корректности работы функциональности приложения.
Нефункциональное тестирование — проверка нефункциональных особенностей приложения (удобство использования, совместимость, производительность, безопасность).
Инсталляционное тестирование — проверка протекания стадии инсталляции (установки) приложения.
Регрессионное тестирование — проверка на наличие багов, вызванных изменениями в приложении.
Повторное тестирование — выполнение тест-кейсов, которые ранее обнаружили дефекты, с целью подтверждения устранения дефектов.
Приёмочное тестирование — тестирование, направленное на проверку приложения с точки зрения конечного пользователя/заказчика
Тестирование удобства использования — тестирование, направленное на исследование того, насколько конечному пользователю понятно, как работать с продуктом, а также на то, насколько ему нравится использовать продукт.
Тестирование доступности — тестирование, направленное на исследование пригодности продукта к использованию людьми с ограниченными возможностями
Тестирование интерфейса — тестирование, направленное на проверку интерфейсов приложения или его компонентов.
Тестирование безопасности — тестирование, направленное на проверку способности приложения противостоять злонамеренным попыткам получения доступа к данным или функциям
Тестирование интернационализации — тестирование, направленное на проверку готовности продукта к работе с использованием различных языков и с учётом различных национальных и культурных особенностей.
Тестирование локализации — тестирование, направленное на проверку корректности и качества адаптации продукта к использованию на том или ином языке с учётом национальных и культурных особенностей.
Тестирование совместимости — тестирование, направленное на проверку способности приложения работать в указанном окружении (браузер, мобильное ус-во и т.д.).
Тестирование данных и баз данных — тестирование, направленное на исследование таких характеристик данных, как полнота, непротиворечивость, целостность, структурированность и т.д.
Тестирование использования ресурсов — совокупность видов тестирования, проверяющих эффективность использования приложением доступных ему ресурсов и зависимость результатов работы приложения от количества доступных ему ресурсов.
Сравнительное тестирование — тестирование, направленное на сравнительный анализ преимуществ и недостатков разрабатываемого продукта по отношению к его основным конкурентам.
Демонстрационное тестирование — формальный процесс демонстрации заказчику продукта с целью подтверждения, что продукт соответствует всем заявленным требованиям.
Избыточное тестирование — тестирование приложения со всеми возможными комбинациями всех возможных входных данных во всех возможных условиях выполнения.
Тестирование надёжности — тестирование способности приложения выполнять свои функции в заданных условиях.
Тестирование восстанавливаемости — тестирование способности приложения восстанавливать свои функции и заданный уровень производительности, а также восстанавливать данные в случае возникновения критической ситуации.
Тестирование отказоустойчивости — тестирование, заключающееся в эмуляции или реальном создании критических ситуаций с целью проверки способности приложения задействовать механизмы, предотвращающие нарушение работоспособности, производительности и повреждения данных.
Тестирование производительности — исследование показателей скорости реакции приложения на внешние воздействия при различной по характеру и интенсивности нагрузке.
Нагрузочное тестирование — исследование способности приложения сохранять заданные показатели качества при нагрузке в допустимых пределах и некотором превышении этих пределов/
Тестирование масштабируемости — исследование способности приложения увеличивать показатели производительности в соответствии с увеличением количества доступных приложению ресурсов.
Объёмное тестирование — исследование производительности приложения при обработке различных (как правило, больших) объёмов данных.
Стрессовое тестирование — исследование поведения приложения при нештатных изменениях нагрузки, значительно превышающих расчётный уровень.
Конкурентное тестирование — исследование поведения приложения в ситуации, когда ему приходится обрабатывать большое количество одновременно поступающих запросов, что вызывает конкуренцию между запросами за ресурсы (базу данных, память, канал передачи данных, дисковую подсистему и т.д.)
Фокус-тест (англ. Focus test) — тестирование, проводимое с целью получения первичной реакции игроков. Необходимо для оценки удобства использования и того, как продукт принимается целевой аудиторией или сторонними людьми.

Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы.

UX (англ. User eXperience — опыт пользователя) — ощущение, испытываемое пользователем во время использования цифрового продукта.

UI (англ. User Interface — пользовательский интерфейс) — это инструмент, позволяющий осуществлять взаимодействие «пользователь — приложение».

Анализ граничных значений (англ. Boundary Value Analysis — BVA). Анализ граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

Дымовое тестирование (англ. Smoke test) — короткий цикл тестов для подтверждения, что после сборки кода (нового или исправленного) приложение стартует и выполняет основные функции.

Исследовательское (ad-hoc) тестирование — это разработка и выполнения тестов в одно и то же время, что является противоположностью сценарного подхода.

Конфигурационное тестирование (англ. Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)

Матрица соответствия требований (англ. Traceability matrix) — это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases).

Операционное тестирование (англ. Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес модели системы.

Предугадывание ошибки (англ. Error Guessing — EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

Причина / Следствие (англ. Cause/Effect — CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие).

Санитарное тестирование — это узконаправленное тестирование достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям.

Серьезность (англ. Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения.

Стадии разработки ПО — это этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широко круга пользователей.

Пре-альфа (англ. Pre-alpha) — начальная стадия разработки. Период времени со старта разработки до выхода стадии Альфа. Также так называются программы, прошедшие стадию разработки, для первичной оценки функциональных возможностей в действии.

Альфа-тестирование (англ. Alpha testing) — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования.

Бета-тестирование (англ. Beta testing) — интенсивное использование почти готовой версии продукта с целью выявления максимального числа ошибок в его работе для их последующего устранения перед окончательным выходом (релизом) продукта на рынок, к массовому потребителю.

Релиз-кандидат или RC (англ. Release candidate), Пре-релиз, иногда «гамма-версия» — стадия-кандидат на то, чтобы стать стабильной.

Релиз или RTM (англ. Release to manufacturing — промышленное издание) — издание продукта, готового к тиражированию.

Пост-релиз или Post-RTM (англ. Post-release to manufacturing) — издание продукта, у которого есть несколько отличий от RTM и помечается как самая первая стадия разработки следующего продукта.

Таблица принятия решений (англ. Decision table) — инструмент для упорядочения сложных бизнес требований, которые должны быть реализованы в продукте.

Тест-дизайн (англ. Test design) — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы).

Тест-план (англ. Test Plan) — это документ, описывающий весь объем работ по тестированию, а также оценки рисков с вариантами их разрешения.

Тестирование взаимодействия (англ. Interoperability Testing) — это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами.

Тестирование сборки (англ. Build Verification Test) — тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования.

Тестирование пользовательского интерфейса (англ. UI Testing) — тестирование, выполняемое с целью определения, удобен ли некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения.

Тестовый случай (англ. Test Case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Чек-лист (англ. Check list) — это документ, описывающий что должно быть протестировано.

Эквивалентное Разделение (англ. Equivalence Partitioning — EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0.

Z-конфликт (англ. Z-fighting) — наложение текстур друг на друга.

Оверклокинг (англ. Overclocking) — процесс увеличения частоты (и напряжения) компонента компьютера сверх штатных режимов с целью увеличения скорости его работы.

A/B тест — это просто / Habr

A/B тестирование — это мощный маркетинговый инструмент для повышения эффективности работы вашего интернет-ресурса. С помощью A/B тестов повышают конверсию посадочных страниц, подбирают оптимальные заголовки объявлений в рекламных сетях, улучшают качество поиска.

Мне часто приходится сталкиваться с задачами организации A/B тестирования в различных интернет-проектах. В этой статье хочу поделиться необходимыми базовыми знаниями для проведения тестов и анализа результатов.

Зачем нужны А/B тесты?

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

Наше решение — это интуитивное предположение о том, что пользователям ресурса станет проще подписываться на новые материалы, мы ожидаем повышения числа подписчиков.

Наши предположения и гипотезы строятся на основе личного опыта и наших взглядов, которые совсем не обязательно совпадают со взглядами аудитории нашего ресурса. Другими словами, наше предположение вовсе не означает, что после внесения изменений мы получим желаемый эффект. Для проверки таких гипотез мы и проводим A/B тесты.

Как проводим тесты?

Идея A/B тестирования очень проста. Пользователи ресурса случайным образом делятся на сегменты. Один из сегментов остается без изменений — это контрольный сегмент “A”, на основе данных по этому сегменту мы будем оценивать эффект от вносимых изменений. Пользователям из сегмента “B” показываем измененную версию ресурса.

Чтобы получить статистически значимый результат, очень важно исключить влияние сегментов друг на друга, т.е. пользователь должен быть отнесен строго к одному сегменту. Это можно сделать, например, записав метку сегмента в cookies браузера.

Для снижения влияния внешних факторов, таких как рекламные кампании, день недели, погода или сезонность, замеры в сегментах важно делать параллельно, т.е. в один и тот же период времени.

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

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

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

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

Что улучшаем?

Если вы собираетесь провести A/B тестирование на своем ресурсе, то наверняка у вашего проекта уже сформированы основные показатели, которые необходимо улучшить. Если таких показателей еще нет, тогда самое время о них задуматься.

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

Конверсия

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

Экономические метрики

Как правило, эти метрики применимы для интернет-магазинов: величина среднего чека, объем выручки, отнесенный на число посетителей интернет-магазина.

Поведенческие факторы

К поведенческим факторам относят оценку заинтересованности посетителей в ресурсе. Ключевыми метриками являются: глубина просмотра страниц — число просмотренных страниц, отнесенное к числу посетителей на сайте, средняя продолжительность сессии, показатель отказов — доля пользователей, покинувших сайт сразу после первого захода, коэффициент удержания (можно считать, как 1 минус % новых пользователей).

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

Анализ результатов

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

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

Эффект от внесения изменения определяют как разность между средними значениями ключевого показателя в сегментах. Тут возникает следующий вопрос, насколько мы уверены в достоверности полученного результата? Если мы еще раз проведем тест, то какова вероятность того, что мы сможем повторить результат?

Ниже на картинках приведены примеры распределения значений показателя в сегментах.

Графики распределения характеризуют частоту появления того или иного значения случайной величины в выборке. В данном случае все значения распределены вокруг среднего.

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

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

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

Как правило, для принятия положительного решения об эффективности изменений уровень значимости выбирают равным 90%, 95% или 99%. Пересечение распределений при этом равно соответственно 10%, 5% или 1%. При невысоком уровне значимости существует опасность сделать

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

Несмотря на важность этой характеристики, в отчетах по A/B тестам, к сожалению, часто забывают указать уровень значимости, при котором был получен результат.

Кстати, на практике примерно 8 из 10 A/B тестов не являются статистически значимыми.

Стоит отметить, что чем больше объем трафика в сегментах, тем меньше разброс среднесуточных значений показателя. При небольшом трафике из-за большего разброса значений случайной величины потребуется больше времени для проведения эксперимента, но в любом случае это лучше, чем вовсе не проводить эксперимент.

Оценить значимость результатов

Для сравнения случайных величин математики придумали целый раздел под названием проверка статистических гипотез. Гипотез всего две: “нулевая” и “альтернативная”. Нулевая гипотеза предполагает, что разница между средними значениями показателя в сегментах незначительна. Альтернативная гипотеза предполагает наличие существенной разницы между средними значениями показателя в сегментах.

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

В качестве примера приведу сравнение средней длительности сессии в сегментах на одном из ресурсов, для которых я проводил эксперимент: studentttest.xls.

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

В случае, если вы измеряете только конверсию, то вы имеете дело с бинарной слуайной величиной, которая принимает только два значения: посетитель “сконвертировался” и “не сконвертировался”. Для оценки статистической значимости в этом случае можно воспользоваться он-лайн калькулятором.

Инструменты

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

Если ваши ресурсы позволяют, то такой инструмент можно реализовать самостоятельно на основе анализа логов действий пользователей. Если ресурсы ограничены, то стоит воспользоваться сторонним инструментом. Например, в Google Analytics есть возможность задавать пользовательские сегменты.

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

А дальше?

В статье приведены базовые знания, необходимые для проведения A/B тестов и анализа результатов. Следующий шаг — это продуктовая аналитика. В завершении хочу поделиться ссылкой на отличную презентацию по продуктовой аналитике с примерами A/B тестирования от Курышева Евгения.

Образ современного тестировщика. Что нужно знать и уметь / FunCorp corporate blog / Habr

Бытует мнение, что простейший путь к IT лежит через тестирование. Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щуриться от боли и слёз, когда тебе прилетает очередной набор тест-кейсов для регрессионного тестирования.

Отчасти это даже правда, но, скорее, для ситуации, которая была на рынке лет 10 назад. Сейчас же всё обстоит несколько иначе. Причин для этого масса, и они самые разные. Если отметить ключевые, то, пожалуй, это:

Возросшие требования к тестировщикам, их знаниям и квалификации, так как всё чаще решаются задачи чуть сложнее, чем «клик-клик — и в продакшен». Работа тестировщиков становится всё более «инженерной», требует технической подкованности, специфических знаний, навыков и компетенций. Тестировщики всё чаще становится QA-инженерами (кто в теме, тот понимает разницу).

Возросшее предложение на рынке, когда толпы вчерашних «гражданских» ринулись в пучину IT, подогреваемые обилием информации: от конференций и книг до статей и курсов по тестированию ПО. Ваш покорный слуга в своё время также приложил руку к созданию пары общедоступных курсов по причине желания тиражировать базовые вещи из своей профессиональной области (посмотреть можно здесь и здесь).

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

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

Что учить самим или чему учить своих бойцов?

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

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

Материал для этой статьи базируется на собственном опыте работы с блестящими специалистами моих команд, на результатах преподавания в МГУ, МГТУ и онлайн-курса, а также на сотнях проведённых собеседований и десятках нанятых QA-специалистов разных профилей. Не претендую на исключительную правоту своего взгляда, однако считаю, что мой опыт позволяет моей точке зрения быть достаточно компетентной.

Черты характера

Было бы странно полагать, что с возросшими требованиями к техническим аспектам работы тестировщиков значимость личностных качеств уменьшилась или исчезла вовсе. Более того, я уверен, что черты характера лежат в основе успешного специалиста и имеют решающее значение при схожих знаниях и навыках. Ведь мы работаем не с human-интерфейсами к Stack Overflow и Википедии, а с живыми людьми, которые остаются таковыми и в офисе, и дома. Поэтому так важно учитывать качества личности в контексте предстоящего выбора отрасли, профессии и специальности в ней.

Почему я так считаю? Всё очень просто! Я легко могу отправить специалиста на курсы или конференцию, заказать книги или провести тренинги по нюансам тест-дизайна, языкам программирования, SQL, сетям и прочим техническим аспектам, чтобы через некоторое время получить первые результаты и в дальнейшем приумножать их, закрепляя полученную информацию на практике. Однако нельзя отправить на курс «Как перестать бегать за офисными плюшками и начать инвестировать в собственные знания», «Как перестать быть безответственным вруном и начать жить честно», «Как перестать быть серой мышью и стать увлечёным человеком», «Как перестать ненавидеть людей и научиться работать в команде» и рассчитывать на ощутимый результат после прослушивания. Увы, это правда жизни, внутреннее несогласие с которой позволяет широкому пласту «инфобизнесменов» зарабатывать на непокорных, жаждущих изменить свои фундаментальные столпы и черты характера единичным тренингом или серий онлайн-вебинаров. Именно поэтому так важно обладать на старте правильной жизненной мотивацией и качествами для работы в IT и в QA в частности. Итак, что же важно?

Мотивация учиться и склонность к самообучению

Честно ответьте себе на вопрос: нравится ли вам учиться? Не разово, а на постоянной основе. Готовы к единственному прыжку, который волшебным образом выведет вас «в дамки», или страстно желаете ежечасно и ежеминутно впитывать в себя новые знания? IT — это сфера, где достаточно неудачно моргнуть, и вы уже на обочине индустрии. Не стоит рассчитывать, что прочитав за год книгу по тестированию, вы раскроете для себя врата в дивный мир новых знаний, которые позволят вам быть в тренде на десятилетие вперёд. Идеально, если для учёбы вам не всегда нужен мудрый наставник и учитель и вы в состоянии самостоятельно усадить себя за новую книгу, вебинар или курсы.

Ответственность

Оцените свой уровень ответственности. Простой способ: озвучьте для начала сами себе несколько своих самых крупных ошибок в жизни. Не получается? Речь не о вашей безупречности, вспомните, что не ошибается только тот, кто ничего не делает. Вспомнили? Если только пару мелочей, то это грустный показатель. Хуже только, если вспомнив ошибки прошлого, вы тут же внутренне обвинили в них кого-то другого или обстоятельства, а не признали свою ответственность за произошедшее. А вот если вы вспомнили парочку крупных фейлов, где виноваты были именно вы, да ещё и вспомнили как их исправили, то дела с вашей ответственностью обстоят сильно лучше. Вышка — это когда вы не только исправили ошибку, но и застраховались от неё на будущее так, чтобы она не повторялась. Ответственный подход к работе — залог успешной карьеры в любой области, а потому и для тестировщика это крайне важная черта. Главное — не перегибать и знать меру, ведь гиперответственность — не всегда хорошо.

Увлечённость

Вы увлечённый человек? Вот честно, чем вы увлекаетесь? Ничем особенным? Или это много мелких хобби, которыми вы занимаетесь раз в год? Может, что-то большое, но времени постоянно не хватает, а потому хобби ждёт лучших времен. Человек остаётся человеком и в офисе, и когда выходит из него. И если человек действительно увлечён чем-то в обычной жизни, значит, и в работе его можно чем-то увлечь настолько, что он будет засиживаться вечерами или изучать вопрос на выходных по собственной инициативе. Задача грамотного руководителя и самого специалиста — найти такие задачи. Конечно, важно при этом доводить начатое до логического завершения и не бросать на полпути. Тестировщик не может быть «сухарём». А вот если он горит своей работой и продуктом, то результативность такого сотрудника будет выше.

Гибкость поведения

Важная черта для работы в современных IT-компаниях и в QA в частности — это гибкость. Новые знания и веяния приходят со скоростью ветров Юпитера, устоять в стиле Гендальфа Серого «Ты не пройдёшь!» перед индустрией крайне сложно и не всегда целесообразно. А потому довольно важно уметь подстраиваться под новые условия работы, будь то генеральная линия компании, новые продукты, команда, методологии работы или инструменты. Чем гибче сотрудник, тем больше шансов у него карьерно развиваться в IT.

Коммуникабельность и контактность

Без сомнений, можно быть успешным специалистом, будучи довольно замкнутым, но при этом глубоко погружённым в свою задачу, однако научиться чему-то новому и обучить окружающих больше шансов у общительного и контактного человека. Необязательно каждому быть великим оратором и публично выступать на мероприятиях, но важно уметь находить общий язык с коллегами, грамотно изъяснять свои мысли устно и письменно. В работе тестировщика это довольно важные черты, ведь общаться нужно много и часто, и чем больше вы про QA, тем глубже и детальнее вы погружаетесь в смежные сферы, где умение выстроить коммуникацию — половина успеха.

Командность

Тестировщику необходимо быть командным игроком. Неважно, работаете вы в сервисной модели тестирования или тестировщики интегрируются внутрь каждой команды. Очень важно, чтобы вы давали «чувство плеча» своей команде, чтобы они могли положиться на вас, а вы на них. Один в поле не воин — для тестировщиков это ещё и история про дальнейший рост в карьере. Ведь именно команда, как ваше ближайшее окружение, является первостепенным источником знаний, которые вы будете получать о продукте, процессах и технологиях. Если вы командный игрок, то в тестировании вы добьётесь бóльших успехов, чем одиночка.

Инициативность и решительность

Как известно, под лежачий камень вода не течёт, а потому инертность выйдет вам боком и в профессии тестировщика. Хороший тестировщик — проактивный, не ждёт пинка от коллег и руководителя, а сам приходит с новыми решениями и предложениями. Если тестировщику один раз сказали «это не баг, а фича», то он не должен опускать руки. Вместо этого надо брать инициативу и излагать свою точку зрения. Безусловно, не стоит впадать в крайности и спорить по любому поводу, но и соглашаться со всем, что скажут, не стоит. В основе работы хорошего тестировщика не только критическое мышление, подвергающее проверке на прочность окружающий мир, но и умение в нужный момент сформировать собственную позицию и отстоять её перед окружающими.

Этот список можно ещё продолжать и дополнять, я выделил ключевые черты на основе собственного опыта. Безусловно, речь не идёт о том, что если у вас нет этих качеств, то вы профнепригодны. Но можно с уверенностью утверждать, что чем меньше из заявленных качеств будет в вас, тем будет сложнее и вам самим, и вашей команде, и вашему руководителю. Любые исключения допускаются, что лишь подтверждает правило.

Основы тестирования

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

Классификация видов тестирования

Даже начинающий тестировщик должен иметь базовые представления о различных видах тестирования, когда они используются и для чего. Это сухая теория, которая сама по себе не нужна, но без неё «класть поверх» практику может быть мучительно больно и долго, а попутно ещё и велосипедов выдумаете, да граблей известных соберёте. Не ленитесь, ознакомьтесь, благо источников уйма. Зато потом с лёгкостью сможете на собеседованиях проходить задачки уровня «протестируйте карандаш».

Локализация ошибок и багрепортинг

Мало ошибку найти. Крайне важно ошибку нужным образом локализовать, установив как можно больше обстоятельств и условий для её стабильного воспроизведения. Более того, необходимо обрести навык составления качественных баг-репортов. На своих лекциях и при работе с командой я часто использую следующее сравнение: «Ваш баг-репорт хороший в том случае, если вы вышли на улицу, взяли за руку первую попавшуюся бабушку, и она смогла воспроизвести дефект по вашему описанию или верифицировать его отсутствие».

Техники тест-дизайна

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

Системы баг-трекинга, управления знаниями и тестами

Канули в небытие те времена, когда баг-репорты писали на листах, а тестовую документацию, чек-листы и тест-кейсы вели в гугл-доках (да-да, я знаю, что некоторые до сих пор пишут, и иногда это даже удобно). На смену этому самопалу пришли профессиональные инструменты — баг-трекинговые системы (из наиболее популярных стоит отметить Jira, Redmine), системы управления знаниями (Confluence, Wiki и другие) и системы управления тест-кейсами (TestRail, Zephyr, TestLink и т.д.). Базовые принципы работы с инструментами можно получить, вписываясь в открытые программы бета-тестирования или установив софт самостоятельно (на рынке есть как бесплатные решения, так и условно-бесплатные в масштабе ознакомительных сессий).

Методологии разработки ПО

Глубокого понимания методологий разработки ПО на начальных этапах тестировщику, может, и не потребуется, важно хотя бы на пальцах понимать отличия наиболее популярных (Waterfall, Scrum и Kanban). Но со временем ему придётся погружаться всё глубже и глубже в методологии, подбирая соответствующие подходы и техники при тестировании в контексте того или иного процесса разработки. Важно быть готовым к такому и уделять определённое внимание этой стороне вопроса.

Клиент-серверная архитектура

Большинство современного ПО строится на китах клиент-серверного взаимодействия. Тестировщику важно быть в контексте этой архитектуры, понимать принципы её работы, основные преимущества и недостатки. Это позволит не только лучше проводить испытания в ходе своей работы, но и при необходимости понимать, каким образом найденные дефекты нужно локализовывать, правильно определяя, на чьей они стороне.

Операционные системы

Принципы работы операционных систем, что они из себя представляют и какие вообще бывают — общие знания, которые, как правило, упрощают жизнь тестировщика. Даже понимание трендов замещения десктопных ОС мобильными, а также владение навыками работы с ОС на уровне пользователя уже плюс. А если погружаться в этот вопрос глубже, то со временем необходимо будет обзавестись навыками настройки и использования целой плеяды ОС (из самых популярных стоит отметить Android, Windows, iOS, macOS, Linux).

Клиентское тестирование веб-приложений

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

Браузеры

В контексте клиентского тестирования веба важно понимать устройство тонких клиентов, браузеров в частности, а также их отличия, специфику рендеринга и работы скриптов, движков под капотом, версионности, дополнительного инструментария браузеров и т.д. Тестировщику важно всегда держать в голове популярность использования того или иного браузера у реальных пользователей продукта, чтобы распределять тесты наиболее эффективным способом. Самые популярные: Google Chrome, Safari, Firefox, Opera, Internet Explorer.

Консоль разработчика в браузере

Веб-тестировщик должен уметь пользоваться консолью разработчика в браузере (как минимум работать с элементами на странице и сетевыми запросами). В случае работы с элементами страницы тестировщик должен понимать, как локализовать их или при необходимости изменить, а в случае с сетевым взаимодействием — уметь разбираться в последовательности запросов и полученных ответов. В идеале нужно знать различные http-методы (GET, POST, OPTIONS и другие), знать коды ответов (10Х-50Х), уметь читать заголовки и тела ответов.

HTML, CSS, JavaScript

Чтобы тестировщик лучше понимал, из чего состоят и как устроены современные веб-страницы, будет крайне полезно иметь хотя бы базовое представление о HTML, CSS, JavaScript. Эти знания также помогут локализовывать ошибки, связанные с конкретными элементами на странице, быстро находить их и при необходимости менять на клиентской стороне.

Бэкенд-тестирование

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

Модель OSI

Базис, с которого стоит начинать бэкенд-тестировщику, — это модель OSI. Несмотря на то, что в большинстве случаев тестировщику вряд ли пригодятся уровни ниже прикладного и представительского, будет неплохо, если он будет понимать, где находятся эти уровни относительно других, в чём их специфика и как они применяются.

REST. SOAP. JSON-RPC

REST, как архитектурный стиль клиент-серверного взаимодействия, лежит в основе современного интернета. Понимание требований к REST-архитектуре должно быть в арсенале знаний бэкенд-тестировщиков, равно как и знания о стандартах, используемых в нём (HTTP, JSON, XML). В отдельно взятых направлениях не менее важным может оказаться знание протоколов SOAP (а вместе с ним XML, XSD, WSDL) и JSON/XML-RPC, их возможностей и ограничений.

Командная строка

Без навыков владения командной строкой бэкенд-тестировщик не сможет обойтись в большинстве случаев. На начальном этапе достаточно будет базовых вещей в духе работы с папками и файлами, их создания, чтения, перемещения и т.п. Эти знания позволят тестировщику, например, работать с серверными логами для локализации дефектов. А со временем вы уже не сможете обходиться и без bash-скриптов, работы с файловыми дескрипторами, конвейерами и регулярками.

cURL. Postman. SoapUI

Для тестирования REST API на стартовом уровне отлично подойдёт утилита командной строки cURL, которая позволит тестировщику отправлять тестовые запросы и получать ответы, разбирать их и сравнивать фактический результат с ожидаемым. Более продвинутым и одновременно более казуальным (за счёт наличия GUI) инструментом тестирования API является Postman, навыки использования которого также весьма полезны. А если нужно тестировать SOAP API, то идеально подойдёт инструмент SoapUI (на самом деле с ним можно тестировать и REST API).

Базы данных

Тестировщику важно знать и уметь работать с СУБД, в первую очередь с SQL (MariaDB, MySQL, PostgreSQL, MS SQL). И наиболее востребованным является знание SQL. Очень часто в описании вакансий есть упоминания про этот навык, который звучит как «Знание SQL на уровне простых запросов». Как правило, для начала достаточно знать базовые вещи уровня INSERT, SELECT, DELETE, UPDATE, WHERE, ORDER BY, в некоторых случаях нужны JOIN, INNER JOIN, RIGHT JOIN, LEFT JOIN. Кроме того, несомненным плюсом будут знания и навыки работы с NoSQL БД (MongoDB, Cassandra). Они позволят тестировщику сверять ожидаемые и фактические результаты в ходе выполнения тестов при работы с данными.

Клиентское тестирование мобильных-приложений

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

IDE

Для тестировщика мобильных приложений важно освоить на базовом уровне среду разработки (XCode для iOS, Android Studio для Android). Знания этих инструментов позволяют осуществлять локальные сборки приложений, при необходимости и с помощью разработчиков конфигурировать их под нужды тестирования, лучше локализовывать баги, читая клиентские логи, и даже работать с исходниками приложения. Кроме того, в IDE есть возможность запуска приложения через эмулятор, что может пригодиться тестировщику.

Инструменты мониторинга HTTP/HTTPS-трафика

Тестировщик обязан понимать клиент-серверную архитектуру и уметь локализовывать ошибки с её учётом. И если в тестировании веб-приложений для этого обычно хватает консоли разработчика, то для мобильных приложений нужно использовать специализированное ПО (Charles, Fiddler, Wireshark), которое позволит перехватывать и анализировать сетевые запросы. Т.е. с помощью этих инструментов в большинстве случаев можно довольно точно определить, на чьей стороне проблема. Более того, они позволяют подменять запросы, эмулируя то или иное поведение ПО (как со стороны клиента, так и со стороны сервера). Это нужно не только для локализации проблем, но и для проведения ряда испытаний в рамках тестирования приложения.

Сервисы дистрибуции мобильных приложений

Для тестирования разных версий приложений необходимо иметь базовые навыки работы с сервисами дистрибуции мобильных приложений, например, Fabric (Crashlytics), HockeyApp, TestFlight. Они позволяют не только получить нужные сборки для тестов, но и анализировать статистику использования, а также работать с падениями приложений, локализуя проблемы и выясняя их причины.

Автоматизация тестирования

Я не стал разграничивать автоматизацию тестирования по направлениям, выделив её в отдельную специализацию. Безусловно, есть ряд принципиальных различий между автоматизаторами тестирования веба, бэкенда и мобильных приложений, но в этом разделе мне хотелось бы консолидировать наиболее важные знания и навыки, которые востребованы инженерами по автоматизации тестирования вне зависимости от их специальности. Стоит отметить, что автоматизация тестирования сама по себе довольно сложна не только с технической точки зрения, но и с точки зрения практик тестирования. А потому настоятельно рекомендую смотреть в эту сторону, предварительно освоив не только общие моменты, но и одно из направлений, перечисленных выше. Если вы научитесь тестировать руками, вам будет проще и понятнее заниматься автоматизацией.

Язык программирования

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

Первый:

сложность обучения языкам — штука довольно относительная, ведь кому-то проще даётся модный стильно-молодёжный Python с динамической типизацией, а кому-то легче с жёстко типизированной и структурированной Java со статической типизацией. Важно попробовать и понять, твоё это или нет.

Второй:

ориентируйтесь на сообщество, у которого вы сможете обучиться языку. Это в равной степени может быть как внешнее комьюнити (форумы, курсы, тренинги и т.п.), так и внутреннее (коллеги по цеху тестирования или даже разработчики). Однако стоит помнить, что равняться исключительно на коммьюнити не стоит, особенно если речь идёт о разработчиках. Безусловно, они эксперты в области своего языка, но не стройте радужных иллюзий, что они начнут помогать вам писать функциональные автотесты на регулярной основе (это очень редкий кейс), да и в специфике тестирования они далеко не всегда могут быть столь же компетентными.

Третий:

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

На основе опыта последних лет самыми популярными языками в контексте тестирования я бы назвал Python, Java, PHP, а в мире мобильной разработки — нативные языки Kotlin, Objective-C и Swift.

Тестовые фреймворки

Дабы тестировщику не приходилось начинать автоматизацию с изобретения собственных велосипедов и чтобы, минимизировать встречу с граблями, автоматизаторы тестирования часто используют тестовые фреймворки (xUnit, nose, unittest, pytest, TestNG, Cucumber) в зависимости от языка, на котором пишут тесты. Важно освоить эти базовые фреймворки, чтобы сделать работу с тестами наиболее эффективной и удобной.

Драйверы и надстройки для автоматизации тестирования

Помимо тестового фреймворка специалисты по автоматизации тестирования должны использовать драйверы, которые позволяют взаимодействовать с приложением через программный интерфейс вместо графического. Без них не обойтись, если вы собираетесь автоматизировать клиентские приложения. Если вы собираетесь работать с вебом, то обязательно нужно изучить Selenium WebDriver, если с iOS — XCUITest, а для Android вам пригодятся Espresso и UI Automator (нативная поддержка от Google), вариативно — Robotium или Selendroid. Для пущего удобства используют надстройки, которые, с одной стороны, усложняют инструментарий специалиста по автоматизации, а с другой — дают дополнительные возможности. Особое внимание рекомендую тут уделить Appium и Cucumber.

Системы отчётности результатов автотестов

Какие бы автотесты вы ни писали, по завершению было бы неплохо иметь возможность получить отчёт о проведённом тестировании, да такой, чтобы не мельтешило в глазах от строчек текста. Наиболее популярной сейчас, пожалуй, можно назвать разработку отечественных коллег — Allure. Инструмент всё чаще используется для удобной визуализации результатов выполненных автотестов, в нём есть возможность группировки тестов по компонентам вашего приложения или задачам, в контексте реализации которых проводятся испытания.

Системы контроля версий

После того как вы напишете свой первый автотест, вам непременно захочется писать ещё и ещё, а затем модифицировать, ускоряя работу, расширяя логику, углубляя проверки, а потом и поделиться результатами с коллегами. Хранить каждую из версий ваших тестов локально, раскладывая по различным папкам, архаично, трудоёмко и неудобно. Поэтому логично перенимать лучшие практики от программистов и научиться пользоваться системами контроля версий. Из наиболее популярных стоит отметить Git, SVN, Mercurial, TFS. Замечу, что Git доминирует на рынке и при прочих равных стоит использовать именно его. На начальном этапе тестировщику потребуется знание того, что такое commit, push, pull (force), fetch, checkout, branch, merge, rebase, revert.

Системы непрерывной интеграции

Запустив свой первый автотест, вам непременно захочется делать это ещё и ещё, а со временем даже поделиться с кем-то этой возможностью. И тут на помощь придут инструменты непрерывной интеграции, такие как Jenkins, TeamCity, Bamboo. Скорее всего, у коллег-разработчиков есть свой CI-инструмент для сборки проектов, возможно, даже и для запуска unit-тестов. Чтобы примкнуть к ним со своими функциональными автотестами будет здорово, если вы будете понимать принципы работы этих инструментов. А если ничего подобного у коллег ещё нет, тогда вы будете первопроходцем и сможете делать удобные параметризированные запуски своих автотестов (на разных хостах, с разными данными и т.д.) по факту изменений, запросу или по расписанию.

Возврат инвестиций от автоматизации тестирования

Последним, но не наименее важным, является знание методики подсчёта возврата инвестиций от автоматизации тестирования. Речь идёт хотя бы о приближённом представлении, какие тесты стоит автоматизировать и поддерживать, а какие лучше даже не пытаться. Если коротко, то отталкивайтесь от важности функционала и тест-кейса, который вы собираетесь автоматизировать, закладывайте трудозатраты и сложность разработки автотеста, а также потенциальную потребность, частоту и сложность его обслуживания и поддержки. Ведь одно дело, когда речь о ключевом нативном функционале, на который написаны все элементы фреймворка и прогнозируются минимальные трудозатраты на поддержку автотеста, и совсем другой разговор, когда речь идёт об автотесте на экспериментальную фичу, которую раскатили на 1% аудитории, фреймворк ещё не поддерживает этот функционал, который вдобавок интегрируется с нестабильными внешними сервисами, да ещё и переделывать егособираются ближайшие пару месяцев. Уметь определять, когда писать автотест, а когда нет — важный навык для специалиста по автоматизации тестирования.

Управление командой тестирования

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

Лидерство

Я глубоко убеждён, что лидерство — прирождённое качество, недаром Генри Форд говорил: «Спрашивать, кто должен быть боссом, всё равно что спрашивать, кто должен быть тенором в этом квартете». Тем не менее, можно научиться лидерству. Ведь есть и обратное мнение, что лидерами не рождаются, а становятся. Безусловно, лидерские качества, есть в каждом из нас. Другое дело, что для одних руководить и воодушевлять людей —это дар и мана небесная, а для других — кошмар и адовые муки. Сложно себе представить, что кто-то из читателей сознательно выберет путь развития в управленцы, зная, что это будет приносить дискомфорт и неприятности. Всё-таки с желанием быть лидером у управленца значительно больше шансов на успех.

Решительность

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

Формирование команды

Умение работать с командой, формировать её, направлять и развивать — важные качества руководителя. Группа людей — ещё не команда. Изначально у них могут быть разные цели и задачи. Пока они не объединены идеей, не мотивированы и не жаждут плечом к плечу преодолевать трудности, они не могут быть командой. Задача хорошего руководителя — сплотить людей, склеить их, подбирая задачи и выставляя цели, которые будут приводить к формированию настоящей команды. Для этого потребуется и умение подбирать новых людей, и находить подход к своим сотрудникам, а при необходимости и с кем-то попрощаться. Вам надо научиться работать с разными людьми, развивая свои способности находить общий язык с командой, формировать её и развивать для эффективной совместной деятельности.

Планирование

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

Навык убеждения и ведения переговоров

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

Позитивное мышление и умение мотивировать

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

Итого

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

Еще раз хочу напомнить о важности определённого характера для работы в IT и тестировании в частности. Помните, что на курсы по языкам программирования и СУБД можно отправить любого, а вот на курсы по тяге к саморазвитию и увлечённости, которые бы позволили бы успешно пройти первые курсы, увы, отправить никого не получится.

Надеюсь, что статья оказалась полезной для тех, кто её прочитал, будь то новичок или опытный специалист, ведь выбор профессиональных линий развития в области тестирования достаточно велик, чтобы в нём слегка потеряться. Напомню, что вся эта история — in my humble opinion, а потому не судите строго и не забрасывайте тапками. Буду благодарен за конструктивную обратную связь.

Всем качества!

с чего начать и куда смотреть / JUG Ru Group corporate blog / Habr

Вы наверняка знаете, что есть большая разница между тем, как будет работать ваше приложение/сервис в зависимости от того, сколько пользователей его используют. То, что работало во время разработки, может развалиться, когда придут первые реальные пользователи со своим окружением, а то, что работало с сотней пользователей, может умереть, когда их станет 10 тысяч. Или бывает, что вы все потестили на искусственных данных, а потом ваша база начинает торзмозить из-за пользователя с именем İnari.

О том, как выживают баги, когда «включать» в проекте нагрузочные тесты, откуда брать для них данные и можно ли вообще не тестировать, вывалив результаты сразу в продакшн, мы поговорили с Алексеем Лавренюком («Яндекс») и Владимиром Ситниковым (Netcracker).

Пару слов о себе и своей работе. Как ваша работа связана с тестированием?

Алексей Лавренюк: Я разработчик в «Яндексе», в службе нагрузочного тестирования. Делаю инструменты и сервисы для тестирования производительности. Можно посмотреть на наши open-source инструменты для нагрузочного тестирования – Yandex.Tank и Pandora, и на наш сервис для нагрузочного тестирования – Overload. Сейчас открыт бесплатный доступ к его бета-версии.

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

Владимир Ситников: Я уже 12 лет работаю в компании Netcracker. Сейчас я занимаю позицию инженера по производительности, т.е. я не тестирую продукты, но наблюдаю, как ведет себя система в реальной эксплуатации и в тестах. В сферу моей ответственности входит анализ того, как те или иные решения в сфере разработки и дизайна влияют на финальный результат. Поэтому я зачастую не просто смотрю на результаты тестирования, но и планирую его. В основном это относится к нагрузочному тестированию.

Когда-то я и сам занимался тестированием, но сейчас это осталось в прошлом.

— Давайте немного поговорим о теории. Корректно ли говорить, что проблемы на стадии тестирования появляются из-за разработчиков, не учитывающих какие-то параметры задачи или использующих неподходящее решение?

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

Нагрузочное тестирование — это не дубинка, которая бьет разработчиков по голове, когда они написали непроизводительный код. Это очень мощный измерительный прибор, по сути осциллограф для электронщика, позволяющий прощупать код и найти в нем узкие места. А потом после оптимизации увидеть (и продемонстрировать) результат в цифрах и графиках.

Владимир Ситников: Я бы хотел дополнить. «Откуда вообще возникают баги» — это вопрос тысячелетия. И он тесно связан с другим интересным вопросом — почему, несмотря на все тестирование, баги доживают до реальных систем и появляются только там. Почему в ходе тестирования мы их не находим? Неужели мы неправильно ставим задачу?

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

Половина всех проблем на продакшене — это сочетание 2-3 дурацких ошибок или допущений разработки: кто-то создал неправильный код, использовал дурацкий алгоритм и т.п. Каждая такая ошибка сама по себе не сказывается на производительности — современное железо довольно мощное, много чего переваривает. Но вместе две или три ошибки «выстреливают». А из-за разделения разработки и поддержки авторы этих ошибок о них и не узнают.

Редко когда по факту ищут авторов кода и говорят: «Пожалуйста, так больше не надо писать». Но чтобы гарантированно не совершать подобных ошибок в будущем, разработчику надо получить этот опыт. При поддержке своей собственной системы выводы из «набитых шишек» делались бы быстрее.

— Есть ли смысл в раннем нагрузочном тестировании (на этапе разработки)?

Алексей Лавренюк: Самые дорогие ошибки получаются тогда, когда нагрузочное тестирование притащили за уши на готовый проект (я уже не говорю о тех случаях, когда код тестируют в продакшене). Код написали, функционально он работает, но выясняется, что там, где требуется 10 ответов в секунду (всего-то), сервис может переварить только один, да и то со скрипом. Еще хуже, если в этом виноват фундамент – фреймворк, который выбрали, потому что «им все пользуются» или «ну он такой новый, прикольный». То есть придется переписывать вообще все.

Чем раньше отлавливаются проблемы, тем проще их решить.

— То есть начинаем разрабатывать и одновременно запускаем тестирование?

Владимир Ситников: И да, и нет.  Иногда на ранней стадии надо совсем грубо посмотреть, что происходит. Это может иметь смысл. Но, как правило, вначале код не работает. А замерять производительность кода, который, допустим, возвращает неправильный ответ, — гиблое дело. Мы тратим время, ресурсы (в том числе машинные), а результат — неизвестный.

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

Бывают случаи, когда заказчик приходит с определенными требованиями с самого начала, но чаще их приходится формулировать только на этапе «подключения» нагрузочного тестирования.

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

Здесь мне кажется уместной аналогия с обычным тестированием. Когда его надо включать? Отнюдь не в конце разработки. То, что в конце разработки придут тестировщики и все исправят, — это миф. Тестирование не исправляет, а ищет ошибки. И нагрузочное тестирование — это инструмент поиска ошибок определенного рода. Однако в отличие от обычного тестирования, проверяющего по сути только возможность прохождения программы по ветке алгоритма до определенной точки, нагрузочное представляет собой бета-тест продакшна, что ведет к отличиям в данных, нагрузке, соотношении тестов в миксе и т.п.

Чтобы успешно находить ошибки, надо иметь критерии поиска. Поэтому как процесс нагрузочное тестирование запускается ближе к началу разработки, а по факту оно проходит условно после первого цикла тестирования (автоматического или ручного), когда кто-то дает отмашку, что в целом система ведет себя правильно.

— Понятно, что абсолютно все не протестировать. Какие моменты необходимо тестировать в первую очередь (в ракурсе нагрузочного тестирования)?

Алексей Лавренюк: Тестировать в первую очередь надо критический сценарий — то есть тот, который приносит деньги. И провести как минимум два вида тестов: на разладку, чтобы определить пределы производительности, и на измерение таймингов, чтобы убедиться, что сервис укладывается в SLA. То есть сервис обязательно нужно «добить» и померить тайминги на том уровне нагрузки, который предполагается в продакшн.

— С чего необходимо начинать нагрузочное тестирование?

Алексей Лавренюк: Перед тем, как начинать нагрузочное тестирование, нужно убедиться, что перед этим провели функциональное и поправили все баги. Причем именно на вашем стенде. Удостоверьтесь, что в середине вашей стрельбы к вам на стенд никто не придет, чтобы скачать пару сотен гигабайт. В общем, подготовьте удобное тестовое окружение, в котором вам никто не будет мешать.

Владимир Ситников: Само тестирование стоит начинать с формулирования нефункциональных требований — т.е. требований по производительности и стабильности.

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

Понятие «нефункциональные требования» обширно. В разных проектах их составляющие могут иметь различный приоритет. Например, «система должна быть способна отработать 3 дня без перезагрузки» или «в случае пропадания и восстановления связи с базой данных приложение должно вернуться к нормальной работе не более чем за 2 минуты» — это тоже нефункциональные требования.

К слову, понятие «нефункциональные требования» формирует представление, что это нечто самостоятельное. Но по факту эти требования, описывающие, как должен работать функционал. Т.е. без нефункциональных требований и функциональные теряют смысл, равно как невозможно приложить NFR к любому случайно выбранному функциональному требованию.

— Существуют ли какие-то общие рекомендации по проведению нагрузочного тестирования?

Владимир Ситников: В целом нагрузочное тестирование похоже на обычное. Мы берем наиболее важные сценарии или те, за которые мы боимся больше всего. Поэтому кто-то с пониманием проекта должен прийти и указать на наиболее опасные сценарии. Дальше мы уже занимаемся автоматизацией и проводим замеры.

— Насколько большую роль играет интерпретация результатов нагрузочного тестирования?

Владимир Ситников: Огромную. Важны не цифры, а понимание, почему они именно такие. Если у нас получилось 42, это не значит, что результат — хороший. Заказчик просил, чтобы работало не дольше минуты, а у нас получилось полминуты. Мы молодцы, расходимся? Нет! Важно понимать, почему  мы не могли сделать быстрее, во что мы упираемся. А еще надо быть уверенным в том, что отчет — реален.

Был такой пример: мы замеряли, как влияет виртуальная машина на производительность приложения, т.е. сравнивали производительность приложения, работающего на железе, и приложения, работающего на виртуальной машине. Сделали замеры, получили хорошие цифры (близкие к ожидаемым) — расхождение в производительности в несколько десятых процента. На этом все могло закончиться. Но кто-то внимательнее посмотрел на результаты и понял, что у нас вместо запуска приложения возвращалась страница с ошибкой логина. В тестах мы не прошли по реальному приложению. Вместо этого под видом каждого из шагов мы проверили скорость логина, который на неправильном пароле выдал отказ.

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

Алексей Лавренюк: Очень часто люди недооценивают важность графиков, смотрят только на итоговые статистики. Если вы тоже так делаете, рекомендую погуглить «квартет Энскомба» и посмотреть вот эту статью от Autodesk.

Многие популярные в интернете нагрузочные инструменты, например ab, дают только итоговые статистики и ложную уверенность в работоспособности сервиса под нагрузкой. Они скрывают детали, провалы на графиках. Такой провал может стоить денег (покупатель ушел), а исправить его очень просто (поправить параметры garbage collector).

Кроме того, многие популярные и дорогие нагрузочные инструменты архитектурно устроены неправильно и лгут вам. Об этом написано в этой статье.

— Какие есть особенности нагрузочного тестирования веб-сервиса? По идее тестировать надо не только код, но и окружение, как это делается?

Алексей Лавренюк: Тестировать надо все, что вас интересует. Если вы подозреваете, что производительность приложения зависит от пробок в Москве, найдите способ это протестировать. Я не шучу, наши геосервисы запускают автоматически нагрузочные тесты на данных о пробках, когда их уровень достигает 7 баллов.

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

— Откуда берутся данные для нагрузочного тестирования вашего типичного проекта? Используются ли моки или данные с продакшн?

Владимир Ситников: Я бы не сказал, что к данным есть какой-то типичный подход. Проекты все-таки разные. Есть такие, где системы вообще не хранят данные, а являются промежуточными звеньями в некой цепочке. Для их тестирования мы просто генерируем необходимую информацию. Иногда, наоборот, системы что-то хранят. Если это, например, история записей, проблем, вроде как, нет. Но если системы хранят какое-то состояние (БД и т.д.), то здесь проявляются нюансы.

На начальном этапе, когда у нас нет никакого дампа продакшена, данные приходится генерировать (обсуждать бизнес-структуру и генерировать нужное количество подходящего сорта данных). К сожалению, я бы не сказал, что это успешно работает. Сгенерированные данные позволяют пережить какое-то время, но, к сожалению, получить таким образом данные, похожие на правду и подходящие для разных сценариев, тяжело. И начинаются игры, когда мы генерируем часть данных для одного типа запросов, часть — для другого, часть — для третьего. Нам удобнее генерить частями, но при этом получаются перекосы: либо данных слишком много (потому что мы по каждому типу сценариев хотим иметь запас), либо мы пропускаем какие-то сценарии. Из-за этого рано или поздно мы переходим на нечто более-менее похожее на дампы — импорт из внешних систем или продакшн с маскированием.

С импортом тоже есть свои проблемы. Мы работаем в телеком-сегменте, где дампы продакшн-систем нельзя копировать направо-налево. Там присутствуют определенного типа данные, которые просто так копировать нельзя. Поэтому приходится изобретать, как сделать так, чтобы система вроде бы работала, но данные были заменены на звездочки и т.д.

— Не проще тестировать сразу на продакшене, подключая какую-то долю пользователей?

Алексей Лавренюк: В нашем случае это не тестирование, это аккуратный релиз. По-хорошему, всегда, даже после тестирования, нужно выкатывать на долю пользователей, потому что в продакшне может пойти все не так, как в тестинге.

Чем подключение доли пользователей отличается от нагрузочного тестирования? В этом случае у вас нет возможности полностью управлять нагрузкой, вы не можете довести сервис до предела (пользователи просто 500 ошибку начнут получать), вы не можете безнаказанно крутить на нем ручки и замониторить столько, сколько могли бы на тестовых серверах.

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

Иными словами, если вас устраивает ответ «держим/не держим» (причем с вероятностью разочаровать какую-то долю своих пользователей), то можно и не тестировать нагрузочно. Если же вы хотите знать пределы производительности, узкие места, в какие мониторинги лучше смотреть, за какие крутилки в первую очередь хвататься и к кому бежать – то все-таки сделайте нагрузочное тестирование.

Владимир Ситников: Это не наш случай. Существуют компании, которые без проблем тестируют в продакшене. У них есть часть клиентов, которая может быть перенаправлена на новую версию кода. В нашем случае речь идет о системе, важной для бизнеса наших заказчиков. Если она не работает, заказчик теряет деньги. Поэтому и нагрузочные тесты проводим до попадания кода в эксплуатацию.

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

— Есть ли у вас какой-то излюбленный инструментарий для проведения нагрузочного тестирования?

Владимир Ситников: Конечно. У нас 3 основных инструмента: для тестирования серверной части мы используем Apache JMeter, для тестирования браузера мы используем Selenium и для тестирования Java — JMH. Эти инструменты закрывают подавляющее большинство потребностей.

То, какие инструменты для тестирования предпочитает использовать Алексей Лавренюк, вы можете узнать у него лично на конференции по тестированию Гейзенбаг 2017 Piter.  Перед тем, как побеседовать со всеми желающими в дискуссионной зоне, Алексей выступит с докладом о нагрузочном тестировании web-проектов, где в режиме real time show будет «обстреливать» демонстрационный web-сервис на Python Tornado, специально написанный так, чтобы проявились проблемы производительности, анализировать отчеты нагрузочных тестов, исправлять «узкие места», а затем сравнит производительность «до» и «после».

Описание этого и других докладов, которые ожидают вас на Гейзенбаг 2017 Piter, смотрите на сайте конференции.

Что же такое тестирование?

Оригинал статьи: https://dojo.ministryoftesting.com/lessons/so-what-is-software-testing Перевод: Ольга Алифанова Если бы вам пришлось ответить на вопрос «Что такое тестирование?», что бы вы сказали? Это понятие довольно трудно впихнуть в пару-тройку коротких предложений. Плюс к тому многие недопонимают, что же такое тестирование, чем занимаются тестировщики – даже среди самих тестировщиков. Тестирование как навык и как профессия постоянно развивается. В этой статье мы рассматриваем, чем тестирование является, и чем нет. Из чего состоит тестирование Расследование Расследование определяется как «наблюдение или изучение путем близкого наблюдения и систематического изучения» [1]. Процесс тестирования должен быть расследованием. Мы не всегда знаем, что получим на выходе, но наша задача – выяснить информацию, которая поможет людям принимать решения. Это не просто сравнение работы системы со спецификацией, где прописан ожидаемый результат. Мы должны мыслить критически, задавать сложные вопросы, рисковать, подмечать то, что на первый взгляд кажется несущественным, а при тщательном анализе оказывается важным и требующим дальнейшего изучения. Исследование Список требований всегда неполон – всегда найдутся неучтенные требования, которые опущены или предполагались по умолчанию. Вне зависимости от полноты ваших требований, они всегда будут неполны. Вы не будете заранее знать, что делает ваше приложение. И тут в игру вступает исследовательское тестирование. Исследовательское тестирование определяется как одновременное обучение, тест-дизайн и прогон тестов [2]. Тестировщик исследует приложение, узнает новую информацию, учится, находит что-то новое для тестирования по ходу дела. Он может заниматься этим в одиночку или в паре с другим тестировщиком (а может, и разработчиком). Тестирование не должно восприниматься, как прогон списка готовых тестов или тест-кейсов, дающих твердый «pass/fail’ результат. Если у вас есть юзер-стори или набор требований, конечно, важно иметь их в виду. Однако критерии приемки бывает полезно переформулировать как «критерии отказа». Когда критерии приемки не удовлетворены, продукт не принят, но если они в порядке, это не значит, что в ПО нет багов. Проверки и верификация должны совмещаться с исследованием и расследованием, а также вопросами в духе «Что будет, если…», на которые вы можете не знать ответа, пока не попробуете, и ответы на которые не покрыты вашими готовыми кейсами. Снижение рисков Одна из причин, по которой мы тестируем – это поиск дефектов, рисков и другой информации о продукте, которая позволяет нам действовать, чтобы конечный пользователь не пострадал. Мы можем: Исправлять баги. Переоценить и изменить изначальные требования. Помочь пользователю с продуктом. Создать пользовательскую документацию. Донести информацию об имеющихся проблемах до заинтересованных лиц. Устранить все возможные баги, с которыми может столкнуться пользователь, просто невозможно, каким бы сложным не было ваше ПО. Однако, тестируя, мы снижаем риск того, что пользователь с ними столкнется – или серьезность последствий такого столкновения. Ценность Тестирование – это ценная часть разработки ПО, но его часто недооценивают из-за его непредсказуемой и креативной природы. Результат ежедневного труда разработчика – это код, аналитика – требования или документация, однако результаты труда тестировщика может быть довольно сложно измерить. Зачастую тестировщикам сложно рассказать о своих планах, своем прогрессе и результатах. Те, кто не разбирается в тестировании, в результате плохо понимают, что было сделано, как, и почему. В итоге понять ценность тестирования сложно. В мире множество компаний, разрабатывающих ПО вообще без тестировщиков. Отсутствие счетного результата, создаваемого тестировщиками – одна из причин, по которой некоторые предпочитают использовать тест-кейсы как способ измерения – их можно легко сосчитать. Но ценность тестирования – это намного больше, чем тест-кейсы. Исследовательское тестирование, возможно, не дает в результате набора четких кейсов, однако тестировщик находит больше интересных багов, отступая от жестких сценариев. Отчасти поэтому людям нравятся метрики, которые учитывают количество заведенных багов, написанных и пройденных кейсов, и других вещей, которые можно сосчитать. Некоторые проекты используют эти метрики, чтобы измерять качество продукта, а также качество работы разработчиков и тестировщиков. Эти метрики концентрируются на неправильных вещах и могут вас обманывать. Тестирование ценно на всех стадиях жизненного цикла разработки, не только когда пишется код. Вот что еще можно протестировать: Идеи Требования Дизайн Предположения Документацию Инфраструктуру Процессы. Задача тестировщика – задавать вопросы, исследовать, критически размышлять над этими вещами. В результате то, что могло бы стать багом в процессе разработки, можно изловить гораздо раньше. Коммуникация Коммуникация – это огромная часть работы тестировщика. Тестировщики предоставляют информацию о качестве программного продукта, поэтому очень важно передавать эту информацию точно, чтобы заинтересованные лица принимали верные решения. Человек может начать работать тестировщиком, имея слабые технические навыки, но если он силен в коммуникации и может внятно донести свою мысль – это куда важнее. Тестировщики должны использовать правильные слова и верно строить фразы, чтобы они не были противоречивыми – так снижается риск недопонимания. То, что вы хотели сказать – необязательно то, что вы в итоге сказали, и часто люди делают допущения и в результате предпринимают неверные действия, потому что коммуникация была плохой или недостаточной. Нам нужно регулярно общаться с людьми, играющими различные роли, находящимися на разных позициях и обладающих разным объемом знаний о продукте. С разработчиками, задавая им вопросы и узнавая больше о продукте, который они создают. Разработчики помогают нам вникать в технические аспекты, и им мы объясняем, что за баги мы нашли и как их воспроизвести. С владельцами продукта, чтобы понимать требования, задавать вопросы по сценариям использования и делиться информацией насчет этих сценариев, чтобы они могли принимать решения насчет релизов продукта. С тестировщиками. Если вы работаете в команде тестировщиков, очень важно общаться с коллегами, обсуждать с ними проблемы и принимать решения. Возможно, вам придется тренировать новичка или джуниора, и очень важно внятно объяснять им их задачи и помогать, если им приходится нелегко. С пользователями и заказчиками, чтобы убедиться, что их ожидания и их проблемы правильно поняты. Если вы помогаете им решить проблему, вы должны быть способны объяснить, как пошагово избавиться от нее, так, чтобы собеседник вас отлично понял. С менеджерами, чтобы сообщить, что было проделано и что осталось сделать, чтобы проинформировать их о рисках и их последствиях, а также временных рамках. Если вы предлагаете улучшения, внятно рассказывайте о своих идеях и их влиянии на продукт. Письменная коммуникация важна не меньше устной. Создать блестяще написанную, обширную документацию, которая никому не нужна, легче легкого. Мы должны убедиться, что используем правильный способ общения в каждом конкретном случае, будь то человек, процесс или проект. Потенциальная бесконечность По сути, мы всегда тестируем только выборку. Каждый нетривиальный продукт обладает непредставимым количеством параметров с большим количеством возможных значений. Откуда вы знаете, что тестируете важные значения? Мы не можем протестировать все. Часть нашей работы – принятие решений о том, что тестировать, понимание последствий того, что будет протестировано только это, и способность обосновать свой выбор. Из чего тестирование не состоит Простота О тестировании часто думают как о чем-то, чем может заниматься любой. Возможно, в какой-то степени это правдиво – любой может исследовать продукт, задавать вопросы о нем, прогнать пошагово тест-кейс или проверить, соответствует ли продукт списку требований. Но чтобы делать это хорошо и систематически, нужен настоящий навык. Нам часто говорят «пишите кейсы так, чтобы их мог прогнать любой дурак», и из-за этого создается ложное впечатление, что тестировать очень просто. Мы тупо пишем тесты согласно критериям приемки, не так ли? Но тестировщики, тестирующие свободным поиском, знают, что это не так. Даже проверки – не такое-то простое дело. Мы принимаем непростые решения, где нужны эти проверки, и какие из них следует автоматизировать. Эти решения требуют понимания фреймворков автоматизации, навыка программирования, знания, как работает API, и владения инструментами вроде Selenium. Резюмируя, мы должны разбираться в приличном наборе технологий. Помимо этого, нам нужно знать, что нужно автоматизировать, а к чему автотесты подпускать нельзя. Автоматизируемость «Ручные тестировщики нам больше не нужны – мы можем автоматизировать все!» Все мы видели те или иные вариации этой фразы в Твиттере, на форумах и в статьях. Тестирование – это исследовательская, детективная деятельность, и ее невозможно заменить автоматизированными проверками. Компьютер технически не способен исследовать продукт так, как это делает человек. Мы можем автоматизировать те или иные проверки, но компьютер и человек будут прогонять их по-разному. Живой человек заметит многое из того, на что никогда не обратит внимание машина, и прислушается к своему ощущению «тут что-то не так» – и, соответственно, даст обратную связь не только по конкретной проверке, но и по всему подмеченному в процессе. Компьютер сделает только то, что ему сказано сделать. Автоматизированные проверки очень ценны для тест-стратегии, но на данный момент неспособны заменить живых тестировщиков, потому что люди и машины занимаются принципиально разными вещами. Тестировщики используют инструменты, в том числе автотесты, для поддержки своей работы. Специальные инструменты помогают нам генерировать данные, автоматизировать рутины, анализировать результаты тестов. Ими нужно владеть, чтобы облегчить себе жизнь, а не с целью заменить ручной труд полностью. Повышение качества Тестировщики не делают ничего, что бы напрямую улучшало качество продукта. Прогоняя тест, мы никак не влияем на код – следовательно, качество ПО остается неизменным. Только после того, как разработчики исправляют баги, качество продукта может измениться. Мы не можем «втестировать» качество в продукт. Тестирование – не единственная область разработки ПО, принимающая во внимание качество продукта. За ним нужно следить на всех стадиях жизненного цикла, и за него отвечают все участники команды разработки. Тестировщики могут использовать свои специфические навыки для сотрудничества с коллегами, но за качество отвечаем не только мы – это головная боль всей команды! Ни тестировщики, ни разработчики, правящие баги, не могут в результате сделать вывод, что качество продукта улучшилось. Мы не можем протестировать все, поэтому всегда вероятны сценарии, которые мы не проверяли, таящие в себе баги. Качество может ухудшиться из-за изменений или чего-то, неизвестного нам – мы даже не подозреваем, что у нас есть проблемы, пока не произойдет нечто, вскрывающее их. И даже если тестировщики могут уверенно сказать, что продукт готов к релизу, конечные пользователи могут его забраковать – например, из-за криво составленных требований. Все зависит от точки зрения. Качество определяется как «ценность для человека, чье мнение значимо». Его трудно измерить, и поэтому с определенностью заявить, что тестирование на каком бы то ни было этапе улучшает качество продукта, довольно трудно, даже невозможно. Фиксированная, не требующая воображения деятельность, подчиняющаяся строгим правилам Самые интересные баги зачастую находятся при помощи исследовательского тестирования. Прогон одних и тех же тестов раз за разом вряд ли даст вам много новой интересной информации – и, на сердце руку положа, довольно скучно гонять их вручную. Не существует лучших практик тестирования, применимых в абсолютно любых проектах. Вы должны выяснить, что лучше всего работает в вашем контексте и в вашей области. Размышления над новыми креативными способами тестирования – очень увлекательная часть нашей работы. Способность экспериментировать, искать лучшие инструменты, изучать новые навыки и технологии, и делать то, что наилучшим образом подходит нашему проекту, помогает нам постоянно совершенствоваться и держать свои навыки в форме. Жизненно необходимо для успеха продукта Проект может быть вполне успешным и без тестировщиков – тому множество примеров. Однако даже в случае отсутствия тестировщиков как таковых тестирование все же кем-то выполняется на той или иной стадии жизненного цикла. Разработчики тестируют собственный код, а заказчики – требования. Конечный пользователь иногда тестирует продукт до релиза. Люди могут тестировать, даже не отдавая себе отчета, что они этим занимаются. Никогда не заканчивается Под бесконечностью тестирования понимается невозможность протестировать все и вся в приложении. Нет реалистичных способов протестировать все комбинации, действия пользователя, внешние условия, значения данных или пути через код. В этом плане тестирование, действительно, бесконечный процесс. Следует принять как данность, что всегда останется что-нибудь непротестированное. Большинство проектов жестко ограничены временем, бюджетом и ресурсами, и тестировщики должны укладываться в эти ограничения, тестируя максимально эффективно. Часть работы тестировщика – это принятие решений, что именно тестировать, и понимание последствий этих решений и связанных с нимирисков. Тестирование завершается, когда у менеджмента достаточно информации, помогающей принять решение, готов ли продукт к релизу. Тестирование – это многое, многое другое Я перечислила только некоторые аспекты того, что же такое тестирование. Эта статья могла бы быть значительно длиннее! Нет единого определения, что подразумевается под тестированием, а впихнуть в одно предложение все то, чем занимаются тестировщики, просто невозможно! Если поискать определение тестирования в Интернете, можно наткнуться на фразы вроде «поиск багов в приложениях» – но как мы уже выяснили, это не только и не столько поиск багов. Ссылки: Explaining Testing To Anybody — James Bach Software Testing Club — So What Is Testing ? The Impossibility of Complete Testing — Cem Kaner Exploratory Testing — James Bach Acceptance Tests : Let’s Change the Title Too — Michael Bolton The Rapid Software Testing Guide to What You Meant To Say — Michael Bolton Exploratory Testing Explained — James Bach Explore It — Elisabeth Hendrickson Обсудить на форуме

Краудтестинг, или Где взять опыт для первой работы в тестировании / Badoo corporate blog / Habr

Изображение: источник

Привет, Хабр! Меня зовут Евгений Кузнецов. Я работаю в Badoo, в отделе QA.

Почти пять лет назад я начал интересоваться тестированием: читал книги, искал информацию в интернете. На одном из форумов наткнулся на тему про подработку, где один из участников оставил ссылку на сайт uTest.com. И это была действительно удачная находка, поскольку uTest оказался крупнейшей платформой для тестировщиков с кучей полезной информации и сотнями оплачиваемых краудсорсинговых проектов.

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

Что такое краудтестинг

Предположим, вы продакт-менеджер и собираетесь выпустить новую версию приложения для Android и iOS. Сроки горят, вам срочно нужны результаты регрессионного тестирования, а единственный тестировщик в вашей команде говорит, что оно займёт два дня, а потом потребуется ещё день для исправления возможных багов. Более того, один из Android-девайсов сломался, и его необходимо заменить, чтобы обеспечить хотя бы базовое платформенное покрытие.

Как можно ускорить процесс тестирования без ущерба качеству продукта? Можно расширить QA-команду и купить больше девайсов; написать кучу автотестов и запускать их в «облаке»; наконец, арендовать несколько девайсов, сесть и тестировать приложение вместе с QA-инженером. Или обратиться к какой-нибудь краудтестинговой платформе. Обычно это сайт, на котором зарегистрированы тысячи тестировщиков. Они готовы тестировать любое веб- или мобильное приложение на собственных гаджетах и ноутбуках.

Вам нужно предоставить ссылку на сборку (например, с помощью HockeyApp или TestFlight), выбрать операционную систему и устройства, на которых вы хотите тестировать свой продукт. Можете даже выбрать страну нахождения тестировщиков. В общем, список пожеланий может быть очень длинным. Затем менеджер платформы разошлёт приглашения — и армия тестировщиков приступит к работе. Через некоторое время вы получите результаты и решите, какие баги нужно фиксить, а с какими можно существовать и после релиза.

Так весь процесс выглядит со стороны заказчика. А теперь давайте посмотрим на него глазами тестировщика.

Что нужно, чтобы начать тестировать

Ничего особенного. Если вы читаете эту статью, значит, у вас есть компьютер, мобильный девайс или что-то ещё. Этого достаточно для регистрации на платформе и участия в проектах. Укажите в профиле модель своего устройства, версию ОС, список браузеров на компьютере и т. д. Будет лучше, если у вас в распоряжении несколько мобильных устройств, например, iOS- и Android-девайсы — вероятность получить инвайты будет выше.

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

Итак, сначала вам предложат пройти тест, чтобы понять, насколько хорошо вы умеете искать баги и писать репорты. После этого всё просто: вы получаете приглашение, читаете описание проекта и решаете, будете ли в нём участвовать. Время на поиск багов ограничено. После завершения цикла тестирования все репорты просматриваются тимлидом проекта, а затем заказчиком. Отправленные вами баги либо принимаются, либо отклоняются.

Баг принят ⇒ получаете деньги.
Баг отклонён ⇒ получаете опыт, так как в комментарии к репорту будет объяснена причина отклонения.

Зачем краудтестинг начинающему тестировщику

Опыт

Я начал работать на краудтестинговых площадках до того, как нашёл первую работу. У меня были неплохие знания теории тестирования, но не было практического опыта (без которого многие рекрутеры даже не хотят начинать разговор). Работая на краудсорсинговых платформах, вы получите отличный практический опыт тестирования программного обеспечения. Разнообразие софта будет зависеть от имеющихся у вас гаджетов. У меня были iPhone и ноутбук (на Windows 7) с установленной виртуальной машиной (на которой крутились XP и Vista). Чуть позже я купил Android-девайс и iPad.

За первые два месяца я поучаствовал примерно в 20 проектах, которые длились от нескольких часов до нескольких дней. E-commerce-приложения и сайты, игры, соцсети, мессенджеры… Если будете активно участвовать и находить много багов, то ваш рейтинг будет расти, а значит, вы станете получать больше приглашений.

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

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

В итоге в вашем портфолио появится много интересных проектов и забавных баг-историй, которые можно будет использовать на собеседованиях.

Чем более вы продуктивны в тест-циклах, тем больше приглашений на них у вас будет.

Новые скилы

Очевидно, что при тестировании большого количества ПО вы будете осваивать новые навыки: как снять краш-логи с Android-/ iOS-девайса и прочитать их, как использовать ADB Console и monkey-тестинг, как правильно использовать все настройки девайса (включение ограничения приложений на доступ к камере/ геолокации, «универсального доступа», режима зумирования), как использовать браузерные инструменты для разработчиков и многие другие. И вам придётся всё это узнать, чтобы найти больше багов, так как каждый проект — это мини-соревнование между тестировщиками.

Вы научитесь работать с новыми инструментами. Например, одним из моих проектов была проверка ивентов Google Analytics, в тот день я открыл для себя Charles Proxy. Немного позже я начал использовать все его возможности (throttling, rewriting, mapping). Ещё, помню, у меня был проект по тестированию безопасности, и я нашёл прекрасный инструмент Zed Attack Proxy.

Кстати, если хотите прокачать свои навыки, рекомендую статью «Тестирование мобильных приложений: tips & tricks».

Любопытство — самый ценный навык тестировщика.

Сообщество

Общение — один из самых важных навыков для тестировщика. Это ключ ко всему. Что бы вы ни хотели узнать, найти или получить, нужно общаться. Каждый новый человек может дать вам какие-то новые возможности. На краудтестинговых платформах вы встретите много интересных людей, которые будут с вами «на одной волне». На форумах есть сотни тем, в которых можно задавать любые вопросы. Это особенно важно, когда вы начинаете свой путь в тестировании, поскольку можно научиться и получить совет у более опытных людей.

Будьте активны, задавайте вопросы в чате тест-цикла. Если вам кажется, что в описании что-то упущено, обязательно скажите об этом. Помогайте другим участникам, если знаете ответы на их вопросы. Тимлид или заказчик это заметят — и позже вы сможете получать приглашения в проекты «для избранных».

Общение — ключ к возможностям.

Языковая практика

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

Не бойтесь ошибаться: для 90% участников английский — тоже не родной язык.

Деньги

Последний аргумент — деньги. Работу на краудтестинговых платформах можно рассматривать как оплачиваемую стажировку. Ведь вы получаете и опыт, и доход. Размер оплаты будет зависеть от критичности и количества найденных багов. На большинстве платформ он колеблется в диапазоне 3—15 у. е. (в зависимости от проекта, могут отстегнуть и 50 у. е.) за баг.

Сначала я зарабатывал около 400 евро в месяц, работая по паре часов в день. Потом я решил сосредоточиться не на количестве, а на качестве баг-репортов. Начал проводить больше времени на платформе — и в результате стал зарабатывать около 700—800 евро в месяц. Мой рейтинг ощутимо вырос — и вскоре я получил от менеджера проекта приглашение в небольшую команду на закрытый цикл тестирования одного продукта. После около 12 часов работы каждый из нас получил больше тысячи евро.

Старайтесь сосредоточиться на поиске критичных багов и повышении качества репортов, а не на их количестве. Тогда работа будет более интересной и в конечном счёте вы больше заработаете.

Платформы, на которых я работал

Крупнейшее онлайн-сообщество тестировщиков ПО. Помимо оплачиваемых проектов по тестированию, здесь есть масса полезной информации, статьи и хороший форум. Возможно, это лучшее место для начала работы. К сожалению, у меня с ним, что называется, не сложилось. Четыре года назад на платформе было очень мало проектов для тестировщиков из России (сейчас с этим, насколько я знаю, получше). В то время клиенты были в основном из Европы и США, и они хотели тестировать продукты на своих потенциальных рынках. Россия, разумеется, к ним не относилась. Конечно, можно было прибегнуть к хитрости: использовать VPN и написать в профиле, что ты тестировщик из Англии или США. Так я, собственно, и сделал, чтобы получить свой первый проект. Но для меня такой способ оказался не очень удобным, так что я начал искать другие платформы.

Раньше платформа называлась Testcloud, и она стала моей любимой краудтестинговой площадкой.
Удобный интерфейс, налаженное взаимодействие с тимлидами и заказчиками, хорошая система рейтинга тестировщиков и прекрасные рейты за найденные баги (вывод денег — через PayPal). На этой платформе у меня было множество разных и интересных проектов. В течение нескольких месяцев я был единственным русскоязычным тестировщиком, поэтому мне доставались все проекты с RU-локализацией.

Через год я решил стать тимлидом на этой платформе. Тимлид на краудтестинговой площадке — это тот же фрилансер, получающий приглашения в проекты; только он не тестирует продукты, а проверяет баг-репорты и контролирует весь цикл тестирования. Но, к сожалению, в тот момент я был очень занят на новом месте работы — и из-за нехватки времени мне пришлось уйти с площадки. А вообще у ребят замечательная команда, и я рад видеть, что платформа растёт. Очень рекомендую!

Отличная платформа с разными проектами. Несколько раз мне даже присылали гаджеты для тестирования, и некоторыми я пользуюсь до сих пор. Кстати, пару лет назад появился и русскоязычный вариант — crowdtesting.ru.

Участвовал в нескольких циклах тестирования.
В некоторых проектах требуется знание немецкого языка.

Индийская платформа. До сих пор получаю с неё приглашения на проекты.

И ещё несколько ресурсов

Если верить информации на сайте, платформа сотрудничает с Facebook, Spotify и Microsoft. Так что, если у вас есть желание зарепортить какие-то раздражающие баги FB (у меня, пожалуй, наберётся пара десятков), это место для вас.

Хочу заметить, что этот проект является организатором тестатонов (хакатонов для тестировщиков), один из которых проходил в Москве.

Не имеет ничего общего с известной компанией. Но, кто знает, возможно, у вас в руках окажется и предрелизная версия приложения Uber.

Ещё одна крупная платформа. Интересная особенность: платят не за найденные баги, а за время, потраченное на тестирование. А ещё там есть прикольный блог, где вы можете почитать истории тестировщиков с этой площадки.

Заключение

Я без проблем нашёл первое место работы во многом благодаря опыту в краудтестинге. Было огромное количество писем и звонков, которые превратились в четыре оффера из пяти интервью. В моей следующей компании все очень заинтересовались тестированием на краудтестинговых площадках, и я даже выступил в роли заказчика на одной из них. И сейчас, работая в лондонском офисе Badoo, я использую многие навыки, которые получил в то время.

Работа на краудсорсинговых платформах — хорошая возможность начать QA-карьеру. Вы получите опыт, научитесь пользоваться новыми инструментами, познакомитесь с интересными людьми, заработаете неплохие деньги, и главное — получите удовольствие от тестирования.

Тестировщики не ломают софт — они ломают ваши мечты о нём…(с) James Bach

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

P. P. S. Кстати, в Badoo мы тоже используем краудтестинг для поиска секьюрити-багов. Так что, если вы эксперт в области IT-безопасности и хотите заработать (до £2000 за уязвимость!), то добро пожаловать в нашу bounty-программу на сайте hackerone.com.