Я давно работаю с uTest и попробую пояснить некоторые моменты работы сервиса.
Комментарии по “граблям”:
1. Всё взаимодействие происходит на английском языке,
При желанию заказчика (Customer в платформе) тестовая документация может вестись на русском языке. Платформа теперь поддерживает utf. Это не исключает общения с PM в uTest на Английском, но все же упрощает работу.
2. Коммуникации и менеджмент отнимает практически все рабочее время штатного QA-менеджера и прочая, и прочая...
В uTest есть несколько уровней управления проектом. На самом высоком — PM (Project Manager), это всегда сотрудник uTest. При желании PM он может набирать себе команду TTL (Test Team Leader).
TTL — это не менеджеры uTest. Это наиболее продвинутые, прошедшие экзамен тестировщики из сообщества uTest, понимающие как работает платформа и способные управлять процессом тестирования. Так же показавшие свою адекватность в целом и владеющие внушительным парком девайсов (надо ж на чем-то проверять). В общем, пацаны ваще ребята. Так же есть Premier TTL, они управляют другими TTL на проекте, когда нужно одновременно запустить несколько тестовых циклов и постоянно держать руку на пульсе (как в вашем случае). Но TTL — это желание PM, если он не захотел пригласить кого-либо в помощь, то взаимодействовать придется с ним напрямую.
Так же заказчик может напрямую работать с тестировщиками, общаясь в тестовом цикле в чате или через Testers Messenger. Кстати, это хороший мотиватор для тестировщиков.
3. Взаимодействие происходит через систему баг/таск-трекинга сервиса, без возможности интеграции в вашу систему.
Это не совсем так, можно интегрироваться с Jira, есть специальный плагин. По идее ваш PM должен был это рассказать, если вопрос вообще поднимался. С другими системами интеграция не предусмотрена.
4. Внутреннему QA-менеджеру необходимо вычитывать каждую проблему, заведенную тестировщиками сервиса в трекере, и воспроизводить у себя.
Вы не совсем правильно понимаете как это работает. Есть два пути:
a) Если на проекте есть TTL, либо PM сам проверяет репорты (это крайне редкое явление). TTL проверяет баги от тестировщиков (не дубликат ли, соответствует ли области тестирования и прочее) и либо меняет статус репорта на Pending Reject/Approve (если Reject, то обычно есть комментарии почему баг не стоит аппрувить) и тогда он попадает к заказчику на ревью. Если TTL получил достаточно информации о продукте, то ошибки редки.
Технически TLL может самостоятельно решить принимать (Approve) или реджектить баг. Но разрешение на это дает заказчик. При аппруве выставляется ценность бага для заказчика — “ни о чем”, “хороший”, “супер”. Это добавляет некоторое количество денег к базовой стоимости бага. Плюс на эту стоимость (незначительно) влияет рейтинг тестировщика в uTest. Реджекты влияют сильно негативно на рейтинг тестировщика.
b) В любое время, вы, как заказчик, можете пройти по списку багов и решить все самостоятельно. Так же как и TTL, вы выбираете ценность бага, если он вам подходит. Это влияет на рейтинг тестировщика и в следующий тестовый цикл он может уже не попасть, если его баги оказались так себе. Тоже самое с реджектами.
Увлекаться выставлением ценности “Somewhat” не рекомендую. В самом простом случае тестировщики будут отказываться от приглашений на тестовые циклы.
У вас, кстати, тоже есть полное права и все возможности убрать “обманщиков” из тестового цикла навсегда. Напишите PM.
По выводам.
Вполне верные выводы, но они показывают то, что вы используете uTest не совсем неправильно.
Во-первых, uTest, как вы и отметили — это crowdsource и вы можете обозначить, кого вы хотите видеть на проекте, частично это делается через платформу, а частично через общение с PM. Тут много моментов, всего не опишешь в двух словах, но возможности uTest по тестированию огромны, чтобы их использовать надо понимать, как работает сервис.
Во-вторых, в случае uTest вас совершенно не должно беспокоить когда работают тестировщики. Для вас они — безликая масса. Если результат не устраивает, тогда вы говорите об этом PM. Чаще говорите — быстрее будут изменения.
В третьих, поговорите с PM на тему появления TTL на проекте. Он снимет массу головной боли. Можете настаивать на том, чтобы он говорил на русском языке (таких там есть). По правилам uTest прямое общение TTL с кастомером запрещено… но, почему бы не попробовать попросить об этом ;) В любом случае, на uTest можно организовывать рекрутинговые тестовые циклы, отмечать хороших тестировщиков (Favorite tester), продумывать стратегии на основе тестовых циклов, фокусировать тестировщиков на определенные области (In scope/Out of scope). При их наличии TTL с реджектометом способен очень хорошо почистить то, что приходит от тестировщиков.
В четвертых, продумайте систему мотивации тестировщиков. Например, время от времени, запускайте специальные циклы с гарантированной оплатой (по тесткейсам), либо с бонусом за определенный тип найденных проблема, либо устраивайте соревнования между тестировщиками (MVT Award в контексте uTest). Никаких особых отличий от обычной команды тут нет.
Отличная статья, спасибо! Если, внезапно кто еще не читал, то книга Тони Шей (Tony Hsieh) — Zappos. Доставляя счастье (http://www.deliveringhappiness.com/about-us/about-2/) это практическое доказательство сказанного выше.
Комментарии по “граблям”:
При желанию заказчика (Customer в платформе) тестовая документация может вестись на русском языке. Платформа теперь поддерживает utf. Это не исключает общения с PM в uTest на Английском, но все же упрощает работу.
В uTest есть несколько уровней управления проектом. На самом высоком — PM (Project Manager), это всегда сотрудник uTest. При желании PM он может набирать себе команду TTL (Test Team Leader).
TTL — это не менеджеры uTest. Это наиболее продвинутые, прошедшие экзамен тестировщики из сообщества uTest, понимающие как работает платформа и способные управлять процессом тестирования. Так же показавшие свою адекватность в целом и владеющие внушительным парком девайсов (надо ж на чем-то проверять). В общем, пацаны ваще ребята. Так же есть Premier TTL, они управляют другими TTL на проекте, когда нужно одновременно запустить несколько тестовых циклов и постоянно держать руку на пульсе (как в вашем случае). Но TTL — это желание PM, если он не захотел пригласить кого-либо в помощь, то взаимодействовать придется с ним напрямую.
Так же заказчик может напрямую работать с тестировщиками, общаясь в тестовом цикле в чате или через Testers Messenger. Кстати, это хороший мотиватор для тестировщиков.
Это не совсем так, можно интегрироваться с Jira, есть специальный плагин. По идее ваш PM должен был это рассказать, если вопрос вообще поднимался. С другими системами интеграция не предусмотрена.
Вы не совсем правильно понимаете как это работает. Есть два пути:
a) Если на проекте есть TTL, либо PM сам проверяет репорты (это крайне редкое явление). TTL проверяет баги от тестировщиков (не дубликат ли, соответствует ли области тестирования и прочее) и либо меняет статус репорта на Pending Reject/Approve (если Reject, то обычно есть комментарии почему баг не стоит аппрувить) и тогда он попадает к заказчику на ревью. Если TTL получил достаточно информации о продукте, то ошибки редки.
Технически TLL может самостоятельно решить принимать (Approve) или реджектить баг. Но разрешение на это дает заказчик. При аппруве выставляется ценность бага для заказчика — “ни о чем”, “хороший”, “супер”. Это добавляет некоторое количество денег к базовой стоимости бага. Плюс на эту стоимость (незначительно) влияет рейтинг тестировщика в uTest. Реджекты влияют сильно негативно на рейтинг тестировщика.
b) В любое время, вы, как заказчик, можете пройти по списку багов и решить все самостоятельно. Так же как и TTL, вы выбираете ценность бага, если он вам подходит. Это влияет на рейтинг тестировщика и в следующий тестовый цикл он может уже не попасть, если его баги оказались так себе. Тоже самое с реджектами.
Увлекаться выставлением ценности “Somewhat” не рекомендую. В самом простом случае тестировщики будут отказываться от приглашений на тестовые циклы.
У вас, кстати, тоже есть полное права и все возможности убрать “обманщиков” из тестового цикла навсегда. Напишите PM.
По выводам.
Вполне верные выводы, но они показывают то, что вы используете uTest не совсем неправильно.
Во-первых, uTest, как вы и отметили — это crowdsource и вы можете обозначить, кого вы хотите видеть на проекте, частично это делается через платформу, а частично через общение с PM. Тут много моментов, всего не опишешь в двух словах, но возможности uTest по тестированию огромны, чтобы их использовать надо понимать, как работает сервис.
Во-вторых, в случае uTest вас совершенно не должно беспокоить когда работают тестировщики. Для вас они — безликая масса. Если результат не устраивает, тогда вы говорите об этом PM. Чаще говорите — быстрее будут изменения.
В третьих, поговорите с PM на тему появления TTL на проекте. Он снимет массу головной боли. Можете настаивать на том, чтобы он говорил на русском языке (таких там есть). По правилам uTest прямое общение TTL с кастомером запрещено… но, почему бы не попробовать попросить об этом ;) В любом случае, на uTest можно организовывать рекрутинговые тестовые циклы, отмечать хороших тестировщиков (Favorite tester), продумывать стратегии на основе тестовых циклов, фокусировать тестировщиков на определенные области (In scope/Out of scope). При их наличии TTL с реджектометом способен очень хорошо почистить то, что приходит от тестировщиков.
В четвертых, продумайте систему мотивации тестировщиков. Например, время от времени, запускайте специальные циклы с гарантированной оплатой (по тесткейсам), либо с бонусом за определенный тип найденных проблема, либо устраивайте соревнования между тестировщиками (MVT Award в контексте uTest). Никаких особых отличий от обычной команды тут нет.