Скорей всего, кто-то уже набил на этом руку, а для кого-то подобный вопрос все еще остается настоящей головной болью. Процесс оценки времени на тестирование – задача на все 100% коллективная.
К тому же, подобный просчет включает в себя не только стадии тестов, но и первичную оценку со стороны QA специалиста, которая со временем может претерпеть глобальные изменения, о которых не было предварительно сообщено клиенту.
В последнее время тема внедрения КПЭ в сферу тестирования является очень актуальной, и этому моменту уделено много внимания со стороны профильных специалистов.
Понятие КПЭ
Термин КПЭ (ключевые показатели эффективности) – своего рода индикатор достижения конечного успеха в определенной сфере деятельности или в достижении заранее установленных целей. По-простому можно сказать, что КПЭ – это численно измеримый индикатор фактически достигнутых результатов.
В случае ситуации с тестированием, КПЭ – это показатель эффективности работы QA отдела внутри определенной организации по обеспечению качества.
Зачем тестировщикам КПЭ?
На самом деле все очень просто и понятно: с помощью КПЭ можно просматривать текущее состояние проекта и на их основе принимать профилактические меры, позволяющие избежать глобальных проблем (задержки сроков, пропуска большого числа явных ошибок и т.д.). Именно на основе КПЭ любой руководитель проекта может не только просматривать сильные и слабые стороны разработки, но и отслеживать в динамике процесса создания продукта слабые и сильные стороны личностных управленческих решений (что именно было правильным решением, какие решения были более удачными, а которые – менее), чтобы в будущем иметь возможность точечно их откорректировать.
Также, в сумму КПЭ можно добавить не только общераспространенные численные показатели, но и качественные величины (к примеру, «уровень удовлетворённости клиента»).
Где взять пресловутое КПЭ?
Какие именно метрики лучше всего использовать на своем проекте? Как их правильно просчитать? Есть ли в теории какая-нибудь система с набором шаблонных метрик, из сопоставления которых и «рождается» КПЭ?
Любой проект – вещь во многих смыслах уникальная. Не стоит слишком сильно надеяться на то, что метрики с одного проекта идеально подойдут для второго: их стоит обязательно создавать на основе специфики каждого конкретного проекта и потенциальных ожиданий/опасений со стороны клиента.
Теперь можно рассмотреть вопрос, как посчитать время на тестирование на основе реальных примеров.
Пример
Итак, воображаемая команда по тестированию начала проверять программное обеспечение для определенного клиента. Продукт изначально позиционировался как несколько функциональных компонентов, а также подразумевал интеграцию с back-office системами хранения данных (базы данных).
Сразу отметим, что под термином «клиент» мы будем понимать любую личность, которая так или иначе заинтересована в процессе тестирования ПО и стремится получить тот эффект, при котором, собственно, продукт может максимально удовлетворить запросы конечных пользователей и спокойно отправиться в многократную эксплуатацию.Клиент обратился в компанию по тестированию с определенными своими ожиданиями и заранее намеченной целью.
На первом этапе руководитель проекта, либо же ответственный тест менеджер, должен разузнать у него все эти цели и ожидания. На практике есть множество вариантов подобного анализа: опросные листы, создание брифов, устный диалог.
Очень важно максимально полно узнать, что именно интересует клиента, за что придется в будущем переживать, и что у него «болит и страдает».
После того как будут сформированы потенциальные ожидания и опасения клиента, на плечи компании по тестированию возлагается работа по их трансформации в конечную цель. Несложно догадаться, что целью любой проверки в сфере тестирования является комплекс по интеграционному и функциональному тестированию программного обеспечения клиента.
Далее, после обсуждения целей работ, необходимо выполнить процедуру декомпозиции, то есть разбить глобальный функционал на составные части, чтобы привлеченная команда QA специалистов понимала, за что конкретно она отвечает. На данном этапе рассмотрения примера лучше всего будет детально описать, что же собой представляет пресловутая декомпозиция.
Декомпозиция – специальный научный подход, применяющий структуру задачи и позволяющий сменить решение одной глобальной задачи путем решения нескольких меньших подзадач. Принципы декомпозиции состоят в том, что проверяемый продукт можно рассматривать как блок, состоящий из нескольких подсистем, проверка которых намного проще, чем тестирование всего ПО.Если клиент пожелал получить итоги тестирования интеграции, значит команде QA необходимо выполнить процесс декомпозиции интеграционной функциональной проверки всего продукта. Для этого потребуется провести анализ, чтобы понять, из каких именно частей состоит система клиента, сколько вообще систем взаимодействует при обмене данными и над какими именно системами будущие пользователи смогут совершать определенные действия.
В теории все достаточно понятно и просто: необходимо из большой задачи отделить ряд небольших подзадач. Ничего ведь сложного, но вот на практике получается так, что QA отдел сталкивается с банальным непониманием основополагающих критериев для декомпозиции поставленной задачи, а потому действия выполняются наугад.
Как итог – неравномерная нагрузка на тестировщиков, плохая оценка будущих трудозадач, неверное понимание поставленной задачи и логически ошибочное представление об итогах работы. Чтобы лучше уяснить данный блок, нужно обратиться к принципу SMART.
Понятие и принципы SMART
По сути, SMART – это особая мнемоническая аббревиатура, которую применяют менеджеры разных сфер для качественного запоминания принципов постановки целей. Каждая буква аббревиатуры имеет свою техническую расшифровку:
- Specific – определенный. Разрабатывая задачу, мы должны заранее понимать, какого итога желаем достичь;
- Measurable – поддающийся измерению. На проекте нужны задачи, которые можно измерить (как по времени, так и по трудозатратам);
- Attainable – достижение. Умный руководитель проекта никогда не даст неопытному сотруднику сложно решаемую задачу, ведь время, затраченное на ее решение, назад никто не вернет. Понимание личностных особенностей каждого сотрудника команды тестирования позволит максимально качественно распределять нагрузку, предоставляя новичкам решать простые задачи, а профессионалам – выполнять поручения «со звездочками»;
- Relevant – существенный. Реально ли выполнение той или иной задачи именно сейчас? А если команда не успеет? Что тогда делать?
- Time-bound – временные рамки. Любая поставленная перед тестировщиками задача должна решиться за определенное время. Установление временных слотов позволяет сделать процесс проверки максимально прозрачным и контролируемым.
В результате мы имеем полное понимание того, как именно глобальная задача может поделиться на несколько небольших. Теперь дело за проведением анализа всех составных частей.
Их можно выделить в следующий набор исполняемых действий:
- Проводим проверку всего функционала, указанного в интеграции;
- Создаем тестовые данные;
- Проверяем задачи по последующей доработке функционала;
- Заводим баги в баг-трекер;
- Тестируем релизы и hot-fix;
- Проверяем, есть ли возможность передачи в каждой новой версии ПО двух и более приоритетных продуктов.
Теперь пришло время пройтись по каждой отмеченной подзадаче и рассмотреть выбранные метрики.
Список метрик, из которых формируется КПЭ
Проверка функционала, указанного в интеграции
Как правильно выполнить эти действия? Можно, к примеру, воспользоваться проверенной методикой «% покрытия ХХ числа модулей ПО тестами», которая в форме классической Exсel-таблицы позволяет скомбинировать все группы проверок в одно целое.
Пример Exсel-таблицы с проверками
Создание тестовых данных
Можно использовать метрику «число модулей/функциональных частей продукта, для которых создано 100% работающих сущностей».
Проверка задач по доработке последующего функционала
Здесь необходимо сделать просчет потенциальных доработок со стороны клиента и среднее количество времени, которое будет в будущем затрачено на выполнение проверки. Подобное решение позволяет быстро оценить, на что именно была направленна каждая из версий (либо же исправление ошибок, либо же создание и имплементация функциональности по желанию клиента). Как итог – можно запросто проанализировать, успевает ли команда к моменту реализации запланированного функционала или нет.
Заводим дефекты в систему отслеживания ошибок
Можно воспользоваться несколькими распространенными метриками, с помощью которых можно получать максимально исчерпывающую информацию касательно текущего состояния версии разрабатываемого ПО: «сумма дефектов, заведенных в систему отслеживания ошибок», «сумма багов приоритета Blocker на версии ПО».
Тестируем релизы и hot-fix
В данном случае идеально подходит комбинация таких метрик: «% созданных тест-кейсов, пройденных на проекте» + «% успешности прохождения тест-кейсов на готовой версии продукта».
Как итог от применения КПЭ
Разработка КПЭ любого проекта – весьма процедурная и длительная задача, но в тоже время, очень полезная и интересная. Вот из-за чего.
Выполняя сборку необходимых на проекте метрик, можно получить ответы на такие вопросы: с чем именно проектная команда справилась на ура, в каких показателях уровень тестирования подрос, были ли управленческие решения и распоряжения верны и эффективны. С помощью КПЭ в случае звонка клиента любой тест менеджер запросто может ответить на следующие вопросы:
- Каково текущее состояние метрики;
- Какие именно модули можно считать наиболее проблемными и критичными;
- С какими модулями нужно быть осторожным;
- Какие показатели можно установить для приоритетных версий;
- Можно ли выпускать продукт.
После использования метрик на любом проекте станет гораздо проще проводить подготовку промежуточной отчетности для клиента, а вся проектная группа QA специалистов сможет прикладывать максимальные усилия в будущем, чтобы время проверки существенно сокращать.
Как быть если проект вышел, а нужно все заново проверить?
Традиционно, время в таком случае спокойно умножается на 2, ведь проектная группа уже все давно позабыла, занята чем-то другим, и поэтому необходимо определенное время, чтобы познакомиться с системой поближе. Также, может добавиться нестандартный цикл, а значит, кроме обычного тестирования, может потребоваться 100% регрессия – тогда необходимо добавить некоторое время на полную регрессию.
Заключение
В завершение можно отметить, что для оценки времени на тесты проще всего начать собирать эффективные метрики, которые в будущем можно систематизировать и использовать их наиболее подходящие группы в зависимости от специфики заказанного веб-продукта. Даже можно позаимствовать уже готовые метрики на сторонних проектах и у других компаний, чтобы потом максимально грамотно адаптировать их согласно своим техническим нуждам. Главное – это грамотная разбивка проекта на спринты и модули, анализ которых и позволит проектной группе отметить, сколько именно времени необходимо на качественное и эффективное тестирование.
Оставить комментарий