to astenix

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

А попытайтесь представить себе, что возможно.

Представить-то я могу :)
Но в жизни сказать "Вообще все протестировано, багов точно больше нет" пока нереально.

to kitsune

Мои выводы: Все три показателя, если они >0, указывают, что тестирование недостаточно эффективно и в каких фичах сосредоточены упущения тестеров.

Это я не поняла, можете развернуть?

Я имела в виду, например:

релиз2 тестировали 2 недели, 10 фич, 20 багов пропущено

Пропустили 20 багов - значит тестирование недостаточно эффективно.
Пропустили баги в конкретных 10-ти фичах - значит есть упущения в тестировании именно этих 10 фич. Начинать улучшение тестирования можно с этих 10-ти фич.

Спасибо за дополнительные примеры и за объяснение с дублированием.

Я поняла, чего мне не хватало. Мы здесь нигде толком не раскрыли, что делать с этими показателями дальше. Мы видим, что тестирование недостаточно эффективно, но не знаем, что делать, чтобы его улучшить.
Целесообразно анализировать причину попадания бага в релиз. Например:
- есть ли тест, проверяющий эту ситуацию (если нет, то почему он не был создан и кто должен это сделать)?
- если теста нет, то почему (не было требования, неверно понято требование, изменилось требование, незапланированное поведение пользователя, не хватило квалификации, упущено по невнимательности, другое)?
- если есть, был ли он выполнен (да, нет)?
- если не был выполнен, то почему (низкий приоритет теста, не хватило времени, не хватило квалификации, просто забыли, другое)?
- если был выполнен, то почему не был обнаружен баг (баг не проявился; проявился, но не поняли, что это баг; проявился, но не заметили)?

Чтобы строить статистику причин пропуска багов можно в форму описания дефекта добавить спец. поле, или просто условный комментарий дописывать. А потом смотреть количество багов пропущенных по причинам А, Б, С, ... в фичах 1, 2, 3... Х.

Это именно то, что я искала. Спасибо большое всем за обсуждение!

to kitsune

Доступа к самим багам у вас нет?

Пока нет, но постараюсь получить.

Спасибо за примеры показателей. Я их обдумывала и получилось вот что:

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

Фича - понятие растяжимое. Простенький диалог поиска с одним полем и двумя кнопками - фича. И визард с двумя десятками настроек и пятью десятками возможных результатов срабатывания - тоже фича.
Пример: Фич две, багов соответственно попало в продакшен 1 и 9. На тестирование фичи 1 ушло 25 мин. На тестирование фичи 2 ушло 2 дня.
Что дает нам эта информация? Маленькую фичу тестировали недолго. Большую долго. В маленькой пропустили мало багов. В большой - много. И...? Какие еще выводы можно сделать?

Количество багов по типу (UI/FN/Performance/Security). Сопоставлять с количеством тестов.

Пример: Security - разработано 100 тестов, прогнали 91 тест. В продакшен попало 15 багов, из них 2 критикала.
Что дает нам эта информация? Ну, прогнали не все тесты. А если бы прогнали все, нашли бы пропущенные баги? Показатель об этом умалчивает.

Количество багов, на которые есть аналогичные баги, найденые во время тестирования (и баги не были не пофикшены из-за низкого приоритета, например).

Пример: Есть 4 таких бага.
Что дает нам эта информация? Тестерам надо было мыслить шире и не пропускать однотипные баги. Но то же самое нам сказал бы один такой баг или 101.

Мои выводы: Все три показателя, если они >0, указывают, что тестирование недостаточно эффективно и в каких фичах сосредоточены упущения тестеров.

Но мне все равно кажется, что чего-то не хватает. Чего именно - не пойму. Я подумаю еще.

to Natalya Rukol

Наташа, спасибо.

Вопросы:

пропустили 4% багов и 7% с разбивкой по весу

1) % от чего?

"количество пропущенных в продакшн багов" или "соотношение пропущенных и найденных"

2) Найти все баги невозможно. Потому что ПО слишком сложное и проверить все, во всех возможных сочетаниях и конфигурациях, на всех возможных входных данных и при всех возможных действиях юзеров невозможно.

Поэтому разумно ли измерять эффективность тестирования только в багах?
Может учитывать при этом покрытие системы тестами? И приоритеты? И конкретизировать показатель, например, так:

"количество пропущенных critical и major багов при условии, что выполнены все тесты, покрывающие требования с приоритетами High и Medium"

?

В статье сказано

Чтобы принести проекту максимум пользы, вы должны точно знать, что ему сейчас нужно. Чтобы знать что нужно, вам необходимо анализировать его показатели, что именно за пределами нормы: сроки, качество или бюджет. И уже после этого создавать вашу уникальную формулу с требованиями к тестированию. При этом, будем честны: «сократить сроки» или «увеличить покрытие» — это всё те же «помассируйте меня».
Нужны точные показатели.

Дано: На вопрос, для чего ему нужно тестирование ПМ отвечает "В продакшен проскакивает много багов и мы узнаем об этом от пользователей. Нам нужно тестирование для того, чтобы узнавать об этих багах и не пропускать их в продакшен".

Собственно вопросы:
1) Какие именно показатели нужно выспрашивать у ПМа в данном случае?
2) И что если ПМ не знает, что ему нужно для достижения этой цели (повышение скорости тестирования, или улучшение качества отчетности, или ...)?
3) Насколько точными (конкретными?) должны быть эти показатели? Если можно, пожалуйста, пример.