품질은 누가 책임지나요?

헤이 하브르!

IT 제품의 고품질 개발이라는 새로운 중요한 주제가 있습니다. HighLoad++에서는 바쁜 서비스를 빠르게 만드는 방법에 대해 자주 이야기하고, Frontend Conf에서는 속도가 느려지지 않는 멋진 사용자 인터페이스에 대해 이야기합니다. 우리는 정기적으로 테스트에 관한 주제를 갖고 있으며, 테스트를 포함한 다양한 프로세스 결합에 관한 DevOpsConf를 갖고 있습니다. 그러나 일반적으로 품질이라고 할 수 있는 것과 포괄적으로 작업하는 방법에 대해서는 그렇지 않습니다.

이 문제를 해결해 보겠습니다. 품질회의 — 우리는 개발의 모든 단계에서 사용자를 위해 최종 제품의 품질에 대해 생각하는 문화를 발전시킬 것입니다. 책임 영역에 집중하지 않고 테스터뿐만 아니라 품질도 연관시키는 습관.

컷 아래에서는 러시아어를 사용하는 QA 커뮤니티를 창시한 Tinkoff.Business의 테스트 책임자인 프로그램 위원회 책임자와 이야기를 나눕니다. 아나스타샤 아세바-응우옌 QA 업계 현황과 새로운 컨퍼런스의 사명에 대해 설명합니다.

- 나스티아 안녕하세요. 자기소개를 부탁드립니다.

아나스타샤: 저는 은행에서 테스트를 관리하고 있으며 직원 수가 90명이 넘는 매우 큰 팀을 책임지고 있습니다. 우리는 중요한 비즈니스 라인을 가지고 있으며 법인의 생태계를 책임지고 있습니다.

저는 기계와 수학을 공부했고 처음에는 프로그래머가 되고 싶었습니다. 하지만 흥미로운 제안을 받았을 때 저는 직접 테스터로 시험해 보기로 결정했습니다. 이상하게도 이것이 내 소명이 되었다. 이제 나는 이 업계에서 내가 하는 모든 일을 봅니다.

나는 품질 보증 규율을 열렬히 지지하는 사람입니다. 나는 어떤 제품이 만들어지는지, 회사와 팀, 그리고 원칙적으로 개발 과정에서 품질이 어떻게 처리되는지에 무관심하지 않습니다.

내가 보기엔 그건 분명해 이 방향의 커뮤니티는 충분히 성숙하지 않았습니다., 적어도 러시아에서는. 우리는 품질 보증이 애플리케이션의 요구 사항 준수 여부를 테스트하는 것만이 아니라는 사실을 항상 이해하는 것은 아닙니다. 나는 이 상황을 바꾸고 싶다.

— 품질 보증 및 테스트라는 단어를 사용합니다. 보통 사람의 눈에는 이 두 용어가 자주 겹치는 경우가 많습니다. 깊이 파고 들면 어떻게 다릅니 까?

아나스타샤: 오히려 그들은 다르지 않습니다. 테스트는 품질 보증 분야의 일부이며 직접적인 활동입니다. 바로 제가 무언가를 테스트하고 있다는 사실입니다. 실제로 많은 유형의 테스트가 있으며 다양한 사람들이 다양한 유형의 테스트를 담당합니다. 그러나 러시아에서는 기업에 테스터를 공급하는 아웃소싱 업체가 등장하면서 테스트가 단일 유형으로 축소되었습니다.

대부분의 경우 기능 테스트로만 제한됩니다. 개발자가 코딩한 내용이 사양을 준수하는지 확인하는 것이 전부입니다.

— 다른 품질 보증 분야에는 어떤 것이 있는지 알려주십시오. 테스트 외에 여기에는 무엇이 포함되어 있나요?

아나스타샤: 품질보증은 무엇보다 품질 좋은 제품을 만드는 것입니다. 즉, 우리는 우리 제품이 어떤 품질 특성을 가져야 하는지 자문합니다. 따라서 이를 이해하면 누가 이러한 품질 속성에 영향을 미치는지 비교할 수 있습니다. 상관없어요 개발자, 프로젝트 관리자 또는 제품 전문가 제품 개발, 백로그, 전략에 영향을 미치는 사람입니다.

테스터는 자신의 역할을 더 잘 알게 됩니다. 그는 자신의 임무가 요구 사항 준수 여부를 테스트하는 것뿐만 아니라 요구 사항을 테스트하고, 제품 전문가가 제공하는 공식에 대해 질문하고, 고객의 모든 암시적 요구 사항과 기대치를 드러내는 것임을 이해합니다. 고객에게 새로운 기능을 제공할 때 우리는 진정으로 고객의 기대에 부응하고 고객의 고통을 해결해야 합니다. 품질의 모든 속성에 대해 생각해 보면 고객은 만족할 것이며 자신이 사용하는 제품을 생산하는 회사가 자신의 이익을 진심으로 고려하고 "단순히 기능을 출시하는 것"이라는 원칙에 따라 작업하지 않는다는 것을 이해하게 될 것입니다.

— 방금 말씀하신 부분은 제품 전문가의 업무인 것 같습니다. 이는 원칙적으로 테스트나 품질에 관한 것이 아닙니다. 일반적으로 제품 관리에 관한 것입니다.

아나스타샤: 포함. 품질 보증은 특정 개인이 책임지는 분야가 아닙니다. 이제 테스트에는 인기 있는 방향이 있습니다. 애자일 테스트. 그의 정의에 따르면 이는 일련의 특정 관행을 포함하는 테스트에 대한 팀 접근 방식입니다. 전체 팀이 이 접근 방식을 구현하는 데 책임이 있으며 팀에 테스터가 있을 필요도 없습니다. 전체 팀은 고객에게 가치를 제공하고 그 가치가 고객의 기대에 부응하도록 하는 데 중점을 두고 있습니다.

— 품질은 주변의 거의 모든 분야와 교차하여 주변의 모든 것에 프레임워크를 부여한다는 것이 밝혀졌습니다.

아나스타샤: 오른쪽. 고품질의 제품을 어떻게 만들고 싶은지 생각할 때 품질의 다양한 속성에 대해 생각하기 시작합니다. 예를 들어, 고객이 필요로 하는 기능을 실제로 만들었는지 확인하는 방법입니다.

이러한 유형의 테스트가 이루어지는 곳은 다음과 같습니다. UAT (사용자 승인 테스트). 불행히도 러시아에서는 거의 실행되지 않지만 때때로 최종 클라이언트를 위한 데모로 SCRUM 팀에 존재합니다. 이것은 외국 회사에서 상당히 일반적인 유형의 테스트입니다. 모든 클라이언트에게 기능을 공개하기 전에 먼저 UAT를 수행합니다. 즉, 제품이 실제로 기대치를 충족하고 문제를 해결하는지 테스트하고 즉시 피드백을 제공하는 최종 사용자를 초대합니다. 이 후에야 다른 모든 클라이언트로의 확장이 발생합니다.

즉, 우리는 비즈니스, 최종 고객에 초점을 맞추지만 동시에 기술을 잊지 마세요. 제품의 품질도 기술에 따라 크게 좌우됩니다. 아키텍처가 좋지 않으면 기능을 신속하게 출시하고 고객 기대에 부응할 수 없습니다. 확장을 시도할 때 많은 버그가 있을 수 있고, 리팩토링을 시도할 때 무언가가 깨질 수 있습니다. 이 모든 것이 고객 만족도에 영향을 미칩니다.

이러한 관점에서 아키텍처는 우리가 신속하게 변경을 수행할 수 있고 모든 것이 망가질 것을 두려워하지 않는 깔끔한 코드를 작성할 수 있어야 합니다. 따라서 레거시가 너무 많다는 이유만으로 개정 반복이 몇 달에 걸쳐 연장되지 않고 긴 테스트 단계를 수행해야 합니다.

— 전체적으로 개발자, 설계자, 제품 과학자, 제품 관리자 및 테스터가 이미 참여하고 있습니다. 품질 보증 프로세스에는 또 누가 참여합니까?

아나스타샤: 이제 이미 클라이언트에 기능을 전달했다고 가정해 보겠습니다. 물론, 제품이 이미 생산 중인 경우에도 제품의 품질을 모니터링해야 합니다. 이 단계에서는 소위 버그라고 불리는 불분명한 시나리오의 상황이 나타날 수 있습니다.

첫 번째 질문은 이미 제품을 출시한 후에 이러한 버그를 어떻게 처리합니까? 예를 들어, 우리는 스트레스에 어떻게 반응합니까? 페이지를 로드하는 데 30초 이상이 걸리면 클라이언트는 별로 만족하지 않을 것입니다.

이것이 착취가 시작되는 곳입니다. 또는 그들이 지금 부르는 것처럼, 개발자. 실제로 이들은 이미 생산 중인 제품의 작동을 담당하는 사람들입니다. 여기에는 다양한 유형의 모니터링이 포함됩니다. 테스트에는 하위 유형도 있습니다. 즉, 출시 전에 무언가를 테스트하지 않고 프로덕션에서 즉시 테스트하는 프로덕션 테스트입니다. 이는 사고에 신속하게 대응하고 영향을 미치며 시정할 수 있도록 인프라 구성 관점에서 일련의 조치입니다.

인프라도 중요하다. 테스트 중에 고객에게 제공하고 싶은 모든 것이 실제로 있는지 확인하는 것이 불가능한 상황이 종종 있습니다. 우리는 이를 프로덕션에 적용하고 명확하지 않은 상황을 포착하기 시작합니다. 그리고 테스트의 인프라가 프로덕션 인프라와 일치하지 않기 때문입니다. 이는 새로운 유형의 테스트로 이어집니다. 인프라 테스트. 이는 다양한 구성, 설정, 데이터베이스 마이그레이션 등입니다.

이는 질문을 제기합니다. 아마도 팀은 인프라를 코드로 사용해야 할 것입니다.

저는 인프라가 제품 품질에 직접적인 영향을 미친다고 믿습니다.

컨퍼런스에서 실제 사례를 담은 보고서가 나왔으면 좋겠습니다. 코드로서의 인프라가 품질에 어떤 영향을 미치는지 자신의 경험을 통해 알려주실 준비가 되셨다면 저희에게 연락해 주세요. 코드형 인프라를 사용하면 다른 방법으로는 불가능했던 모든 설정을 확인하고 테스트하는 것이 더 쉬워집니다. 따라서 고품질의 제품을 개발하는 과정에는 운영도 포함됩니다.

— 분석 및 문서화는 어떻습니까?

아나스타샤: 이는 엔터프라이즈 시스템에 더 많이 적용됩니다. 기업에 관해 이야기하면 분석가, 시스템 분석가와 같은 사람들이 즉시 떠오릅니다. 그들은 때때로 기술 작가라고 불립니다. 예를 들어 한 달 동안 사양을 작성하고 완료하는 작업을 받습니다.

테스트 프로세스 중에 버그가 식별되고 반환이 시작되기 때문에 이러한 문서를 작성하면 매우 긴 개발 반복과 긴 개선 반복이 발생한다는 것이 반복적으로 입증되었습니다. 결과적으로 개발 비용을 증가시키는 루프가 많이 발생합니다. 또한 이로 인해 취약점이 발생할 수도 있습니다. 우리는 참조 코드를 작성한 것 같지만 완벽하게 고려된 아키텍처를 깨뜨리는 변경 사항을 적용했습니다.

최종 결과는 완전히 고품질 제품이 아닙니다. 패치가 아키텍처에 이미 나타났기 때문에 일부 위치의 코드는 테스트에서 충분히 다루어지지 않았고 마감 기한이 촉박해 모든 버그를 신속하게 닫아야 합니다. 그리고 원래 사양에서는 구현해야 할 모든 사항을 고려하지 않았기 때문입니다.

개발자는 해충이 아니며 의도적으로 오류가 있는 코드를 작성하지 않습니다.

처음에 필요한 모든 사항을 포함하는 사양을 고려했다면 모든 것이 필요에 따라 정확하게 구현되었을 것입니다. 그러나 이것은 유토피아이다.

100페이지 분량의 명세서를 완벽하게 작성하는 것은 아마도 불가능할 것입니다. 그렇기 때문에 문서를 작성하는 다른 방법에 대해 생각해 볼 필요가 있습니다., 사양, 개발자가 필요한 작업을 정확하게 수행하는지 확인하는 데 더 가까워지는 작업 설정.

여기서 Agile의 접근 방식이 떠오릅니다. 즉 수용 기준이 포함된 사용자 스토리입니다. 이는 소규모 반복으로 개발하는 팀에 더 적합합니다.

— 사용성 테스트, 제품 사용성, 디자인은 어떻습니까?

아나스타샤: 팀에 디자이너가 있기 때문에 이것은 매우 중요한 포인트입니다. 대부분의 경우 디자이너는 디자인 부서나 아웃소싱 디자이너가 서비스로 사용합니다. 디자이너가 제품 전문가의 말을 듣고 그가 이해한 대로 행동한 것처럼 보이는 상황이 종종 있습니다. 그러나 반복을 시작하면 실제로 수행된 작업이 예상했던 것과 다르다는 것이 밝혀졌습니다. 디자이너가 무언가를 잊었고, 행동을 완전히 생각하지 않았습니다. 왜냐하면 그는 팀에 있지 않고 컨텍스트나 최전선에 있지 않기 때문입니다. -최종 개발자가 레이아웃을 완전히 이해하지 못했습니다. 프론트엔드 개발자가 디자인을 이해하는 데 문제가 있기 때문에 여러 번의 반복이 필요할 수 있습니다.

게다가 문제가 하나 더 있습니다. 이제 디자인 시스템이 인기를 얻고 있습니다. 그들은 과대 광고를 하고 있지만 그 이점이 완전히 명확하지는 않습니다.

디자인 시스템은 한편으로는 개발을 단순화하지만 다른 한편으로는 인터페이스에 많은 제한을 가한다는 의견을 접하게 되었습니다.

결과적으로 우리는 클라이언트가 원하는 기능을 만드는 것이 아니라 우리에게 편리한 기능을 만듭니다. 왜냐하면 우리는 그것을 만들 수 있는 특정 큐브를 이미 가지고 있기 때문입니다.

나는 이것이 디자인을 더 쉽게 만들려고 노력하는 것이 실제로 클라이언트의 문제점을 해결하고 있는지 궁금해하고 살펴볼 가치가 있는 주제라고 생각합니다.

— 품질 보증과 관련된 주제가 놀라울 정도로 많습니다. 러시아에서 이 모든 문제를 논의할 수 있는 회의가 있습니까?

아나스타샤: 가장 오래된 테스트 컨퍼런스가 있는데, 올해로 25회째를 맞이하는 SQA Days 품질보증 컨퍼런스라고 합니다. 주로 기능 테스터를 위한 도구와 특정 테스트 접근 방식에 대해 논의합니다. 일반적으로 SQA Days의 보고서는 테스터 자체의 책임 영역에서 특정 영역을 심층적으로 조사하지만 복잡한 활동은 검토하지 않습니다.

이는 다양한 도구와 접근 방식, 데이터베이스, API 등을 테스트하는 방법을 이해하는 데 많은 도움이 됩니다. 그러나 동시에 더 나은 제품을 만들기 위해 단순히 테스트하는 것 이상을 포함하도록 동기를 부여하지도 않습니다. 반면에 테스터는 제품과 해당 비즈니스 구성 요소의 글로벌 목표를 생각하는 프로세스에 더 많이 관여하지 않습니다.

저는 대규모 부서를 운영하며 업계 전반의 현황에 대한 통찰력을 제공하는 많은 인터뷰를 진행합니다. 일반적으로 우리 직원은 기업에서 일하며 책임 영역이 명확합니다. 외국 프로젝트에 참여하는 동료들은 다양한 유형의 테스트를 사용합니다. 그들은 스스로 부하 테스트, 성능 테스트, 때로는 보안 테스트도 수행할 수 있습니다. 이는 팀이 제품 품질을 보장하는 데 실제로 도움이 되기 때문입니다.

러시아 사람들도 업계가 기능 테스트로 끝나지 않는다고 생각하기 시작했으면 좋겠습니다.

— 이를 위해 우리는 품질을 통합 분야로 다루는 새로운 컨퍼런스인 QualityConf를 조직하고 있습니다. 아이디어에 대해 더 자세히 알려주십시오. 컨퍼런스의 주요 목표는 무엇입니까?

아나스타샤: 우리는 좋은 제품을 만드는 데 관심이 있는 사람들의 커뮤니티를 만들고 싶습니다. 품질 개선을 위해 무엇을 변경해야 하는지에 대한 구체적인 이해를 바탕으로 컨퍼런스 후에 와서 보고를 듣고 떠날 수 있는 플랫폼을 제공합니다.

요즘에는 테스트나 품질에 문제가 생겼을 때 어떻게 해야 하는지 컨설팅을 요청하는 경우가 종종 있습니다. 팀과 소통을 시작하면 문제는 테스터 자신에게 있는 것이 아니라 프로세스가 어떻게 구성되어 있는지에 있다는 것을 알 수 있습니다. 예를 들어, 개발자가 자신에게 코드 작성만 책임이 있다고 믿으면 작업을 테스트에 넘겨주는 순간 책임이 종료됩니다.

모든 사람이 잘못 작성된 저품질 코드와 열악한 아키텍처가 프로젝트에 큰 문제를 위협한다는 사실을 생각하는 것은 아닙니다. 그들은 오류로 인한 비용, 즉 프로덕션 단계에서 발생하는 버그로 인해 회사와 팀에 큰 비용이 발생할 수 있다는 점을 생각하지 않습니다. 이것에 대해 생각하는 문화가 없습니다. 컨퍼런스에서 배포를 시작했으면 좋겠습니다.

나는 이것이 혁신이 아니라는 것을 이해합니다 품질의 14가지 원칙의 저자인 Edward Deming은 지난 세기에 오류로 인한 비용에 대해 썼습니다. 학문으로서의 품질 보증은 이 책을 기반으로 하지만 불행히도 현대 개발에서는 이를 간과하고 있습니다.

— 테스트 및 도구에 관한 주제를 직접 다룰 계획이신가요?

아나스타샤: 도구에 대한 보도가 있을 것이라는 점은 인정합니다. 회사와 팀이 제품에 영향을 미칠 수 있는 매우 보편적인 도구가 있습니다.

모든 보고서는 하나의 공통 임무에 따라 전 세계적으로 통합됩니다. 즉, 이러한 접근 방식, 도구, 방법, 프로세스, 테스트 유형의 도움으로 우리가 제품 품질에 영향을 미치고 고객의 삶을 개선했다는 사실을 청중에게 전달하는 것입니다.

도구를 위한 도구에 대한 보고서는 절대 없을 것입니다. 프로그램에 포함된 모든 보고서는 공통 목표에 따라 통합됩니다.

— 당신이 말하는 내용에 누가 관심을 가질 것이며, 컨퍼런스의 손님으로 누구를 보십니까?

아나스타샤: 프로젝트, 제품, 시스템의 운명에 관심을 갖고 있는 개발자를 위한 보고서를 제공합니다. 마찬가지로, 이는 테스터들에게도 흥미로울 것이며, 특히 관리자들에게는 더욱 흥미로울 것 같습니다. 관리자란 결정을 내리고 제품, 시스템, 팀의 운명과 개발에 영향을 미칠 수 있는 사람을 의미합니다.

이들은 제품이나 시스템의 품질을 개선하는 방법을 궁금해하는 사람들입니다. 우리 회의에서 그들은 다양한 조치에 대해 배우고 현재 그들에게 무엇이 문제인지, 무엇이 바뀌어야 하는지를 이해할 수 있을 것입니다.

주요 기준은 품질에 문제가 있다는 것을 이해하고 영향을 미치고 싶은 것이라고 생각합니다. 우리는 이것이 처음으로 가능할 것이라고 생각하는 사람들에게 다가갈 수 없을 것입니다.

— 업계 전체가 테스트뿐만 아니라 품질 문화에 대해서도 이야기할 준비가 되었다고 생각하시나요?

아나스타샤: 성숙해진 것 같아요. 이제 많은 기업이 전통적인 Waterfall 접근 방식에서 Agile로 전환하고 있습니다. 고객 중심이 있고 팀의 사람들은 실제로 고품질 제품을 만드는 방법에 대해 생각하기 시작했습니다. 심지어 대기업도 품질 개선에 다시 집중하고 있습니다.

커뮤니티에서 발생하는 요청의 수를 보면 이제 때가 왔다고 생각합니다. 물론 이것이 대규모 혁명이 될지는 모르겠지만 의식의 혁명이 일어나기를 바랍니다.

- 동의해요! 문화를 심어주고 의식을 바꾸겠습니다.

IT제품 고품질 개발 컨퍼런스 품질회의 일어난다 7월 XNUMX일 모스크바에서. 고품질 제품을 구성하는 단계가 무엇인지 아시고, 생산 과정에서 버그를 성공적으로 해결한 사례도 있으며, 실제로 널리 사용되는 방법을 테스트했습니다. 여러분의 경험이 필요합니다. 보내다 그들의 1월 XNUMX일 이전 신청, 그리고 프로그램 위원회는 컨퍼런스의 전반적인 무결성을 위해 주제에 초점을 맞추는 데 도움을 줄 것입니다.

연결 채팅, 품질 문제와 컨퍼런스를 논의하는 곳입니다. 전보 채널프로그램 뉴스를 최신 상태로 유지합니다.

출처 : habr.com