개발이 테스트를 만났을 때(Shift left testing)

개발이 테스트를 만났을 때(부제: 제안_테스트의 미래)

2016.01 by JungGunhome: genycho.blog.me

역할 : 스페셜리스트배우 : 도메인전문가

역할 : 제너럴리스트배우 : 테스트전문가

알고리즘알고리즘알고리즘알고리즘

테스트테스트테스트테스트

개발이 테스트를 만났을 때

This is…복잡한 알고리즘 과제(프로젝트)에 대해

테스트 전담자가 협업한 사례

사례를 통해 독립된 테스트로부터

개발팀과 함께하는 테스트로의 이동 맛보기

(shift left testing)

단순 기능테스트에서 더 나아가

개발팀의 다양한 품질 이슈에 대응한 사례

I. 개요

II. 엔지니어링 관점의 수행내용

III. 테스트 전략 관점의 수행내용

IV. 기타 수행내용

V. 정리

대상 프로젝트들의 특성소규모 연구/요소 기술개발/분석엔진 등의 과제

영상분석, 데이터 분석, 네트워크&보안, IoT 등의 기술기반 요소기술 연구 과제

현재 품질은 낮으나 가이드하면 변화가 쉽게 발생하는 특성

-> 다양한 테스트 프랙티스들을 수행하고 그 결과를 확인하기가 용이

소규모(~12명)사업부 펀딩(=내부 고객)

요구사항 불명확

복잡하고트랜디한 기술 기반

젊고, 고학력(뛰어난 인재)

Testability가떨어지는

품질 인식은 낮은하지만, 품질이 중요한

테스트 수행 조직 구성소규모 과제 특성에 따라 테스트 인력은 Shared Service로 탄력적으로 운용

다양한 과제 도메인, 수행 프랙티스 별로 전담 인력 구성

빅데이터 분석 비디오 분석, IoT 보안,네트워크

도메인 리서치과제 파악 및테스트 전략

수립

테스트 교육,설계 가이드

테스트 시나리오리뷰 및 확장

개발/테스트코드리뷰 및 보완

테스트웨어 개발,자동화 환경구축

테스트 수행품질 Review

활동

0.25 0.25 0.25 0.25 0.5 0.25 0.5 0.25

A프로젝트 B프로젝트 가 프로젝트 나 프로젝트 ㄱ 프로젝트

TM

TE

TM

TE

TM

TE※ Shared Service 인력 운용

※ 수행 프랙티스

사례에 포함된 프로젝트 간략 소개(2014년~2015년)

모바일 인증 개발보안

(인증)FIDO 표준 규약 - 2014년말 단기 지원

관리자 포털 공통자산 웹어플리케이션관리자 포털

공통기능개발자 6명 내외 2015년 초 별도 요청으로 수행

과제명 기반 기술 대상 도메인 개발팀 규모 그 외 특이사항

제조공정 빅데이터 분석데이터

분석제조 공장 불량 원인파악 등

과제 PM외 5명복잡한 통계함수의 결과 값 확인 이슈, 빅데이터 프레임워크의 성능이슈

암호화 원천기술보안

(암/복호화)과제 PL 외 3명

보안 알고리즘의 난해함

사업부 제품과의 통합 이슈

물류 수요예측 기능 개발데이터

분석물류 수요예측 과제 PM외 4명

예측 알고리즘의 난해함

사업부 제품과의 통합 이슈

IoT기반 공장장비 제어

지능화IoT 반도체 공정 과제 PM외 6명

IoT 기술(하드웨어+소프트웨어) 이해 및Testability 문제

사업부와의 관계 이슈

I. 개요


1. 테스트 교육

2. 테스트 설계

3. 테스트 코드 가이드

4. 짝 테스트&프로그래밍

5. 테스트 자동 수행 환경 구축



V. 정리

과제 맞춤 테스트 교육과제 초기에 관련 내용을 묶어 교육 수행

(목차 예)

- 테스트 계획서 상의

테스트 활동 소개 및 필요성 설명

- 테스트 교육(빈발결함, 유사 사례)

- 테스트 시나리오 작성 목적 및 작성법

- 샘플 테스트 코드 설명 및

테스트 코드 작성 가이드

- Jenkins를 이용한 테스트 자동 수행 설명

등

[ 샘플 ]

테스트 활동 소개 및 필요성 설명- 어떤 테스트 활동을 왜 하는지 공감대 형성

- 언제, 무엇을, 어떻게 해야 하는지에 사전에 교육하고 피드백을 받아 보완

테스트 설계 교육- 단위 테스트, 통합 테스트에 대한 구분, 작성 목적 교육

- 테스트 설계 양식 공유 및 작성 가이드

빈발 결함, 기존 사례 교육

- 개발하는 제품의 특성에 따라 기존 사례, 빈발결함 등을 사전에 정리하여 공유

[ 빈발결함(화면 유형) ] [ API 품질 가이드 ]

I. 개요


1. 테스트 교육

2. 테스트 설계






V. 정리

테스트 설계란

- 테스트를 빠뜨리지 않고, 같은 시간에 더 많이 테스트하기 위해 미리 생각하는 과정

- 연구 과제의 경우 복잡한 알고리즘, 명확하지 않은 요구사항 때문에 테스트

설계를 잘 하는 것이 중요함

블랙박스 접근은

- 과제 팀이 테스트 시나리오 초안은 작성(수준은…)

- 존재하는 요구사항, 알고리즘 설계서 등의 산출물을 통해 테스트 설계 접근

- 테스트 설계 내용을 가시화해서 다시 리뷰하는데 중점

화이트 박스 접근은

- 산출물이 많이 미흡하고, 연구 과정에서 그때그때 로직이 변경될 수 있는 상황

- 개발 코드나 테스트 코드를 같이 보면서 상세 내용을 파악하는게 필요

※ 그레이 박스 테스팅(설계) ?

- 기본은 블랙박스로 접근하면서 그 내부는 어떻게 동작하는지 개발 코드를 참조

※ 잠깐!, 테스트 설계는 누가 해야 하는가?

- 테스트 설계는 테스트 할 테스터가 해야 한다- 할 수는 있겠지만 정말 잘 할 수 있을까? ROI가 나올까?

개발팀(분석,설계자)

고객

테스트

+ : 업무 분석하면서 업무를 잘 알고, 기술도잘 아는 사람. 작업 내용 리뷰를 원하는 사람- : 테스트는 잘 모르고, 분석자보다는 설계/개발자에가까운 경우가 많음

+ : 많은 테스트 지식과 경험을 갖고 있어 테스트를 어떻게 해야 할지 잘 아는 사람- : 업무를 잘 모르는 사람

+ : 업무를 가장 잘 아는 사람- : 시간도 없고, 시스템적인 기술 지식, 이를 잘 표현하는 스킬이나 책임이 약한사람

누가테스트 설계를

해야 할까?

테스트 종류, 목적에 따라. 상황에 맞게기본은 누구 한 명이 알아서 하는게 아니라 다같이 한다

1단계) 기존 산출물 분석을 통한 업무 파악 – 재확인 및 공유, 보완

2단계) 상위 레벨 이해관계자와 공유 및 피드백 확인

(예) 개발팀이 작성한 테스트 시나리오 초안 기반 분석

테스트케이스 후보 추출 및유효성 확인을 위한 체크

기존에 존재하는 산출물, 설명 내용 기반으로체크리스트, 도식 등을 이용하여 개발팀과 리뷰

1단계) 기존 산출물 분석을 통한 업무 파악 – 재확인 및 공유, 보완

2단계) 상위 레벨 이해관계자와 공유 및 피드백 확인

복잡한 알고리즘과수행과정이도식을 보니 쉽게 이해가되네요

. 생각하지 못했던 상황이나,

. 처리 후 동작을 어떻게 할지,

. 각 업무간에 어떻게 주고받을지 더 고민을 해야 겠네요

정리하고 보니,저희도 신규인력 설명할 때 활용하면 좋을것같아요

이런 경우는 단순히 리턴처리보다는 따로 에러를 발생시켜줬으면 좋겠네요

테스트 커버리지 측정을 통한 코드레벨 테스트 설계 보완

- 커버리지(라인, 브랜치 커버리지)를 측정하고 테스트가 안 된 부분을 건건이 테스트

엔지니어가 리뷰

TC 추가) 요청된 메시지의 버전 정보가 정해진 버전과

다른 경우 기대한 Exception(InvalidDataFormatException)

이 발생하는지를 확인하는 테스트 케이스 추가

커버리지 확인) 해당 부분은 임의로 발생시킬 수 없는 부분으로,

테스터가 코드 리뷰 후 테스트 불가 내용 확인

※ (사례) 코드레벨 업무 flow 분석 과정에서 개발 코드 리뷰도 일부 수행

: 산출물이 미흡하거나 아직 작성 전인 경우가 많고, 알고리즘 자체가 문서로

설명하는데 한계가 있어 코드레벨로 분석하고 이를 도식화하여 분석 함

소스 코드

구조-Process 처리여부구조-Log 처리구조-Exception 처리입력 파라미터 체크input table 없는 경우 처리output table 없는 경우 처리해당 컬럼명이 없는 경우 처리로직 상의 if 문 조건 나열계산식에서 입력값 짝에 따라 분자 or 분모가 0이 되는경우코드 내에 형 변환(문자 -> 숫자, 숫자-> 문자, Double->int 등)

로직 수행 중 오류 발생 시 에러 테이블에 넣어주고 있는지

1) 복잡한 수행로직 파악 2) 분기 조건, 에러 상황 등을 추가 분석해테스트 케이스에 반영

- 소스코드 분석 체크리스트 예

I. 개요


1. 테스트 교육

2. 테스트 설계






V. 정리

테스트 코드 작성 가이드

- Java, C, 특정 프레임워크(Cascading, MapReduce,Kura 등) 맞춤 테스트 코드 가이드

※ Tip. 상세 코딩 부분보다는 ‘테스트’ 관점의 뷰를 가이드

대상 가이드 내용 유형

암/복호화 로직

분기상황,

에러 발생 상황,

Assert문을 통한 검증

junit

C언어로 구현된

프로그램

툴 리서치 및 가이드 작성

샘플 코드 소개GoogleTest

빅 데이터 과제유틸리티를 이용한단위테스트 및 Data-driven 테스팅 샘플 작성

MapReduce

예측 알고리즘 과제단위, 통합 테스트 구분별다양한(기본/대안/예외 흐름등) 테스트 케이스 작성

Cascading

IoT 과제Mock을 이용한 하드웨어영역 Mocking 테스트 구성

Eclipse Kura

Framework

일반 웹어플리케이션

다양한(기본/대안/예외 흐름등) 테스트 케이스 작성

스프링 프레임워크

테스트 대상

(TC1) 가장 일반적인 상황

[ 샘플 구성 ]

(TC2) 분기 흐름

(TC3) 특이한 흐름

(TC4) 에러 상황

…

[ 지원 사례 ]

개발 초기 맞춤 샘플 단위 테스트 코드 예

- 가장 기본적인 테스트 외에도 다양한 흐름에 대한 테스트 케이스(코드)를 소개

- 작성한 샘플 코드를 통해 개발팀이 쉽게 테스트 코드 작성에 입문(러닝커브 최소화)

개발팀 테스트 코드개발팀 테스트 코드

코드 관리 업무코드 관리 업무

수정 1회 정상 테스트- 응답(TRUE)만 확인

삭제 1회 정상 테스트 - 응답(TRUE)만 확인

검색 1회 정상 테스트 - 응답(TRUE)만 확인

다건조회 1회 정상 테스트 - 응답(TRUE)만 확인

가이드한 테스트 코드가이드한 테스트 코드

(공통) 테스트 데이터가 변경될 때를 위한 데이터 정의 분리

등록 정상 테스트 – 등록 후 실제 1건이 DB에 추가되었는지 검증등록 추가 테스트 – 유니크해야 하는 이름에 동일한 이름 테스트수정 1회 정상 테스트수정 추가 테스트 – 존재하지 않는 ID에 대한 수정 요청(결함)삭제 1회 정상 테스트삭제 추가 테스트 – 존재하지 않는 ID에 대한 삭제 처리(결함)삭제 추가 테스트 – 해당 코드를 사용하는 데이터가 있는 경우(로직 반영 X)검색 1회 정상 테스트검색 추가 테스트 – 특수문자에 대한 검색 테스트(에러 발생)다건조회 1회 정상 테스트다건조회 추가 테스트 – 데이터가 없는 경우(결함, 에러가아닌 TRUE처리필요)다건조회 추가 테스트 – 데이터가 없는 페이지 요청시(에러 발생)

테스트가value를 줄 수있는 것!!

※ (사례) 테스트 코드 구조 가이드

- 향후 테스트 코드 유지보수를 고려한 효율적인 테스트 구성 가이드

- 테스트 코드 네이밍, 주석 처리 등 가이드

테스트 코드 구성

FaroServiceTestCase- 테스트 수행 전 스프링프레임워크의 설정 파일 로딩- 매 테스트 후 테스트 이전 상태로DB 초기화- 특정 쿼리문을 직접 수행 가능한인터페이스 제공 등

SampleServiceTest@Autowired로 객체 주입 후- 기본적인 테스트- 다른 흐름 테스트- 잘못된 키 값 등의 테스트- 필수입력 누락 등의 테스트…

SampleTestData- 테스트에 사용되는 데이터를분리하여 다른 테스트에서도참조할 수 있도록 정의(추가로 엑셀 또는 DB에서가져올 수 있게 보완 가능)

CodeMngService- 코드 전체 조회- 코드 검색- 코드 등록, 수정, 삭제…

AbsractTestData- 테스트 데이터를 DB, 엑셀 등으로부터 관리할 수 있도록 지원하는 추상 클래스

스프링 설정 파일 로딩 등공통 작업을 한 곳에서

관리하여 작성 공수 절감

설정이 바뀌더라도한 곳만 수정하면 그대로

모두 반영 가능

테스트에 사용되는 테스트데이터는 한 곳에서 변수로 정의하고

참조하도록 구성

데이터가 변경되더라도한 곳에서 변경 관리

가능

타 업무에서참조할 수도 있는 경우는

별도 클래스로 분리

I. 개요


1. 테스트 교육

2. 테스트 설계






V. 정리

짝 테스트를 통한 품질 강화- 영구적인 품질을 만드려는 테스트

- 개발자 + 테스터 짝으로 테스트를 수행

- 과제원은 테스트 접근 방식을 배우고,

테스터는 업무 로직을 배운다

- (기대효과)

커뮤니케이션이 좋아진다

결함을 잘못 잡는 일이 줄어든다

더 많은 결함을 잡을 수 있다

개발자는 초기 품질이 높은 코드를 테스트 의뢰한다

(잘못된 효과)

서로간의 불신 (서로 상대방을 말이 통하지 않는 사람 이라고 인식)

짝 테스트가 시간만 뺏고 별 도움이 안 되는 일이라는 인식

테스트에 대한 실망

짝 테스트 수행 절차(최초 예)

처음 할 때만 참조하고 그 이후부터는 자유롭게 수행

전반 15분

후반 15분

지시 (테스트 스킬 전달)

지시 (실제 실습)

역할을 바꾸어서 개발자가 테스트를 진행하게 합니다- 했던 것을 해보라고 하면.. 헉.

1) 짝 테스트의 목적과 방식을 설명합니다2) 테스터가 하는 방식을 체계화하여화면의 경우라고 하면, - 먼저 해당 화면이 무엇을 하는 화면이고, 어떤 경우가 있을지를 같이 고민- 전체 UI 뷰, UI 이벤트(새로고침, 사이즈 변경 등), UI 엘리멘트 정상 유무- 각 타입, 실제 필드에 대한 유효성- 각 이벤트, 기능 동작의 정상 유무- 확장된 테스트는 뭐가 있을지 논의

개발자의 설명(지시)가 제품 구석구석 숨겨진 기능까지를포함하는 경우가 많아 제품을 잘 배울 수 있는 기회가 됩니다

개발자

개발자

테스터

테스터

짝 테스트 수행 사례

- 개발자 6명과 3일간 30분씩 짝 테스트 수행,

- 결함 및 공통 이슈 사항 등 40여개

세션 짝개발자 일시 대상 수행 중 메모 후 이메일로 공유

1 A개발첫째날오전

역할관리 화면

[역할관리 - 조회](1) 화면 리사이즈시 데이터 영역이 잘리는 현상 있음(하단 스크롤로 끝까지 옮겨도 표시되지 않음)(2) (공통-검토필요) 현재 화면 위치를 왼쪽 메뉴에서 초록색으로 표시해 주는데 F5 새로 고침 시 초록색이 표시되지 않음(3) (권고) 조회조건에 역할의 사용여부로 조회할 수 있는 기능이 있었으면 편할 것으로 보임(4) 검색조건에 특수문자 입력이 가능하거나 타 화면과 달리 trim 처리가 적용/ 또는 미적용된 경우가 섞여 있음(5) (검토예정이라고 함) 역할명, 설명등을 주어진 길이만큼 입력하면 목록에서 ... 으로 표시됨.

툴팁이 표시되면 좋을 것으로 보임 * 수정팝업을 띄우면 표시되니 결함보다는 권고사항성입니다~[역할관리 - 추가](6) 입력 시 id, 명에 trim 처리가 필요할 것으로 보임.(조회시는 권고이나 등록/수정 시에는 trim이 필요)(7) (다른 화면도 체크 필요) 신규 추가시에 사용여부를 N으로 하고 저장해도 Y로 저장 됨 <- 쿼리에 'Y'로 박혀 있음[ 사용자 팝업1,2 ](8) 직급 컬럼 등의 정렬이 타 화면과 일치하지 않음 (가운데 정렬 필요)(9) 조회조건 필드가 특수문자는 막혀 있는데 trim 처리는 하는 등 타 검색 필드와 일관성 필요(10) “그거”라고 했던 건 - 체크박스를 선택하고 페이지를 이동하면 다른 페이지에서 선택하지 않은 건들이 선택되어 있는 등 이상 동작을 하는 경우가 발생 함

2 B 개발첫째날오전

업무그룹관리화면 내 팝업

[업무그룹 메뉴팝업](1) 팝업 화면 타이틀명에 공통적으로 언더바가 포함되어 있음(2) 여러 팝업에서 같은 항목의 정렬이 서로 다름

- 길이가 일정한 코드성 데이터는 가운데 정렬, 이메일, 설명 등과 같이 값이 가볍적으로 바뀌는 값들은 좌측 정렬이 맞을 것으로 보임(3) (확인필요) 화면 및 컬럼 폭 리사이즈가 안 되는데 길이가 길어질 수 있는 항목의 경우 툴팁을 검토할 필요가 있음(4) 메뉴에 대해 사용여부를 N으로 수정해도 타 화면 팝업에서 메뉴가 조회됨(5) (권고) 메뉴 추가에서 기존 추가한 메뉴와 새로 추가할 수 있는 메뉴가 구분이 안 됨. 방안 몇가지 얘기했던 것 검토 요청[사용자 팝업](6) 사용자를 선택하지 않고 선택 버튼을 클릭하면 메시지는 "한 건 이상을 선택해 주세요" 라고 정상 표시되나 바로 팝업 창을 닫아버림. 선택할 수 있도록 팝업 창 유지 필요(7) 각 항목들의 좌우 정렬이 타 화면과 다름(8) 팝업 화면 전체에 공통 발생 - 조회 데이터의 필드들이 모두 불필요하게 editable 함

3 C 개발첫째날오후

업무그룹관리메인 화면

[업무그룹관리](1) 업무그룹 ID에 한글이 들어갈 수 있으나 조건조회 해당 필드에 한글이 입력되지 않음(2) (확인필요-일관성) 신규 추가후 리프레시 될 때 추가된 건이 전체 페이지의 제일 하단에 표시되는데 타화면과 기준 논의 필요 <- 사용자 추가의 경우 해당 정렬 위치에

추가되었던 것으로 보임(3) (권고) 조회조건에 업무그룹의 사용여부별로 조회할 수 있었으면 좋겠음(4) 업무그룹ID 등에 trim처리를 해야 할 것으로 보임(5) "그거" 라고 했던, a) 목록 조회에서 전체 조회하여 여러 페이지 조회, b) 조회조건 입력 후 조회버튼이 아닌 끝 으로 이동 선택 => 아무 건도 조회되지 않음, c) 조회조건

삭제하여 전체 조회 => 전체조회는 정상적으로 되나 하단 페이지 숫자가 표시되지 않음.

4 D 개발둘째날오전

로그인,회원가입 / 사용자관리(일부)

[회원가입](1) 로그인 ID 값에 대해 trim 처리를 하지 않음(2) ID 입력, 중복체크 한 상태에서 사용자 이름을 입력하지 않고 저장하면 ID 중복 체크를 하라는 메시지가 표시 됨(3) 비밀번호, 비밀번호 체크에 대해 필수입력 표시 누락(4) (검토) 이메일, 전화번호에 대한 영문자 입력 등에 대해 체크 로직 적용에 대해 검토 권고

* ID, 비밀번호 생성 규칙은 반영 예정이라고 함[로그인] - N/A[사용자관리](5) UI 브라우저 리사이즈 시 사용자 관리만 하단 스크롤이 2개 생기는 현상 있음(6) 전체 화면이 아닌 경우 하단 footer가 페이지 네비게이션 영역을 덮는 현상 발생(7) (권고,공통) 왼쪽 메뉴 접기 아이콘이 있는데 접은 상태에서는 화살 방향이 반대여야 펼치는 기능으로 인지하기 쉬울 것으로 보임(8) 조회 조건의 사용여부 콤보박스 값이 직접 선택 및 수정이 가능함(9) 브라우저 리사이즈 시 조회 영역은 정상 확장되나, 하단 데이터 영역이 확장되지 않는 현상 발생(10) 사용자 정보 수정 팝업에서 필수값을 입력하지 않았을 때의 메시지가 ID중복체크를 하지 않았다는 잘못된 메시지 발생(11) (동시성) A 관리자가 사용자 정보를 수정(팝업)하고 있을 때 B 관리자가 해당 사용자를 삭제. 다시 A 관리자가 수정 저장하면 메시지 상으로는 정상적으로 수정되었다고

표시가 됨(해당 사용자는 삭제) - 서버 상에서 수정하려는 id가 없어서 정상 반환하는 현상 때문으로 보임.

5 E 개발둘째날오후

메뉴관리

[메뉴관리](1) 메뉴에 대해 사용여부를 N으로 수정해도 타 화면 팝업에서 메뉴가 조회됨(2) 메뉴 하위의 메뉴페이지 리스트에 대해 N으로 수정해도 Y로 다시 변경되어 조회 됨(3) 메뉴 하위의 메뉴페이지 신규 추가시 사용여부를 N으로 하고 추가하면 추가는 되었다고 메시지 표시되나

실제로는 저장 안 됨(4) 메뉴 페이지를 여러개 등록한 후 삭제하면, 삭제가 1,2건만 되고 이후 삭제가 되지 않음(5) 하나의 메뉴에 대해 동시에 다른 페이지에서 접근하는 테스트에 대해

A가 보고 있는 상태에서 B가 삭제하는 경우 A에서 다른 동작을 하면 "알 수 없는 에러가 발생하였습니다" 라는 상황을 파악하기 어려운 메시지가 표시됨

(6) UI 브라우저 리사이즈 시 조회 영역은 정상 확장되나, 하단 데이터 영역이 확장되지 않는 현상 발생

시스템에 결함으로 떨어지기전에 결함 조치의 기회를 제공.

개발자들의 만족도 높고“더 많은 시간, 상시 해 줬으면 좋겠다!!”

결함 발견에서 더 나아가개발표준 논의가 필요한 부분, 조치 방법 등을

옆에 있던 다른 동료들이 실시간으로 간섭(?^^)

※ 테스트 코드 짝 프로그래밍- 과제원은 특정 상황에서의 테스트 코드 작성 팁을 배우고, 테스터는 개발 소스를 배운다

- 테스터는 계속 품질 마인드를 개발자에게 주입(?) 한다

처음에는 개발하고 디버그해 볼 수 있게 기본적인 것만 짜고,개발이 다 끝난 후나, 이런저런 결함이 나올 때 테스트케이스를 추가하면 좋아요.

나중에 테스트 커버리지 툴 돌려볼거니까 그걸 참조해도되구요. 테스트 안 된 부분은 다 리뷰해 볼 거에요 (찌릿~)

이렇게 단위테스트를 잘 짜놔야 전체 품질이 견고해 져요

이거 꼭, 이렇게까지 많이 테스트 코드를 짜야 해요?

그럼 여기도 또 케이스 추가해야 해요?

I. 개요


1. 테스트 교육

2. 테스트 설계


4. 짝 테스트




V. 정리

개발 초기부터 테스트 수행 자동화

고객

과제관리자

과제팀

매일 테스트수행 현황 파악

오~홍~

우린 이렇게개발,테스트를잘 진행하고 있답니다

테스트가 별 문제없이잘 통과하는 구나

Junit 테스트 결과레포트

테스트 커버리지(호출, 라인, 조건

커버리지)

코드 인스펙션 결과(PMD 레포트)

※ Jenkins를 이용한 테스트 자동수행 환경 구축

한 번 해 보고 나니,그 다음부터는 쉽더라구요.

I. 개요



1. 테스트 전략(계획)수립

2. 테스트 결과 분석

3. 전문적인 서비스 제공


V. 정리

테스트 전략 수립

(사례 1) 클라이언트 – 서버 사이드로 구성된 제품

- 테스트를 단위, 통합1(서버/클라이언트 별), 통합2(서버-클라이언트 연동)로 구분하고

각 레벨별 수행 목적과 수행 대상, 방법을 상세히 정의

사용자 환경

단위테스트

통합테스트1

통합테스트2

인수테스트

각 메소드(또는 단위 기능)에 대해다양한 예외 상황을 만들어 면밀히 테스트

서버, 클라이언트 각 영역 안에서여러 단위기능들의 묶음에 대해 기능 흐름을몇 가지로 정의하고 테스트

서버 - 클라이언트 간의 상호 연동 관점에서기능 흐름을 몇 가지로 정의하고 테스트

XXX개XXX개

X개X개

XX개XX개

????

사용자 관점(사업부)에서 제품을 어떻게사용할지 흐름을 정의하고 테스트

클라이언트 서버

모듈A

모듈B

모듈C

모듈D

모듈E

모듈F

단위테스트

인수테스트

통합1

통합1통합2

(사례 2) Cascading 프레임워크 기반의 동적 워크플로우 생성 엔진

- 테스트 대상의 기술적, 업무적 특성에 따라 단위와 통합 테스트를 정의하고 각 레벨별 테스트 접근

단위 테스트: 하나의 Pipe에 대해 상세히 테스트

통합 테스트: Source에서 Sink(또는 실패종료)까지 임의의 흐름을 테스트

(사례 3) 하드웨어-소프트웨어 통합 형태의 제품

- 기술적 특성 및 전체 시스템 중 담당 영역에 다른 단위, 통합, 실장 테스트 등의 구성

테스트테스트테스트테스트 구분구분구분구분소프트웨어소프트웨어소프트웨어소프트웨어 테스트테스트테스트테스트

(단위단위단위단위 테스트테스트테스트테스트)테스트테스트테스트테스트 보드보드보드보드 테스트테스트테스트테스트

(통합통합통합통합 테스트테스트테스트테스트)모의모의모의모의(랩랩랩랩)테스트테스트테스트테스트 실장실장실장실장 테스트테스트테스트테스트

설명

내부 자바 프로그램에 대한

단위테스트

어플리케이션 인터페이스

관점에서 사용 흐름에 따른

테스트

축소 모형 기반 모의 테스트 실제 환경 또는 테스트

환경에서 테스트

수행방법

Junit 테스트 시나리오 기반으로

매뉴얼 테스트

매뉴얼(테스트 시나리오) 매뉴얼

수행주체

과제팀 과제팀, 3자 사업부/과제팀 사업부/과제팀

어플리케이션정보파일

센서,하드웨어

I. 개요







V. 정리

테스트 결과 분석 및 자산화

테스트 결과에 대한 상세한 분석 테스트 노하우, 산출물 등에 대한 자산화

I. 개요







V. 정리

[ 테스트 요구사항 상세화 ]

- 각 테스트 관련 요구 지표(알고리즘 신뢰도, 성능 등) 확인

- 측정 방법, 기준 상세화

[ 과제성격 별 테스트 전략 수립 ]

- 소프트웨어/하드웨어, 서버/클라이언트 등의 구성에서

개별/통합 관점의 테스트 접근

- 테스트 설계에 대한 리뷰 및 보완 프로세스

[ 표준 작성 항목 ]

- 테스트 목적, 단계 정의

- 입/출력 산출물, 시작/종료 조건

- 테스트 환경

- 역할과 책임

- 테스트 일정

테스트 계획서, 시나리오 등 필수 작성 산출물에 대한 양식, 작성 가이드, 초안 작성, 리뷰/보완 등 수행

테스트테스트테스트테스트 계획서계획서계획서계획서

품질/테스트 체계에 따른 산출물 양식 제공, 작성 가이드

기능기능기능기능 테스트테스트테스트테스트결과서결과서결과서결과서

표준화된 테스트 서비스 수행

3자 테스트 수행 및결과 공유

상황에 따라서는 연구과제에 대한외부 공식적인 테스트 대행(사례: 연구과제에 대한 출하검사 등)

제품제품제품제품 품질품질품질품질 결과서결과서결과서결과서. 기능 테스트 점수. 성능 테스트 점수

. 보안 정적 검사 P/F. 오픈소스 라이센스 점검

. 코드 인스펙션 점검

I. 개요




1. 고객과 과제팀 간의 브릿지 역할

2. 개발/테스트 코드 리뷰

3. 코드 인스펙션

4. 공통 서비스에 대한 창구 역할

V. 정리

테스트를 통한 고객(사용할 개발자)과의 커뮤니케이션

- 테스트를 가능한한 보기 쉽고, 이해하기 쉽게 표현하여 고객(사용자)이 설계,개발, 테스트 단계에

빨리 개입할 수 있도록 여러가지 방법으로 시도

고객

아~~ 이런이런테스트를 하(려)고 있군

주석 -> 테스트 명세 생성 툴 적용- 가독성이 낮은 테스트 코드에 주석으로 설명을 달고 이를 테스트 결과와 함께 웹 상에서

바로 확인할 수 있도록 제공(툴 자체 개발)

…

고객

아~~ 상세하게 어떤 테스트인지설명이 있구나

작성자@author

@Desc

@Step

@Input

@Expected

@Name

@TC_ID

자동생성자동생성

테스트 코드의 주석 작성다른 개발자 개발리더,

테스트

I. 개요




1. 고객과 과제팀 간의 브릿지 역할

2. 개발/테스트 코드 리뷰

3. 코드 인스펙션

4. 공통 서비스에 대한 창구 역할

V. 정리

개발/테스트 코드 리뷰

- 별도로 테스트 코드 리뷰를 수행하고 내용 공유

- 업무 분석을 위해 개발코드를 리뷰하고, 의견 공유

테스트 코드 리뷰 사례 (타과제)

- 테스트 케이스(메소드) 이름은 test{테스트대상}_{테스트목적}_seq 로구성해 주세요

- 테스트 케이스는 정상 수행 이외에 여러 개를 따로 추가할 수 있습니다. 하나의 테스트 케이스에서 여러 목적을 테스트하지 말아주세요

- 테스트메소드(케이스) 에는 보통 throws Exception 을 붙여서Exception을 테스트하는게 아닌거면 내부에서 try,catch를 하지 않아도됩니다

- Exception 발생을 테스트하는 경우에는 기대한 정확한 XXException만잡도록 하고, 해당 라인 다음에 fail문을 추가해서 정확히 원하는 위치에서Exception이 발생했는지 확인합니다

- 파일 리소스 같은 경우 상대경로로 참조하게 설정해야 하니, 제공한유틸리티를 활용해 주세요

개발 코드 리뷰 사례

- toString에 넣을 값이 없는 경우에라도 null 이 아닌빈문자(””)가 반환되도록 해 주세요

- 해당 부분은 테스트 커버리지가 안 나오는데 테스트 해 보니흐름상 이미 동일한 체크가 있어서 절대 발생할 수 없는부분이네요. 검토해 주세요

- 이 부분의 catch는 해당 Exception의 상위 Exception으로catch해도 될거 같습니다

- 테스트를 실행해 보면 특정 경우에 null 이 반환되는데 다른클래스에서는 이에 대해 처리 로직이 없습니다

개발 초기 코드 또는 기존 과제에서 자주 위반된 룰 소개

개발 초기부터 코드 인스펙션 툴(PMD) 적용 및 조치 가이드

- 개발 초기부터 PMD(코드 인스펙션 툴) 수행 및 설명

- 불필요한 개발 코드, 에러를 유발할 수 있는 개발 코드 등

Top 10, 해당 룰에 대한 상세 설명

PMD, 보안, 성능 등전사 지원 프로세스 문의

품질/테스트Shared 지원인력

과제팀

기술그룹 內內內內 Shared SA

테스트랩 Fortify 점검지원인력

기술그룹 內內內內 Shared SA

PMDPMD

보안보안

성능성능

PMD 룰커스터마이징 회의

Fortify 정적 점검 회의

성능테스트결과 검토 회의

. 웹 페이지의 응답속도 측정할 수 있는 툴은?

. 자바스크립트 테스트 방법은?

. R-PVR은 무엇이고, 왜 받나요?

. 이 과제는 테스트 대상인가요?

기능 테스트 외 타 서비스 정보 제공, 브릿지 역할

- 과제 팀에 전사 지원 프로세스, 알고 있는 타 사례 등 공유

- 지원조직의 서비스 카탈로그 안내 및 타 과제 지원 받은 사례 공유

I. 개요




V. 정리

1. 과제 팀의 회고

2. 전하려는 메시지

3. 테스트의 캐리어 패쓰

� 과제 팀의 회고들 1

영역 좋았던 점 나빴던 점

C 처음 테스트 교육 들으면서 TDD를 할 수 있을거 같았다PMD 룰 보면서 코딩 스킬을 많이 배웠다

TDD 이상과 현실사이(재사용 안 되더라)

D 결과가 잘 나와서(끝나서) 좋다테스트 시나리오 짜면서 엔진이 명확해 지고이해할 수 있어서 좋았다

일정이 너무 짧다문서 변경 및 현행화하기가 어려웠다

E 테스트, PMD 하면서 개발 스킬이 많이 늘어한층 성숙해 질 수 있었다

일정이 너무 짧았다

G 처음에는 테스트 지원 인력이 와서 뭘 할 수있을까 했는데 하면서 정말 우리 product 품질을 높일 수 있는 기회가 되어 좋았다

일정.ㅠ.ㅠ테스트 시나리오를 개발 다 끝난 다음이 아니라미리 작성했었으면 좋았을 거 같다.

H(과제PM)

다음에 과제하게 되면 과제 초반부터 같이하면 좋을 거 같다. 원래 애자일을 안 좋아하는데이번처럼 특정 주기에 사전에 정했던 테스트활동은 괜찮은 거 같다.

“알고리즘을 모르는 테스트 인력이 뭘 할 수 있을까 생각했으나,내가 만든게 무엇인지 잘 이해하고 테스트할 수 있게 지원해 주었다”

과제 팀의 회고들 2

[ 짝 테스트 ]

(좋았던 점) 미처 생각지 못한 버그도 찾아내주신 점, 짝테스트는 Junit보다 화면 테스트할 때 도움이 많이 되었습니다

다른 사례에서 비슷한 문제의 해결방법에 대해서 들은 것이 좋았습니다, 짧은 시간에 버그를 많이 잡아주신 점

(아쉬운 점) 짝테스트 30분은 시간이 좀 짧아서 아쉬웠습니다

[ 테스트 케이스 보완 ]

(좋았던 점) 보완한 것을 보고 보완하니 하기가 수월했어요, 테스트를 더 상세하게 보완해 주신점

(아쉬운 점) 내부적으로 테스트 설계를 변경했는데 이 부분이 공유되지 못한 점이 아쉬워요

[ 테스트 코드 짝 프로그래밍 ]

(좋았던 점) Junit 테스트 코드를 어떻게 코딩해야 되는지 알려주어 좋았습니다,

JUnit 샘플과 방법을 보고나니 테스트코드 생성이 너무너무 수월했습니다

(아쉬운 점) 제가 사전 지식이 별로 없어서 준비가 많이 안 됐던 것 같아요

[ 그 외 하고싶은 말은 ]

(좋았던 점) 각 활동마다 30분 씩 시간 맞추어서 하신 점도 정말 좋았습니다

(아쉬운 점) 테스트시 커맨더랑 아바타가 아니고 같이 동작해보고 얘기하는 시간도 있으면 좋을 것 같습니다

개발자끼리 짝 테스트를 하면 매일 하던 방법으로 테스트 하게 될거 같습니다. 계속 같이 해 주세요

전하려는 메시지

과제팀과제팀 테스트테스트 고객/사업부고객/사업부

테스트 강화로 제품의 기능& 품질 확보

관련 프로세스,산출물 가이드로 과제 자체에 대해 더 집중가능

코드 리뷰, 단위테스트 방안 가이드로개발 관점의 품질활동 수행

개발 시작부터 3자(사용자) 관점에서지속적인 피드백으로 협업

다양한 테스트 프랙티스에 대한 적용 경험 축적(소규모 과제)

개발 마지막에만 하는 테스트가 아니라개발 초기부터 능동적이고 적극적으로하는 테스트 수행

개발팀-고객 사이에서 가교 역할

기본 품질이 확보된제품 딜리버리

테스트 내용 (실시간)공유를 통해 제품에 대한 상세한 파악가능

제품에 대한 고객 관점의 피드백 제공 가능

win-win win-win

제품에 대한 쉬운 이해

고객이 원하는 제품 딜리버리

제품에 대한 쉬운 이해

고객이 원하는 제품 딜리버리

테스트의 역할 확대

개발팀테스트

고객

개발(팀)을 못 알아주는테스트팀.ㅠㅠ

고객의 맘을 안 알아주는개발팀.ㅠㅠ

산출물도 없고, 물어봐도잘 알려주지도 않고. ㅠㅠ

AS-IS

개발팀테스트 고객테스트

고객을 대신해 주는테스트팀.굿.굿

나를 도와주러 온테스트팀. 굿.굿.

개발팀과 함께하며 제품을 위해 같이 협업하는 보람

고객의 관점을 알고 능동적으로 참여하는 보람

TO-BE

테스트의 캐리어 패쓰를 다양하게

- 개발 프로젝트의 다양한 역할자처럼, 테스트도 다양한 역할을 가질 수는 없을까?

Test Architect

. 기술적인 리더쉽을 제공하고 그들의 테스트 조직에 전략적인방향을 제시

. 기술적인 assistance와 advice를 테스트 매니저에게 제공한다

. 오랜 기간의 큰 이슈를 풀 수 있는 방법을 고안

방법론전문가,

SA,TA,DA,…

개발자

PM

PL

툴 지원인력

개발 프로젝트

Test Roles Description

Test Manager. 프로젝트의 모든 테스트 관리 활동 조정

. 시간과 예산 내에서 테스트 업무의 품질 목표 달성 책임

. 마스터 테스트 계획의 수립

Test Engineer. 테스트 설계

. 테스트 자동화 리드Test Lead,

Senior Tester. 매뉴얼 테스트 리드

Tester . 테스트 수행(Manual, Automation)

테스트 역할자

테스터 테스트 리더

테스트 엔지니어 테스트 아키텍트

테스트 매니저

테스터

TM

TL

테스트 프로젝트

전략 수립 지원

테스트 툴 교육

Manual, Automation가이드 지원

Q & A외부인력이 테스트 설계를 할 수 있을까요? ROI가 나올까요?

(단위)테스트 코드는 개발자가 작성해야 하는데굳이 우리가 관여할 필요가 있나요?

이 많은 걸 나보고 다 하라는 건가요?

내용 중에 잘 전달이 안 됐을 수 있지만 테스트 설계는 개발팀, 또는 고객이 주도적으로하는게 핵심입니다. 테스트는 이들이 테스트 설계를 하고 같이 리뷰할 수 있도록시작 포인트와 수단을 제공하는 역할이고, 테스트 관점의 뷰를 계속 제공합니다

여전히 단위테스트는 개발자 스스로 하는게 맞습니다. 다만 (어떤) 테스트 관련된활동이 있다면 테스트 역할자가 보고 더 잘 할 수 있도록 피드백을 주는 건 필요하다고생각합니다또한, 이 과정에서 테스트 역할자도 많이 배우게 됩니다

절대 그렇지 않습니다. 다양한 테스트 활동을 소개하는게 이 발표의 메인 취지입니다.테스트에도 여러가지 일이 있고, 저희도 여러 사람이 있으니, 각자에게 맞고 좋아하는활동을 선택해서 각각을 잘 발전시켜 나갈 수 있었으면 좋겠습니다.

감. 사. 합. 니. 다.

Software

개발이 테스트를 만났을 때(Shift left testing)