Home

Автор: тестировщик и блогер Sean

Оригинал статьи: http://chippietester.blogspot.ru/2015/10/measuring-success-in-testing.html

Перевод: Ольга Алифанова

Я абсолютно убежден,что подходы и методы тестирования нужно постоянно совершенствовать. В последнее время моя команда стремится к тому, чтобы наши тестировщики тоже разделяли эту позицию. Мы пытаемся этого добиться, разъясняя, что:

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

Беседуя с тест-аналитиками о совершенствовании наших подходов и внедрении новых техник, я начал задумываться о целях улучшения тестирования. Как мы узнаем, что эта эволюция положительно повлияет на него? Как мы определим, что новая идея действительно улучшила наши процессы?

Я спросил тест-аналитиков, бизнес-аналитиков и владельцев продукта, как измеряется успешность тестирования.

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

 Расшифровка моих записей:

1. Метрики, связанные с количеством дефектов.

a. Количество дефектов, найденных в процессе тестирования.

i. Смысл метрики: если мы нашли множество дефектов в фазе тестирования, то эти дефекты не дойдут до пользователя. Следовательно, качество нашего продукта повысилось.

b. Количество дефектов в релизе

i. Смысл метрики: если в релизе багов не обнаружено, то наше тестирование покрывает все возможные области продукта.

c. Количество критических дефектов в релизе.

i. Смысл метрики: убедиться, что критические дефекты не доживают до релиза.

d. Проблемные места:

i. Насколько значимы найденные баги? Баги есть в любом продукте, но имеют ли они значение для бизнеса?

ii. Критичность дефекта – штука субъективная. Если в релиз не вышел ни один критичный дефект, но продукт провалился и никому не нужен, возможно, вы неверно оценили уровень критичности. Успешно ли в этом случае ваше тестирование?

iii. Если мы не находим баги - это не значит, что их не осталось. И наоборот - возможно, в коде просто было очень мало багов изначально. И чьей заслугой в результате будет качественный продукт - тестировщиков или программистов?

2. Метрики, измеряющие время.

a. Время, потраченное на тестирование.

i. Смысл метрики: чем быстрее будет выпущен продукт, тем лучше. Следовательно, чем меньше времени мы тратим на тестирование, тем оно успешнее.

b. Время, прошедшее с момента обнаружения последнего бага.

i. Смысл метрики: если мы давно не находили багов, возможно, их не осталось.

c. Проблемные места:

i. Быстро - не значит качественно.

ii. Если вы не можете найти баги, это не значит, что их нет. Возможно, найдены все очевидные баги, но продукт не избавлен от них окончательно, и его качество может пострадать..

3. Покрытие

a. Степень покрытия кода тестами

i. Смысл метрики: если весь код запускался хотя бы раз, выше шансы, что мы найдем баги продукта. Эту задачу решают, к примеру, юнит-тесты.

b. Количество приемочных критериев, которым удовлетворяет продукт.

i. Смысл метрики: мы знаем, как продукт должен работать. Если он работает как надо, значит, мы создали именно то, что собирались создать.

c. Вопросы для размышления:

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

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

4. Объем тестирования

a. Объемы проведенного тестирования

i. Смысл метрики: если мы много тестировали, продукт наверняка получится качественным.

b. Объем тестирования, которое не было проведено

i. Смысл метрики: мы сознательно решили не тестировать эти области.

c. Вопросы для размышления:

i. Большие объемы тестирования могут быть пустой тратой времени. Отказ от тестирования требует взвешенного решения, что именно нужно тестировать, а что можно пропустить. Это решение всегда связано с определенными рисками, самый серьезный из которых - ваша предвзятость. В прошлый раз вы не тестировали эту область, продукт от этого не пострадал - будете ли вы проверять ее в следующий раз? Повлиять на решение может и предвзятость бизнеса - "В прошлый раз мы много тестировали, а продукт провалился - значит, тестируйте еще больше!"

Мой взгляд на то, как измерить успешность тестирования

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

К примеру, если критерии успешности продукта – это его выход в срок и в рамках бюджета, сможете ли вы оценить, какую роль в этом сыграло тестирование? Поэтому, оценивая, насколько тестирование помогло успеху продукта, я ищу ответы на следующие вопросы:

1. Достаточно ли я тестировал?

• Достаточно ли сценариев я проверил?
• Насколько быстро я справился с работой?

2. Добавило ли тестирование ценности продукту?

• Сделал ли я все, что мог, чтобы нововведение было успешным?
• Могу ли я добиться тех же результатов, отказавшись от тестирования некоторых областей?

3. Нашел ли я баги в продукте?

• Какие баги критичны для успешности продукта?
• Какие баги наиболее значимы для заинтересованных лиц?

4. Что такое "успешный продукт" в глазах заинтересованных лиц?

• Нет багов?
• Быстрый релиз?
• Долгосрочная стабильность?

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

Мне очень нравится статья Майкла Болтона «Три вида метрик и два способа их использовать». Она заставила меня задуматься о различных подходах к использованию метрик и том, какого уровня детализации требует оценка тестирования.

Думаю, главное, что я узнал в процессе общения с людьми и размышлений на эту тему - это то, что к оценке успешности тестирования нужно подходить со всей серьезностью. С моей точки зрения, это не столько шаблонная, сколько творческая деятельность, и в любом случае, это стоит обдумать.