В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

QA juniors

8661 membersпожаловаться на группу
2020 December 27

H

Horrid man SV4 in QA juniors
Keane
Это же очевидно. Или есть разработчики, у которых это не так?
Окей, можешь не писать ожидаемый результат, Но тогда после твоей 500 ошибки будет просто редирект на Гугл и кому-то это будет норм результат
источник
19:53пожаловаться#1

K

Keane in QA juniors
Di
И вы заведёте баг репорт на то, что перешло, по вашему мнению, не на ту страницу
Хотя так и должно быть по доке/спеке etc
В смысле? Зачем я заведу репорт на то, что багом не является? Если я не прочитал требования (верю, что где-то они есть) и ошибочно завёл баг, то я идиот.
источник
19:53пожаловаться#2

A

Aletca in QA juniors
Баг - это несоответствие фактического и ожидаемого результата.  Поэтому ожидаемый результат и фактический записываем в баг репорт. Вы вообще о чем спорите?
источник
19:54пожаловаться#3

D

Di in QA juniors
Keane
В смысле? Зачем я заведу репорт на то, что багом не является? Если я не прочитал требования (верю, что где-то они есть) и ошибочно завёл баг, то я идиот.
Потому что вы не знаете требований (читать, ожидаемый результат) и посчитаете, что текущее поведение это баг
источник
19:54пожаловаться#4

K

Keane in QA juniors
Horrid man SV4
Окей, можешь не писать ожидаемый результат, Но тогда после твоей 500 ошибки будет просто редирект на Гугл и кому-то это будет норм результат
А как в этом случае ведут себя разработчики? При фиксе багов они бездумно что-то исправляют не уточняя, как это должно правильно функционировать?
источник
19:54пожаловаться#5

K

Keane in QA juniors
Aletca
Баг - это несоответствие фактического и ожидаемого результата.  Поэтому ожидаемый результат и фактический записываем в баг репорт. Вы вообще о чем спорите?
О том и речь. В самом заголовке бага уже имеется информация о том, что не так. А ожидаемый результат должен быть понятен всем участникам процесса разработки с самого начала. Иначе что мы вообще делаем, если не знаем как оно должно работать. :)
источник
19:56пожаловаться#6

DN

Dmitrii Novikov in QA juniors
Keane
А в чём смысл? Я завожу баг "При переходе на такую-то страницу появляется Error 500". Какой в этом случае ожидаемый результат? Мой ожидаемый результат - "чтобы работало". :)
Ну не "чтобы работало", а "страница загрузилась", хотя бы. 500 -- это тоже "работает", так посмотреть
источник
19:56пожаловаться#7

D

Di in QA juniors
Keane
А как в этом случае ведут себя разработчики? При фиксе багов они бездумно что-то исправляют не уточняя, как это должно правильно функционировать?
А что такое правильно функционировать?
Это как раз таки ожидаемый результат, который либо зафиксирован в доке (что, возможно, редко явление), либо где-то оговорён/уточнён
источник
19:56пожаловаться#8

DN

Dmitrii Novikov in QA juniors
Keane
Это же очевидно. Или есть разработчики, у которых это не так?
"это же очевидно" открывает дорогу в ад, на самом деле
источник
19:57пожаловаться#9

K

Keane in QA juniors
Di
Потому что вы не знаете требований (читать, ожидаемый результат) и посчитаете, что текущее поведение это баг
Я запутался. :)
В первом примере вы сказали, что имеется дока.
источник
19:57пожаловаться#10

D

Di in QA juniors
Keane
Я запутался. :)
В первом примере вы сказали, что имеется дока.
Вы сказали что она не везде есть (что правда)
Я чуть изменил пример
источник
19:58пожаловаться#11

K

Keane in QA juniors
Dmitrii Novikov
"это же очевидно" открывает дорогу в ад, на самом деле
Как и то, что разработчик в команде не знает как должно быть правильно.
источник
19:58пожаловаться#12

D

Di in QA juniors
Keane
Как и то, что разработчик в команде не знает как должно быть правильно.
А если это фиксит разраб, который не принимал участие в изначальной разработке ?
источник
19:58пожаловаться#13

A

Aletca in QA juniors
Заголовок должен строиться по принципу "что, где, когда" - это не ожидаемый и не фактический результат. Результаты, как и шаги дополняют описание бага
источник
19:58пожаловаться#14

DN

Dmitrii Novikov in QA juniors
Aletca
Баг - это несоответствие фактического и ожидаемого результата.  Поэтому ожидаемый результат и фактический записываем в баг репорт. Вы вообще о чем спорите?
Спор о том, что "очевидный" ожидаемый результат можно не писать в баг-репорт
источник
19:59пожаловаться#15

K

Keane in QA juniors
Di
А если это фиксит разраб, который не принимал участие в изначальной разработке ?
Я сам не разработчик, конечно. Но обычно я ничего не исправляю наобум. :)
источник
19:59пожаловаться#16

D

Di in QA juniors
Keane
Я сам не разработчик, конечно. Но обычно я ничего не исправляю наобум. :)
А на основании чего?
источник
19:59пожаловаться#17

DN

Dmitrii Novikov in QA juniors
Keane
Как и то, что разработчик в команде не знает как должно быть правильно.
Ну да, разработчик не знает. Тестировщик не знает, что разработчик может не знать. "Все здесь молодцы" (с)
источник
20:00пожаловаться#18

A

Aletca in QA juniors
Dmitrii Novikov
Спор о том, что "очевидный" ожидаемый результат можно не писать в баг-репорт
а, ну это из разряда, что и тесты вообще раньше не писали, и жили как-то
источник
20:01пожаловаться#19

DN

Dmitrii Novikov in QA juniors
Aletca
а, ну это из разряда, что и тесты вообще раньше не писали, и жили как-то
Не совсем, если вчитаться.
источник
20:01пожаловаться#20