На моей нынешней должности QA стало узким местом. У нас был неудачный случай, когда функции были исключены из текущей сборки, чтобы QA мог закончить тестирование. Это означает, что разработанные функции могут не пройти тестирование в течение 2-3 недель после того, как разработчик уже ушел. Поскольку dev движется быстрее, чем QA, этот промежуток времени будет только увеличиваться.
Я продолжаю перелистывать свою копию Code Complete в поисках фрагмента «Жесткие данные», который показывает, что стоимость исправления дефектов растет экспоненциально, чем дольше он существует. Может ли кто-нибудь указать мне на некоторые исследования, которые подтверждают эту концепцию? Я пытаюсь убедить силы в том, что узкое место QA намного дороже, чем они думают.
источник
Ответы:
Вам не нужны никакие ссылки, ИМХО. Вот что вы могли (скорее, должны ) сделать:
Определите стоимость задержки! Давайте предположим, что для тестирования этой функции требуется 1 неделя. Задержка 2-3 недели подразумевает, что функция не будет доступна по крайней мере до 4-й недели. И это тоже при условии 100% успеха. Добавьте время фиксации еще одну неделю, так что это примерно 5 недель задержки.
Теперь, если возможно, получите доступ к ожидаемому сроку реализации проекта / функции. Когда клиент этого ожидает? Это ускользнет? Если нет, будут ли другие проскальзывать как следствие? Итак, на сколько «релиз» будет отложен в результате?
Какова «стоимость для компании» для этого выпуска, то есть сколько клиент ожидает получить прибыль от этого выпуска? Если они ожидают 5200 долларов в год прибыли от этого выпуска, то каждая недолгая спад обойдется им в 100 долларов в упущенном доходе. Это вид клиента. Вы можете иметь или не иметь доступ к этим данным, но стоит учесть и указать, как задержка может повлиять на отношения.
Теперь, что потеря для разработчиков? Как только разработчик перейдет к другим функциям, вы попросите его / ее прервать цикл и «исправить» предыдущую функцию. Какая потеря времени / усилий? Преобразуйте это в стоимость компании, используя зарплату как кратную за каждый потраченный час. Вы можете использовать это, чтобы сказать количество «прибыли / дохода», на которое «съедают» отходы.
То, на что вы наткнулись, может быть удобно количественно определено с помощью «Затраты на задержку» - отстаивают Дон Рейнерштейн в «Принципах разработки продукта», а также Дин Леффингвелл в «Требованиях к гибкому программному обеспечению». Вы должны быть в состоянии подкрепить каждое такое требование экономическими факторами, чтобы убедить «высшие силы», чей основной язык - $$ - вы должны говорить на их языке, чтобы убедить их :)
Зверь удачи! (каламбур предназначен :)
источник
Я не думаю, что Code Complete - это то, что вам нужно. Это не проблема кода, это проблема процесса и, возможно, проблема управления.
Если часть вашего процесса особенно слаба, то пришло время разрушить Теорию Ограничений :
Определите ограничение.
Это означает поиск самой медленной или самой неэффективной части всего процесса. В твоем случае это тестирование. Но какая часть тестирования? Это:
Все это очень разные проблемы и требуют разных решений. Вам нужно решить, что является наиболее дорогостоящим / важным. Обосновать это руководству не должно быть сложно, так как все вышеперечисленные действия стоят времени (деньги АКА), и только пара из них - время с добавленной стоимостью.
Используйте ограничение.
Другими словами, оптимизировать вокруг процесса ограничивающего. Никогда не позволяйте тестерам бездействовать. По сути это составляет:
Этот этап не о оптимизации самого процесса тестирования (пока), а скорее об уменьшении накладных расходов. Не тратьте время тестеров. Исключение времени, которое действительно тратится впустую, также должно быть легко продать руководству.
Подчините другие действия ограничению.
На этом этапе тестеры настолько продуктивны, насколько это возможно, сами по себе, поэтому нам нужно начать заимствовать производительность из других областей:
Поднимите ограничение.
Если тестеры работают на полную мощность - как с точки зрения производительности, так и с минимальными накладными расходами - и это все еще недостаточно быстро, то вам нужно начать вкладывать больше средств в тестирование.
Вернитесь к шагу 1.
Я хотел бы сказать, что это все здравый смысл, но, к сожалению, это не так, по крайней мере, в большинстве организаций. Если вы сталкиваетесь с большим сопротивлением со стороны руководства, неоценимой техникой является картирование потока создания ценности (техника бережливого производства), которую вы можете использовать, чтобы показать, сколько времени и, следовательно, денег фактически тратится каждый день, когда кандидат на освобождение не может перейти к следующему этапу. Трудно понять стоимость возможностей, но это один из лучших способов визуализации и демонстрации.
И если ничего из этого не работает ... тогда, может быть, вы в неблагополучной компании, уходите, пока не стало слишком поздно!
Но вы не решите эту проблему, просто бросив несколько бумаг на рабочий стол менеджера и попросив их бросить деньги на проблему, потому что они предполагают (правильно), что бросание денег на нее может на самом деле не решить ее, и может даже сделать это хуже. Вы должны предоставить решения , и вот о чем этот ответ. Если вы представите проблему как «вот список способов, которыми мы можем начать решать эту проблему, в порядке убывания затрат / выгод», а не «нам нужно больше тестеров», тогда у вас будет гораздо больший успех.
источник
Страницы 29 и 30 могут содержать данные, которые вы ищете, хотя может потребоваться дальнейшее наблюдение.
Я хотел бы изучить исследование, упомянутое в этом предложении на странице 30:
Кстати, именно ваш вопрос заставил меня снова взять книгу, чтобы обновить ее :-)
источник
То, что вы описываете, является узким местом в процессе. Теория Lean утверждает, что в процессе всегда будет узкое место, но его серьезность может варьироваться в широких пределах. Если QA наняла еще одного, то развитие может стать узким местом.
Чтобы понять стоимость, представьте следующую ситуацию. Вы выбрали одного из разработчиков. Его работа никогда не будет гарантией качества, но всегда будет стоять в очереди на неопределенный срок. Представьте себе, что это будет означать, что QA может обеспечить качественное обеспечение работы остальных разработчиков своевременно и без задержек.
В этом сценарии стоимость задержки равна стоимости зарплаты разработчика, поскольку его работа будет потрачена впустую.
Причина, по которой я спорю с точки зрения стоимости, а не ценности, создаваемой процессом, заключается просто в том, что труднее документировать ценность процесса, даже если он намного лучше.
источник
Экспоненциальная стоимость поиска ошибки, кажется, основана на исследовании NIST . Исследование было проведено с учетом различных этапов водопада:
( таблица здесь отсюда )
Одной из целей методологий разработки программного обеспечения Agile является устранение этих отдельных этапов и снижение этих затрат. Цифры не применяются при использовании других методологий для водопада.
источник
Ваша проблема не в QA, на самом деле, если ваш QA проводит тестирование, задержки - это, по крайней мере, ваше беспокойство. Пожалуйста, позвольте мне объяснить (опять же, это распространенное заблуждение в индустрии программирования) ... QA Гарантирует качество продукта, наблюдая за всем SDLC, начиная с Требований (может быть, раньше), путем разработки, проверки, выпуска и поддержки. Тестирование гарантирует отсутствие явных дефектов в коде. Есть очень большая и важная разница. Если бы у вас был настоящий QA, они бы по всему отделу Test / V & V спрашивали, почему они затрачивали время (и, следовательно, деньги) на отсрочку релизов, или на управление проектами, если они правильно управляли планированием проектов или на всем протяжении процесса управления. конечно, было достаточно тестеров для создаваемого кода и т.д ...
Итак, предполагая, что под QA вы действительно подразумеваете Test, вернемся к первоначальному вопросу. Code Complete понял все правильно - стоимость дефекта - это время, затрачиваемое от вставки до исправления. Раннее обнаружение полезно только в том случае, если вы также исправляете это рано, но интерпретация большинства людей неверна.
(Примечание: я играю здесь адвоката дьяволов, не воспринимайте это буквально, потому что я ничего не знаю о вашей ситуации) Причина задержки в вашем отделе тестирования - это цена, безусловно, однако я должен спросить, если вы ожидая, пока они найдут ваши недостатки, что вы делаете - не должны ли вы найти свои собственные недостатки? Возможно, если бы у них было меньше работы (благодаря более высокому качеству ввода с меньшим количеством дефектов от вас), задержка была бы не такой значительной и затраты были бы меньше. Как менеджер, я бы спросил вас, как вы планируете уменьшить количество дефектов в коде, который вы доставляете проверить, так как (исходя из ваших аргументов) эти дефекты стоят дороже, если вы обнаружите их самим.
Также, как вы, менеджер, я мог бы заявить, что работа по тестированию не выявляет ваши дефекты, их работа заключается в том, чтобы обнаруживать, что дефектов нет - если вы ожидаете, что они найдут дефекты, возможно, вы недостаточно хорошо выполнили свою работу.
Будьте осторожны, как вы подходите к этому. Если у вас нет решения проблемы, вы, скорее всего, отойдете на второй план.
источник