Практика uTest.

1. Приветствую всех учеников, с Вами Destiny. Поздравляю вас с началом практики на
Нашей первой площадке Utest и сегодня мы с вами в лекции разберем следующие моменты.


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

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


4.
Теперь пройдемся по старому платнику, далее более подробно перейдем академию.

Перед нами платный тестовой цикл.

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

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

Далее, Description, это краткое описание продукта.
Как мы видим тут идет речь о платформе для обмена электрическеми скутерами.
Тут очень краткое описание, обычно оно больше, сами увидите на практике)

Далее Inscope, или тестируемая область.
Что именно тестировать в приложении здесь не указано, видимо заказчика интересует вся область приложения, все ее функции.
Тут нас просто приветствуют и говорят о том, что вы имете приглашение в мобильный иследовательский цикл приложения VOI скутерс.
Так же говорится о тестовом билде приложения, тут указана версия 3.4.0
Давайте здесь обговорю нюансы, билд приложения, это версия приложения.
Если в инскоупе указана определенная версия билда, значит тестировать нужно только ее, другие версии в тестировании не нуждаются. Обычно это происходит после правок/обновления приложения и тестируют как новые функции работают со старыми.

Идем дальше. Раздел ENVIRONMENTS или окружающая среда.
Окружающая среда, это список девайсов, которыми нужно или можно тестировать приложение.
Тут говорится о том, что тестировщик может только сообщать об ошибках и / или заявлять тестовые случаи для этих сред:
Далее идут приоритетные устройства, т.е те устройства, в которых заинтересован заказчик.
Далее идет кусок тестируемой области, т.е инскоуп. Тут как и я говорил, можно тестировать все приложение, но за исключением OUT OF SCOPE, или вне области тестирования, дальше как раз будет этот раздел.
Так же важно, тут указано, что тестировать приложение можно только на английском языке.

Далее подраздел Notes, записи.
1. Тут говорится о том, что заказчика интересуют только проблемы с приложением, так же с упором на функциональные, технические баги.
2. Здесь говорится о принятии только функциональных багов на страницах Landing Webview. В этом разделе будут отклонены контент баги и визуальные баги.
3. В третьем просят не тестировать опции "отметить как отсутсвующий" и "сообщить о проблеме" для скутеров. Тут понятно, заказчика интересуют только функции для потребителя.
4. В 4 говорят о том что раздел Справка в боковом меню была обновлена. И просят проверять ее тщательно, как вы хотите, но не переусердсвуйте)
5. Тут говорится что скутеры доступны только в нескольких европейских городах и для них есть отдельный другой цикл.

Переходим к разделу OUT OF SCOPE.
Рассказываю.
Раздел KNOWN ISSUES - известные баги.
Рассказываю.

Далее раздел Issue Reporting Instructions
Тут речь о инструкции для оформления багов.
1. В первом нам напоминают что баги оформляются только на английском языке.
2. Во 2 идет образец оформления заголовка для бага.
Как мы видим в [ ] указавается наименнование девайса, версия ос.
Далее тип тестирования и после краткое описание бага.
После идут указания по вложениям к багу, т.е доказательства.
"Рассказываю".

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

Attachments
Рассказываю.
Team Contact Information
Рассказываю.
Test Case Payouts
Рассказываю.
Bug Payouts
Рассказываю.

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

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


5. Разбор академического тестового цилка.
Сейчас мы разберем старый пример академического цикла.
Начнем. Самое первое, тестовый цикл что такое?
Тестовый цикл это - определенное задание в котором сказано,
что мы тестируем например сайт либо приложение.
Как мы тестируем. Это области INSCOPE, OUTSCOPE и другие правила из описания цикла.
А так же с помощью чего мы тестируем. Это могут быть различные девайсы
используемый софт прокси vpn и так далее.
Начинаем с вкладки оверью. Тут расписанна вся информацию работы по данному цикла.
5.1 announcement
Первое что мы видим, это объявление с информацией ограненное оранжевыми границами.
Объявление присутствует не в
каждом тестом цикле и она у вас появляется когда приходит какая-то
новость от куратора. Куратор использует это для того, чтобы держать вас в курсе
всех нововведений таких как что нужно протестировать например какую-то новую
добавленную функцию либо обновить версию программы которую вы тестируете либо внимательнее читать in scope, потому что некоторые тестировщики его могут нарушать и так далее.
5.2 Следующая вкладка которая у нас есть называется Description.
В этом поле прописывается краткая информация о работе с данным тестовым
циклом. Например здесь нас приветствует, говорят что данный цикл
создан для того чтобы научить тестировщиков работать с мобильными
девайсами в циклах, научить занимать слоты, выполнять TestCase и составлять
баг репорты и так далее.
5.3 INSCOPE.
Мы видим уже знакомое для нас поле inscope. Напомню что в inscope у нас
прописывается различные моменты, которые необходимо протестировать,
указано с каких мы можем устройств тестировать, что мы должны
протестировать и другая важная информация.
Первое с чего у нас начинается inscope в данном цикле.
Как пройти в данную академию, первое необходимо просмотреть какое-то
видео по ссылке, далее необходимо полностью изучить описание тестового
цикла, это все страницы целиком на которой мы сейчас находимся и также
прочитать полезную статью, после этого нам необходимо принять
приглашение в тестовый цикл внизу экрана и занять слот под наш девайс.
Последнее нам необходимо выполнить тест кейс и
выложить хотя бы один баг репорт.
Следующее что мы можем заметить
Which Application or Website Should i Test? Здесь у нас указывается что мы конкретно должны протестировать у нас есть и веб-сайт для того чтобы мы
протестировали его с мобильных устройств и также приложение для ios и для android.
Далее мы можем заметить что у нас идет как раз перечисления что искать по
компонентам What areas should i focus my testing on?

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

5.4 OUT OF SCOPE
После этого у нас идет также знакомая нам область OUT OF SCOPE, здесь напомню указывается правила которые мы не можем нарушать.
Давайте прочитаем какие здесь у нас правила даны:

не совершать никаких заказов либо покупок используя реальной карты;
дальше не создаем аккаунт то есть мы тестируем только процесс создания
аккаунта;

не выкладываем больше трех багов.

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

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

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

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

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

Следующий пункт
никаким образом не показываете тестируемому приложению либо сайту, что вы его
тестируете либо что вы работаете от платформы или Uтест
либо aplauz тест. Данный пункт очень интересен, но давайте сразу дам
прояснение по этому поводу. Когда вы тестируете сайт либо приложение и у вас
подобным образом сказано, что вы не должны неким образом
показывать, что вы тестирощвик, нужно просто не использовать слова такие, как
тест и и тест aplauz в создании аккаунта либо в почте с которого будете
регистрироваться либо если вы проверяете работают ли комментарии.

5.5 Issue Reporting Instructions
Reporting Instructions. видно что здесь у нас инструкции по тому как мы должны
оформлять баг. Конкретно в данном цикле. Здесь сказано мы должны
просмотреть видео по ссылке, далее мы должны прочитать курс как писать баг
репорт и здесь приведены 2 ссылки , они у нас есть в переводе академии. После
этого указано по какому формату должен быть заголовок нашего бага, сначала идет
девайс, затем мы пишем область и пишем описание бага. И приведенно 2 примера И в завершении сказано, какие вложения должны быть у наших баг репортов.
Required Attachments здесь написано что каждый баг должен сопровожден тремя
вложениями. Это должен быть видео с багом и скриншот с помеченной областью. В принципе все понятно.

5.6 Special Instructions
И в самом конце у нас идет специальная инструкция здесь у нас просто продублированы статьи из
академии которые нам нужно прочитать.

5.7 Team Contact Information
Далее мы видим информацию о том, кто является нашими кураторами на цикле и соответственно это вся информация.

Немного важной информации.
Области inscope и out of scope называются областями тестирования. Когда вы совершаете поиск ошибок вы должны
ориентироваться одновременно по данным областям, если ваш баг подходит
к области in scope вы также должны проверить не нарушает ли он область тестирования исходя из out of scope.

5.8 Test Case / Review Payots.
5.9 Bug Payouts
5.10 Your Specified Environments.
С разбором академии мы закончили, теперь мы узнаем, как принимать академию и как ее пройти.

6. Как принять академию?

Мобильная и компьютерная академия принимаются одним и тем же способом.
Академии introduction принимается еще проще.
Открываем мобильную академию, мы попадаем на страницу с описанием цикла
после этого мы листаем в самый низ страницы, ставим галочку, что мы ознакомились с правилами цикла и нажимаем на кнопку
claim slot & accept после этого нас перенаправляет на страницу с выбором
слота, напомню что вы должны внимательно прочитать название слота и если у вас
есть устройство для выполнения данного слота вы его принимаете.
в мобильной академии на выбор есть android либо ios
если у вас примеру какой-то iphone либо ipad то выбирайте ios если какой-то
android устройства то соответственно android.

Забегая вперед если мы говорим про платные тестовые циклы хочу сказать, что
там могут быть другие названия слотов, например в названии слота будет указан
samsung s9 плюс это означает что данный слот вы сможете выполнить только с
данного устройства либо может быть указано android 6 0 вот здесь название
слота это означает что у вас будет возможность выполнять данный слот только
с устройство на котором установлен android 6 0 то же самое и с компьютерной
академии, те же самые правила после того как мы
выбрали с вфяами какое мы будем выполнять
слот давайте к примеру возьму ios, нажимаем кнопку claim слот и у нас
появляется окно с выбором устройство с которого мы будем выполнять данный
тестовый кейс который привязан к нашему слоту, я выбираю свои устройства и
нажимаю Claim and join. Важно что то устройство которое вы здесь
выбрали именно с него вы должны выполнять данный кейс не важно какой у
вас будет циклб нажимаем кнопку клейман же и вы увидите
вот такое вот окошко что вас заблокированы службы геолокации для того
чтобы вам успешно принять участие в данном цикле вам нужно всего лишь нажать
кнопку про цикле если вы нажмете на кнопку a return to overview
то вы просто вернетесь на страницу с описанием цикла,
поэтому нажимаете кнопку Proceed Without, после того как вы нажмете на кнопку Proceed Without, у вас обновиться страница с описанием цикла и для того чтобы убедиться что вы принимаете в нем участие, напомню вы можете перейти на вкладку project и увидите в разделе test cycles, что у вас появится данный тестовый цикл, который вы приняли на вкладке Active
мобильная и компьютерная академия принимается одинаковым образом. Если вы
будете принимать introduction академию то там работает все точно также за исключением того что вам не придется выбирать слот. Таким образом вы можете принять все три тестовых академии.

7. Три варианта, как вы можете принять приглашение и попасть на страницу с тестовым циклом

Как только вам пришло уведомление о приглашении в тестовый цикл, у вас есть
три варианта как вы можете принять приглашение и попасть на страницу с
циклом давайте их разберем первый вариант: вы можете открыть письмо
которую вам пришло ваш почтовый клиент , скопировать ссылку на тестовый цикл в которой вас пригласили и перейти по ней через настроенный девайс с включенным впн, после этого вы сразу же попадете на страницу с описанием цикла для удобства.
Сразу советую настроить свой смартфон для работы, так как вы сможете принимать заказы, даже не находясь рядом с компьютером для
этого нужно сменить язык системы на английский и сменить регион
на тот от которого вы зарегистрировались.
Перед тем как, заходить на uTest через телефон, проверьте все настройки, так же как и на компютере, через WhatLeaks.com
Второй вариант если вы уже находитесь на uTest, на главной
странице как в моем примере можно перейти на страницу с описанием
тестового цикла из раздела новостной ленты My Activity, здесь вы всегда
сможете увидеть такие моменты как изменение статуса бага, когда его
принимают отклоняют либо запрашивают дополнительную информацию, информацию о выплатах, изменению статуса TestCase,
Активность ваших друзей и так далее.
И третий вариант через вкладку project после
перехода по данной вкладке справа вы
сможете увидеть раздел Test Cycles , в Test Cycles invites вы можете увидеть список циклов в которые вас пригласили, но которые вы еще не приняли. Для
перехода на страницу с описанием тестового цикла, также достаточно нажать
на название цикла после того как вы примете тестовый цикл в разделе Test Cycles
на вкладке Active, у вас они появятся в этом списке.


8. Объясняю за слоты и кейсы.
Теперь перейдем к следующему термину TEST CASE
Это определенный сценарий, в котором перечислены шаги которые нам необходимо выполнить и мы должны после выполнения
шагов, зафиксировать позитивный либо негативный результат. После того как мы
выполнили все шаги, нам необходимо отправить тестовый кейс на проверку.
TEST CASE - это отличный бонус к вашей основной работе по поиску багов, так как
вы всегда знаете сумму выплаты за проделанную работу, вы всегда знаете
сколько у вас в среднем уйдет времени на выполнение того или иного тестового кейса. И вне зависимости от результата вам всегда будет начислена фиксированная выплата payout. Заключительный термин, который нам необходимо разобрать, что такое слоты Slots. Это выбор одного, либо нескольких девайсов для выполнения определенной работы. Какая может быть работа. Работа может быть только двух типов либо это поиск багов либо выполнение тестового сценария. (TEST CASE)Как же определить какой слот вы занимаете? Чтобы ответить на этот вопрос необходимо зайти во вкладку со слотами и посмотреть, обратить внимание на следующий нюанс, если кроме описания тестового цикла у вас нету вот такой вот синий плашки с информации как например в этом слоте. (с информацией об оплате).
Это означает что вы занимаете слот для поиска багов.
Если у вас помимо информации с описанием тестового цикла
есть также вот такая вот плашка в которой прописывается payout выплата,
среднее время выполнения - это означает
что данный слот вы занимаете для выполнения тестового сценария.
А теперь разберём самый первый нюанс, скажем так проблема с которой
сталкивается большинство учеников на первых же академиях, проблема заключается в следующем:
вам приходит первая академия, вы занимаете в ней слот для выполнения
тестового кейса и у вас возникает вопрос. Вот вы приняли к примеру слот допустим с айфона можете ли вы при этом выкладывать баги с других устройств ответ: конечно можете
Очень многие ученики на моменте выбора девайса для выполнения тестовогосценария, путаются с слотом для выполнения поиска багов.
Ребята запомните одну простую вещь если у вас есть вот
такая вот плашка(payot), то вне зависимости от того с какого устройства вы будете его выполнять, вы можете с любых устройств выполнять поиск багов, которые входят в in scope тестового цикла, но если вы выбираете слот для поиска багов в котором нет информации по выплате и среднем времени выполнения, то только с тех устройств, которые вы выберете.
После кнопки Claim слот вы можете выполнять поиск багов.
Запомните этот момент, он вам понадобится на самых первых академиях.

9. Рассказываю про типы и подтипы тестовых циклов.

При работе с тестовыми циклами полезно знать какие бывают типы и подтипы тестовых циклов.
Существует большое множество типов и
подтипов, поэтому давайте разберем самые основные,
чтобы определить с каким типом тестового цикла мы работаем нужно открыть страницу с описанием тестового цикла и сверху где написано type в кружочке будет указано сокращение типа тестового цикла
в данном примере это:
FN - сокращение от функционального тестового цикла, данный тип вcтречается
в 90% случаев.
В приоритете такого типа тестового цикла, как правило находятся функциональные баги также довольно часто можно выкладывать и другие виды багов, но упор как правило идет именно на функциональную часть.
Более детальную информацию всегда можно найти в описании к циклу.
Следующий тип тестового цикла - юзабилити, в приоритете находится performance, юзабилити либо визуальные баги.
И еще реще можно встретить
тип : localisation тестовые циклы. Сокращение будет написано LN, как правило
происходит тестирование перевода на сайтах, либо приложениях, то есть на
первом месте в таких тестов циклах будут контент баги.
Это основные типы тестовых циклов с которыми мы будем работать.
Остальные типы циклов приходят как правило Survey, по специальным опросам.

11. Разбор практики академии.

11.1 Домен сайта

11.2 Поддомен сайт

Беру сайт https://www.adidas.com/us

Домен, его нужно всегда проверять после перехода на новую страницу, чтобы не выйти за пределы тестируемой области.
Как же правильно их проверять?
В инскоуп дана такая ссылка. Но что может быть пойти не так?
Допустим, я сейчас нахожусь на впн великобритании, так как аккуант настроен на великобританию. И вижу что домен изменился на co.uk.
Данный домент будет выходить за пределы тестируемой области.
Если домен указан .com, значит нам нужно включить впн США.
Включаем. Все, видим, что у нас теперь .com как и в инскоуп.
Так же если вы тестируете без впна, вас можете перевести на домен .ru
За этим необходимо внимательно следить.
Если в инскоупе написано при необходимость тестирования через ютест-прокси, то тестируем сайт с помощью них.

С доменами разобрались. Давайте теперь перейдем к поддоменам.
Если в тестовом цикле указано тестировать конкретный поддомен.
Например carrers.adidas-group.com.
Нас интересует часть carrers. Как видите основной домен тоже изменился с adidas.com на adidas-group.com. К сожалению для примера на сайте нет идеального раздела.
Если указан данный поддомен carrers, то тестируем исключительно этот раздел, по списку областей из inscope.
Еще один пример https://www.adidas.com/us/men
Если указанна такая ссылка, значит мы тестируем сайт исключительно в разделе /men. Правила все аналогичные.
Так же может быть указано и несколько поддоменов, правила аналогичные)
Не забывайте. После каждого перехода на новую страницу, проверяйте адрес сайта, чтобы вы не ушли на стороннюю область.
Если после смены айпи с помощью впн или прокси, домен у вас не меняется, то нужно почистить куки и перезайти на сайт. Для этого нужно зайти в настройки браузера и полностью почистить историю.

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

11.3 Чем отличается юзабилити и визуальный баг?
Следующий нюанс когда ученики путают юзабилити баги с визуальными багами.
Чтобы не путаться в этих двух видах, запомните простую вещь.
Юзабилити баги в отличии от визуальных багов не нарушают целостность информации. И напомню что юзабилити баги, это баги связанные с дизайном.
Приведу пример. Представьте, что на ютесте справа вверху в одном из браузеров иконка чата съехала чуть наверх. Мы видим деффект, который не нарушает целостности информации, так как текст читабелен и все картинки полностью доступны для просмотра. Поэтому данный баг будет являться юзабилити.
Если же ваш баг нарушает целостность информации, то он подойдет к типу визуального бага. Так же приведу пример, когда один текст наехал на другой текст, либо когда картинка заехала на другую картинку. В данном случае целостность информации будет нарушена.

11.4 Правило множественного воспроизведения бага перед оформлением.
Еще один важный нюанс. Когда вы нашли баг обязательно пробуйте его заново воспроизвести. Желательно почистить куки или открыть браузер в режиме инкогнито. Это нужно для того, чтобы понять, произошел случай баг или баг постоянный. Чтобы почистить куки, вам необходимо открыть настройки браузера, открыть историю, почистить историю, а так же данные.
Так же нужно обратить внимание на описание цикла. Можно ли выкладывать баги, которые не воспроизводятся несколько раз, так как куратор всегда будет пытаться воспроизвести ваш баг.
Если ваш баг воспроизводится переодически, например 4 раза из 10, то такой баг выкладывать можно и вы можете указать это в вашем баг репорте.

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

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

Если мы заговорили про часто встречаемые ошибки, давайте их перечислим.
Советую вам куда-нибудь записать эту информацию.
1 самый встречаемый баг - кнопка либо ссылка не работает.
Ссылок на сайте встречается много и данные на которые они ссылаются часто изменяются, удаляются, либо переезжают на другой адрес. С кнопками сложнее, они либо не работают либо перестают работать после каких-то действий пользователя.
2 самый встречаемый баг - деффектное перенаправление
Нужно всегда внимательно проверять куда вы нажимаете и вы должны всегда думать о том куда вас должно было перенаправить . Приведу пример, вы нажимаете на ссылку поддержки на сайте, но у вас открывается главная страница сайта. Это как раз таки и будет деффектным направлением.
3 самый встречаемый баг, приложение где используются фильтры или сортировка, они могут работать некорректно. Допустим в находитесь в разделе обуви, выбрали кроссовки и в поле фильтра выбрали диапозон цены от 50$ до 100$, после применения, вы смотрите выпавший список товаров и видите, что у вас присутствуют кроссовки за 230$. Такие баги бывают часто.
4 самый встречаем баг, когда у нас неверная итоговая цена. Довольно часто, данный баг встречается в интернет магазинах, когда не корректно применяется акция или не верно рассчитывается цена.
Есть еще несколько часто встречаемых багов, например когда изменение одного параметра обновляет другой параметр, либо сбрасывает его. Опять же часто такой баг встречается на сайтах и приложениях где есть сортировка и фильтры. Может быть такое, что сортировка и фильтр по отдельности работают корректно, но стоит вам настроить одновременно фильтр с сортировкой, то какой-то элемент перестанет функционировать, либо будет функционировать не корректно.
Так же часто встречаемые баги, визуальные. Когда картинка либо текст наезжает на какой-то другой элемент и целлостность информации нарушается.
Мы обсудили стратегию по поиску багов, которые пользуются все тестировщики и показала себяс хорошей стороны на длительной дистанции.

12. Дубликат
Теперь поговорим о таком термине как дубликат и почему нам важно его избегать.
Как вы должны были знать из академии, при работе с багами нельзя допускать дубликат. Давайте разберем, что это такое? И я вам приведу несколько примеров.
Дубликаты - это баги с общем корнем проблемы. Понятие довольно краткое, но станет гораздо понятнее после нескольких примеров.
Представьте, вы тестируете какой-то сайт. Как допустим у меня adidas.com и внизу экрана есть несколько ссылок.
Допустим About Us, Students, Adidas Stories. Не важно куда ведут эти ссылки.
Если вас на одну или две из ссылок перенаправит на ошибку 404, ты вы не сможете выкладывать эти баги как отдельные, так как они имеют общий корень проблемы и будут являться дубликатами.
Но если допустим, при нажатии на первую ссылку вас перенаправляет на страницу с 404 ошибкой, а при нажатии на вторую страницу вас перенаправялют на пустую страницу. Это будет два разных бага. И их можно выложить отдельно и они не будут являться дубликатами, так как корень ошибки у них разный.
Также необходимо учитывать, что вне зависимости от того, где находятся баги и в какой области, если у них один и тот же корень проблемы, то это все равно будут дубликаты.

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

13. Рейтинг
Вы также должны были прочитать информацию о том, как строится рейтинг, но давайте разберем это более детально. Для того, чтобы узнать какой у вас сейчас рейтинг. Вам необходимо нажать Tester profile и перейти на вкладку Statistics.
Здесь будет вся статистика, в которой вы увидите сколько у вас было принятых тестовых циклов, сколько вы выложили багов, сколько вы сделали тест-кейсов и остальная информация. Ваш рейтинг, как вы должны знать зависит от двух показателей: Это активность и качество.
Показатель качества зависит от соотношения принятых багов к отклоненным, а так же от критичности выложенных вами багов. Чем больше у вас принимают высоко критичных багов, чем соотвественно выше будет ваш рейтинг, что касается активности. Активность растет от количества выложенных вами багов и сделанных репродов. Репроды это воспроизведение чужих баг-репортов. (показать график)
Тут вы можете увидеть изменение вашего рейтинга и разуемеется посмотреть диаграммы на которых отображается статистика по принятым, отклоненным и еще не расмотренных баг-репортов. После видеоурока, мы прикрепим к материалу статью из академию, где указанно какие существуют рейтинги и какой нужен дляних порог показателя рейтинга. Чем выше рейтинг, тем больше вам будет приходить платных циклов, а так же будет больше доплата за принятые баги.
Если говорить в целом, от чего зависит количество платных заданий, то помимо рейтинга, учитывается ваш опыт на платформе, а конкретно количество платных циклов, в которых вы проявляли активность и разумеется важный нюанс, количество ваших девайсов, которые вы указали в Tester Profile. Еще дам совет, кроме добавления новых устройств, рекомендую хотя бы выложить по несколько багов с этих устройств.
Теперь мы знаем из чего строится рейтинг и зачем он нам нужен.

14. Критичность багов (Somewhat/Very/Exceptional)
Теперь давайте поговорим более детально о критичности багов. Критичность багов влияет не только на ваш рейтинг, но и на стоимость вашего бага (покзаать страницу с оплатой), чем критичнее ваш баг, тем соотвественно больше денег вы заработаете и больше рейтинга вы получите. Таблицу с оценкой критичности багов вы всегда можете найти внизу любого цикла в области описания.
Вообще существуют три типа критичности багов.
Минимальной, средней и высокой критичности. Если вам приходит тестовый цикл, в котором заказчик не пишет конкртеику о том какие баги будут являться, более критичными, то руководствуйтесь следующими правилами:
Если ваш баг полностью ломает функционал на сайте либо в приложении и при этом данный баг нельзя обойти никаким путем, то баг будет считаться средней или высокой критичности.
Давайте приведу пример: Если к области тестирования относится кнопка регистрации, но при этом сам процесс регистрации и происходит баг:
При нажатии на кнопку регистрации, вас не перенаправляет на следующую страницу. Данный баг допустим происходит на нескольких устройствах, а также на нескольких браузерах. Данный баг будет считаться как раз средней либо высокой критичности. Если ваш баг не является критичным для конечного потребителя и особо не влияет на функционал тестируемого продукта, то баг будет считаться минимальной критичности.
После того как вы выложите баг, обязательно проверьте воспроизводится ли он на других устройствах или браузерах. Если баг воспроизводится на других устройствах, а так же браузерах, то обязательно укажите это в баг-репорте. Это прибавит критичности вашему багу.

15. Как правильно пройти академию?
Теперь когда вы понимаете из чего строится рейтинг и как определяется бага, я расскажу в чем же заключается смысл прохождения академии и как ее правильно пройти. Академия нам нужна не только для того, чтобы получить галочку за ее прохождение и не только для того, чтобы научиться оформлять баг-репорты и работать с тестовыми циклами. А так же для того, чтобы набрать начальный рейтинг.
Давайте подытожим всю информацию и определим как же нам успешно пройти первые три академии.
Для успешного прохождения всех академий вам нужно, не только выполнить все условия описанные в описание тестовых циклов, но и выложить максимально допустимое количество наиболее критичных багов.
Если вы внимательно прочитаете условия циклов, то в совокупности на 3 академиях, вы можете выложить 7 багов.
15.1 Статусы багов (Pending/Request/Approved)
Для полноты картины, нам так же необходимо разобрать какие бывают статусы багов. Статус багов мы можем увидеть на странице с нашим багом внутри тестовго цикла, вот в этом разделе (issues, на примете тест цикла.), а так же слева во вкладке Projects в выпавшем списке в под разделе Issues.
Когда мы только что отправили наш баг-репорт, у него будет статус NEW. Через некоторое время статус бага поменяется на pending и при этом в текстовой части баг-репорта уже нельзя будет внести коррективы. После статуса Pending куратор начнет рассматривать ваш баг-репорт. После этого статус Pending, поменяется на один из трех статусов :
а) Первый вариант Request info, данный статус означает, что от вас необходима дополнительная информация либо необходимо внести какие-то корректировки.
Для просмотра инструкции от куратора, нужно зайти на страницу с данным баг-репортом. Чтобы зайти на страницу с баг-репортом, вы должны сделать следующее, заходите в тестовый цикл, нажимаете вкладку issues и в списке находите свой баг, можно поставить галочку My bugs Only. Нажимаете на название своего бага и здесь у вас появятся информация, которую написал куратор.
б) Второй вариант, если ваш баг принимают, то статус бага будет Approved и он будет выделен в зеленый цвет. Когда ваш статус поменялся на aproved, вы так же сможете увидеть какой конкретно тип апрува принадлежит к вашему багу.
Первый тип WNF WILL NOT FIX, данный статус означает, что ваш баг репорт либо не подходит под тестовую область либо не проходит по критерям критичности тестовой области, от него вы не получаете рейтинга, но получаете минимальную выплату.
Второй тип Somewhat, минимальная критичность бага, показатель качества у вас почти не прибавляется, но при этом растет активность
Третий тип Very, средняя критичность. Показатели активности и качества неплохо идут в плюс.
Четвертый тип Exceptional, высокая критичность бага, дает вам еще больше активности и качества.
в) Если же ваш баг отклоняют, то его статус становится Rejected и будет выделен красным цветов.
1 тип, Rejected DNFI, Выдают в случаи когда вы нарушаете Out of scope.
2 тип, Rejected WAD, Work s designs, означает, что работает как задумано.
3 тип, Rejected Duplicate, сокращенно Rejected (DUP), о нем вы уже знаете.
4 тип, Rejected Other, что означает другая причина. Если вам ставят отметку other вам всегда пишут комментарии по какой причине ваш баг отклонили

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

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

Первым делом, что мы должны указать в баг-репорте, это ваш заголовок, issue title, заголовок бага мы всегда составляем из инстукции написанной в описании цикла, эту информацию мы можем увидеть на самой странице баг-репорта, либо же в оверью тестового цикла. Сперва мы должны указать девайс. Здесь все понятно.
Дальше у нас идет область бага. На этапе определения области бага очень часто тестировщики делают ошибку, неправильно определяют область. Чтобы правильно определить область бага, нужно запомнить простую вещь: Областью бага будет являться целиком вся страница, на которой располагается баг. Если у вас на сайте, на главной странице, не важно сверху экрана, внизу экрана, посередине, происходит какой-то баг, то областью будет главная страница сайта или по другому хоумпейдж. Для других областей иногда используются аббревиатуры, с их списком вы сможете познакомиться после лекции.
После того как мы указали область бага, мы ставим тире и указываем описание бага. Здесь так же очень многие тестировщики совершают большое количество ошибок. Когда вы пишите описание баг-репорта, это последний пункт в заголовке. Всегда пишите его разборчиво и максимально конкретно. Я рекомендую использовать следующий языкой скрипт. "При таком-то действии, происходит такой-то результат" и давайте разберем на моем примере:
При нажатии на кнопку "Learn more" меня перенаправляют на пустую страницу.
Я всегда советую использовать этот скрипт для заголовка, так как он самый универсальный.
Тип бага мы определяем строго по правилам академии.
Далее у нас идет пункт Frequency(фриквенси), это частота воспроизведения бага.
Если вы смогли воспроизвести баг хотя бы 2 раза подряд, можете указать частоту EveryTime(всегда), если баг воспроизводится с нескольких попыток, то лучше указать (часто) Hardly Eyce.
Следующий пункт Priority, или же Приоритет. Отвечат, как мы сами оцениваем критичность данного бага. Это никак не повлияет на оценивании критичности вашего бага, со стороны заказчика, но в любом случае оценивайте адекватно, как вы считаете.
Май энвеременс (моя среда),здесь вы указываете девайсы и браузеры, с которых получилось воспроизвести ваш баг. Данный пункт может повлиять на конечную критичность вашего бага, поэтому не игнорируйте его.
Далее перейдем к описанию шагов:
Здесь все довольно очевидно, если будете соблюдать правила академии и будете сверять свой баг-репорт по правилам академии, то никаких ошибок вы не совершите. Я заметил, только одну часто встречающуюся ошибку, которую не явно описали в академии. Она связана с самым первым шагом. Вам нужно запомнить следующее:
Если вы тестируете сайт, то в первом шаге вы всегда пишите 1. Open testsite и полностью вставляете ссылку в том виде, в котором она дана в инскоупе.
Если вы тестируете мобильное приложение, то в первом шаге вы всегда пишите - Open test app "Название приложения"
Далее у нас идет описание ожидаемого результата. В ожидаемом результате мы пишем свое ожидание, как должна работать та или иная функция, если ваш баг связан с функционалом, если ваш баг не связан с функционалом, а например связан с опечаткой в тексте. В этом случае вы указываете - что ожидаете увидеть текст без ошибок на той или иной странице. Вы так же можете использовать следующий языковой скрипт:
"Я ожидаю, что после такого-то действия на такой то странице, будет такой-то результат." При этом, старайтесь указывать как можно больше деталей.
Давайте приведем пример: Я ожидаю, что когда нажимаю на кнопку "Learn More" в секции Food, я буду перенаправлен на следующую страницу, где я смогу увидеть какую-то информацию про это заголовок.
Следующий пункт у нас называется актуальный результат.
В актуальном результате вы можете использовать похожий скрипт и написать: После того как вы делаете то или иное действие, происходит такой-то результат, в следствии чего так и так. Давайте приведем пример, "После нажатия на кнопку "Learn More" меня перенаправляет на пустую страницу, поэтому я не могу найти информацию про данный топик"
В Error Message, вы указываете код ошибки, который выдает сайт или приложение. (пример ошибка 404), если сообщения никакого нет, то указывать в этом поле ничего не нужно.

16. Вложения.
Напомню, что требования по вложениям у нас всегда написаны в описании цикла. Если мы говорим про самую первую академию, Introduction, то там нужен только 1 скриншот. На скриншоте должна быть пометка, с помощью красного прямоугольника, с областью где происходит баг.
Если мы рассматриваем мобильную и компьютерную академию, помимо скриншота, мы должны записать видео с багом и записать лог.
По поводу видео, требуемое правило, которое нужно соблюдать - это формат .mp4 (h264). Вне зависимости того, какой программой вы пользуетесь для записи видео, вы всегда можете настроить данный формат. После видеоурока, ученикам будет предоставлен софт вместе с программой для записи видео с экрана и скриншотом настройки программы. И последнее, что касается логов, логи должны быть всегда в формате .txt . Об этом не забывайте, это очень строгое правило, которое нужно помнить.

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

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

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

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

18. Стоит ли отклонять не нужные платные циклы?
Нам часто задают вопрос, в академии сказано, если отклонить тестовый цикл, то мы получим дополнительный рейтинг за честный ответ. Стоит ли это делать?
Спешу сразу ответить, делать этого категорически не стоит. Потому, что даже если у вас нет времени на то, что бы поработать в данном цикле, если вы его отклоните, в дальнейшем он может вам не прийти, а там вероятно будут доступны какие-то слоты с тестовыми кейсами, на которых вы бы могли заработать какую-то сумму денег. Поэтому делать это, я крайне не рекомендую. Поднимать рейтинг мы будем, исключительно на наших баг-репортах в академии и платных циклах. И так же последний вопрос, перед тем как мы перейдем к логам.
Какой софт мы будем использовать? Весь софт, который нам понадобиться с работой на данной платформе, мы предоставим после публикации видеоурока.
Софт мы будем использовать следующий:
Для компьютера, для записи видео мы будем использовать ice scream screen recorder.
Если у вас Mac, можете использовать встроенные утилиты.
Что бы записать видео с android, мы можем использовать такие программы как azt recorder. Либо любые другие аналоги.
Чтобы записать видео с айфона, нам не нужно закачивать никакие программы, мы воспользуемся встроенным виджетом.


19. Что касается записи логов:
Для записи логов, мы используем различный софт. Все зависит от связки ваших девайсов.
Если у вас пк Windows, но телефон iPhone. То вам нужно будет установить программу 3utools, которая так же идет в списке с нашим софтом.
Если к примеру у вас macOS и iPhone, то рекомендуем использовать программу iMazzing, ее можно установить по специальной ссылке, которую мы предоставим вам после видеоурока.
Если вы используете пк Windows/macOS в связке с андроид, то рекомендуем использовать platform tools. Инструкции по настройке платформ тулс мы так же приложим к видеоуроку.

20. А теперь давайте разберем несколько примеров, как записывать логи.
Логи с хрома;
Логи с IE;
Запись логов с новой страницы;
Запись логов с айфона.
Тут я сам расскажу

21. Советы по безопасности аккаунта на ютесте:
1. Не показывайте в вашем видео или в ваших скриншотах, любое упоминание/иконки VPN. VPN настрого запрещен на ютесте.
2. Так же я советую удалить все расширения браузеров, в особенности блокировщиков рекламы, так как они могут искажать контент на сайте и могут выдать ложный баг. А куратор увидя их сразу, отклонит ваш баг.
3. Отключите антивирус, на время тестирования.
4. Не показываете никаких русских букв или слов на своих вложениях.


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