Drive your career as React Developer with Symphony Solutions!
×Закрыть

Питання до QC

Нещодавно здавала тест у SoftServe,у тестах потрібно вміти розрізняти localization,spelling,functional,alligment defect.
Поясніть,будь ласка, різницю між ними🙏🏻🙏🏻
І де можна про це детально почитати?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Надеюсь меня не уволят за этот пост, но за 1.5 года в SS я проработал с 6 QA на 2 проектах и слышал от них только про «functional» =))) До этого в Ciklum еще были «localization». То есть баги то связаные с остальными типами были но назывались они в тикетах / в речи по-разному, а в Jira вообще такой классификации не было)

Тут справа елементарного розуміння значення англійських слів — як можна йди працювати в ІТ і не ррзуміти що таке alignment?

Как раз поработав в айти ты начинаешь понимать что у того же alignment может быть куча значений в зависимости от контекста. Начиная от alignment of requirements заканчивая alignment of the button. Да и если qa заменит слово alignment словом position — я замечательно пойму о чем он)

І де можна про це детально почитати?

Вот самое отвратительное, что чем дальше в лес — тем больше туториальщиков, и меньше конкретной информации, написанной человеческим языком не только про «что такое severity/priority», а и где оно применяется.

Но нехорошо всем, программистов про SOLID спрашивают, по каждой букве и вопросы «а сколько вы раз в день какой паттерн используете?»

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

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

Что такое severity/priority, внезапно, определяется ПРОЕКТОМ. Да, если не идиоты, до для каждого проекта или пачки однотипных проектов они прописаны в письменном виде. И ещё страничка исключений, которые позволяют эскалировать или деклассировать инциденты, а также группировать и прототипировать expect-сущности, а то и автоматизировать создание промисов там где проблемы появляются независимо от проекта (вне его) и предсказуемые.

Чудове запитання як на мене, і достатньо легке. Особисто я б віддавав перевагу кандидатам які знають принаймі значення цих слів, перед тими які такого не знають, і по моєму це очевидно. Якщо цьому працівнику напишуть «plase check this webpage, i’ve fixed alligment mistakes» і людина не знатиме що сталось і що від неї хочуть то це не гуд

Не прошли?
Ничего страшного. В другой компании попадётся другой набор дурацких вопросов и вы на них ответите и пройдёте.

SoftServe — буквоедство и бюрократия, но в наших реалиях лучше к ним, чем в какой-то Игнайт или Puls Software.

и вы на них ответите и пройдёте

Наивное предположение. Если эти дурацкие вопросы и не менее дурацкие ответы придуманы или слизаны с не менее дурацких источников, и разумеется «единственно верные» — хрен кто пройдёт кроме выпускников их же курсов. ЫПАМ в этом никто не догонит, эти абсолютные рекордсмены уже даавно на финише и готовят основной персонал сами как в Индии (результат идентичен).

Вопросы составлял идиот. Из всего описанного только localization testing имеет какой-то общеупотребимый смысл. Не знаю, правда, чем это поможет )

Если ничего не путаю:
localization — дефект перевода. Типа гуртовщики мыши.
spelling — ачипятка.
functional — функциональный дефект, например, 2 + 2 = 5.
alignment — выравнивание. Одно поле смещено относительно 2-го на 10 пикселей.

Но могу и соврать в чём-то, давно не смотрел в эту сторону.
Где искать: в ISTQB, например.

localization — это не только перевод. А еще форматы дат, валюты, децимал символ и т.д.

Верно подмечено, спасибо за дополнение.

А я думала мене вже не здивують рівні бюрократії в українських компаніях. Цікаво для чого цей тест був (але як тут вже написали, це не про баги, а чисто про переклад цих 4х англійських слів, нащо такі формальності аж в тести це пихати)

Цей тест був для того, щоб оцінити наскільки людина орієнтується в типах тестування, відповідно і типах дефектів, і це якраз про баги, питання цілком нормальне

нет, не нормальное
1. Такая терминология (кроме локализейшн) нигде не используется
2. В чем смысл такой точной классификации?

Тут не розібрали суть питання. На «технічному тестуванні» є картинка з багом і треба його знайти і вказати тип багу(вибрати 1 з 4, вроді). Або на одному з питаннь треба знайти скільки яких багів є на картинці.

dou.ua/...​rums/topic/31370/#1925456

где не используется? Я как дев постоянно сталкиваюсь с этими терминами, как это можно не знать? Тем более тестеру

Покажи глоссарий от более-менее вменяемой тестерской организации, где бы присутствовали spelling и alignment defects как отдельные типы. А главное — зачем? Если это все равно описывается в саммари и/или теле бага.

Ви даром місите воду. По факту там питання «select what kind of bug exists on a picture» і дропдаун з варіантами.
Там не потрібно ніяких дефініцій, просто знайти баг і знати переклад тих слів. Відносно елементарні питання, перший рівень складності

Это не отдельные типы «ошибок», это английские слова, которые тестер должен знать.
Можно конечно оправдываться «мне это не надо», но это тоже самое что «мне не нужен английский».
В саммари оно не всегда будет, вполне могут скинуть таску со скриншотом и описанием «fix alignment», вместо «move button to 10px left».

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

Есть много видов багов. Как и прочие насекомые, они сильно отличаются видом, питанием, поведением.
Как правильно сказано в комментах — читайте статьи.
Как устроитесь на работу — зайдите в багтрекер,
besplatka.ua/...​ciya-komah-photo-a89f.jpg
отфильтруйте самые крупные, злобные, пофикшенные, и почитайте их описание, кто фиксил, это информативно.
Потом отфильтруйте нефикшенные баги и попробуйте их «поймать». Так кошки котят учат на пойманных мышах, постепенно развивая чутьё и рефлексы.
Самые простые баги — это

localization,spelling

и

alligment

- тупо не переведено название поля или оно «съехало».

Наркотики — зло

Впервый вижу такие понятия как:

spelling,alligment defect.

 с опытом работы QA/QC более 5ти лет. Стыдиться теперь что ли...
Даже в Глоссарий ISTQB заглянула, но и там их нет...
Зачем такое в тест вставлять? Вообще не понятно.

Понабирают гумaнитвapeй в IT, а те пытаются забить на арифметику и люто, бешено плодят сущности.

Это еще пока психологи не поняли, как ввернуть в классификацию багов психологию, нлп, вектора и соционику.

Так и запишем, никаких багов, у пользователя внутренний конфликт. Решение — забанить.

в попередній темі достатньо посилань на літературу, де це все описано, там же можна почитати і зрозуміти
Якщо Ви зараз заганяєтесь на таких питаннях, пробувати на курси в серв, можливо, ще трохи ранувато

Це бюрократична бредятина, від тих хто взагалі не розуміє природи цих дефектів. Це все одно що офіціанту треба вміти розрізняти бійку в барі від розлитого чаю.

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

Це бюрократична бредятина

Вот именно.
Тому, кому нужно будет пофиксить баг — фронтендеру/бэкендеру/контент-менеджеру — им вообще до лампочки, какой это вид бага. От этого он сам себя не пофиксит.
Их различать желательно самому тестировщику, чтобы знать, кому писать таск на фикс. Вряд ли кто-либо вообще целенаправленно пишет вид бага в таске, это тупо, время жрать только.

Вряд ли кто-либо вообще целенаправленно пишет вид бага в таске, это тупо, время жрать только.

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

Тому, кому нужно будет пофиксить баг — фронтендеру/бэкендеру/контент-менеджеру — им вообще до лампочки, какой это вид бага. От этого он сам себя не пофиксит.

Однак тип багу впливає на priority & severity, визначає сторі поінти, а значить і впливає на те коли, хто і в якому спрінті це все буде фіксати, а це вже має вплив в цілому на весь процес

От перестановки слагаемых сумма не меняется.
Это о том, что время на багфикс в сумме одинаковое, как ты ни жонглируй priority & severity. Если баг может пожить и до следующей версии, то это не тестировщик решает.
Потому вот эти все великие решения про сорта гoвнa — это имитация бурной деятельности.

Понабирают гумaнитвapeй в IT, а те пытаются забить на арифметику и люто, бешено плодят сущности.

Так, «не тестировщик решает», але на прийняття рішення впливає в т.ч. і тип дефекту, відповідно, його позначення полегшує потім роботу тим, хто приймає ці самі рішення.

при условии, что типирование проведено верно )

Це вже проблема тестувальника, для того бажано розбиратись в тих питаннях, для того і питання на тестах, про яке створена тема

нит. Могу написать типизацию в которой черт ногу сломит )) это то же будет проблема тестувальника? ))

якщо вона буде написана Вами для використання ним, а він в ній буде погано орієнтуватися і постійно помилятися, то тут 2 варіанти:
— його низька кваліфікація в цих питаннях
— Ваша типізація занадто складна, і її потрібно спростити

оба варианта — не

проблема тестувальника

— выбор допустимой квалификации исполнителя — на стороне бизнеса
— выбор модели типирования — на стороне бизнеса

заявления вида

Це вже проблема

«подставить нужное» — никак не приближают к достижению целей. А больше являются «увиливанием от ответсвенности/решения/итп».

«- с моей стороны пули вылетели, проблема на вашей стороне» ©

Это молодые манагеры лютуют, а не гуманистические твари.

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

Им в конце месяца jira отчет рисует ро этим полям, с процентами. Можно хмыкать и принимать руководящие решения.

Так же тупо, как подсчет строк кода:
Один напишет коротко, но другие его код будут неделю пытаться разобрать.
Второй напишет объемно, а другие без труда в нем все поймут.
Гуманитарий-манагер сократит второго, потому что кода больше, ага.

С багами тоже:
Один фронтендер делает все быстро, с багами, баги фиксит тоже быстро.
Второй фронтендер работает медленнее раза в 2, багов допускает меньше.
В сумме скорость первого все равно выше, но гуманитарий-манагер и тут забивает на арифметику, ему больше нравится, что второй слoyпoк верстает с меньшим числом багов.

Однак тип багу впливає на priority & severity,

Несмотря на то, что это утверждение есть факт, неверен сам принцип.
Severity — выбирается тестировщиком в зависимости от влияния на систему, но не от типа дефекта. Я могу привести примеры algnment багов с critical saeverity и functional багов с trivial severity, абсолютно не проблема. А могу — наоборот.
Priority — вообще определяется PO в зависимости от того, насколько ему пользователи грызут мозг насчёт пофиксить данный баг.
Таким образом, поле «тип бага» является не более, чем информационным шумом, который мало чем будет полезен, разве что есть корреляция между assignee и типом бага.

Тут не розібрали суть питання. На «технічному тестуванні» є картинка з багом і треба його знайти і вказати тип багу(вибрати 1 з 4, вроді). Або на одному з питаннь треба знайти скільки яких багів є на картинці. Якщо такі питання роблять проблеми для авторші то найбільш раціональна відповідь

Якщо Ви зараз заганяєтесь на таких питаннях, пробувати на курси в серв, можливо, ще трохи ранувато
Тому, кому нужно будет пофиксить баг — фронтендеру/бэкендеру/контент-менеджеру — им вообще до лампочки, какой это вид бага. От этого он сам себя не пофиксит.

какой вид — да. а вот на описание ваще не пофиг. «неправильный текст» слишком размыто и хорошо, если внутри подробного описания будут детали. А если нет? То ли дело «не соответсвует мокапу», «не соответствует реальности» или же «опечатка в сообщении о том-то».
Хз, насколько здраво спрашивать такое в тестах, но как девелопер говорю, что вообще не пофиг, умеет ли человек однозначно, коротко и в устоявшихся на проекте терминах описать проблему.
[upd] а, так, это надо для скриншота баги выбрать подходящую формулировку. Конечно, здравый подход.

вообще не пофиг, умеет ли человек однозначно, коротко и в устоявшихся на проекте терминах описать проблему

Согласен. Только это вопрос обучаемости и, как следствие, профпригодности. Меня поначалу пинали, надо мной насмехались, я стал ставить себя на место разработчика и спрашивать себя: «через год пойму ли я сам, что здесь написано?» и это помогло. Плюс шаги воспроизведения, плюс скрины, плюс ожидаемый результат, плюс фактический — всё в репорт.

А что там детально читать?
Это вообще, скорее, тест на знание английского.
localization — тестирование/баги перевода на доступные в тестируемой системе языки.
spelling — это когда написано licalization вместо localization.
functional — тестирование/баги функционала.
ᅠ ᅠ ᅠ ᅠ ᅠ ᅠ
ᅠᅠ ᅠ ᅠ ᅠ ᅠ ᅠ ᅠ ᅠ ᅠ ᅠ ᅠ ᅠ ᅠ ᅠ ᅠ ᅠ ᅠ ᅠᅠ ᅠ ᅠ ᅠ ᅠ ᅠ alligment defect — дефект выравнивания. Как когда после запятых нет пробелов.

Alligment
Allugment
Alignment — выравнивание. Это французское слово, означающее выстраивание солдат в шеренгу. Отсюда и написание с нечитаемыми гласными. От слова «линия» — ligne.

smoke test -> fog test -> Fogol test — проверка текста на читабельность и наличие хотя бы 0.1% запятых от общего числа знаков.

Подписаться на комментарии