엘에스웨어시스템

현재 메일공유를 통해

   => 1단계) 현 패키지가 이정도 테스트가 됐구나 알림 정도 

   => 2단계) 제가 품질방향 접근에 있어서 부족한 부분들 정리하면서 저 자체적으로 보완 

   => 3단계) 보완된 부분들 정리가 되면 툴로 만들어 자동 운영 단계로 나아갑니다.

[금주 진행한 테스트]

 1) 사전테스트

 2) 부분확인회귀테스트

 3) Resolved된 항목 확인/회귀테스트

 4) 리스크 분석 위험/품질요소를 고려 테스트

[테스트 상세설명]

1) 사전테스트

  - 목      적 : 사전확인항목 (기본기능 또는 그 기능으로 다음 테스트 불가 항목) 중 결함 발생될 경우 재패키지 요청 

  - 진행요일 : 월요일 오전 (패키지 설치 후 빠른 테스트 진행)

                  *월요일 결함 수정 불가능, 재패키지 어려울 시 추후 항목 Resolved된 후 버전 확인 절차 

  - 비     고 : 재패키지 요청 히스토리

                  1/24 (월) 재패키지 요청 - 결과: 지연

2) 부분확인회귀테스트

 - 목     적 : 고객사에서 발생된 critical 항목이 동일하게 발생되지 않겠끔 방어전략 진행

 - 진행요일: 월요일

3) Resolved된 항목 확인테스트

 - 목     적: 살충제 패러독스 현상을 막기 위한 진행

 - 진행요일: 화~수 또는 화~목요일

 - 메일전송내용: 타조직 분들 결함들도 확인하면서 수정/방치된 결함들을 closed 진행(진행예정) 건  2022/01/06 목요일 오전 11:02:12

      기존 테스트케이스를 반복적으로 진행하다보면 살충제 패러독스 현상으로 다양한 결함을 발견하지

      못해 기존 등록되어 있는 결함들 중 Resolved된 항목들 확인(회귀) 진행하기도 하는데요.

      품질자동화 외 분들 결함들도 확인하면서 수정/방치된 결함들을 closed 진행(진행예정)을 했습니다.

      혹시 문제가 되면 말씀해주시면 요청하셨던 분 결함 항목은 제외하고 진행하고,

      항목과 다르게 테스트해서 재현되더라도 너그럽게 이해 부탁드립니다.

      PS) 참고로 VOC는 고객사에서 중요한 요구사항이 포함될 수 있기에 Resolved 장기간 방치된 항목만 확인

           예정입니다.

4) 리스크 분석 위험/품질요소를 고려 테스트

 - 목     적: 장애 발생가능성, 사업영향도 고려 후 기능 선별 후 집중 테스트 진행

 - 진행요일: 무관

Software Testing 사이트들입니다.

​

https://www.javatpoint.com/software-testing-tutorial

https://www.softwaretestingmagazine.com/

https://users.ece.cmu.edu/~koopman/des_s99/sw_testing/

https://www.applause.com/blog/software-testing-life-cycle-stlc-phases

https://www.guru99.com/software-testing-introduction-importance.html (SW 테스팅 사용 이점)

비용 효율성: 소프트웨어 테스팅의 중요한 이점 중 하나. IT 프로젝트를 적시에 테스트하면 장기적으로 비용을 절약하는 데 도움, 소프트웨어 테스팅 초기 단계에서 버그가 잡힐 경우 수정 비용 감소

보안: 소프트웨어 테스트의 가장 취약하고 민감한 이점, 사람들은 신뢰할 수 있는 제품을 탐색, 위험과 문제를 조기에 제거하는 데 도움

제품 품질: 모든 소프트웨어 제품의 필수 요구 사항 테스트를 통해 고품질 제품이 고객에게 전달되는지 확인

고객 만족: 모든 제품의 주요 목표는 고객에게 만족을 제공. UI/UX 테스팅은 최고의 사용자 경험을 보장

[정의]

모든 입력 조건과 동작을 참, 거짓으로 표현하여 조합을 만들고 테스트 케이스를 작성하는 방법

[의사결정 테이블의 활용]

사용 예) N제품 사용자 계정 테스트 시 활용

리스크 분석 위험/품질요소를 고려해 기능테스트케이스 작업 후 테스트 진행하도록 하겠습니다.
- 장애 발생가능성(상호관계, 구현난이도),
- 사업영향도(중요도, 사용빈도) 
- 품질요소 가중치
- 리스크 등급

원리1 - 테스팅은 결함이 존재함을 밝히는 활동이다.

  테스팅은 소프트웨어에 잠재적으로 존재하는 결함을 줄일 수는 있지만, 결함이 전혀 발견되지 않은 경우라도 해당

  소프트웨어에 결함이 없다고 증명할 수는 없다.

  즉 테스팅은 결함이 존재함을 밝히는 것이다.

원리2 - 완벽한 테스팅은 불가능하다.

  모든 가능성(입력과 사전 조건의 모든 조합)을 테스팅하는 것은 지극히 간단한 소프트웨어를 제외하고는 가능하지 않다. 일반적으로 완벽한 테스팅이 불가능한 이유는 다음과 같다.

  - 한 프로그램 내의 내부조건이 무수히 많을 수 있음 (무한 경로)

  - 입력이 가질 수 있는 모든 값의 조합이 무수히 많음 (무한 입력값)

  - GUI 이벤트 발생 순서에 대한 조합도 무수히 많음 (무한 타이밍)

따라서 완벽한 테스팅보다는, 테스팅 대상의 리스크 분석을 토대로 테스트 활동의 노력을 차별화하는 것이 옳다.

우주항공, 의료 등 안전이 최우선인 소프트웨어를 개발하고 테스팅 할 때는 테스팅의 완벽함이 요구될 수 있겠지만, 이는 불가능한 목표이므로 일반적인 소프트웨어 테스팅보다 더 많은 노력과 리소스를 투입하여 강도 높게 수행하는 것이지 실제로 완벽한 테스트가 수행되는 것은 아니다.

원리3 - 결함 집중

 출시 전 대다수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보이며, 이러한 결함의 집중은 대부분 운영상의 장애를 초래한다. 일반적으로 결함이 집중될 수 있는 모듈들은 다음과 같다.

  - 자체적으로 복잡한 구조를 가지고 있는 모듈

  - 소프트웨어나 시스템의 다른 부분 또는 다른 모듈과 다량의 복잡한 상호 작용을 하는 모듈

  - 개발 난이도가 높거나 최신 기술을 사용한 모듈

  - 기존에 개발된 것을 재사용하지 않고 새롭게 개발한 모듈

  - 크기가 큰 모듈

  - 경험이 미흡한 개발팀에서 개발한 모듈

원리4 - 살충제 패러독스

 동일한 테스트케이스로 동일한 테스트를 반복적으로 수행한다면, 나중에는 더 이상 새로운 결함을 찾아내지 못한다. 시스템에 잠재된 보다 많은 결함을 발견하기 위해서는 테스트케이스를 정기적으로 리뷰하고 개선할 필요가 있다.

 공식적인 기법을 적용하여 설계된 테스트케이스 역시 반복적으로 수행되면 새로운 결함을 지속적으로 발견할 가능성은 낮아진다. 이런 경우, 해당 기법을 다른 모듈 또는 다른 시각에서 재적용시켜 테스트케이스를 업데이트하는 노력과 탐색적 테스팅, JIT 테스팅 등의 경험기반접근법을 통해 새로운 테스트케이스를 추가하는 것이 필요하다.

원리5 - 테스팅은 정황에 의존적이다.

 테스팅은 정황에 따라 다르게 진행된다. 예를 들어, 안전-최우선 소프트웨어를 테스트하는 경우, 전자상거래 사이트를 테스트할 때와는 다른 방식으로 진행해야 한다.

 이때, 정황과 도메인(분야)에 따라 다르게 테스팅을 진행해야 하지만 아래와 같이 모든 테스팅에서 변하지 않는 사항도 존재한다.

  - 테스트 주요활동에 대한 테스트 프로젝트 계획

  - 표준적인 기법 적용

  - 독립적 테스트 환경

  - 효율적/효과적 테스트 팀 조직

  - 정식 리포팅 등

원리6 - 오류-부재의 궤변

 개발된 시스템이 사용자의 필요와 기대에 부응하지 못하고 사용성이 현저히 낮다면 결함을 찾고 수정하는 과정은 아무 소용없다. 사용자 또는 비즈니스의 요구를 충족시켜주지 못한다면, 설사 결함을 모두 발견하여 제거하였다고 하더라도 품질이 높다고 볼 수는 없다.

원리5 - 테스팅은 정황에 의존적이다.

테스트 디자인이란,

테스트 베이시스를 토대로 테스트 활동 전체에 대한 기본 설계를 하는 행위로 볼 수 있습니다.

"테스트를 어떻게 수행할 것인가?" 라는 것이 테스트 디자인의 행동 목적이므로, 이를 위해 테스트 베이시스를 기준으로 검토하여 테스트 설계를 진행

‘테스트 베이시스’가 무엇인가요? ‘테스트 디자인’은 무엇인가요? 

> 테스트 베이시스(Test Basis) 개요

• 테스트 케이스의 기준이 되는 시스템과 컴포넌트의 요구사항을 추론할 수 있는 테스트 케이스의 기반이 되는 모든 문서를 뜻함.
 

> 테스트 베이시스 - 요구사항 명세서

요구사항 명세서는 요구사항 분석 과정이 완료된 후 선별된 기능을 바탕으로 시스템 및 서비스에서 제공하는 특성과 기능을 기록한 문서를 말합니다.
 

요구사항 명세서 구성

• 일반적으로 요구사항 명세서에는 「요구사항 ID, 요구사항 이름, 구분, 유형, 업무 중요도, 요구사항, 관련부서」 등을 기재합니다.

테스터는 요구사항 명세서로 어떤 작업을 하는가?

• 요구사항 명세서는 고객이 소프트웨어 제품/서비스에 요구하는 필요 사항을 적는 '요구사항'이 자세히 기재되어 있습니다.
• 그 뿐만 아니라 요구사항을 식별하고 요구사항에 대해 간단하게 설명할 수 있는 '식별 아이디'와 '요구항목 이름' 등 다양한 내용으로 구성되어 있습니다.
• 테스트 설계 전 요구사항을 확인하고, 향후 요구사항대로 최종 산출물이 개발되었는지 확인이 필요합니다. 또한, 요구 검증에 대한 테스트 결과는 고객에게 제공할 의무가 있습니다.

> 테스트 베이시스 - 아키텍처

아키텍처(소프트웨어 구조)는 소프트웨어의 구성요소들 사이에서 유기적 관계를 표현하고, 소프트웨어의 설계와 업그레이드를 통제하는 지침과 원칙을 기록한 문서를 말합니다. 

아키텍처 패턴의 종류

소프트웨어 아키텍처 패턴이란 시스템에 대한 기본 구성 스키마로써, 하위 시스템의 집근간의 관계를 구성하기 위한 규칙과 지침을 패턴으로 분류한 것 입니다. 이 아키텍처 패턴 또한 소프트웨어 개발 시 테스트 베이시스로 사용합니다. 이번 글에서 설명하고자 하는 바는 아키텍처 패턴도 테스트 베이시스로 사용한다는 점을 설명하는 게 목적이므로, 이번 기회에는 패턴의 종류만 언급하고, 상세 내용은 다루지 않겠습니다. 해당 패턴에 대한 내용은 Architectural Pattern페이지를 참고해 주세요.

• 계층화 패턴 (Layered pattern)
• 클라이언트-서버 패턴 (Client-server pattern)
• 마스터-슬레이브 패턴 (Master-slave pattern)
• 파이프-필터 패턴 (Pipe-filter pattern)
• 브로커 패턴 (Broker pattern)
• 피어 투 피어 패턴 (Peer-to-peer pattern)
• 이벤트-버스 패턴 (Event-bus pattern)
• MVC 패턴 (Model-view-controller pattern)
• 블랙보드 패턴 (Blackboard- pattern)
• 인터프리터 패턴 (Interpreter pattern)

테스터는 아키텍처 패턴으로 어떤 작업을 하는가?

• 테스터들은 이러한 아키텍처의 패턴을 확인함으로써 시스템과 컴포넌트들이 어떤 식으로 연계되고, 어떻게 상호작용 하는 지를 이해할 수 있습니다.
• 그리고 이를 통해 테스트 설계 시 위험 요소를 미리 식별하거나 테스트 케이스를 작성하여 개발 완료 후 확인이 가능해집니다.
• 예를 들어, 데이터 간 인터페이스(Interface)에서 주고 받는 파라미터(Parameter) 값의 데이터 타입(Data Type)을 굳이 일일히 테스터에서 알려주지 않아도 되므로, 예외 상황 테스트(Exception Testing)를 훨씬 원활하게 수행할 수 있습니다.

> 테스트 베이시스 - 개발 설계 문서

개발 설계 문서란, 요구시힝 분석/설계 단계를 거쳐 식별된 내용을 어떻게 컴포넌트 및 시스템으로 개발할 지에 대해 기술한 문서들을 말합니다.

개발 설계 문서의 종류

• 기획서(화면 설계서 or 스토리보드): 시스템 구성도, 이해관계자 정의, 팀 R&R 정의, 개발 범위 명시
• 시스템 흐름도
• 프로세스 정의서
• 용어 사전
• ERD
• 공통코드 정의
• 네이밍 룰
• WBS

테스터는 개발 설계 문서로 어떤 작업을 하는가?

• 위 V 모델은 테스터들이 소프트웨어 개발의 각 단계에서 도출한 산출물들로 어떤 테스트를 하는 지에 대해 개괄적으로 설명합니다.
• 요구사항 항목들은 시스템 개발 완료 후 인수 테스트(Acceptace Testing)으로 진행됩니다.
• 시스템의 작동 방식에 대한 내용은 시스템 테스트(System Testing)으로 진행됩니다.
• 시스템의 요구 항목 및 작동 방식은 통합 테스트(Integration Testing)으로 진행됩니다.
• 각 컴포넌트 및 모듈의 세부 기획 사항은 단위 테스트(Unit Testing)으로 진행됩니다.
• 그 외에도 각 단계에서 진행할 수 있는 여러 테스팅 활동들이 있습니다.

※ "전체 테스트", "풀(Full) 테스트"라는 말은 콩글리시(Konglish)이며, 국제 표준에서는 인정하지 않는 실무자들의 언어이므로, 가급적 사용을 지양하시기 바랍니다.

> 테스트 디자인(Test Design) 개요

디자인(Design)이라는 단어를 들으면 우리는 흔히 그래픽 디자인을 연상하지만, 사실 Design은 '기획'이나 '설계'를 의미합니다. (다음 영한사전, Dictionary 영영사전) 그러므로 우리가 "테스트 디자인"을 말할 때 "테스트 케이스를 도화지에 그림 그리듯 하는 것이다."라고 표현하시는 분들도 계신데 사실 조금은 틀린 표현입니다. 테스트 디자인은 그 용어 자체로 "테스트 활동을 설계한다"라는 의미를 가지고 있기 때문입니다.

즉, 테스트 디자인이란, 위 1번에서 설명한 테스트 베이시스를 토대로 테스트 활동 전체에 대한 기본 설계를 하는 행위로 볼 수 있습니다. "테스트를 어떻게 수행할 것인가?"라는 것이 테스트 디자인의 행동 목적이므로, 이를 위해 테스트 베이시스를 기준으로 검토하여 테스트 설계를 진행하게 됩니다.

"테스트 활동을 설계한다"는 말과 "테스트를 계획한다"는 말은 다른 의미입니다. 아래 '관련 참고 자료'에서 Test Plan vs Test Design 내용을 참고하여 주세요. 기회가 될 때 필자들이 다시 설명 드릴 수 있도록 하겠습니다.

> '테스트 디자인 과정에서 테스트 베이시스를 검토한다'는 의미는?
 

"테스트 디자인 과정에서 테스트 베이시스를 검토한다." 라는 의미는 결국 2번에서 설명한 테스트 디자인(Test Design) 활동을 하기위한 기본 자료를 검토한다는 의미 입니다.

1번에 설명한 테스트 베이시스 예시에 대하여 테스트 베이시스에 대한 리뷰를 진행하게 됩니다. 리뷰와 관련된 내용은 본 다른 필자들이 작성하신 "시스템이나 문서에 대한 엄격한 테스팅"에 대한 의미는 무엇인가요? 의 내용을 참고하세요.

http://www.qamadness.com/5-test-design-techniques-qa-engineers-should-know/

심각도를 표현하는 단어를 정확하게 사용하는 것도 중요하지만 먼저 조직 내에서 각 결함 심각도의 구분을 명확한 기준을 가지고 정의해야 한다. 결함 심각도 구분별로 해당하는 내용이 모호할 경우, 결함 리포팅의 신뢰성이 떨어질 수 있고, 특히 결함 심각도를 보는 조직이나 사람마다 다르게 평가하여 논쟁에 불필요한 시간을 반복적으로 낭비할 수 있다.

결함 심각도 구분 기준

치명적 결함 (Critical Defects)

- 하드웨어 또는 소프트웨어 장애, 시스템 중지, 시스템 잠김, 데이터 손실 또는 변조

주요 결함 (Major Defects)

- 기능 실, 잘못된 기능, 주요 기능 오작동

[ 일반 결함 (Average Defects)

  - 불완전한 기능, 사소한 기능 오작동, 잘못된 인터페이스 ]

사소한 결함 (Minor Defects)

- 타이밍 에러, 사용자 불편, 스크린 표준의 위반, 좋지 않은 인터페이스

개선 사항 (Enhancement)

- 에러는 아니지만 개선이 필요한 사항

* (일반 결함)은 주요 결함과 같이 포함이 되어 치명적 결함, 주요 결함, 사소한 결함 3가지로 결함관리시스템 등록이 됩니다.