V2
█ ➤ Интро
Доброго времени суток всем участникам майской волны обучения, всем участникам QA Project, в сегодняшнем уроке мы разберём как правильно пройти академию платформы Test IO, разберём все ее нюансы, как писать репорты и что мы должны и будем иметь по итогу. Так же мы разберем с чем мы будем иметь дело после прохождения академии и на что стоит обратить внимание.
Начнём.
█ ➤ Академия
С прошлого урока, если вы сами не подались в исследование платформы, у нас должна быть следующая картина(показываю на академический цикл, стату принятых багов и т.д.).
Как я уже говорил в первом уроке, если вы не получили цикл сразу, то он приходит каждый понедельник, среду и пятницу. Если вы не получили его в эти дни - необходимо обратиться в поддержку платформы, чтобы они выслали цикл вручную. Академические циклы приходят по кругу в течении двух недель и закончатся только после принятия 50% присланных багрепортов, при этом не менее 3 багов должно быть отправлено, неважно в одном цикле вы их отправите или в нескольких. (количество принятых багов считается в совокупности нескольких циклов, если вы не успели отправить их за первый).
Разберем интерфейс цикла.
1. Время, оставшееся у вас на выполнение конкретно этого тестового цикла. После его завершения вам моментально выдадут следующий академический цикл для выполнения.
2. Согласие на участие в тестовом цикле. После того, как вы прочитали весь овервью, вы либо принимаете, либо отклоняете академический цикл.
3. Вкладка доступа к разделу «Доступ к тестовому продукту».
На Test IO ввели правило: Вы не получите доступ к тестовому продукту и к функции оформления багов до тех пор, пока не согласитесь с условиями, описанными в данном окне. После прочтения и согласия с условиями – вы вписываете необходимую фразу в окно и жмете на кнопку «Unlock access data».
4. В разделе "Goal of this test" у вас будет вся вступительная информация, а так же информация, необходимая для понимания вашей задачи в тестовом цикле.
5. Раздел "Websites to test" перекочевал из вкладки «Access» только для академического тестового цикла. В нем будут указаны тестируемые сайты и заметки, необходимые для доступа к ним.
6. Раздел Out Of Scope. Все, что запрещено делать в этом академическом цикле. Этот раздел так же будет присутствовать в платных заданиях. Один из важнейших разделов в Overview.
7. Дополнительные требования к баг-репортам или течению цикла(Additional Requirements).
Отличительная черта академии Test IO от uTest - В академии Test IO принимают ИСКЛЮЧИТЕЛЬНО ФУНКЦИОНАЛЬНЫЕ БАГИ.
Для идентификации критичности функционального бага используйте статью из Академии(механика тестирования), описывающую все уровни критичности бага -
найти её можно тут. (прикрепить ссылку)
8. Test this features
После нажатия на одно из выпадающих меню вы увидите:
- Где находится та или иная область тестируемого продукта
- Что вы можете там найти и как эту область правильно протестировать
- Подсказки по области
- Дополнительная секция OOS(Out of Scope), в которой указывается что в этой секции запрещено и будет восприниматься как не нужное к тестированию.
Что же нужно, чтобы пройти академию?
Сама платформа заявляет следующее:
1. Необходимо оформить и отправить минимум 3 бага.
2. 50% из этих отправленных багов должен принять TTL.
3. У вас не должно оставаться непроверенных баг-репортов. То есть: ваши баг-репорты имеют статус "Approved by customer" и цикл(или циклы) в которых вы участвовали находятся в архиве.
Перед прохождением академических циклов необходимо добавить в список девайсов все имеющиеся у вас в доступе устройства, дабы вам было максимально комфортно искать баги в кратчайшие сроки.
Не смотря на это, академический цикл можно пройти на любом указанном вами девайсе или девайсах, поэтому на это особого внимания не обращайте, по крайней мере до платных циклов.
После того, как вы зашли в академический цикл - первым делом вы обязаны (!) прочитать весь раздел Overview и описание тестируемых областей, т.к. в некоторых из них находится дополнительная секция ООС.
Основными правилами для академических циклов являются:
1. Выкладывать репорты исключительно для функциональных багов (показать где находится эта надпись)
2. Баги, связанные с функцией поиска не принимаются (показать в 02 хедер надпись и пример такого бага)
3. Баги, связанные с функцией фильтрации считаются контентными, если после фильтрации лишь один или несколько товаров не подходят по фильтру (показать пример и надпись в 04 поп)
4. Баги, связанные с регистрацией аккаунтов и их процессом являются ООС (показать надпись и пример)
5. Не выкладывать более 3 багрепортов за один цикл (показать надпись)
Так же имеются перемежающиеся запреты (например ООС про аккаунты повторяются в двух областях).
Самым прекрасным вариантом будет оформить и отправить ровно 3 бага, из которых если у вас примут 2 – вы получите доступ к платным заданиям. Если вы в первой академии оформили 3 бага и 2 из них у вас приняли – брать следующий академический цикл не обязательно, вас уже одобрят.
Тестируемые продукты в академических циклах меняются от обновления к обновлению, в данный момент там присутствует девять разных сайтов девяти разных брендов.
Приступим к поиску необходимых нам багов.
*процесс поиска или "поиск" уже подготовленных багов*
Для того, чтобы повысить шанс на апрув наших багов необходимо описывать ваш баг максимально чисто и без ошибок, чтобы человек по ту сторону экрана, который работает с вами, мог понять что вы от него хотите.
Используйте знаки препинания, обозначения областей кавычками, выделяйте примеры скобками и т.д.. Сделайте общение с вами приятным и TL'ы будут чаще принимать вашу сторону.
Существуют так же и более жесткие TL'ы на Test IO. За все время работы на этой площадке самым главным каверзным человеком я выделил лишь одного TL'a – его имя Thomas.
Этот человек будет придираться к каждому вашему пункту в баг-репорте, пока все не будет предельно ясно и понятно, но и к нему можно найти подход.
Не только один Thomas любит видеть у себя на экране идеальные баг-репорты. Поэтому чтобы увеличить наши шансы на апрув баг-репорта, мы будем следовать следующим правилам, чтобы и вы и ТЛ были рады и получали удовольствие от работы:
1. Всегда пишите максимально подробно название, ожидаемый и актуальный результаты. При необходимости лейте воду, можете добавить немного драмы, но не переусердствуйте.
2. Записывайте короткие, но четкие скринкасты, исходя из правил академии, чтобы ТЛ сразу понял в чем суть проблемы.
3. Старайтесь быстро и вежливо отвечать на реквесты, чтобы у ТЛа складывалось приятное ощущение от работы с вами.
4. Если вам сложно описать проблему из-за нехватки знания языка – формулируйте свои мысли на русском языке и переводите через переводчик, главное в баг-репорте передать суть проблемы.
*процесс оформления баг-репортов*
Что мы должны иметь в итоге.
В самом лучшем случае, зарепортив 3 бага и получив 3 апрува - нас допускают к платным заданиям. В случае, если один из трех багов отклонили - не беспокойтесь, как я уже сказал ранее - вас допустят.
Что делать, если все-таки что-то пошло не так?
Необходимо увеличить процент принятых багрепортов. Таким образом получается следующая таблица:
Подытожим информацию, которая поможет нам пройти академический цикл без проблем:
1. ВНИМАТЕЛЬНО прочтите весь Overview и "Test this features".
Где находится та или иная область, что в ней нужно протестировать, что в ней тестировать не нужно, что запрещено и что разрешено, какие доказательства вы должны прикладывать и как работать с циклом - вся необходимая информация будет в этом разделе.
2. Примите тестовый цикл, если вы уверены в том, что вы справитесь с циклом, у вас есть время на его выполнение и вся прочтенная информация была вами понята. Если у вас возникли какие-либо проблемы или недопонимания - обратитесь к саппортам, они объяснят что платформа хочет от вас.
3. Получите доступ к функции описания багов и информации по доступу к тестовому продукту, вписав необходимую фразу в разделе “Access”. Не открыв доступ к тестовому продукту - вы не получите возможность отправлять ваши репорты на проверку.
4. Обратите внимание на вкладки “Bugs” и “Known Bugs”, если они существуют для вашего академического цикла. В них будут указаны баги, которые уже известны или выложены другими тестировщиками в рамках ранних циклов. Выкладывать их запрещено, так как они будут являться дубликатом и при проверке будут отклонены. В академических циклах, так же как и на uTest, вы не видите выложенные в текущем цикле баги, поэтому выкладывать можно все, что вы найдете (в рамках правил)
5. Грамотно опишите баг, опираясь на информацию в Академии Test IO (перевод академии тут)(прикрепить ссылку). Как я уже говорил ранее, красиво написаный репорт - залог успеха на любой платформе. Если ваше знание языка не позволяет писать красноречивыми фразами - используйте переводчики(Яндекс.Переводчик, Deepl), они хорошо справляются и количество ошибок машинного перевода в них крайне мало.
█ ➤ Быстрый обзор платных циклов. Вот мы прошли академический цикл. Что же делать дальше?
Перед нами открывается целый фронт работ, разберем все по порядку.
Exploratory
Является основным видом тестирования на платформе.
Во время подобного тестирования вы можете по-своему исследовать веб-сайт, мобильное приложение или программу. Платформа дает вам ограничения только в отношении областей и функций, которые должны быть протестированы, а также типов ошибок, которые необходимы заказчику.
В таких циклах не предлагаются другие методы тестирования, такие как perfomance тестинг (тестирование производительности продукта) или автоматическое тестирование.
Функции, данные для тестирования, дополнительные требования и информация из чата цикла определяют то, что вы должны проверить. В большинстве случаев предполагается тестирование только определенных областей, например, корзина, но иногда все приложение или вебсайт находятся в in-scope.
Обычно выплата за exploratory тесты будет производиться в соответствии с количеством принятых багрепортов.
Приватные циклы могут и будут различаться от обычных циклов и вся информация касаемо областей, выплат и т.д. будут упомянуты заранее.
User Stories Testing
Вас просят провести некоторую последовательность действий и подтвердить или опровергнуть результат, указанный в заголовке самой User Story.
Выглядит это следующим образом:
После нажатия на “Test User Story” вам дадут ту самую последовательность. Вы её повторяете и выкладываете результат в следующем окне.
Если все работает так, как описано – вы нажимаете на кнопку “Works”.
Если есть какие-то несостыковки, происходит другой баг или что-то еще – нажимаете на кнопку “Fails”, после чего, если такого бага нет во вкладке “Known Bugs” или “Bugs” – вы можете оформить баг-репорт и получить полную выплату.
Если что-то пошло не так и вы не можете протестировать эту последовательность – вы нажимаете кнопку “I’m blocked” и описываете причину неудачи в комментарии к истории.
Тестирование историй в данный момент находится в стадии "беты", поэтому допуск к этому типу заработка имеют не все участники платформы, важно это знать и понимать.
Bug Fix Confirmation
После того, как клиент исправит один из багов, отправленных в предыдущем цикле, он может отправить запрос тестировщикам, чтобы подтвердить, была ли ошибка исправлена или все еще присутствует. Это означает, что вам будет предложено повторно протестировать баг на его воспроизводимость и направить свой отзыв непосредственно клиенту, независимо от того, присутствует ли ошибка или нет.
Вы получите право на участие в подобном тестировании, когда достигнете количества 50 отправленных багрепортов и 100 репродукций и если ваши показатели качества и надежности равны 60 или выше.
Как только это тестирование станет вам доступно, вы увидите новый пункт меню на левой боковой панели. Здесь вы можете найти доступные и прошедшие заявки на Bug Fix Confirmation. Вы также увидите новую вкладку на своей панели с доступными запросами на проверку валидности багов.
Таким образом выглядит заявка на подтверждение валидности. Кликнув на неё, вы попадете на следующую страницу.
Там у вас будет доступ к описанию ошибки и приложению, в котором необходимо проводить все действия.
В левой панели навигации этой страницы вы также можете увидеть такую информацию, как выплата за выполнение задания и запрошенное устройство.
Внизу страницы вы увидите кнопку «Start confirmation». После того, как вы щелкнете по нему, вы зарезервируете текущее задание на время следующих 30 минут, что означает, что никакой другой тестер не сможет взять его в течение времени бронирования, если вы не отмените его вручную.
Как только вы начнете выполнять задание, вам будет представлен оригинальный багрепорт, который был представлен в тесте. Обязательно проверьте, присутствует ли проблема в новом URL-адресе, и продолжайте далее.
Попробовав повторить баг, выберите один из следующих вариантов:
«Bug is fixed», если ошибка больше не присутствует.
«Bug is not fixed», если ошибка все еще существует.
«Can't proceed», если вы не можете продолжить из-за технических проблем.
В разделе «Комментарии» вы можете оставить любой дополнительный отзыв для клиента о только что выполненном задании.
Это поле становится особенно актуальным, если вы выбираете "Bug is not fixed" или "Can't proceed".
В этом случае необходимо предоставить всю необходимую информацию касаемо этого бага, чтобы клиент смог с ней работать в дальнейшем.
Выберите браузер, который вы использовали на своем устройстве и добавьте доказательство, показывающего результат выполнения задания - скринкаст, если проблема была устранена, и скриншот, если ошибка все еще присутствует. Обратите внимание, что вложение должно соответствовать общим правилам вложений на платформе.
Нажав кнопку «Отправить», вы отправите свой отчет напрямую клиенту. Обратите внимание, что ваш отзыв будет направлен непосредственно клиенту, поэтому обязательно следуйте правилам платформы. Вы не сможете редактировать репорт, поэтому отправляйте его только после того, как все поля заполнены правильно и вы загрузили правильное вложение. Вы также можете отменить запрос на исправление ошибки в нижней части страницы, если вы не можете выполнить его.
Usability тестинг.
В эскплоратори циклах: Вас попросят представить так называемые предложения по улучшению качества продуктов. В этом случае вы можете сообщить о предлагаемых улучшениях или неожиданном поведении.
Usability Suggestions — это те или иные предложения по улучшению работы уже имеющихся функций в тестируемом продукте. Они отличаются от UX багов как минимум тем, что в предложениях по улучшению мы никаким образом не затрагиваем интерфейс и дизайн продукта.
Примерами таких предложений являются:
• В списке желаемого присутствует кнопка добавления в корзину каждого товара отдельно, но кнопки "Добавить все товары" - нет.
Это может сэкономить время для покупателя и сделать процесс работы с функцией более комфортной.
• При регистрации, некоторые "важные" поля как электронная почта, имя и т.п. не отмечены как "важные"(допустим символом звезды).
Таким образом пользователь сможет понять, какие поля обязательны для заполнения, а какие можно пропустить, что опять же повысит комфортабельность использования продукта.
В большинстве случаев такие баги оформляются следующим образом.
Текущая ситуация: Описание той или иной функции и как она работает в данный момент без улучшения
Предложение: Как можно улучшить эту функцию или область. Здесь необходимо указать прямое предложение без абстрактных мыслей.
Польза: Какую пользу принесет ваше предложение и каким образом область или функция преобразится. Необходимо убедить читающего в пользе вашего улучшения, используя веские аргументы.
Важно понимать, что подобного рода предложения хоть и исходят из личного предпочтения пользователя или общепринятых стандартов, есть ряд правил касаемо аргументов и предложений в целом:
- Нельзя предлагать изменить цвет той или иной кнопки, либо же изменить дизайн сайта в целом. Этим занимается команда дизайнеров продукта, они делают так, как их просит заказчик. Даже если вы профессиональный дизайнер - мы не лезем на чужое место.
- Предложение по расстановке элементов в области не принимают, опять же, этим занимаются другие люди.
- Изменить тот или иной элемент или область, потому что "известный специалист" так делает.
Время от времени проводятся специальные юзабилити-тесты. Настройки будут отличаться от теста к тесту, но обычно присутствуют три ключевых элемента или их комбинация:
1. «Размышление вслух»: вы должны вслух озвучить то, что им понравилось или непонравилось во время работы с приложением или вебсайтом и/или же вслух отвечать на заданные в цикле вопросы.
2. Опрос: вы должны посетить веб-сайт и заполнить опрос, включающий вопросы, связанные с продуктом заказчика.
3. Отчет об удобстве использования: тестировщики должны представить отчет об удобстве использования и ответить на конкретные вопросы в письменном виде.
Выплата зависит от проекта и предполагаемых усилий, но обычно она выше, чем для обычных тестов.
Только лучшие тестеры приглашаются на такие тесты. Чтобы стать одним из них, отправляйте хорошо описанные и качественные багрепорты, повышайте показатели рейтинга качества и надежности и следуйте всем правилам площадки.
Так же на платформе присутствуют Skill Up тесты и тесты с бонусом за участие.
Skill Up тест - это что-то вроде академического цикла, только с оплатой за найденный баг. Такой цикл приходит не от заказчика, а от самой платформы и является циклом для поднятия квалификации тестировщика. Простыми словами: вам платят за то, что вы ищете баги на выданных сайтах (их около 7) ВЕЗДЕ. Ограничений по Out Of Scope практически нет. Загвоздка лишь одна. Всего можно зарепортить 1 функциональный, 1 визуальный и 1 контент баг (всего в сумме от 5 до 10 евро за цикл). Такие тесты приходят раз в 1-2 месяца и желательно их выполнять, т.к. это неплохой прирост к рейтингу, а так же лишние деньги.
Тест с бонусом за участие - обычные платные циклы в которых заказчик дополнительно выплачивает вам фиксированную ставку (обычно 10 евро), суть в том, что вам не обязательно искать в таком цикле баги или выкладывать репродакшны, однако это все же стоит делать из соображения сохранения рейтинга на платформе. Если же у вас нет времени на выполнения цикла, то можно просто принять его и получить ставку без выполнения работы. Такие циклы приходят на более высоком рейтинге, поэтому и терять его не стоит.
Репродакшны.
Как я уже говорил, репродакшны на ИО отличается от Ютеста тем, что нам платят за них 10% от стоимости оригинального бага, но выполняется репродакшн около 2-5 минут. Возможность выполнить репродакшн есть не всегда, актуальная информация о возможности выполнить информацию всегда будет на Dashboard, а так же вы можете вручную проверить возможность воспроизвести тот или иной баг, зайди внутрь определенного багрепорта другого тестировщика в принятом вами цикле.
Оплату за репродакшн вы получите только в случае, если оригинальный багрепорт примет заказчик. Так же, как и в случае с багами, если заказчик отклонит баг по определенным причинам - вы получите бонусную выплату за проделанную работу.
Воспроизведения багов являются отличным способом заработать первый капитал на платформе, поэтому не пренебрегайте этой функцией и наоборот, советуем вам первое время заниматься репродакшнами, ибо как я говорил в первом уроке - это способ для вас заработать опыт.
█➤ Ответы на вопросы.
1. Не приходит выплата/выплата имеет статус Paid, но денег на счету нет. Что делать?
Как я уже говорил ранее, вы должны заказать выплату в определенный срок. Проверьте, сделали вы это, в меню выплат, нажав на соответствующую кнопку в меню. Если выплата была заказана - в сказанный ранее срок она получит статус Paid.
После получения статуса - денежным средствам необходимо время, чтобы они поступили на ваш счет. Крайний срок - 11 число следующего месяца. Если средства не пришли до этого времени - необходимо обратиться в поддержку платформы или платежной системы и узнать причины задержки.
2. Приходит мало платных заданий. Не с чем работать.
Для увеличения числа платных заданий необходимо указать максимально возможное количество девайсов и браузеров в них. Обязательно следите за своим рейтингом качества и активности. Регулярное игнорирование циклов или регулярное отсутствие в них активности влечет за собой ухудшение рейтинга, а отсюда следует уменьшение платных заданий для недобросовестных тестировщиков.
Так же, если у вас есть продукция компании Apple, добавьте её в список девайсов. На платформе очень ценятся тестировщики, имеющие iPhone, iPad или Mac.
3. Не могу справиться с академией.
Все тим лидеры в академическом цикле действуют строго по правилам платформы. Поэтому, если у вас что-то не получается - у вас есть несколько вариантов:
1. Перепрочтите академию и посмотрите в чем ваша ошибка
2. Просмотрите наше видео с полным разбором академии, в нем подробно описывается процесс описания багов на платформе и их поиск.
3. Если совсем ничего не помогает - обратитесь к любому из саппортов обучения, мы с радостью поможем вам и направим в нужное русло.
█ ➤ Завершение
Как видите, после прохождения академического цикла нам предстоит уйма работы. Вся она хорошо оплачивается и не менее важно - ждет вас. Так же, на все появившиеся вопросы вы можете получить ответ в промежуточном чате, либо же в ЛС у саппортов обучения.
А с вами был Кайзер, до встречи на просторах QA Project.