Size: a a a

2020 August 16

АБ

Арсений Батыров... in QA juniors
Alexandr
Только сегодня увидел вопрос :)
Он может уведомить (сказать/показать, а чтоб потом действительно доказать что указывал на проблему - создать задачу в трекере) о не соответствии фичи ожидаемому результату
Ведь, скорее всего один из критериев качества будет соответствие ОР к ФР :)
Гуд?
Он может уведомить ( дать информацию ), сказать ( дать информацию ), показать ( дать информацию ), создать задачу ( дать информацию ).
Как это изменит сам софт?
источник

СФ

Степа Фомичев... in QA juniors
Арсений Батыров
Он может уведомить ( дать информацию ), сказать ( дать информацию ), показать ( дать информацию ), создать задачу ( дать информацию ).
Как это изменит сам софт?
Инициируется цепочка: информация о проблеме -> анализ -> решение проблемы
источник

АБ

Арсений Батыров... in QA juniors
Степа Фомичев
Инициируется цепочка: информация о проблеме -> анализ -> решение проблемы
А точно инициируется?)
источник

СФ

Степа Фомичев... in QA juniors
Арсений Батыров
А точно инициируется?)
Если процессы в команде налажены, то да. Если нет, то это не проблема тестирования
источник

АБ

Арсений Батыров... in QA juniors
Степа Фомичев
Если процессы в команде налажены, то да. Если нет, то это не проблема тестирования
То есть если баг не правится - это проблема?)
источник

СФ

Степа Фомичев... in QA juniors
Арсений Батыров
То есть если баг не правится - это проблема?)
Если это именно баг, о нем известно и он не правится - это проблема
источник

АБ

Арсений Батыров... in QA juniors
И если это не проблема тестирования, значит тестирование таки не может напрямую повлиять на качество?)
источник

АБ

Арсений Батыров... in QA juniors
Степа Фомичев
Если это именно баг, о нем известно и он не правится - это проблема
Почему?)
источник

СФ

Степа Фомичев... in QA juniors
Потому что баг - ошибка в продукте, какие ещё обоснования нужны?) или это софистика?
источник

И

Ильяс in QA juniors
Баг может не правиться, потому что у него низкий приоритет из-за небольшого влияния, мало времени/ресурсов не хватает.
источник

АБ

Арсений Батыров... in QA juniors
Степа Фомичев
Потому что баг - ошибка в продукте, какие ещё обоснования нужны?) или это софистика?
А все баги надо править?)
источник

СФ

Степа Фомичев... in QA juniors
Ильяс
Баг может не правиться, потому что у него низкий приоритет из-за небольшого влияния, мало времени/ресурсов не хватает.
Для этого есть то, что многие называют «техническим долгом», или «сервисным релизом»
источник

АБ

Арсений Батыров... in QA juniors
Степа Фомичев
Для этого есть то, что многие называют «техническим долгом», или «сервисным релизом»
Технический долг слабо связан с исправлением багов, так то)
источник

АБ

Арсений Батыров... in QA juniors
Это про удобство и скорость разработки обычно)
источник

СФ

Степа Фомичев... in QA juniors
Арсений Батыров
Технический долг слабо связан с исправлением багов, так то)
Откуда ты вообще это взял?)
источник

СФ

Степа Фомичев... in QA juniors
Это исправление накопившихся проблем
источник

АБ

Арсений Батыров... in QA juniors
Степа Фомичев
Откуда ты вообще это взял?)
Например, из определения технического долга?)
источник

СФ

Степа Фомичев... in QA juniors
Будь то рефакторинг, исправление архитектуры, исправление багов, оставленных «на потом»
источник

АБ

Арсений Батыров... in QA juniors
Так мы про баги или про рефакторинг?)
источник

И

Ильяс in QA juniors
Степа Фомичев
Для этого есть то, что многие называют «техническим долгом», или «сервисным релизом»
Не обязательно. Например в админке, есть какой-то баг, который можно обойти или он влияет только на опыт админа. Так как админ, это человек, которого можно обучить и он сидит на зарплате, то можно не фиксить.

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