Вопрос по дз Taulia bug reports

[SvetaE]

Всем привет.

Вопрос - Стоит ли в баг репорте использовать такие слова как "Has to be, Should, ..." , при условии отсутствия четкой спецификации, могу ли я заявлять "Как оно должно быть", если я не дизайнер? Я понимаю деятельность тестировщика как собирателя информации. И еще вопрос по примеру: У нас в таблице Invoices указано 11 рядов, хотя в DATA INPUT FIELD "results per page" указано 10 рядов. Получается, что 11й избыточный ряд это баг, также в этом 11м ряду, мы наблюдаем следующий баг - отсутствие "Action" button. Вопрос - целесообразно ли описывать этот баг (с кнопкой)? Спасибо, извиняюсь, если об этом упоминалось и я прослушала.

[Alexander_Komarov]

Добрый день. Стоит ли репортить ошибки из html и css верстки, или это из другой области?

[Evgnbo]

Некоторые студенты в описании ошибок ссылались на некий Web Guide - а где взять?

[semenovanata]

Здравствуйте!

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

[alex_cyberneticist]

Некоторые студенты в описании ошибок ссылались на некий Web Guide - а где взять?

Во втором уроке было. "Research-based web design and usability guidelines". Ссылка на него есть в заметках к уроку.

[mportnov]

Обычно и про 11й ряд и отдельно отсутствие кнопки в этом ряду напишут 2 рипорта. Чтобы наверняка.

[mportnov]

В нашем случае html/css не нужно

[mportnov]

Ошибки пишутся в порядке обнаружения. Как ляжет бубна, в таком порядке и описываем

[Khurshida_M]

Скажите пожалуйста, а доступ ко всем репортам тестеров находится в открытом доступе в офисе? Это касательно вопроса # 1 в третьем уроке, про то, чтобы посмотреть для примера как пишут репорты senior тестеры

[Yurii86]

Из первого урока (2011г.) есть вопрос .Verification vs. validation, не особо понятно. Если кто понял можете разъяснить своими словами.
Спасибо.

[semenovanata]

Здравствуйте! Подскажите, пожалуйста, верно ли определение?

[Iwin]

Здравствуйте! Подскажите, пожалуйста, верно ли определение?

Михаил нигде не обращался к этому определению, поэтому считаю, что это избыточная ненужная для наших целей информация. Но Ваши цели могут быть другими, конечно же...

[Iwin]

Из первого урока (2011г.) есть вопрос .Verification vs. validation, не особо понятно. Если кто понял можете разъяснить своими словами.
Спасибо.

Как я это представляю...
Попробуйте представить себе список покупок в магазине. Зашли в магазин, 1-й пункт колбаса, нашли, положили в корзину, ПОСТАВИЛИ ГАЛОЧКУ, смотрите на следующий пункт и т.д. Получается так называемый чек лист, в котором вы галочкой отмечаете КАЖДУЮ позицию. В итоге, вы проходите по всем ( в идеале, мы предполагаем, что все нужное оказалось в магазине). То же самое с требованиями. У вас есть список требований и напротив каждого требования, ПРОВЕРИВ ЕГО!, вы ставите галочку. Вот этот процесс и будет верификацией.

Теперь представьте, что на кассе вам все посчитали, а денег в кошельке у вас оказалось меньше. Нормальный человек в такой ситуации уберет те продукты, которые ему не очень то и нужны сегодня или вообще не нужны, а просто схвачены под воздействием эмоционального импульса. Кассир их уберет из чека, денег хватит, и Вы все таки сможете купить именно то, что вам действительно нужно. Здесь абстрактный переход на тестирование не так очевиден, но я думаю, вполне допустим. В процессе тестирования Вы можете столкнуться с ситуацией, когда какое-то из требований (requirements) вы посчитаете не нужным, излишним, или слишком сложным (колбаса могла бы быть и подешевле взята) и напишете репорт, что надо бы с этим что-то сделать. Так вот процесс оценки самих требований (не слишком ли эта колбаса дорога?) и есть процесс валидации.

повторюсь это работает лично для меня. если для вас это не очевидно, не кидайте помидорами...

[Yurii86]

Кто-то пробовал тестировать ResumeBuilder GUI (https://www.portnov.com/ru/)

[KaterinaB]

Всем привет.

Вопрос - Стоит ли в баг репорте использовать такие слова как "Has to be, Should, ..." , при условии отсутствия четкой спецификации, могу ли я заявлять "Как оно должно быть", если я не дизайнер? Я понимаю деятельность тестировщика как собирателя информации. И еще вопрос по примеру: У нас в таблице Invoices указано 11 рядов, хотя в DATA INPUT FIELD "results per page" указано 10 рядов. Получается, что 11й избыточный ряд это баг, также в этом 11м ряду, мы наблюдаем следующий баг - отсутствие "Action" button. Вопрос - целесообразно ли описывать этот баг (с кнопкой)? Спасибо, извиняюсь, если об этом упоминалось и я прослушала.

Из моего опыта скажу, что Should be звучит как assumption, я обычно пишу per this or that acceptance criteria this and that is expected;


По поводу Taulia:
taulia.PNG
В данном случае это 2 бага, один для Actions button, второй для отображения 11 ряда вместо необходимых 10.