Одноклассник оставил сообщение и задал такой вопрос: Я хочу продвигать внедрение измерения качества внутри команды и лучше оценивать качество доставки каждой итерации версии, но у меня мало практического опыта. Есть ли какая-либо реализация. метод или меры предосторожности.

Давайте сначала поговоримСамо измерение качества, то есть нужно ли измерять качество?

Ответ очевиден：Качество необходимо измерять, и измерять его нужно постоянно!почему？

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

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

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

Сущность измерения качества заключается в конкретном количественном, а не абстрактном качественном значении.

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

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

1. Обеспечение качества – это не только вопрос студентов, занимающихся обеспечением качества, поэтому измерение качества не может осуществляться только путем сосредоточения внимания. на тестовых размерах.
2. Метрики необходимо формулировать на основе характеристик команды и конкретных условий бизнеса, а также того, нужно ли их оценивать как разумные, а не насильно формулировать и внедрять.
3. Измерение качества призвано гарантировать, что конечное качество доставки может лучше удовлетворять потребности пользователей и способствовать дальнейшему достижению бизнес-целей, а не принуждать к измерению ради измерения.
4. Измерение качества не достигается в одночасье. На разных этапах жизненного цикла программного обеспечения и зрелости команды объем измерения и строгость реализации должны быть гибкими.

Наконец, я хотел бы поделиться некоторыми своими мыслями об измерении качества программного обеспечения.

1. Не измеряйте ради измерения. Важно найти правильный объект измерения.

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

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

2. Метричные показатели должны быть привязаны к конкретным вопросам, иначе показатели не имеют смысла.

Наиболее распространенными из них являются покрытие тест-кейсов и процент прохождения тест-кейсов. Какова роль этой метрики и какую проблему она пытается решить?

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

3. Показатели и значения измерения должны быть согласованы с непосредственными заинтересованными сторонами.

Давайте возьмем в качестве примера показатель прохождения дымовых испытаний. Что нам делать, если команда исследований и разработок не согласна?

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

4. Метрики и числовые значения не могут решить проблему, они могут только доказать, что произошло.

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

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

5. Существует множество предпосылок для осуществления измерения качества, и измерение качества не существует само по себе.

Например, качество кодирования каждой версии можно оценить путем измерения количества дефектов, количества вариантов использования и соответствующих им процентов.

Эта логика в порядке,Но просто получить сравнительные данные недостаточно.。дефект&Варианты использования должны быть связаны с соответствующей веткой кода.,Код должен соответствовать требованиям. В противном случае есть только данные,нет причинно-следственной связи,Не могу доказать проблему,Он также не может решить наиболее существенные проблемы несовершенства требований и низкого качества кода.

6. Измерение качества — это сложный технический проект, требующий активного взаимодействия и сотрудничества.

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

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