Как "продать" QA руководству |
21.08.2017 00:00 |
Автор: Майкл Фритциус (Michael Fritzius) Оригинал статьи: https://testzius.wordpress.com/2017/05/21/how-to-sell-qa-to-higher-ups/ Перевод: Ольга Алифанова Полный круг Мы (снова) описали полный круг, и обеспечение качества вновь рассматривается как нечто, приносящее убытки, а не сокращающее их. Я много пишу об автоматизации, но в душе я все еще ручной тестировщик. Искусство взять ПО в свои руки и придумать нестандартные способы поиска дефектов в нем очень важно для любой компании, которая хочет быть успешной. Убедить менеджмент в том, что QA необходимо, может быть затруднительно. Мы-то все это понимаем, потому что мы этим живем и дышим, но людям "снаружи" все это кажется черной дырой, куда уходят деньги – особенно если вы регулярно выдаете хорошее ПО и так. Мой опыт говорит, что менеджмент любит цифры и метрики. Поэтому я хочу поделиться идеями, как использовать это на благо себе, дабы убедить вышестоящее руководство в необходимости обзавестись хорошим QA. Количественные аргументы Лучший способ доказать, что QA необходимо – присвоить багам ценник. Этот ценник должен отражать финансовый урон, который понесет компания, если этот баг попадет в релиз. Некоторые баги (к примеру, косметические недочеты) стоят копейки. Некоторые – такие, как дыры в безопасности – могут достигать миллиардов долларов. Некоторые баги (например, отсутствие снятия 10 долларов с каждого покупателя за что-нибудь) будут стоить больше и больше в зависимости от количества людей, столкнувшихся с ними. Некоторые баги будут стоить очень дорого, если группа людей (или целые отделы) прекратит работу над тем, над чем должна, и займутся исправлением проблемы. Цена ряда багов будет высокой, если они связаны с несоответствием каким-либо стандартам. Но любой, абсолютно любой баг приведет к тому, что люди бросят работу, приносящую прибыль, и начнут заниматься починкой. Комбинация этих и других переменных – это стоимость бага. Сравните это значение с тем, сколько в год уйдет на команду QA/ Можно отметить, что я не упомянул про стоимость поиска багов командой QA, и цену труда разработчиков, исправляющих баг. Даже если мы скажем, что один тестировщик находит один баг, и у одного разработчика починка бага займет сутки – это все равно слезы по сравнению с тем, как дорог будет баг, ушедший в релиз. Качественные аргументы Количественные аргументы, приведенные выше, возможно, уже вооружили вас довольно крупными числами. Но давайте поговорим о других доводах – о качественных. Это такие вещи, как восприятие компании, как внутреннее, так и внешнее. В какую копеечку нам влетит черный пиар, если баг уйдет в релиз? Сколько будет стоить привлечение новых сотрудников? Захотят ли люди работать в компании, которая, судя по всему, разваливается на части? Сколько будет стоить удержание имеющихся работников? Не уйдут ли люди из-за стресса, возникающего из-за необходимости постоянного пожаротушения? Сколько стоит потеря данных, борьба с хакерами? Не продают ли хакеры ценную информацию тому, кто подороже даст, заставляя вашу компанию выглядеть недостойной доверия? Не перерабатывают ли люди, не болеют ли чаще обычного? Не пришлось ли вам нанять больше специалистов поддержки для работы с недовольными клиентами? Точную стоимость качественных активов подсчитать сложно, но если вы можете это сделать – сравните это число с тем, сколько стоит содержание команды QA. Побочные эффекты Если вы, читатель этой статьи – тестировщик, вы могли заметить, что найденный баг, серьезно влияющий на пользователей, крупно экономит деньги компании. Побочным эффектом от этой статьи может быть корректировка вашей стратегии тестирования. На данный момент самая проблемная область ПО – это безопасность. Крайне редко слышишь в новостях про серьезные баги, не имеющие к ней отношения. Вот несколько советов, как искать наиболее дорогостоящие баги. Какие части системы…
Заключение Если убеждение менеджмента, что QA необходимо, все еще кажется неразрешимой проблемой, вооружитесь фактом, что успех требует отличного ПО. Если оно у вас есть, все остальное будет. Отличный отдел QA – это ключевой фактор отличного ПО. |