Size: a a a

2020 December 22

В

Вовка in QA juniors
Андрей Коломытов
Да нет, именно так. Продукт -- задокументирвоанная ошибка. Но это ещё не конец работы и не единственная метрика оценки эффективности работы тестистировщика.
Нет, нам надо показать что продукт не работает, найти в нем ошибки, а не доказать что продукт- это ошибка
источник

АК

Андрей Коломытов... in QA juniors
Вовка
Нет, нам надо показать что продукт не работает, найти в нем ошибки, а не доказать что продукт- это ошибка
Да, вы правы. Не вижу противоречия.
источник

В

Вовка in QA juniors
Показать что продукт это ошибка - это скорее относится к валидации продукта
источник

В

Вовка in QA juniors
Точнее верификация, все время путаю их
источник

АК

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

DN

Dmitrii Novikov in QA juniors
Андрей Коломытов
Но ошибка, как именно обнаруженная ошибка, она сущестует где-то, в чём-то.
Безусловно!
источник

АК

Андрей Коломытов... in QA juniors
Речь не шла, и не идёт, об оценке всего продукта.
источник

DN

Dmitrii Novikov in QA juniors
Андрей Коломытов
Наверное, мне нужно точнее и проще выражаться. Продукт тестистирования -- ошибка, задокументированный баг (хотя, конечно, наверное не только). Тестистировщик производит задокументированные баги.
Точно так же можно сказать, что продукт работы программиста -- это написанный код, а не работающее приложение
источник

АК

Андрей Коломытов... in QA juniors
Dmitrii Novikov
Точно так же можно сказать, что продукт работы программиста -- это написанный код, а не работающее приложение
Мне не кажется, что это корректное сравнение. Продуктом работы программиста может быть как код, так и оценка кода, модуль\\часть програмного продукта или програмный продукт в целом. Продукт тестирования -- всегда ошибка. Если хотите -- первичный продукт.
источник

DN

Dmitrii Novikov in QA juniors
Андрей Коломытов
Мне не кажется, что это корректное сравнение. Продуктом работы программиста может быть как код, так и оценка кода, модуль\\часть програмного продукта или програмный продукт в целом. Продукт тестирования -- всегда ошибка. Если хотите -- первичный продукт.
"продукт тестирования -- всегда ошибка" -- и тут мы возвращаемся к тому, что если ошибок не найдено, значит, тестирование не было произведено.
источник

АК

Андрей Коломытов... in QA juniors
Dmitrii Novikov
"продукт тестирования -- всегда ошибка" -- и тут мы возвращаемся к тому, что если ошибок не найдено, значит, тестирование не было произведено.
Примерно. Не то, что бы такое было не возможно, но нет никакого смысла исходить из возможности отсутствия ошибок. Скорее, не ошибок нет, а недоношли. Опять же, сейчас я оперирую строго Каннером в прочитанном объёме.
источник

АК

Андрей Коломытов... in QA juniors
Он приводит аналогию с врачём: нет, милок, у вас всё хорошо. А оно не хорошо.
источник

DN

Dmitrii Novikov in QA juniors
Андрей Коломытов
Примерно. Не то, что бы такое было не возможно, но нет никакого смысла исходить из возможности отсутствия ошибок. Скорее, не ошибок нет, а недоношли. Опять же, сейчас я оперирую строго Каннером в прочитанном объёме.
А вот если исходить из "недонашли", то ПМ получит 100500 багов вёрстки, но не получит информацию о блокере в подсистеме, которая сто лет не изменялась (а чо её трогать; если мы ошибок много не найдём, нас депремируют)
источник

В

Вовка in QA juniors
Так на скринах же говорится про цель(задачу), а не про продукт тестирования
источник

DN

Dmitrii Novikov in QA juniors
Утрирую
источник

АК

Андрей Коломытов... in QA juniors
Вовка
Так на скринах же говорится про цель(задачу), а не про продукт тестирования
Я исхожу из всего объёма прочитанного. Предположим, действительно, это важно. Что должно поменяться, в таком случае, в выводах?
источник

AS

Apostol Sergey in QA juniors
Андрей Коломытов
Он приводит аналогию с врачём: нет, милок, у вас всё хорошо. А оно не хорошо.
Андрей вы же понимаете что нельзя судить о тестировании с точки зрения человека одной книги. Есть другие прекрасные труды описывающие противоположную точку зрения.
источник

АК

Андрей Коломытов... in QA juniors
Dmitrii Novikov
А вот если исходить из "недонашли", то ПМ получит 100500 багов вёрстки, но не получит информацию о блокере в подсистеме, которая сто лет не изменялась (а чо её трогать; если мы ошибок много не найдём, нас депремируют)
Если баги вёрстки действительно есть, их нужно фиксировать. Каннер предлагает не засирать однотипными багами, как я понимаю. Если же мы будет считать, что багов может не быть -- это увеличит вероятность нахождения блокера? Зачем, и как, его искать, если мы исходим из того, что его нет?
источник

DN

Dmitrii Novikov in QA juniors
Андрей Коломытов
Я исхожу из всего объёма прочитанного. Предположим, действительно, это важно. Что должно поменяться, в таком случае, в выводах?
Я думаю, подход. За поиском ошибок начинающие тестировщики забывают о не менее важном (а то и более) вопросе для определения релизного календаря: "а что у нас вообще работает?!"
источник

АК

Андрей Коломытов... in QA juniors
Apostol Sergey
Андрей вы же понимаете что нельзя судить о тестировании с точки зрения человека одной книги. Есть другие прекрасные труды описывающие противоположную точку зрения.
Андрей. Это моя первая книга по QA. Здесь рекомендовали именно её. Теперь разбираюсь 🙂
источник