Или по крайней мере сильно осложнить продвижение. Общие вещи об uTest в недавнем прошлом я уже писал. Также стоит почитать записи Романа и Феликса, чтобы узнать о возможностях uTest.

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

Работа в uTest делиться на несколько частей:

- проекты, попадающие в публичное тестирование и доступные всем зарегистрованным тестировщикам;

- приватные проекты, набор в которые идёт на форуме;

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

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

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

Самые интересные проекты – приватные. Во-первых, по ним есть базовая информация по которой можно понять, стоит ли участвовать. Известно примерное время начала проекта. Можно увидеть сколько у тебя конкурентов и их уровень. Иногда известно, кто будет менеджером проекта. Хотя там иногда такие сюрпризы случаются…

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

Однако, есть несколько способов, которые гарантируют повышенное внимание с их стороны и при :

1. Массированное дублирование ошибок, которые были опубликованы ранее. Обалденной фишкой uTest является общий трекер по проекту. Можно посмотреть сколько ошибок уже есть, посмотреть тексты описаний, скриншоты, переписку между автором и менеджером проекта. Это сделано, в том числе, для того, чтобы участники не занимались дублированием.

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

3. Постинг ошибок вне области тестирования. Многие проекты ограничивают тестирование и фокусируют внимание участников на определённых вещах. Тут надо всегда помнить, что crowdsource – это не просто очередная форма аутсорсинга/аутстаффинга, а один из подходов, который позволяет повысить эффективность работы с меньшими затратами:

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

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

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

5. Игнорирование сообщений от менеджера проекта. Какие бы ни были вопросы (они всегда корректны :] ), на них обязательно нужно отвечать. Если менеджер предлагает дополнительную работу, но возможности выполнить её нет, то нужно просто вежливо написать, что предложение очень интересное, но сделать его сейчас нет возможности. Это даёт +1 к карме и повышает шанс получить предложение в будущем.

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

В целом uTest относится очень лояльно к ошибкам тестировщиков и появления отклонённых багов (Rejected) опасаться не стоит. Я знаю нескольких тестировщиков у которых примерно пятая часть багов была отклонена, никаких проблем с uTest или уменьшения проектов они не видят. Вполне вероятно, что пока количество проектов просто больше, чем количество тестировщиков с достаточной репутацией и квалификацией. Я думаю, что отношение Approved/Rejected нужно держать в уме, если есть планы на долгосрочную работу в uTest. Спорить с менеджерами проекта тоже можно, а иногда и полезно, но делать это нужно со всем уважением и в контексте потребностей клиента. Возвращаясь к ошибкам вне области тестирования – ни один из тестировщиков, и часто менеджер проекта, не знают на какой стадии готовности находится проект заказчика и почему он устанавливает какие-либо правила. Вполне может оказаться, что по сути только то, что он просит протестировать готово, а всё, что вокруг – это просто сырой прототип, ошибки в котором не имеют значения, какими бы они не были.