Что менеджер проектов должен знать о тестировании

Автор: Наталья Руколь

Я 8 лет занимаюсь тестированием. Ручным и автоматизированным, в роли тестировщика и тест-менеджера, как сотрудник компании и как представитель аутсорса. И почти на всех проектах сталкиваюсь с одной и той же проблемой: руководители проектов не понимают, зачем им нужно тестирование.

Если задать среднестатистическому РМ'у простой вопрос: «Зачем на этом проекте тестирование?», то чаще всего ответом будет «Ты же тест-менеджер, ты и должна ответить на этот вопрос».

Но ведь приходя в парикмахерскую вы не говорите мастеру «вы сами знаете, что мне нужно»? И в продуктовом магазине вы не просите продавца накидать вам в корзину то, что вам нужно? Вы можете советоваться, вы можете узнавать «а как можно?», спрашивать варианты, но решение всегда за вами. В чём отличие тестирования? Может, в том, что слишком мало менеджеров проектов понимают, зачем оно им?

В этой статье я постараюсь выступить в роли продавца, который показывает клиенту: «а что вообще бывает?» Многие вещи будут описаны, возможно, слишком подробно, слишком просто… Не серчайте, мне просто очень хочется быть понятой :)



Читать дальше

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

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

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

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

Ну по запросу РМ'а можно внедрить в качестве ключевого показателя эффективности "количество пропущенных в продакшн багов" или "соотношение пропущенных и найденных".

При этом согласовать с ним длительность тестового цикла (скорость), размер команды (бюджет) и формат отчётности.

Пример показателей: в прошлой итерации мы пропустили 4% багов и 7% с разбивкой по весу. В следующей итерации нам нужно не больше 2% и 5%, а теперь давайте-ка дружно продумывать стратегию достижения этой цели.

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

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

В каком направлении начала бы анализировать я.

Количество багов на версию релиза в продакшене. Сопоставлять с количеством новых фич в релизе, с временем потраченным на тестирование.
Количество багов по типу (UI/FN/Performance/Security). Сопоставлять с количеством тестов.
Количество багов, на которые есть аналогичные баги, найденые во время тестирования (и баги не были не пофикшены изза низкого приоритета, например). Это к отчетности.
Итд.

to Natalya Rukol

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

Вопросы:

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

1) % от чего?

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

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

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

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

?

to kitsune

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Другой пример:
релиз1 тестировали 2 недели, 5 фич, 10 багов пропущено
релиз2 тестировали 2 недели, 10 фич, 20 багов пропущено
Вывод?

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

Другой пример: выпустили фичу в релиз, функционал тестировали две недели, UI пару дней, от кастомеров пришло 50 багов на UI и один минорный на функционал.
Вывод?

По вашему примеру:
Может быть так:
Security
релиз1 - прогнано 91/100 тестов, 15 багов
релиз2 - прогнано 40/100 тестов, 15 багов

Или так:
релиз1 - прогнано 91/100 тестов, 15 багов
релиз2 - прогнано 40/100 тестов, 30 багов

Выводы?

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

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

Я имела в виду дублирующие баги из прода. Тестеры нашли десяток багов, а потом эти же баги нашли кастомеры (или кто у вас присылает баги из прода).

Про ситуацию, которую вы описываете: тестеры пишут дупликаты друг на друга. Если такой баг 1, он не имеет никакого значения вообще, проблемы дупликатов не существует, можно не тратить усилия. На 101 баг можно осторожно посмотреть.
Я считала на одном проекте процент дупликатов от числа багов, зарепорченых каждым баг-репортером (туда вошли и тестеры, и программисты, и пм). Вне зависимости от количества багов (понятно - у тестера сотни, у пм - десяток) процент дупликатов был одинаковый - что-то вроде 2,5%.
Кроме одного случая, где процент дупликатов был вдвое больше.
Выводы были такие: в нашем случае небольшой процент дупликатов - это естественно, бороться с ними дороже, чем прогонять по циклу (репортинг, реджект, проверка). Насчет индивидуального случая думали отдельно.
(!) но это опасная штука, формальный расчет производительности относительно людей.

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

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

to astenix

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

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

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

to kitsune

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

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

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

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

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

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

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

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

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