Y
Size: a a a
2019 October 04
T
ET
как говорил QA manager Чандра: "We need more excel reports for covered more functionality" :-(
AK
Не холиварю, но похоже на типичный доклад QA :)
Когда начинаешь задавать вопросы, то звучит ответ из разряда: "Ну вы знаете, все сугубо индивидуально!"
Ну а вообще норм практика собирать соотношение и процентаж багов, которые были найдены командой vs заказчик либо конечный пользователь.
Ну а остальное "сугубо индивидуально!"
Когда начинаешь задавать вопросы, то звучит ответ из разряда: "Ну вы знаете, все сугубо индивидуально!"
Ну а вообще норм практика собирать соотношение и процентаж багов, которые были найдены командой vs заказчик либо конечный пользователь.
Ну а остальное "сугубо индивидуально!"
AS
Мобильный доклад Дианы Пинчук «Тестирование mobile deep links» https://comaqa.by/2019/09/05/diana-pinchuk-comaqa-spring-2019/
ET
Не холиварю, но похоже на типичный доклад QA :)
Когда начинаешь задавать вопросы, то звучит ответ из разряда: "Ну вы знаете, все сугубо индивидуально!"
Ну а вообще норм практика собирать соотношение и процентаж багов, которые были найдены командой vs заказчик либо конечный пользователь.
Ну а остальное "сугубо индивидуально!"
Когда начинаешь задавать вопросы, то звучит ответ из разряда: "Ну вы знаете, все сугубо индивидуально!"
Ну а вообще норм практика собирать соотношение и процентаж багов, которые были найдены командой vs заказчик либо конечный пользователь.
Ну а остальное "сугубо индивидуально!"
если у тебя функционал для крупного банка, команда qa 5 человек, а пользователей 100к, логично что они найдут больше багов
Y
Не холиварю, но похоже на типичный доклад QA :)
Когда начинаешь задавать вопросы, то звучит ответ из разряда: "Ну вы знаете, все сугубо индивидуально!"
Ну а вообще норм практика собирать соотношение и процентаж багов, которые были найдены командой vs заказчик либо конечный пользователь.
Ну а остальное "сугубо индивидуально!"
Когда начинаешь задавать вопросы, то звучит ответ из разряда: "Ну вы знаете, все сугубо индивидуально!"
Ну а вообще норм практика собирать соотношение и процентаж багов, которые были найдены командой vs заказчик либо конечный пользователь.
Ну а остальное "сугубо индивидуально!"
потому что обычно именно так и есть именно из-за индивидуальности требований заказчиков, пмов, просто внутреннего устройства компаний и того, что они хотят/обещают предоставлять клиентам, методолгий разработки, на которых это все построено и так далее
AK
если у тебя функционал для крупного банка, команда qa 5 человек, а пользователей 100к, логично что они найдут больше багов
Все сугубо индивидуально, но по-моему нет :) Забыл добавить, что можно еще посчитать в таком ключе не только "баги qa" vs "баги юзеров", но и взять при рассчете severity и priority багов, чтобы не брать в рассчет "мне на этой кнопке стиль текста глаза мозолит"
MM
Не холиварю, но похоже на типичный доклад QA :)
Когда начинаешь задавать вопросы, то звучит ответ из разряда: "Ну вы знаете, все сугубо индивидуально!"
Ну а вообще норм практика собирать соотношение и процентаж багов, которые были найдены командой vs заказчик либо конечный пользователь.
Ну а остальное "сугубо индивидуально!"
Когда начинаешь задавать вопросы, то звучит ответ из разряда: "Ну вы знаете, все сугубо индивидуально!"
Ну а вообще норм практика собирать соотношение и процентаж багов, которые были найдены командой vs заказчик либо конечный пользователь.
Ну а остальное "сугубо индивидуально!"
простите, а что показывает метрика "количество багов"?
MM
сегодня их 0, завтра 3, какой вывод можно из этого сделать ?
ET
наиболее часто видел метрики:
1. Отношение написаных тк и планируемых тк
2. Открытые баги и реопены
3. Тест ковердж
4. Покрытие кода юбнит тестами
5. Отношение автотестов к мануальным
6. Отношение затрат времени на регрессию и тестированию
1. Отношение написаных тк и планируемых тк
2. Открытые баги и реопены
3. Тест ковердж
4. Покрытие кода юбнит тестами
5. Отношение автотестов к мануальным
6. Отношение затрат времени на регрессию и тестированию
AK
простите, а что показывает метрика "количество багов"?
Количество багов, которые были отловленны командой перед релизом, vs количество багов которые были найдены юзерами после релиза.
Т.е. насколько не забагованное приложение \ функционал \ модуль вы поставили в текущем релизе.
Т.е. насколько не забагованное приложение \ функционал \ модуль вы поставили в текущем релизе.
MM
Количество багов, которые были отловленны командой перед релизом, vs количество багов которые были найдены юзерами после релиза.
Т.е. насколько не забагованное приложение \ функционал \ модуль вы поставили в текущем релизе.
Т.е. насколько не забагованное приложение \ функционал \ модуль вы поставили в текущем релизе.
Как вы по количеству НАЙДЕННЫХ багов определяете количество ОСТАВШИХСЯ?))
R
Как вы по количеству НАЙДЕННЫХ багов определяете количество ОСТАВШИХСЯ?))
пасхалки :)....
MM
пасхалки :)....
Если бы так можно было, то на всех конторах давно бы стояли фиксированные KPI по количеству багов))
AK
Как вы по количеству НАЙДЕННЫХ багов определяете количество ОСТАВШИХСЯ?))
Соотношу с теми, которые были найдены пользователями.
Количество оставшихся багов не возможно определить. Где я написал про оставшиеся?
Количество оставшихся багов не возможно определить. Где я написал про оставшиеся?
R
Если бы так можно было, то на всех конторах давно бы стояли фиксированные KPI по количеству багов))
У меня был когда то кастомер, который мягко говоря не очень. ну мы специально делали баги в спринте, потом их "находили" - быстро фиксили и он был счастлив) какая у него охрененная тима.
MM
Соотношу с теми, которые были найдены пользователями.
Количество оставшихся багов не возможно определить. Где я написал про оставшиеся?
Количество оставшихся багов не возможно определить. Где я написал про оставшиеся?
Кстати, а как вы относитесь к тезису, что ключевой показатель эффективности куа это количество багов и надо платить только за них?