АБ
...
Масштабировать прохождение тест кейсов понятное дело проще
Конечно :) Поэтому и используется, в него можно встроить кого угодно. И при росте темпов, скажем, в 5 раз - можно хотя бы надеяться на удачное внедрение. В отличие от.
Size: a a a
2020 June 28
АБ
...
Яснопонятно, цель тестирования ловить баги
Нет :) Цель тестирования - репортить о качестве продукта. Багов в принципе может и не быть (хорошая цель, кстати, местами даже достижимая).
.
Если дрюкать билд до тех пор пока разрабы его не сделают идеальным то можно сказать что тестирование отработало на славу, вот только ресурсов и времени это съест много
.
Мало кто может себе позволить такое тестирование
АБ
Так не надо идеальным, надо "достаточным". А уровень достаточности как раз позволяет определить тестовая документация, в том числе - кейсы приемки.
.
Хотя если только репортить, не обращая внимания на фиксят ли это и не блокируя этим релизы, то все проще, но не пойму накуа такое нужно кому-то
АБ
Одна из задач, например - сформировать такой пайплайн, чтобы:
1. Отчет об успешном прохождении приемки означал бы, что софт имеет достаточное для релиза качество
2. На приемке не находились бы критичные и блокирующие баги (потому что они все были найдены раньше)
3. Затратить на это минимальное количество времени/денег
1. Отчет об успешном прохождении приемки означал бы, что софт имеет достаточное для релиза качество
2. На приемке не находились бы критичные и блокирующие баги (потому что они все были найдены раньше)
3. Затратить на это минимальное количество времени/денег
АБ
...
Хотя если только репортить, не обращая внимания на фиксят ли это и не блокируя этим релизы, то все проще, но не пойму накуа такое нужно кому-то
Ну, для меня когда-то стало контринтуитивной новостью существование "бесполезных" багов. Но теперь да, теперь стараюсь делать так, чтобы они вовсе не репортились.
Т
Нет :) Цель тестирования - репортить о качестве продукта. Багов в принципе может и не быть (хорошая цель, кстати, местами даже достижимая).
Ты недавно говорил, что цель тестирования это снижение издержек
AG
Из недавних - количество багов на проде, скорость приемки, количество критических багов на приемке.
АБ
Ты недавно говорил, что цель тестирования это снижение издержек
Дык! Непонятный статус продукта - это риски, а риски это издержки. Имеешь достоверную информацию о качестве - можешь снизить издержки (пофиксить ли, забить ли).
Т
Тогда цель тестирования это дать оценку продукта для снижения издержек
.
Одна из задач, например - сформировать такой пайплайн, чтобы:
1. Отчет об успешном прохождении приемки означал бы, что софт имеет достаточное для релиза качество
2. На приемке не находились бы критичные и блокирующие баги (потому что они все были найдены раньше)
3. Затратить на это минимальное количество времени/денег
1. Отчет об успешном прохождении приемки означал бы, что софт имеет достаточное для релиза качество
2. На приемке не находились бы критичные и блокирующие баги (потому что они все были найдены раньше)
3. Затратить на это минимальное количество времени/денег
Ввёл канареечные релизы, нахожу криты и баги на проде, но у лояльных юзеров, приемочное тестирование теряет актуальность, могу релизить в почти любой момент, уменьшил время необходимое на чисто тестирование в много раз
АБ
...
Ввёл канареечные релизы, нахожу криты и баги на проде, но у лояльных юзеров, приемочное тестирование теряет актуальность, могу релизить в почти любой момент, уменьшил время необходимое на чисто тестирование в много раз
Это прекрасно! :) А нет статьи об этом? Я бы почитал)
.
Да куча статей и книг
АБ
Нет, конкретно про твой опыт.
.
Девопс в 2009 вроде придумали
.
Нет, конкретно про твой опыт.
А без статьи не счетово уже?
АБ
Как измеряли время? как ставили цели? Как выбираете группу для тестирования?
АБ
...
А без статьи не счетово уже?
Это не к аргументации, это мне правда интересно)