Разбор практики академии. Часть I

11.1 Домен сайта

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

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

Домен, его нужно всегда проверять после перехода на новую страницу, чтобы не выйти за пределы тестируемой области.
Как же правильно их проверять?
В инскоуп дана такая ссылка. Но что может быть пойти не так?
Допустим, я сейчас нахожусь на впн великобритании, так как аккуант настроен на великобританию. И вижу что домен изменился на 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 вам всегда пишут комментарии по какой причине ваш баг отклонили

На этом мы с вами закончили. Мы затронули разбор домен и поддомена, выяснили как наилучшим образом пройти академию, а так же затронули важные вещи как :
Поиск багов;
Дубликаты;
Рейтинг;
Критичность багов;
И статусы багов.
На этом все. Увидимся на следующем уроке, всем пока :)