버그 없는 소프트웨어 개발을 위한 5가지 팁

소프트웨어 애플리케이션에 버그가 있습니까? 물론 사용 가능한 모든 소프트웨어 프로그램에는 문제가 있고 버그가 없는 소프트웨어 스토리는 신화이기 때문에 그렇습니다. 그러나 몇 가지 책 같으면서도 실용적인 축소 기술을 따르면 버그, 오류 및 보안 문제를 크게 최소화할 수 있습니다.

모든 사람이 규칙을 준수하도록 권장해야 하기 때문에 버그 추적과 관련하여 많은 규율이 필요합니다. 특히 신생 기업과 창의적으로 주도하는 산업에서는 비공식적인 의사소통을 억제하기가 상당히 어려울 수 있습니다. 사실 많은 경우 사람들은 '버그 추적'을 프로젝트에서 가장 집중하는 부분으로 지정하지 않습니다.

버그 추적은 실제로 무엇에 관한 것입니까?

Technopedia에 따르면: “ 버그 추적은 품질 보증 담당자와 프로그래머가 소프트웨어 문제와 해결 방법을 추적하는 데 사용하는 프로세스입니다. "

따라서 버그 추적 시스템은 보고된 오류에 대한 모든 정보를 관리하고 각 버그의 상태를 추적합니다. 문제를 추적하는 동안 광범위한 정보가 필요하다는 것을 분명히 알 수 있습니다. 충분한 데이터를 제공하려면 엄청난 시간이 필요할 뿐만 아니라 소프트웨어 개발 분야의 풍부한 기술도 필요합니다.

버그 분류

소프트웨어 버그에는 세 가지 유형이 있습니다.

• 잘못된 사양
• 구현 결함
• 누락된 사양

이러한 버그 유형은 모두 중요한 문제로 쉽게 분류(또는 개선으로 재분류)할 수 있습니다. 앞서 언급한 것은 Xolv.io의 설립자인 Sam Hatoum이 사용하는 재분류 지침 중 일부입니다.

• 잘못된 사양으로 인해 손실이 발생합니까? 예를 들어 사양 상태는 지출을 추적해야 할 때 클릭 수를 추적합니다. 버그를 재분류합니다.
• 구현 결함을 무시할 수 있습니까? 예를 들어, 웹 글꼴은 소프트웨어에 포함되어야 할 때 설치됩니다.
• 누락된 사양이 새로운 기능을 의미합니까? 예를 들어 사용자는 소셜 네트워크에서 프로필 세부 정보를 공유하고 편집할 수 없습니다.

개발 팀이 다른 모든 작업보다 버그의 우선 순위를 지정하도록 지시받았기 때문에 제품 관리자가 버그를 효율적으로 분류하기 위한 이해관계가 높아집니다. 모든 버그가 제거될 때까지 개발자는 작동하지 않습니다.

팀 품질 표준 형성

디자인 및 개발 팀이 앱 바이러스를 개선 사항으로 재분류할 수 있는지 여부를 결정할 때 해당 결정 프로세스는 팀의 품질 표준을 암시적으로 나타냅니다. 예를 들어 고품질 비주얼을 강조하는 브랜드 소유자는 디자인 불일치에 대한 허용 오차가 낮을 수 있습니다. 대신 이러한 문제를 버그로 재분류합니다.

일관된 재분류 시스템을 통해 팀 품질 표준을 최우선으로 하는 구조화된 전달 접근 방식을 유지하면서 기대 대 현실을 지속적으로 조정할 수 있습니다.

버그 실패

최근 연구에 따르면 시스템 장애의 거의 40%가 소프트웨어 버그로 인해 발생하고 기타 보안 문제 및 프로그램 취약성이 60%를 차지하며 공통 메모리 및 동시성 관련 문제로 인해 발생합니다. 애플리케이션에서 소프트웨어 버그를 줄이는 것이 소프트웨어의 보안, 안정성 및 신뢰성을 높이는 가장 좋은 방법입니다.

버그 없는 소프트웨어 개발을 위한 팁

로깅 도구인 SmartInspect를 개발하는 동안 개발자는 시스템 품질을 높게 유지하기 위해 많은 방법을 사용했습니다. 앞서 언급한 목록에는 그들이 사용한 기술 중 일부가 포함되어 있습니다.

1. 소통의 장 만들기

버그를 감지하고 보고하려면 모든 문제 보고서에 추가되는 관련 정보를 식별하는 기술이 필요합니다. 필요한 정보를 자동으로 첨부하는 기능을 제공하는 Usersnap과 같은 많은 버그 추적 및 품질 보증 도구가 있습니다. 그럼에도 불구하고 정보가 누락되거나 오해의 여지가 항상 있으므로 적절한 의사 소통이 필요합니다.

특정 테스트 시나리오에서는 개발자와 테스터 사이에 그런 종류의 공개가 허용되지 않습니다. '담당 전문가에게 어떻게 연락할 수 있습니까?'와 같은 질문입니다. 또는 '전화나 이메일로 피드백을 요청해도 되나요?' 버그 추적 프로세스 시작 시 답변해야 합니다.

테스터와 개발자를 대신하여 오해를 피하기 위해 모든 사람을 같은 페이지로 끌어들이고 양 당사자의 작업이 같은 방식으로 존중되는 피드백 중심 문화를 만드십시오.

2. 일대일로 유지

프로젝트 회의에서 버그에 대해 논의하지 마십시오. 이제 오해하지 마십시오. 팀으로 일하고 버그를 재현하고 수정하는 데 나쁜 것은 없습니다. 그러나 전체 내각과 장기간 회의에서 문제를 논의하지 마십시오. Usersnap.com의 기술 블로거인 Thomas Peham에 따르면 버그를 보고하고 다음 개발 '재테스트' 단계에서 이에 대해 논의하는 것은 상당히 느린 접근 방식입니다.

실제로 일대일로 유지하는 것이 훨씬 더 효율적입니다. Yegor가 버그 추적의 5가지 원칙에 대한 자신의 기사에서 썼듯이, 각 버그 보고서는 지정자와 문제 해결자라는 두 사람 사이에 연결됩니다. 프로세스에 참여하는 사람의 수와 상관없이 보고된 문제를 해결하는 데는 두 가지 주요 책임(두 가지 역할)만 있습니다.

3. 팀의 동의를 얻습니다.

전체 팀이 이를 사용하지 않는다면 좋은 버그 추적 데이터베이스가 효과가 없을 것입니다. 모든 이해 관계자(고객 서비스, 품질 보증, 프로젝트 관리자 및 개발자)가 도구를 평가하고 함께 결정을 내리도록 하는 것으로 시작하는 것이 가장 좋습니다. 동일한 시스템을 사용하여 일관된 방식으로 결함을 기록하고 해결합니다.

사람들을 탑승시키는 데 어려움을 겪고 있다면 다음과 같이 할 수 있습니다.

개발자의 경우 다른 방법이 아닌 개별 데이터베이스를 통해 버그 보고서를 수락하는 법을 설정하십시오. 테스터가 피드백이 포함된 이메일을 보내면 대신 정보 시스템에 보고서를 제출하도록 요청하면 됩니다. 정리된 상태를 유지하는 것 외에도 필요한 모든 정보를 제공하고 필요한 필드를 정의하여 보고하는 데 도움이 됩니다.

보다 효율적인 프로세스를 만드는 또 다른 방법은 QA를 받거나 지원을 통해 고객의 버그를 확인하고 개발자가 알림을 받기 전에 데이터베이스에 정확한 단계를 추가하는 것입니다. 소프트웨어 문제를 효과적으로 추적하는 것은 안정적이고 일관된 프로젝트 관리 프레임워크를 갖추는 데 있어 가장 필수적인 측면 중 하나입니다.

• 좋은 디버거

Visual Studio 또는 Delphi와 같은 시스템을 사용하는 경우 사용해야 하는 매우 강력한 디버거에 이미 액세스할 수 있습니다. 개발자들이 시행착오를 거쳐 버그를 제거하려고 하는 스크립팅 환경의 경우, 이 프로세스는 문제를 식별하고 해결하는 번거로운 방법이 될 뿐만 아니라 코드를 완전히 이해하지 못하고 디버거로 단계별로 실행하십시오. 팀을 위한 훌륭한 디버깅 플랫폼을 사용하여 자신에게 도움이 됩니다. 거의 모든 것을 위한 디버거가 있습니다.

4. '닫힌' 버그가 무엇을 의미하는지 알기

버그 종료에 대한 토론에 참여한 적이 있습니까? 축하합니다. 발생할 수 있는 최악의 버그 추적 상황에 처했습니다.

'버그 상태'에 대한 토론에서 자신을 발견했다면 한 걸음 물러서서 다음 질문을 스스로에게 해보십시오.

• 결과를 받아들이는 것은 누구의 책임입니까?
• 합격 기준은 어떻게 되나요?
• 누가 명령을 내릴 책임이 있습니까?

'닫다'의 의미를 살펴보자. 대부분의 개발 팀에서 버그는 오류를 수정한 사람이 닫습니다. Peham은 문제를 보고한 사람이 버그 보고서를 닫을 것을 권장합니다. 개발자가 특정 버그에 대한 해결책을 제시하면 보고자에게 보고서를 닫도록 요청해야 합니다. 이것은 피드백이 소프트웨어 혼란에 대한 충분한 솔루션임을 보장합니다.

5. 가상 머신

가능한 다양한 운영 체제 및 환경에서 소프트웨어의 버그를 테스트하려면 Virtual PC 또는 기타 사용 가능한 가상화 소프트웨어와 같은 도구와 함께 가상 머신을 사용해야 합니다. 이 방법을 통해 가상 머신을 쉽게 복사, 공유 및 재설정할 수 있으므로 모든 종류의 구성에서 소프트웨어를 테스트할 수 있으므로 많은 시간을 절약할 수 있습니다.

정기적으로 테스트하는 모든 운영 체제에 대해 다양한 표준 이미지를 만들어 파일 서버에 저장하는 것이 항상 바람직합니다. 테스트를 위해 매우 구체적인 구성이 필요한 경우 운영 체제, 필수 소프트웨어 및 드라이버 등을 설치하지 않고 기본 이미지 중 하나로 시작할 수 있습니다.

새로운 개념이 아니다.

하툼이 이 개념을 생각해냈을 때, 그는 Zero-Bug 소프트웨어의 아이디어가 새로운 것이 아니라는 것을 알게 되었습니다. 그것은 사실 잊혀진 많은 구식 철학과 마찬가지로 1960년대부터 존재해 왔습니다.

전설적인 품질 전문가인 Phillip Crosby는 Martin Company 또는 현재 알려진 'Lockheed Martin'에서 근무하는 동안 Zero-Defect라는 용어를 발명했으며 "정부 감사에 따라 하드웨어 결함에서 54% 결함 감소"를 달성했다고 보고되었습니다.

초기에 Zero-Defect 기술은 60년대 항공 우주 제조에 사용되었으며 1990년대에 자동차 제조에 적용되었습니다. 제조 산업과 소프트웨어 제공 사이에는 많은 유사점이 있습니다.

예를 들어 인기 있는 애자일 관리 양식인 Kanban은 Toyota Production System에서 시작되었습니다. 이것이 기본적으로 우리에게 말해주는 것은 소프트웨어나 앱 개발에서 기술 영감을 얻기 위해 이러한 제조 프로세스를 쉽게 조사할 수 있고 Zero-Bug가 그러한 영감 중 하나라는 것입니다.

그러나 표준을 충족하는 데 드는 극단적인 비용은 무결점 접근 방식에 대한 주요 비판 중 하나입니다. 그리고 잘못 구현된 경우 이는 실제로 사실일 수 있습니다. Zero-Bug 접근법에서 Hatoum은 버그를 기능으로 재분류하고 상당한 개선을 통해 이 문제를 직접 처리했으며 팀의 품질 표준을 통해 비용을 제어할 수 있습니다.

오늘 시작

기술 사용자 및 개발자는 앞서 언급한 시스템을 사용하여 기존의 모든 결함을 살펴보고 분류할 수 있습니다. 수십만 개의 문제가 있다고 생각되면 지금이 문제를 백로그하고 새로 시작하기에 좋은 시기일 수 있습니다. 걱정하지 마세요. 필요할 때마다 아카이브에서 현재 도메인으로 버그를 이동할 수 있습니다.

개발 팀은 버그 수정을 시작하기 전에 전체 분류 작업이 완료될 때까지 기다릴 필요가 없습니다. 몇 가지 버그가 분류되는 즉시 시작할 수 있습니다. 팀은 모든 항목이 '버그가 해제'되거나 재분류될 때까지 백로그의 다른 항목에 대한 작업을 시작해서는 안 됩니다. 제품 관리자가 새 작업의 우선 순위를 올바르게 지정하도록 하는 것은 바로 이 규칙입니다.

요약하자면

프로젝트에서 보고된 모든 버그는 수정하는 데 추가 시간이 필요합니다. 따라서 버그 추적에는 버그를 추적하는 개인의 뛰어난 의사 소통 기술과 버그를 수정하는 사람의 민감도가 필요합니다. 앞서 언급한 추적 해킹을 통해 팀은 모든 종류의 기술 또는 보안 장애물을 보고하면서 생산성을 높일 수 있습니다.