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

В целом, парадигму качества можно охарактеризовать следующими принципами:

Ориентация на пользователя: качество определяется пользователем, его потребностями и ожиданиями. Именно пользователь является конечным судьей качества, и усилия в области качества должны быть направлены на удовлетворение требований потребителя.
Постоянное улучшение: обеспечение качества — это непрерывный процесс, важным аспектом парадигмы качества является постоянное улучшение. Организации должны стремиться постоянно совершенствовать свои процессы и системы качества, чтобы удовлетворять меняющиеся потребности клиентов и опережать конкурентов.
Всеобщее управление качеством: обеспечение качества — это ответственность всей компании, в работу по его достижению должен быть вовлечен каждый сотрудник. Это означает, что обеспечение качества должно быть интегрировано во все аспекты деятельности организации, от разработки продукта до обслуживания клиентов.
Принятие решений на основе данных: парадигма качества основана на принятии решений на основе данных. Процессы обеспечения качества должны быть основаны на данных и фактах, а решения о качестве должны приниматься на основе данных и анализа, а не интуиции или опыта.
Сотрудничество: обеспечение качества — это совместная работа, и она требует участия и сотрудничества всех заинтересованных сторон, включая клиентов, поставщиков, сотрудников и руководство.

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

Что такое качество?
Как можно измерить качество?
Приносит ли качество успех вашему бизнесу?

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

Слово «качество» определяется мнением наблюдателя.

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

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

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

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

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

Независимый / разъединенный
Объединенный
Встроенный / интегрированный
Оптимизированный

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

Где находится моя нынешняя команда?
Находится ли она на правильном этапе?
Как мне попасть на нужную ступень?

Существует несколько методов, с помощью которых можно оценить свой этап качества. Популярной оценкой с 2000 года является Joel Test, а более поздний DORA — состояние DevOps — отличный способ понять качество кода и программного обеспечения. Но как это охватывает другие области, которые могут способствовать качеству, такие как Agile-практики, структура команды и качество работы?

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

Независимость

Вот как работает независимая проверка программного обеспечения:

Сбор требований. Команда проверки начинает со сбора информации о требованиях и спецификациях программного обеспечения. Сюда входит проектная документация, руководства пользователя и любая другая информация о функциональности программного обеспечения.
План проверки. Далее группа проверки разрабатывает план, в котором описываются шаги и методы, которые будут использоваться для оценки ПО. Этот план включает описание техник тестирования, среды тестирования и график проведения тестов.
Выполнение тестов. После составления плана группа проверки приступает к выполнению тестов. Это может включать в себя функциональное тестирование, тестирование производительности, тестирование безопасности и другие виды тестирования, предусмотренные в плане проверки. Команда также создает тест-кейсы и скрипты, чтобы проверить функциональность ПО и обеспечить соответствие его требованиям.
Отчетность и документация. После завершения тестов создается отчет, в котором документируются результаты проведенного тестирования. Отчет включает в себя краткое описание результатов тестирования, все выявленные проблемы и рекомендации по улучшениям.
Окончательная оценка. На основании результатов процесса тестирования группа проверки дает окончательную оценку качества и функциональности программного обеспечения. Если в процессе тестирования были выявлены какие-то проблемы, команда проверки совместно с командой разработки работает над их устранением до выпуска продукта на рынок.

Как оценивать

Делает ли ваша команда вышеперечисленное? Вы удивитесь, сколько организаций продолжают работать подобным образом. Из-за революции Agile и DevOps многие считают, что мода на это прошла, и ей больше не место в индустрии разработки программного обеспечения.

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

Потратьте немного времени со своими командами и проверьте следующее:

Автоматизированы ли тесты?
Являются ли тесты самопроверяемыми?
Есть ли у вас команда по обеспечению качества/тестированию?
Приходится ли вам ждать, пока кто-то другой примет решение о качестве, поставляемом командой?
Нужно ли команде использовать множество инструментов для отслеживания поставки и качества программного обеспечения?

Это всего лишь несколько вопросов, которые показывают, на каком этапе находится ваша команда и организация. В этом деле могут помочь разные инструменты с открытым исходным кодом. Отличным способом оценки отдельных команд я считаю devopsmaturity от atos.

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

Приглашаем всех желающих на открытое занятие «Один день тестировщика на разных IT-проектах». Во время занятия на примере нескольких реальных проектов обсудим, как работает тестировщик, какие инструменты использует и какими знаниями должен обладать. В результате узнаете, какие знания и навыки нужны тестировщику для работы. Урок подойдет любому, кто интересуется тестированием и хочет развиваться в этой профессии, независимо от опыта.

Записаться на открытый урок