Стоимость более длительной задержки между разработкой и QA

На моей нынешней должности QA стало узким местом. У нас был неудачный случай, когда функции были исключены из текущей сборки, чтобы QA мог закончить тестирование. Это означает, что разработанные функции могут не пройти тестирование в течение 2-3 недель после того, как разработчик уже ушел. Поскольку dev движется быстрее, чем QA, этот промежуток времени будет только увеличиваться.

Я продолжаю перелистывать свою копию Code Complete в поисках фрагмента «Жесткие данные», который показывает, что стоимость исправления дефектов растет экспоненциально, чем дольше он существует. Может ли кто-нибудь указать мне на некоторые исследования, которые подтверждают эту концепцию? Я пытаюсь убедить силы в том, что узкое место QA намного дороже, чем они думают.

Вам не нужны никакие ссылки, ИМХО. Вот что вы могли (скорее, должны ) сделать:

Определите стоимость задержки! Давайте предположим, что для тестирования этой функции требуется 1 неделя. Задержка 2-3 недели подразумевает, что функция не будет доступна по крайней мере до 4-й недели. И это тоже при условии 100% успеха. Добавьте время фиксации еще одну неделю, так что это примерно 5 недель задержки.

Теперь, если возможно, получите доступ к ожидаемому сроку реализации проекта / функции. Когда клиент этого ожидает? Это ускользнет? Если нет, будут ли другие проскальзывать как следствие? Итак, на сколько «релиз» будет отложен в результате?

Какова «стоимость для компании» для этого выпуска, то есть сколько клиент ожидает получить прибыль от этого выпуска? Если они ожидают 5200 долларов в год прибыли от этого выпуска, то каждая недолгая спад обойдется им в 100 долларов в упущенном доходе. Это вид клиента. Вы можете иметь или не иметь доступ к этим данным, но стоит учесть и указать, как задержка может повлиять на отношения.

Теперь, что потеря для разработчиков? Как только разработчик перейдет к другим функциям, вы попросите его / ее прервать цикл и «исправить» предыдущую функцию. Какая потеря времени / усилий? Преобразуйте это в стоимость компании, используя зарплату как кратную за каждый потраченный час. Вы можете использовать это, чтобы сказать количество «прибыли / дохода», на которое «съедают» отходы.

То, на что вы наткнулись, может быть удобно количественно определено с помощью «Затраты на задержку» - отстаивают Дон Рейнерштейн в «Принципах разработки продукта», а также Дин Леффингвелл в «Требованиях к гибкому программному обеспечению». Вы должны быть в состоянии подкрепить каждое такое требование экономическими факторами, чтобы убедить «высшие силы», чей основной язык - $$ - вы должны говорить на их языке, чтобы убедить их :)

Зверь удачи! (каламбур предназначен :)

Я не думаю, что Code Complete - это то, что вам нужно. Это не проблема кода, это проблема процесса и, возможно, проблема управления.

Если часть вашего процесса особенно слаба, то пришло время разрушить Теорию Ограничений :

1. Определите ограничение.

   Это означает поиск самой медленной или самой неэффективной части всего процесса. В твоем случае это тестирование. Но какая часть тестирования? Это:

   • Готовите тестовую среду?
   • Определение, что тестировать?
   • Функциональные (приемочные) тесты?
   • Регрессионные тесты?
   • Разведочные испытания?
   • Сообщение об ошибках / дефектах от испытаний?
   • Определение шагов для воспроизведения ошибки?
   • Получаете разъяснения от разработчиков или руководителей проектов?
   • Исправление проблем, обнаруженных на этапе QA?

   Все это очень разные проблемы и требуют разных решений. Вам нужно решить, что является наиболее дорогостоящим / важным. Обосновать это руководству не должно быть сложно, так как все вышеперечисленные действия стоят времени (деньги АКА), и только пара из них - время с добавленной стоимостью.

2. Используйте ограничение.

   Другими словами, оптимизировать вокруг процесса ограничивающего. Никогда не позволяйте тестерам бездействовать. По сути это составляет:

   • Размещение тестировщиков в командах разработчиков, если они еще этого не делают, поэтому существует постоянный цикл обратной связи с разработчиками.
   • Частые тестовые развертывания, поэтому всегда есть что-то новое / исправленное для тестирования.
   • Делать общение быстрее и чаще. Например, отдавайте предпочтение обмену мгновенными сообщениями через потоки электронной почты.
   • Обеспечение того, чтобы тестеры имели лучшие доступные инструменты (быстрые машины, несколько мониторов, оптимизированное отслеживание ошибок и т. Д.)

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

3. Подчините другие действия ограничению.

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

   • Проинструктируйте разработчиков и обслуживающий персонал о том, чтобы дать тестировщикам приоритет, независимо от того, над чем они еще работают.
   • Если у вас нет многофункциональных команд, резервируйте комнату для собраний каждый день в заранее установленное время, чтобы тестировщикам не приходилось тратить время на их бронирование.
   • Отвлекайте больший процент времени разработчиков (и, возможно, операций) от работы над функциями; например, сосредоточиться на исправлении ошибок, техническом долге / рефакторинге, проверке кода и модульном тестировании.
   • Тестируйте непрерывно и постепенно - не развивайтесь в течение 3 недель, а затем передайте его тестерам. Попросите разработчиков поработать над тем, чтобы сделать их код тестируемым немедленно, например, с помощью скаффолдинга или прототипов пользовательского интерфейса.

4. Поднимите ограничение.

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

   • Если вы полагаетесь на тестовые развертывания вручную, автоматизируйте его с помощью сценариев непрерывной интеграции и управления конфигурацией.
   • Если создание планов тестирования занимает много времени, работайте над получением лучших критериев приемлемости (например, ИНВЕСТ ). Большинство организаций изначально очень плохо в этом.
   • Если приемочные испытания занимают слишком много времени, начните автоматизировать их. Используйте такие инструменты, как Cucumber или FitNesse, или пишите тесты типа xUnit, если необходимо. Есть также Selenium, Watij и другие инструменты автоматизации браузера, если тестирование пользовательского интерфейса занимает много времени.
   • Если регрессионные тесты занимают слишком много времени, автоматизируйте это тоже. Если это не может быть автоматизировано, сфокусируйтесь на улучшении качества вне шлюза, то есть с еще большим акцентом на проверку кода, модульное тестирование, инструменты статического анализа и т. Д. Разработчики должны быть достаточно уверены, что фактических ошибок очень мало, прежде чем их пропустить. QA (дефекты продукта - другая история).
   • Если пробное тестирование является узким местом, вы можете отложить некоторые из них до окончания выпуска или заключить контракт с фирмой по тестированию на выполнение высокопараллелизируемых вещей, таких как тестирование одного и того же рабочего процесса в нескольких браузерах.
   • Если тестировщики не могут воспроизвести много ошибок, рассмотрите возможность создания среды тестирования емкости, чтобы можно было начать воспроизводить периодически возникающие ошибки. Или попробуйте запустить свои автоматические приемочные тесты параллельно и непрерывно, в течение всего дня, ведя подробные журналы.
   • Если исправление ошибок занимает слишком много времени, тогда начните разбивать свои проекты и / или серьезно подумайте о реорганизации ваших решений. Или, альтернативно, не исправляйте некоторые из них; Не каждая ошибка имеет решающее значение, вы должны иметь возможность расставить приоритеты вместе с функциональностью.
   • Если ничего не помогает, наймите больше тестеров.

5. Вернитесь к шагу 1.

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

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

Но вы не решите эту проблему, просто бросив несколько бумаг на рабочий стол менеджера и попросив их бросить деньги на проблему, потому что они предполагают (правильно), что бросание денег на нее может на самом деле не решить ее, и может даже сделать это хуже. Вы должны предоставить решения , и вот о чем этот ответ. Если вы представите проблему как «вот список способов, которыми мы можем начать решать эту проблему, в порядке убывания затрат / выгод», а не «нам нужно больше тестеров», тогда у вас будет гораздо больший успех.

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

Я хотел бы изучить исследование, упомянутое в этом предложении на странице 30:

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

Кстати, именно ваш вопрос заставил меня снова взять книгу, чтобы обновить ее :-)

То, что вы описываете, является узким местом в процессе. Теория Lean утверждает, что в процессе всегда будет узкое место, но его серьезность может варьироваться в широких пределах. Если QA наняла еще одного, то развитие может стать узким местом.

Чтобы понять стоимость, представьте следующую ситуацию. Вы выбрали одного из разработчиков. Его работа никогда не будет гарантией качества, но всегда будет стоять в очереди на неопределенный срок. Представьте себе, что это будет означать, что QA может обеспечить качественное обеспечение работы остальных разработчиков своевременно и без задержек.

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

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

Я продолжаю перелистывать свою копию Code Complete в поисках фрагмента «Жесткие данные», который показывает, что стоимость исправления дефектов растет экспоненциально, чем дольше он существует. Может ли кто-нибудь указать мне на некоторые исследования, которые подтверждают эту концепцию?

Экспоненциальная стоимость поиска ошибки, кажется, основана на исследовании NIST . Исследование было проведено с учетом различных этапов водопада:

Software Development Stage         | Cost
-----------------------------------+------
Requirements and Design            | 1X
Code and Unit Testing              | 5X
Integration and System Testing     | 10X
Beta Testing                       | 15X
Post Release                       | 30X

( таблица здесь отсюда )

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

Ваша проблема не в QA, на самом деле, если ваш QA проводит тестирование, задержки - это, по крайней мере, ваше беспокойство. Пожалуйста, позвольте мне объяснить (опять же, это распространенное заблуждение в индустрии программирования) ... QA Гарантирует качество продукта, наблюдая за всем SDLC, начиная с Требований (может быть, раньше), путем разработки, проверки, выпуска и поддержки. Тестирование гарантирует отсутствие явных дефектов в коде. Есть очень большая и важная разница. Если бы у вас был настоящий QA, они бы по всему отделу Test / V & V спрашивали, почему они затрачивали время (и, следовательно, деньги) на отсрочку релизов, или на управление проектами, если они правильно управляли планированием проектов или на всем протяжении процесса управления. конечно, было достаточно тестеров для создаваемого кода и т.д ...

Итак, предполагая, что под QA вы действительно подразумеваете Test, вернемся к первоначальному вопросу. Code Complete понял все правильно - стоимость дефекта - это время, затрачиваемое от вставки до исправления. Раннее обнаружение полезно только в том случае, если вы также исправляете это рано, но интерпретация большинства людей неверна.

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

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

Будьте осторожны, как вы подходите к этому. Если у вас нет решения проблемы, вы, скорее всего, отойдете на второй план.