버그를 이해하고 해결하는 혁신적인 방법

실제 행동이 예상 행동에서 벗어나면 소프트웨어 버그나 결함이 존재하는데, 이는 고객들이 불만을 품고 개발팀의 사기가 타격을 입을 때입니다.

예상되는 행동이 명확하지 않으면 직관적으로 예상되는 것에서 벗어난다는 문제가 제기됩니다. 이것은 버그인가요 아니면 특징인가요? 어떤 경우든 고객의 관점에서 버그는 바람직하지 않습니다. 고객 주도형 개발 팀은 버그를 식별하고 수정하기 위해 최선의 노력을 기울입니다.

소프트웨어 버그를 보는 두 가지 보완적인 방법이 있습니다. 그것들을 보는 한 가지 방법은 살충제를 사용하여 제거될 수 있는 해로운 곤충의 은유를 포함합니다. 소프트웨어 버그는 곤충이고 소프트웨어 테스트는 살충제입니다. 두 번째 방법은 그것들을 올바른 학습 과정을 요구하는 학습 기회로 보는 것입니다.

 

 

버그를 이해하고 해결하는 혁신적인 방법

 

 

장애, 오류, 장애

그러나 버그란 정확하게 무엇인가요? 무엇이 소프트웨어 제품을 예상된 행동으로부터 벗어나게 할 수 있을까요? 프로그래밍 코드의 측면에서 보면 결함, 오류, 그리고 실패가 있을 수 있습니다. 코드의 결함은 오류를 초래할 수 있습니다. 오류는 실패를 초래할 수 있습니다.

또 다른 비유는 우리가 이 개념들을 명확히 하는데 도움을 줄 수 있습니다. 우리는 아침에 일어나서 고통을 느끼거나 어지러움을 느낍니다. 이 증상들을 실패로 생각하세요. 우리는 의사에게 가기로 결정했습니다. 의사는 매우 낮은 것으로 밝혀진 우리의 압력을 측정합니다. 우리의 압력이 그렇게 낮아서는 안 되기 때문에 이것을 오류로 생각하세요! 그런 다음 우리는 높은 콜레스테롤 수준을 보여주는 혈액 검사를 합니다. 높은 콜레스테롤 수준은 허용 가능한 수준의 편차와 같은 또 다른 오류입니다. 의사는 모든 실패와 오류를 분석합니다. 그녀는 실패로 이어진 오류를 초래한 결함(또는 결함)을 알아내려고 노력합니다.

오류는 결과적으로 더 큰 실패(더 큰 고통)를 초래할 수 있습니다. 오류는 서로 무관할 수 있고, 어떤 것은 실패를 야기하는 반면 다른 것은 실패를 야기하지 않을 수 있습니다. 또한 오류는 서로를 취소하여 거의 또는 전혀 실패하지 않을 수 있습니다(적거나 고통이 없음). 동일한 결함, 다른 결함 또는 결함 간의 상호 작용으로 인한 것일 수 있습니다.

다음은 숫자 배열을 받아들이고 0의 수를 세는 간단한 방법의 예입니다.

숫자 배열을 허용하고 0의 수를 카운트합니다

메서드 numZero에는 변수 i의 초기화 식에 오류가 있습니다. 이 오류로 인해 numZero는 입력 배열의 첫 번째 요소를 고려하지 않습니다. 이는 오류입니다. 결과적으로 첫 번째 요소가 0이면 numZero는 계산에서 실패합니다. 그러나 첫 번째 요소가 0이 아니면 numZero는 실패하지 않습니다. 예를 들어 numZero([1, 9, 0, 7])는 1로 올바르게 평가하고 numZero([0, 1, 2, 6])는 0으로 잘못 평가하므로 실패합니다.

소프트웨어 업계에서는 결함, 오류 및 오류 중 하나를 가리키는 용어로 버그 또는 결함이라는 용어를 비공식적으로 사용하는 경향이 있습니다.

 

 

버그의 종류

버그를 찾기 위해 테스트해야 합니다. 결과적으로 버그 유형은 우리가 수행하는 테스트 유형에 따라 결정됩니다. 기능성이 손상된 기능성 버그가 있습니다. 보안 버그, 신뢰성 버그, 가용성 버그, 유용성 버그 및 성능 버그와 같은 비기능성 버그도 있습니다. 수동 테스트 또는 자동 테스트를 통해 탐지된 유효성 검사 버그, 행복 경로 버그, 음성 테스트 버그, 회귀 버그, 연기 테스트 버그 및 버그를 입력하십시오. 버그 유형 목록은 길지만 가장 중요한 것은 테스트가 버그가 없다는 것을 증명할 수 없다는 것입니다. 대부분의 버그 또는 가장 중요한 것을 발견했다는 자신감을 얻는 데 도움이 될 수 있습니다. 그러나 모든 테스트 작업 후에 버그 제로를 끊임없이 추구하는 함정을 피하기 위해 항상 노력할 가치가 있습니까?

 

 

버그는 일찍 발견

소프트웨어 개발 수명 주기(SDLC)의 여러 단계에서 버그가 생성될 수 있습니다. 요구 사항 분석, 아키텍처 설계, 개발 또는 배포 중 우리가 버그를 더 일찍 감지하고 고칠수록 좋습니다. 이는 요구 사항에서 설계, 개발, 그리고 QA 테스트로 이동함에 따라 버그를 수정하는 비용이 상당히 증가하기 때문입니다. 영국 속담에 따르면 시간 안에 꿰매면 9개가 절약됩니다.

버그를 탐지하려면 단위 수준, 통합 수준, API 수준, 시스템 수준 또는 허용 수준 등 모든 수준에서 테스트하는 것이 중요합니다.

한 소프트웨어 그룹은 SDLC 전반에 걸쳐 테스터를 사용했습니다. 요구 사항 분석 중에 감지된 버그를 높은 우선 순위로 문서화하고 해결했습니다. 

또 다른 그룹은 비즈니스 분석가와 제품 소유자들이 테스트 마인드를 갖도록 교육했습니다. 그들은 긍정적인 경우와 부정적인 경우와 문제가 있는 경우를 찾습니다. 이러한 문제를 발견한 후 테스트 케이스 설계 중에 특정 시나리오를 통합하도록 테스트자에게 직접 통보합니다. 

또 다른 그룹은 좋은 탐색 테스터인 제품 소유자를 고용하곤 했습니다. 요구 사항을 탐색할 지식과 건설적인 비평 능력을 가진 사람들. 비즈니스 영역에 대한 지식과 확장하고 집중하려는 의지가 있는 사람들. 그러한 배경을 가진 제품 소유자들은 종종 버그를 일찍 발견하곤 했습니다. 그들은 또한 복잡한 요구 사항을 피하기 위해 필요한 조치를 취했습니다. 그들은 명확하고 모호하지 않으며 완전하며 시험 가능한 요구 사항을 생성했습니다.

 

 

버그 면역력

살충제 비유를 따라, 시간이 지나면, 생물학의 곤충들은 살충제에 면역력을 갖게 될 것이고 그것들을 죽이기 위해 새로운 살충제를 사용해야 합니다. 비슷하게, 우리 코드에 있는 소프트웨어 버그들은 우리의 실험들에 면역력을 갖게 될 것이고 우리는 그것들을 찾고 고치기 위해 새로운 실험들이 필요할 것입니다.

테스트는 코드의 특정 영역에 집중되고 시간이 지나면 버그를 거의 발견하지 못할 것입니다. 이는 테스트된 코드가 결국 개선되고 결함이 거의 발견되지 않기 때문입니다. 우리가 항상 중요한 버그를 발견하기를 원한다면, 우리는 새로운 방식, 새로운 테스트 수준으로 테스트하고 다양한 유형의 테스트를 시도해야 하며 코드가 진화함에 따라 테스트 사례가 발전해야 합니다.

 

 

결함 추적 시스템

결함 추적 시스템은 문제와 해결 방법을 문서화하는 도구이며, 결함 우선 순위와 심각도, 복제 단계, 가능한 해결 방법, 발행인 및 양수인과 같은 정보가 포함됩니다.

한 팀은 문서화 결함을 재작업과 낭비로 간주했습니다. 그들은 버그가 발견되자마자 수정했습니다. 단위 테스트는 결함을 재생산하기 위해 작성되었고 코드는 수정되어 단위 테스트를 통과했습니다. 그런 다음 테스트와 수정은 체크인되었으며 작업은 정상적으로 계속됩니다. 테스터는 문제가 발견되는 즉시 개발자와 협력할 것입니다. 개발자가 즉시 수정을 제공할 수 있다면 버그가 문서화되지 않았습니다. 즉시 사용할 수 있는 개발자가 없거나 수정에 어려운 의사 결정이 필요한 경우 버그가 문서화되었습니다.

다른 팀은 테스트자, 개발자 및 제품 소유자 간에 공유된 구글 문서에 버그 목록을 만들 것입니다. 이것들은 기능 테스트 중과 기능 릴리스 전에 발견된 버그였습니다. 적어도 모든 중요한 버그는 릴리스 전에 수정되었습니다. 만약 결정이 일부 낮은 우선 순위의 버그로 후보 기능을 릴리스하는 것이라면 그들은 결함 추적 시스템에 이를 문서화할 것입니다. 그들은 항상 기능 릴리스 후에 탐지된 결함을 문서화했습니다.

결함 추적 시스템을 지식의 데이터베이스로 간주하는 그룹이 있었습니다. 모든 버그는 기능 릴리스 이전 또는 이후에 발견되었는지 여부에 관계없이 시스템에 보고되었습니다. 그들은 버그에서 패턴을 찾고 있었습니다. 그들은 상호 관련된 버그가 있는지 여부와 같은 질문을 하고 있었습니다. 왜 고쳐지는 일부 버그는 다시 돌아오는 것일까요? 왜 일부 특정 버그는 산발적으로 발생하는 것일까요? 근본 원인 분석은 해답을 찾고 비슷한 문제가 재발하는 것을 방지하는 방법을 배우기 위해 수행되었습니다.

 

 

버그를 감지하는 것과 그것들을 고치는 것은 다른 것

비록 SDLC 초기에 버그를 예방하고, 감지하고, 고치는 것이 명백히 최선의 방법이지만, 버그를 고치는 것은 어려울 수 있습니다. 만약 고치는 것의 비용이 고치지 않는 것의 비용보다 크다면, 아마도 해결책은 (가능하다면) 고객을 행복하게 할 수 있을 것입니다. 해결해야 할 알려진 모든 문제가 명확하게 문서화되고 모든 이해관계자에게 전달될 수 있기 때문에 버그 추적 시스템이 매우 유용할 수 있는 때입니다. 팀 간의 협력이 필요하고, 수정하는 데 시간이 걸릴 수도 있는 중요한 버그가 문서화되어야 합니다. 우리가 중요한 버그를 발견했을 수도 있지만, 현재 수정해야 할 더 중요한 버그가 있습니다. 우리는 우선순위별로 덜 중요한 버그를 필터링하면서 가장 중요한 것을 먼저 수정해야 합니다.

 

학습 과정으로 인공적으로 도입된 버그

기존 프로세스가 버그를 감지하기에 충분한지 확인하기 위해 시스템에 인위적으로 버그를 도입할 수도 있습니다. 이 정책은 여러 소프트웨어 그룹에서 인기가 있었습니다.

한 그룹은 밤새 테스트 자동화 실행이 버그를 잡을 수 있는지 확인하기 위해 UI 버그를 소개했습니다. 다른 그룹은 개발자를 위한 정기적인 버그 교육 세션을 가졌습니다. 버그는 데브옵스 팀에 의해 소개되었고 이를 찾고 수정하기 위해 개발자에게 힌트를 주었습니다.

마이크로서비스 수준에서 버그를 도입하여 마이크로서비스 행동을 확인하는 그룹이 있었습니다. 그들은 또한 이렇게 세심하게 만들어진 버그가 마이크로서비스 전반에 걸쳐 어떻게 전파되는지 보는 데 관심이 있었습니다.

수많은 그룹이 시스템에 내성이 있는지 확인하기 위해 장애를 선동했습니다. 시스템을 켜고 끄며 고의적으로 장애를 일으키는 소프트웨어를 실행했습니다. 시스템이 얼마나 내성이 있는지, 어떤 종류의 장애가 발생할 수 있는지, 그러한 문제를 개선하는 방법, 그리고 예측하지 못한 여러 상황에 대응하는 방법에 대해 배웠습니다.

 

 

마무리

소프트웨어 버그는 거의 모든 소프트웨어 제품에 이런 저런 형태로 존재합니다. 그 존재는 고객과 소프트웨어 개발팀을 포함한 모든 사람을 불행하게 만듭니다. 아마도 소프트웨어 엔지니어가 번창하기 위한 전제 조건 중 하나는 코드의 결함, 오류 및 실패 사이의 균형을 유지하는 것일 것입니다. 그것들은 우리의 작업과 불가분하게 연결되어 있기 때문에 우리는 그것들을 최대한 방지하는 방법, 그것들이 도입되었을 때 발견하는 방법 및 어떤 상황에서도 그것들을 수정하고 처리하는 방법에 대해 명확히 할 필요가 있습니다.