-
Исходный адрес: Почему ошибки не исправляются
Автор: Алан Пейдж, директор по развитию тестирования в Microsoft, соавтор книги «Как мы тестируем программное обеспечение в Microsoft» (в переводе с китайского «Путь тестирования программного обеспечения Microsoft»).
Перевод: Лу Юэли, Лу Мэнъянь, Ван Хун
В последнее время я встречаю все больше и больше людей, удивляющихся тому, что мы выпускаем продукт с ошибками. Что меня удивило, так это то, что многие из этих людей были тестировщиками программного обеспечения, и я думал, что они уже знают об этом. Я предлагаю вам сначала прочитать более раннюю (но превосходную) статью Эрика Синка. Не уверен, насколько больше я смогу внести свой вклад в эту тему, но хочу попробовать.
Многие ошибки не стоит исправлять. «Вы тестировщик?», — крикнете вы мне, «Тестировщики — стражи качества продукта. Могу еще раз повторить (при необходимости) многие баги исправлять не стоит». «Позвольте мне рассказать вам, почему. В большинстве случаев исправление ошибки требует изменения кода. А изменение кода требует вложения ресурсов (времени) и сопряжено с риском. Это отстой, но это правда. Иногда, если риск и инвестиции далеко перевешивают ценность исправления ошибок, поэтому мы не будем их исправлять.
Наше решение о том, исправлять ли ошибку, не основано и не должно основываться на «чувствах». Мне нравится использовать концепцию «боль пользователя», чтобы помочь мне принимать решения. Я использую три ключевых фактора для рассмотрения и определения «боль пользователя»:
1. Серьезность. Какое влияние окажет эта ошибка: приведет ли она к сбою всей программы? Приведет ли это к потере информации пользователя? Или это не так серьезно? Есть ли более простое решение? Или это просто неактуальный вопрос?
2. Частота. Часто ли пользователи сталкиваются с этой проблемой? Является ли это частью основного рабочего процесса программы? Или это скрыто в функции, которая обычно не используется? Небольшие проблемы, существующие в наиболее часто используемых частях программы, вероятно, потребуется исправить, тогда как некоторые серьезные проблемы, существующие в менее часто используемых частях программы, можно оставить в стороне.
3. Влияние на клиентов. Если вы хорошо подготовились, вы уже должны знать, кто ваши клиенты и сколько (или сколько вы надеетесь иметь) пользователей будет в каждой из ваших групп клиентов. Затем вам нужно решить, затронет ли эта проблема каждого пользователя или только некоторых людей. Если вы сможете отслеживать, как клиенты используют ваш продукт, вы сможете получить более точные данные.
Вышеупомянутые три фактора составляют формулу. Присвойте диапазон значений каждому из вышеперечисленных факторов и выполните некоторые расчеты — вы можете напрямую складывать, умножать или добавлять веса в зависимости от вашего приложения и рыночных факторов. Например, нам нужно всего лишь выполнить сложение и присвоить каждой ошибке числовой диапазон в 10 баллов.
Ошибка №1: Например, это ошибка, приводящая к сбою программы (10 баллов), она существует в основной части программы (10 баллов) и затрагивает 80% клиентов (8 баллов), поэтому эта ошибка вызывает «боль пользователя» «Объем составляет 28 пунктов, и мы уверены, что исправим это.
Ошибка №2: Это просто ошибка компоновки (2 балла), она появляется во вторичном окне (2 балла), а та часть программы, где находится ошибка, будет использоваться только в старых версиях (2 балла). Поэтому значение «больности пользователя» от этой ошибки составляет 6 баллов, и исправлять ее мы, скорее всего, не будем.
К сожалению, многие ситуации не так просты, как описанные выше. Ошибка №3 — это проблема потери данных (10 баллов), которая существует в большей части приложения, но не удается устранить ее только при определенных обстоятельствах (5 баллов) (кстати, данные субъективны). Исследования клиентов показывают, что он используется редко (2 балла). Поэтому его значение «боль пользователя» составляет 17 баллов. Это неоднозначные данные, которые можно изменить или нет. С одной стороны, вложения, необходимые для ее исправления, возможно, не окупятся, но пока проблема понятна и в ней нет «слепых зон», игнорирование ошибки, вероятно, является правильным подходом.
С другой стороны, вам придется сопоставить это с другими ошибками в системе. Здесь мы применяем эффект «Разбитого окна» — если в приложении слишком много таких среднепороговых ошибок, качество продукта (или, по крайней мере, восприятие качества) сильно пострадает. Когда вы рассматриваете каждую ошибку в системе, вам следует также учитывать другие (известные) ошибки в системе и использовать это для анализа и принятия решения, какие ошибки необходимо исправить, а какие не стоит исправлять.
Действительно, очень плохо иметь ошибки в официально выпущенном программном обеспечении, но, основываясь на наших существующих инструментах разработки и языках разработки, мы пока не нашли более разумного решения.
Пополнить:
Когда я пишу это, мне кажется, что я упускаю четвертый фактор в формуле: дату выпуска. Этот фактор также играет ключевую роль в принятии решения исправлять/не исправлять ошибку по мере приближения даты выпуска. Однако я не уверен, является ли это четвертым фактором или каков порог количества «боль пользователя», необходимого для исправления ошибки ближе к выпуску.