[소프트웨어 테스팅] 3. Program Inspections, Walkthroughs and Reviews

2022.03.13 - [컴퓨터 공학/0 +소프트웨어 테스팅] - [소프트웨어 테스팅] 2. the psychology and economics of software testing

[소프트웨어 테스팅] 2. the psychology and economics of software testing

 

이전글에는 소프트웨어 테스팅의 심리학적, 경제적 관점에 대해서 알아보았다.

소프트웨어 테스트는 모든 테스터가 코드를 읽는 것은 아니지만, 테스트의 노력의 일환으로 프로그램 코드를 연구한다는 것은 널리 받아들여지고 있다.

 

오늘은 None Computer Based Test ---> Human Testing에 대해서 알아보자..!!!

 

기본적으로 Human Testing은 오류를 찾는데 매우 효과적이다.

• 프로그램이 완료된 것으로 간주 될때 또는 각 모듈, 유닛이 완료된 후 사용

 

모든 프로그래밍 프로젝트는 이러한 기술을 하나 이상 적용해야 한다.

1. Code Inspections
2. Walkthroughs
3. User Testing

Human Testing은 프로그램의 생산성과 신뢰성에 크게 기여한다.

1. 조기에 오류 발견시 수정 비용이 낮아지고, 수정 가능성이 올라감.
2. 컴퓨터 기반 테스트가 시작 되면 개발자들이 심리적인 변화를 겪게 되는데, 이러한 압박으로 이전에 발견된 오류를 수정 할 때보다 컴퓨터 기반 테스트에서 발견된 오류를 수정할 때 더 많은 실수를 저지르는 경향이 있다.

 

---

 

 

Inspections and Walkthroughs

 - 프로그램을 읽거나 육안으로 검사하는 팀으로 구성(프로그램 개발자가 직접하지 않아서 더욱 효과적)

 - 에러는 찾는 것이 목적

 - 에러를 해결하는것이 목적이 아님(디버그가 목적이 아님)

 - 블랙박스 테스트(예기치 않은 결과 출력)와 달리 일반적으로 정확하게 코드에 배치된다.

 - 에러가 빈번하게 공개되기 때문에, 추후 일괄적으로 에러를 수정할 수 있다.(컴퓨터 기반의 테스트는 에러를 1개씩 검출해 수정한다.)

 - 프로그램의 논리 설계 및 코딩 오류의 30 ~ 70%를 찾는데 효과적이다.(테스팅 프로세스가 끝날 때까지 발견된 모든 오류의 최대 70%를 찾는데 효과적)

 - 요구사항 분석 과정에서 발견한 오류를 검출하는데는 비효과적이다.

 - 컴퓨터 기반의 테스트와 상호 보완적이다.(둘 중 하나가 존재하지 않으면 오류 감지 효율성 저하)
    -> 변수 초기화, 변수 나누기 0 같은것은 Human Testing에서 찾는 것은 힘들다.

 

 

---

 

Code Inspections

Code Inspections에는 몇 가지 절차가 존재합니다.

 

Inspection Team

 - 보통 4명으로 팀을 구성(Moderator, Programmer, Program's designer, Tester)

 - 프로그램 개발자가 아니기 때문에 프로그램의 세부사항에 대해서는 알 필요가 없음.

Inspection Team에서 Moderater(QA)의 역할

 - Inspection 세션을 이끌고 관련 일정, 자료 배포

 - 모든 오류 기록

 - 나중에 에러가 수정되는 지 확인

 

Inspection Agenda

 Inspection전에 진행자는 프로그램 목록과 설계 사양을 다른 참가자들에게 배포한다.

 참가자들은 자료를 숙지한다.

Inspection session에서 하는 일

1. 프로그래머는 프로그램 논리를 기술한다. 회의 중 다른 참가자들은 질문을 하고(이는 오류가 존재하는지 여부를 판단하기 위함이다), 다른 팀원이 아닌 프로그래머가 나레이션을 통해 오류를 검사한다.(이 행위는 효과적인 에러 검출 기술이다.)

2. 프로그램은 과거에 자주 발생한 프로그래밍 오류 체크리스트에 대해 분석된다.(이러한 체크리스트는 다음 session에서 설명)

Inspection session이 완료 되면, 프로그래머에게 발견된 오류 목록을 제공한다.

진행자는 오류를 수정한 후 프로그램을 다시 검사하도록 준비한다.

오류 목록은 분석, 분류 및 향후 검사의 효과를 개선하기 위해 오류 체크리스트를 세분화 하는데 사용.

 

이러한 과정은 오류를 수정하는 것이 아니라 오류를 발견하는데 초점을 맞춰야 한다.

 

검사에 소요되는 시간은 90 ~ 120분정도가 최적의 시간으로 본다.

 

 

Human Agenda

검사 프로세스가 효과적이기 위해서는 테스트 그룹은 다음과 같은 사항을 지켜야한다.

1. 프로그래머에게 공격적인 태도를 취하면 안된다.(프로그래머가 비능률적이거나 무능하다고 암시하는 경우)

2. 검사의 목적은 프로그램의 오류를 발견하여 프로그램 품질을 향상시키는 것이다.

3. 검사 결과는 회의에 참가한 사람들에게만 공유하는 기밀사항으로 하는것을 추천 한다.

 

 

Side Benefits of the Inspection Process

검사 과정에는 몇 가지 부수적인 이점들이 존재하는데...!! 👍

1. 프로그래머는 프로그래머의 프로그래밍 스타일, 알고리즘 선택 및 프로그래밍 기술 같은 피드백을 받을 수 있다.

2. 참가자는 프로그래머의 오류와 프로그래밍 스타일에 노출됨으로써 비슷한 방식으로 이득을 얻는다.

3. 특정 프로젝트와 참가자가 참여하는 프로젝트에 대한 접근 방식을 강화하는 데 도움이 된다.

4. 가장 오류가 발생하기 쉬운 섹션을 조기에 식별하는 방법으로 컴퓨터 기반 테스트 프로세스 동안 직접적으로 주의를 집중 할 수 있다.

-> 효율적이고 신뢰할 수 있는 프로그램 개발가능..!! 🧑‍💻

 

---

 

An Error Checklist for Inspections

검사 프로세스에서 중요한 부분은 체크리스트를 사용하여 프로그램의 일반적인 오류를 검사하는 것..!

하지만, 일부 체크리스트는 오류보다는 스타일의 문제게 초첨을 맞추고 있다("주석이 정확하고 의미 있는가?, if-else 코드 블록과 실행 시간 그룹이 정렬되어 있는가?)

따라서, 오랜 연구 끝에 섹션의 체크리스트는 6개의 카테고리로 나누어져 있다.

• Data Reference Errors
• Data Declaration Errors
• Control-Flow Errors
• Interface Errors
• Input/Output Errors

 

---

 

 

Walthroughs

inspections과 마찬가지로 그룹을 만들어 코드를 읽는 오류 감지 기술 세트이다.

한 팀에 3~5명으로 구성되어 있으며, 그 팀에서 진행자는 Inspections과정과 비슷한 역할을 수행하고, 비서(발견된 모든 오류 기록)가 존재한다. 또한 검사자가 반드시 있어야 한다.

1~2시간 동안 중단 없이 진행되는 회의이다.

회의 인원은 다음과 같이 구성하는 것을 추천한다.

1. 경험이 풍부한 프로그래머
2. 프로그래밍 언어 전문가
3. 새로운 프로그래머(편견 없는 의견을 제시하기 위함)
4. 최종적으로 프로그램을 유지보수 할 사람
5. 다른 프로젝트에서 온 사람
6. 프로그래머와 같은 프로그래밍 팀이 될 사람

 

하지만, 절차가 약간 다른 오류 감지 기법을 사용한다.

• Data Refrence
• Computation
• Data Declaration
• Comparison
• Control Flow
• Input/Output
• Interfaces
• Other Checks

초기에는 검사 프로세스 절차와 동일하다.

하지만, 회의 절차는 다르다.

단순히 프로그램을 읽거나 오류 체크리스트를 사용하는 대신에, Tester로 지정된 사람은 프로그램 또는 모듈을 위한 일련의 대표적인 입력값으로 테스트 케이스를 준비하여 회의에 참석한다.

회의 중에 테스트 케이스는 마음속으로 진행한다. 즉, 테스트 데이터는 프로그램의 논리를 진행하며, 종이 또는 화이트보드로 모니터링 한다.

물론 테스트 케이스는 단순해야하고 수가 적어야 한다.(사람은 기계보다 휠씬 느린 속도로 프로그램을 실행하기 때문)

따라서 테스트 케이스는 테스트를 시작하고 프로그래머에게 논리 및 가정에 대해 질문하는 매개체 역할이다.(테스트 케이스 자체는 중요한 역할이 아님)

워크스루는 테스트 케이스 자체에서 발견되는 것보다 프로그래머에게 질문하는 과정에서 더 많은 오류가 발견된다.🙀

 

회의 참가자의 자세도 마찬가지로 중요하다.

참가자는 프로그래머가 아닌 프로그램 쪽을 향해야 한다.(오류를 범한 사람의 약점으로 간주하지 않는다. 오히려 프로그램 개발에 어려움이 있다고 생각해야한다.)

현장검증에는 검사 프로세스에 대해 기술된 것과 유사한 후속 프로세스가 존재해야 한다.

 

---

 

Desk Checking

옛날에 많이 사용하던 방식이다.🏛

혼자 진행하며(혼자 프로그램을 읽고 오류 목록과 관련하여 프로그램을 확인하고, 테스트 데이터를 살핀다.), inspections과 walkthroughs보다는 비효율적이다.

그 이유는 완전히 규칙을 정하지 않은 과정이기 때문이다.

하지만, 진행하지 않는 것보다는 낫다.

 

---

 

Peer Ratings

프로그램 테스트와는 관련이 없고 익명의 프로그램을 평가하는 것이다.(확장성, 품질, 유지보수성, 사용성 등...)

즉, 오류를 찾는 것이 목적이 아니다.

이 기법의 목적은 프로그래머의 자기 평가를 제공하는 것이다.

6-20명의 참가자를 선정하고 검토할 프로그램 중 두개를 선택한다.

한 프로그램은 훌륭한 프로그램을 대표해야하고, 다른 프로그램은 프로그래머가 품질이 낮다고 하는 프로그램이어야 한다.

각 참가자에게는 4개의 리뷰 프로그램이 주어집니다.

프로그램 중 2개는 "최종" 프로그램이고 2개는 "소수" 프로그램이지만, 심사자는 어느 것이 어느 것인지 알 수 없다.

각 참가자는 30분 동안 각 프로그램을 검토한 후 평가 양식을 작성합니다.

4개 프로그램을 모두 검토한 후 각 참가자는 4개 프로그램의 상대적 품질을 평가합니다.

평가 양식에서는 심사자에게 다음과 같은 질문에 대해 1~10의 척도로 답변하도록 요구한다(1은 확실히 예, 10은 절대 아니오를 의미한다).

• 그 프로그램은 이해하기 쉬웠나요?
• 높은 수준의 디자인이 눈에 띄고 합리적이었습니까? 
• 낮은 수준의 디자인이 눈에 띄고 합리적이었습니까?
• 당신은 이 프로그램을 수정하는 것이 쉽습니까?
• 이 프로그램을 만든 것이 자랑스럽겠습니까?

또한 검토자는 일반적인 의견과 제안된 개선 사항을 요청받는다.

심사 후, 참가자에게는, 투고된 2개의 프로그램에 대한 익명의 평가 용지가 주어집니다. 또한, 전체 프로그램 집합에서 원래 프로그램의 종합적이고 상세한 순위를 보여주는 통계 요약과 같은 프로그램의 다른 검토자의 등급과 비교한 다른 프로그램의 등급 분석도 제공된다.

이 프로세스의 목적은 프로그래머가 자신의 프로그래밍 기술을 스스로 평가할 수 있도록 하는 것입니다.

따라서 이 과정은 산업 및 교실 환경 모두에서 유용한 것으로 보인다.

 

---

 

반응형

 

요약

Human Testing 기술은 오류를 밝히는 데 매우 효과적이다.

• Code Inspections using checklists
• Group Walkthroughs
• Desk checking
• Peer reviews