Dalay_LAMO

нужна помощь.обьясните КАК сделать?

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

Мужик,

В - внимательность.

Здравствуйте, подскажите пожалуйста чем именно поможет консоль разработчика в тестировании?
Знаю что с помощью консоли можно:
-навести на елемент, посмотреть код, стили, сколько пикселей, сыллку и тд
- responsive посмотреть как отображается сайт в разных расширениях на моб.телефонах, планшетах
- посмотреть в консоли ошибки
- посмотреть во вкладке "network" какие процессы запускаются и какие ошибки выводятся к примеру нажатию на кнопку
 
А как Вы пользуетесь консолью?

Собственно, бОльшую часть ты уже описал. Просмотр и редактирование HTML-кода (для разных целей) и стилей. Эмулятор мобильных устройств. Console - просмотр js ошибок, плюс можно выполнять команды. Network - просмотр запросов/ответов, времени выполнения, throttling (эмуляция медленного инета). Application - просмотр и редактирование содержимого LocalStorage (там же можно и куки редактировать, но я юзаю кукименеджер для этих целей). Остальные вкладки не использую.

И подскажите преимущества Firebug в мозиле над консолью.Спасибо

Не знаю таких.

"overcvalified"?

Точно upper-intermediate? 
По сути уже верно посоветовали - если решение принято, то не надо оттягивать поиск работы на год - надо уже в январе рассылать резюме и ходить по собеседованиям. Описанного бэкграунда для работы уже должно быть достаточно. Про возраст не стоит париться - туда, где не готовы рассматривать из-за возраста или других причин, явно указанных в резюме, скорей всего просто не позовут на собеседование.

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

 
Согласен в целом. Только у меня есть сомнения в наличии аналитиков на данном проекте:
 

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

Логично при запиливании фичи запрашивать у разработчика affected area. Проблема в том, что разработчики далеко не всегда способны грамотно описать (или даже понять) эту саму affected area - и часто получается 2 крайности: "проверить достаточно только это, больше ничего не трогал" и "стоит проверить всё, сломаться могло что угодно".
Ну и как выше правильно советовали - улучшать чек-листы, добавляя зависимости (после всплывших багов и после более глубокого анализа).
Чек-листы пишут все тестировщики? Есть ли перекрёстное ревью чек-листов?

Да, хороший вариант :)
Но в браузере всего не протестируешь) Простой пример: начинаешь вводить что-то в форму с мобилы или планшета - вылазит клава и перекрывает пол экрана, а то и вообще ломает верстку.
 
Меня интересуют именно мобилки, планшеты. Есть ли такая практика - юзать реальные девайсы для тестирования? Может есть какое-то проверенный временем набор маст-хев девайсов для тестов веб-приложений?....
upd ну или если эмулятор, то тоже их там много довольно, не помешает совет в выборе хороших эмуляторов.

Набор девайсов зависит от конкретного проекта. В проектах, где заходит речь о тестировании на реальных девайсах, с вероятностью 99.99% собирается аналитика по посещениям. В ней можно посмотреть, какие разрешения экрана и версии ОС наиболее популярны, исходя из этой информации несложно выбрать девайсы.
Я при тестировании веб-проектов обхожусь хромовским эмулятором, на девайсах смотрю только нативные приложения. Пробовал смотреть на эмуляторе Android SDK, но советовать этот способ точно не буду.
В вышеописанном кейсе с экранной клавиатурой может помочь экстеншн (например, этот - https://chrome.googl...addkoolinlfninn), также встроенный эмулятор в хроме может показать, как будет выглядеть сайт с экранной клавиатурой, но только на Nexus 5X (в будущем, возможно, появятся ещё девайсы), но в виде картинки (взаимодействовать с ней нельзя).

В стартовом посте вопрос абстрактный и ответить однозначно нельзя. Я ответил исходя из своих реалий и представлений: бесполезные таски в трекер заносить не нужно (да, я выяснил "бесполезность" в конкретном случае - ни один фронтендщик технически не может гарантировать корректность вёрстки на любых масштабах, таковы реалии веб-разработки). Если бесполезность неочевидна, если есть какие-то иные причины (тут фигурировало "прикрыть свои тылы", информировать кого-то), то баг завести можно.

 Их интересуют "серьезные" ошибки

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

Ещё раз - в первом посте нет ни слова про мобильную версию, обсуждаем поехавшую вёрстку при масштабировании. Зачем в очередной раз подменять темы? И опять же я привёл пример, когда и такая ошибка (неадаптивная вёрстка) не будет интересна ни начальнику, ни заказчику.
"некорректно на андроид хроме с масштабом по умолчанию" - это неправда, на множестве современных устройств с диагональю от 5.5" всё выглядит отлично, всё-таки на данном форуме стоит более тщательно подходить к формулировке ошибки.

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

Это связано с альтернативной одарённостью разработчиков шибко умных анти-спам фильтров в мэйл.ру. Два года назад они попортили немало крови многим компаниям (я работаю в одной из таких) своими фильтрами, правила работы которых узнать было невозможно (и статья на хабре была - https://habrahabr.ru/post/223149/). Теоретически правила декларировались, но по факту, рассылки, сделанные по всем правилам, пользователям не доставлялись (рассылки абсолютно легальные, на которые получено явное согласие пользователя). При этом внятного ответа от их поддержки было невозможно добиться в разумные сроки.
Но это вроде как в прошлом, систему доработали, теперь всё работает достаточно прозрачно. И если письма не доходят, значит не достаточно хорошо налажена система отправки писем у того ресурса, откуда вы ждёте письмо.

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

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

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

По теме: по вводным данным из первого поста устроиться начинающим удалённо есть шанс только если будешь представлять интерес как специалист в какой-то предметной области. Подумай, могут ли твои опыт и знания на текущей работе (или хобби) пригодиться в реальном проекте?

Какая-то странная тема. Вроде называется "обсуждение багов", а по факту вопрос по требованиям. В данном случае не вижу необходимости ограничивать длину поля - данные, введённые в поле, логично сериализовать и провалидировать на стороне сервера (в случае успеха - записать в базу, неуспеха - отправить ошибку). Вопрос "как именно должна работать валидация" - это уже вопрос бизнес-требований. И лучше спросить у заказчика, зафиксировав требования, а не выстраивать предположения, подобные этим:

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

Например в форме уже будет отображено "+38(0__)-__-__-___". Курсор ввода сразу установить после "0" и разрешить ввод, редактирование и перемещение курсора в пространстве символа "_". Это полностью покрывает пул номеров всех областей Украины и мобильных операторов.

Так как они в определённых случаях могут быть неверными и привести к потере клиента. Немного поразмышляв, придумал пару кейсов - 1). телефон с добавочным номером может быть у ремонтной мастерской, арендующей помещение на территории какого-нибудь завода/склада/бизнес-центра 2). Человеку из соседнего государства, живущему рядом с границей, может быть выгодно купить в магазине, заказав доставку в ближайший к нему приграничный населённый пункт. Вопрос реалистичности этих кейсов для конкретного магазина - это вопрос бизнеса.

Возможно, кто-то не знает, но Хром из коробки умеет эмулировать скорость соединения (во вкладке Network можно выбрать необходимый throttling). На момент создания этой темы такой фичи не было :)

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

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

А по поводу окна - "всплывающее окно" мне приятнее, хоть и больше букв :)

Оно несомненно может быть кому-то лично приятнее, но от этого не станет более удобным. У нас есть один менеджер, далёкий от технических терминов, так он в ТЗ называет попапы "всплывашками", зато без улыбки его ТЗ не прочитаешь:)
В слове "попап" всего 5 букв, термин точный и не содержит никакой двусмысленности, поэтому я выступаю за его использование. При этом я скорее против использования слов типа "откастомайзить", "засаппортить", "засетапить" и проч., у которых есть простые удобные синонимы в русском языке.

Не от ТКС,а вот откуда качать приложение не было сказано. Я так понимаю предполагалось что из маркета.

Если бы ТКС просил протестить своё приложение, выделив на это 2 часа, задание выглядело бы вполне адекватным. Апелляции к сложности задания, непредоставлению девайсов и доступов к тестовым серверам мне кажутся надуманными.
Прочитав описание на сайте, я не вижу какой-то заоблачной сложности функционала.
Про личный девайс - я бы не взял на работу тестировщика мобильных приложений, у которого нет личного девайса.
Доступ к тестовому окружению тоже не считаю чем-то необходимым в контексте двухчасового задания.
В общем, если бы задание шло от разработчиков этого приложения, то оно было бы адекватным на мой взгляд. И подозрения в накрутке количества установок как-то не слишком реалистично выглядят - т.к. задание было выдано после предварительного собеседования в скайпе, такая накрутка выглядит слишком ресурсо-затратной.
Но то, что такое задание даёт компания, никак не относящаяся к разработке этого приложения, ставит меня в тупик.

А какая конечная цель компании?

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