[AntiHazzicostas]

Сравнить любую локацию Легиона

Если бы локации в легионе не были пустыми, то они бы вызывали какие-то эмоции при возвращении в них, но нет.

Купи глаза себе что ли.

[Rain_off]

Купи глаза себе что ли.

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

[AntiHazzicostas]

Купи глаза себе что ли.

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

Причем здесь понравились и проработанность? Если ты не в состоянии увидеть, что условный ревендрет сделан из одних и тех же ассетов путем ctrl+c и ctrl+v а условная Азсуна нет, и там ассетов тупо больше раза в 3, то да, купи глаза.
Можно еще сурамар с утробой сравнить, как раз все логично будет, типо топ-зона на данный момент, тоже в первом же патче аддона добавленная. Только где утроба и где сурамар, ага.

[PhantomButthurt]

Как раз таки технически стало хуже. Как по кол-ву багов, особенно багов в СТАРОМ контенте, которые появляются после обнов, так и по кол-ву уникальных ассетов. Их тупо меньше. Из з а чего те же локации выглядят пустовато и однообразно. Сравнить любую локацию Легиона и локации из ШЛ. По аналогии - расколотые острова с ковенантами и утроба vs сурамар.

Ого, глядите-ка, у нас тут разработчик из отдела тестирования, который знает точное количество багов в разных дополнениях.

[Cold_Arpil]

Интересно, чем этот отдел занимается? 

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

Люди платят деньги за продукт. Если продукт некачественный они справедливо ему ставят за луженную оценку. К чему тут пук про школьников?

Что есть качество?
Как его определить?
Кому то нравится. Кому то не нравится. Как нравится или не нравится относится к качеству?
QA отдел проверяет работоспособность продукта на соответствие техническим требованиям и описанию.
А нравится и не нравится - это работа аналитика, маркетинга, в конце концов менеджера проекта и продукта...
Обеспечение качества на 100% контента невозможно априори исходя из самой теории обеспечения качества.
Или вы можете это опровергнуть и похвастаться собственноручно выпущенным качественным продуктом?

У каждого своё понятие качества ПО, но в целом качество ПО определяется:
Возможностями, благодаря которым оно понравится пользователю
Недостатками, которые вынуждают пользователя приобретать другое ПО

И как QAшник могу сказать, что качество ШЛ оставляет желать лучшего.

[AntiHazzicostas]

Как раз таки технически стало хуже. Как по кол-ву багов, особенно багов в СТАРОМ контенте, которые появляются после обнов, так и по кол-ву уникальных ассетов. Их тупо меньше. Из з а чего те же локации выглядят пустовато и однообразно. Сравнить любую локацию Легиона и локации из ШЛ. По аналогии - расколотые острова с ковенантами и утроба vs сурамар.

Ого, глядите-ка, у нас тут разработчик из отдела тестирования, который знает точное количество багов в разных дополнениях.

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

[arkan]

Интересно, чем этот отдел занимается? 

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

Люди платят деньги за продукт. Если продукт некачественный они справедливо ему ставят за луженную оценку. К чему тут пук про школьников?

Что есть качество?
Как его определить?
Кому то нравится. Кому то не нравится. Как нравится или не нравится относится к качеству?
QA отдел проверяет работоспособность продукта на соответствие техническим требованиям и описанию.
А нравится и не нравится - это работа аналитика, маркетинга, в конце концов менеджера проекта и продукта...
Обеспечение качества на 100% контента невозможно априори исходя из самой теории обеспечения качества.
Или вы можете это опровергнуть и похвастаться собственноручно выпущенным качественным продуктом?

У каждого своё понятие качества ПО, но в целом качество ПО определяется:
Возможностями, благодаря которым оно понравится пользователю
Недостатками, которые вынуждают пользователя приобретать другое ПО

И как QAшник могу сказать, что качество ШЛ оставляет желать лучшего.

Как QA-инженер, могу сказать, что на уровне разработки и тестирования ничем вышеуказанным качество ПО не определяется.
То, что вы указали, есть часть аналитики, которая проводится ДО принятия решения о разработке продукта.
Т.е. это комплекс мероприятий, который определяет, что именно хотят пользователи, каким они его хотят и когда они его хотят (понятное дело, что всегда). Далее это накладывается на текущий статус продукта и график работы команд по нему, выдвигаются требования и описание. А согласно ним производится разработка и дальнейшее многоэтапное тестирование.
И вот на уровне QA никто не сидит и не определяет - нужно это или не нужно пользователям. Есть требование  создать кнопку "Убить всех". При нажатии на кнопку все умирают. Значит все работает, с точки зрения замысла.
И вот по сути, основываясь на личных наблюдениях, с выходом каждого нового контента - багов все меньше и меньше в этом самом новом контенте. А в старом да - много, т.к. регрессивное тестирование в бОльшей части отводится на автоматизацию и альфа/бета-тестирование пользователей. Охватить все целиком невозможно в принципе. А каждый раз с выходом нового контента - старого становится больше и больше. Но поскольку старый контент становится неактуальным для большинства пользователей - приоритетом он не обладает. Причем баги даже могут быть известны, но сроки их исправления - туманны.

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

[AntiHazzicostas]

Чувак, обычному игроку строго похрену что там и как работает. Он видит баги там где их не было  и делает вывод, что разрабы - криворукие. Все.

[arkan]

Чувак, обычному игроку строго похрену что там и как работает. Он видит баги там где их не было  и делает вывод, что разрабы - криворукие. Все.

Пользователи всегда "находят баги". Даже там, где их нет. Это давно известно.
Поэтому одни получают зарплату и медали, а другие жалуются на несправедливость бытия...
Про прямоту рук я выше уже писал - все в ВАШИХ руках.
Я надеюсь с новым талантливым сотрудником мы получим наконец таки "годный" контент, а Близзард - новые миллионы активных подписчиков и миллиарды евро-тенге за подписку...

[PhantomButthurt]

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

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

нравится говно с лопаты жрать?

Если ты считаешь какую-нибудь обычную гречневую кашу говном, то употребляющие эту кашу люди не станут ВНЕЗАПНО говноедами.

[Cold_Arpil]

Как QA-инженер, могу сказать, что на уровне разработки и тестирования ничем вышеуказанным качество ПО не определяется.
То, что вы указали, есть часть аналитики, которая проводится ДО принятия решения о разработке продукта.
Т.е. это комплекс мероприятий, который определяет, что именно хотят пользователи, каким они его хотят и когда они его хотят (понятное дело, что всегда). Далее это накладывается на текущий статус продукта и график работы команд по нему, выдвигаются требования и описание. А согласно ним производится разработка и дальнейшее многоэтапное тестирование.
И вот на уровне QA никто не сидит и не определяет - нужно это или не нужно пользователям. Есть требование  создать кнопку "Убить всех". При нажатии на кнопку все умирают. Значит все работает, с точки зрения замысла.
И вот по сути, основываясь на личных наблюдениях, с выходом каждого нового контента - багов все меньше и меньше в этом самом новом контенте. А в старом да - много, т.к. регрессивное тестирование в бОльшей части отводится на автоматизацию и альфа/бета-тестирование пользователей. Охватить все целиком невозможно в принципе. А каждый раз с выходом нового контента - старого становится больше и больше. Но поскольку старый контент становится неактуальным для большинства пользователей - приоритетом он не обладает. Причем баги даже могут быть известны, но сроки их исправления - туманны.

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

1 - верификация не равна валидации. Твой продукт может быть технически безупречно вылизан, но пользоваться им будут полторы калеки. Для остальных пользователей твой продукт не представляет ценности, так как то что им нужно - отсутствует. Можно ли считать такой проект качественным? опять таки, с технической точки зрения да, ведь в нём нету багов.
Яркий пример - киберпанк. Одни кричат что игра забагована, это некачественный продукт. Другим плевать на эти баги, им важен мир, атмосфера и прочее, они считают продукт качественным с ЭТОЙ точки зрения.
P.S. - ISO 8402:1994 QM&QA

2. Вы путаете QA и QC - в работу QA входит оценка рисков и тестирование требований, а проверка того, что кнопка выполняет заложенное требование - это уже QC. QA еще до написания кода может сказать что, условно, кнопка "Убить всё" при реализации на текущем движке может убить не только всех вокруг, но ещё и данные с компьютера пользователя, и есть 3 решения - поменять движок, убрать это требование и не реализовывать кнопку или реализовать кнопку на текущем движке и не удивляться тому, что компанию завалят судебными исками за потраченные данные.

[arkan]

Как QA-инженер, могу сказать, что на уровне разработки и тестирования ничем вышеуказанным качество ПО не определяется.
То, что вы указали, есть часть аналитики, которая проводится ДО принятия решения о разработке продукта.
Т.е. это комплекс мероприятий, который определяет, что именно хотят пользователи, каким они его хотят и когда они его хотят (понятное дело, что всегда). Далее это накладывается на текущий статус продукта и график работы команд по нему, выдвигаются требования и описание. А согласно ним производится разработка и дальнейшее многоэтапное тестирование.
И вот на уровне QA никто не сидит и не определяет - нужно это или не нужно пользователям. Есть требование  создать кнопку "Убить всех". При нажатии на кнопку все умирают. Значит все работает, с точки зрения замысла.
И вот по сути, основываясь на личных наблюдениях, с выходом каждого нового контента - багов все меньше и меньше в этом самом новом контенте. А в старом да - много, т.к. регрессивное тестирование в бОльшей части отводится на автоматизацию и альфа/бета-тестирование пользователей. Охватить все целиком невозможно в принципе. А каждый раз с выходом нового контента - старого становится больше и больше. Но поскольку старый контент становится неактуальным для большинства пользователей - приоритетом он не обладает. Причем баги даже могут быть известны, но сроки их исправления - туманны.

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

1 - верификация не равна валидации. Твой продукт может быть технически безупречно вылизан, но пользоваться им будут полторы калеки. Для остальных пользователей твой продукт не представляет ценности, так как то что им нужно - отсутствует. Можно ли считать такой проект качественным? опять таки, с технической точки зрения да, ведь в нём нету багов.
Яркий пример - киберпанк. Одни кричат что игра забагована, это некачественный продукт. Другим плевать на эти баги, им важен мир, атмосфера и прочее, они считают продукт качественным с ЭТОЙ точки зрения.
P.S. - ISO 8402:1994 QM&QA

2. Вы путаете QA и QC - в работу QA входит оценка рисков и тестирование требований, а проверка того, что кнопка выполняет заложенное требование - это уже QC. QA еще до написания кода может сказать что, условно, кнопка "Убить всё" при реализации на текущем движке может убить не только всех вокруг, но ещё и данные с компьютера пользователя, и есть 3 решения - поменять движок, убрать это требование и не реализовывать кнопку или реализовать кнопку на текущем движке и не удивляться тому, что компанию завалят судебными исками за потраченные данные.

Во первых - причем тут ISO 8402:1994 , который уже 20 лет как заменен и никакого отношения к даному вопросу не имеет? Первый документ, который нашел гугл?
Во вторых - я вот как раз ничего не путаю. QC неотъемлемая часть QA.
В третьих - есть еще как минимум продакт менеджер и архитектор , которые эти самые требования анализируют ДО того, как их выпустить с учетом особенностей системы и представленных данных аналитики.
В пятых - есть огромная пропасть между теорией и практикой.

За найденный баг в моем сообщении - положена печенька.

[Cold_Arpil]

Во первых - причем тут ISO 8402:1994 , который уже 20 лет как заменен и никакого отношения к даному вопросу не имеет? Первый документ, который нашел гугл?
Во вторых - я вот как раз ничего не путаю. QC неотъемлемая часть QA.
В третьих - есть еще как минимум продакт менеджер и архитектор , которые эти самые требования анализируют ДО того, как их выпустить с учетом особенностей системы и представленных данных аналитики.
В пятых - есть огромная пропасть между теорией и практикой.

За найденный баг в моем сообщении - положена печенька.

1 - потому что за 20 лет определение толком и не поменялось. ISO 9000:2015:
Цитирую "Качество продукции и услуг организации определяется способностью удовлетворять потребителей и преднамеренным или непреднамеренным влиянием на соответствующие заинтересованные стороны.

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



2 - давай обратим к тому же ISO 9000:2015
Quality assurance (3.2.10) — part of quality management focused on providing confidence that quality requirements will be fulfilled.
Quality control (3.2.11) — part of quality management focused on fulfilling quality requirements.

QA отвечает за ОБЕСПЕЧЕНИЕ качества продукта, а QC - отвечает за ПРОВЕРКУ продукта на соответствие качеству, но оба являются неотъемлемой частью друг друга

3 - QA  в адекватной компании участвует в создании продукта с самого начала жизненного цикла этого продукта и может сказать ПМу и архитектору в том что их анализ, мягко говоря, не очень.  Не забываем про стоимость бага на разных этапах разработки. И если QA работает хорошо - то до этапа тестирования дойдет ещё меньше ошибок, чем могло быть. А те, которые дойдут - это будут незначительные нефункциональные ошибки

4 - предпочитаю овсяное

5 - теория без практики - ничто, это правда. По теории  QA и QC - это разные люди. По факту - зачастую это один и тот же человек.


P.S я вчера успешно прошёл компетенцию у лида отдела, который имеет 15летний стаж софт/гейм QA. И вопрос про различие QA/QC мне был засчитан по максимальной.