테스트개선지원 사례 - 웹어플리케이션대상
TRANSCRIPT
테스트 개선 지원 사례: 웹 어플리케이션 대상(재사용 코드)
2015.05 by JungGunhome: genycho.blog.me
What?
- 조직/프로젝트에 대해 약식화된 테스트 진단을 수행
- 프로세스 관점뿐만 아니라 아키텍처 관점에서 개선 전략을 수립
- 중요도와 소요시간을 고려하여 단기, 중/장기 개선 계획을 세우고
단기 개선을 협업한 사례
- 실제 수행하고,
수행한 사람, 수행당한(?) 사람들의 회고를 담고 있음
- 목차 -개요테스트 현황 진단단기 개선 내용 (수행)중장기 개선 내용(계획)정리
테스트 강화를 위한 지원 요청
- 솔루션 사업을 진행하며 막연히 품질/테스트를 강화해야 한다는 생각
- 하지만 무엇을, 왜, 어떻게 강화해야 하는지, 어떻게 시작해야 하는지
알지 못함
전반적이고 포괄적이면서 선도적이고 영구적인 그… 무언가… 헉… 어렵다.
저희 제품에 품질 이슈가 많이나오고 있습니다. 전문가로써테스트 지원을…
구체적으로 어떤 테스트 지원을?
지원 전략테스트 전반에 대한 현황 파악 및 단기, 중장기 개선 계획 수립1개월 지원 후 추가 진행 여부 판단
테스트현황 파악
개선 우선순위선정
개선 계획 수립(단기, 중/장기)
단기개선 수행
성과 평가 중/장기개선 수행내용 공유
1개월
기존 진단 모델
의 테스트 영역 을
참조하여 현 상황
파악
현재 레벨->다음
레벨 개선을 위해
필요한 테스트 영
역 식별(개선 중요
도)
식별된 영역 중 개
선하기 가장 쉬운
것부터(개선 난이
도) 상세 개선 계
획을 수립
진단 내용 공유(조
정),
단기 개선할 내용
에 대해 공유하고
착수
가능한 일정(3월
까지)안에 적용할
수 있는 형태로 단
기 개선 계획을 세
우고 개선 수행
수행 내용이 의미,
효과가 있었는지
리뷰하고 중/장기
개선 안에 대해 효
과, 수행 방안 등
을 논의
대상 프로젝트 개요- 공통 자산화 중인 관리자 포털
다음의 공통 기능을 지원. 사용자 관리. 메뉴 관리. 역할 관리. 그룹 관리 (업무그룹). 공통코드 관리. 접속(로그인) 이력 관리
- 개발환경 및 아키텍처
깃든샘문서 공유
Jenkins로 빌드(매일)빌드 서버
Git소스 공유
H2(메모리 DB), 확장제공(오라클, MySQL 등)DB
MyBatis + AnyframeJava + AnyframeUI(JQWidget)프레임워크
자바 (J D K 1.7)개발언어
내용항목
진단모델의 대항목 기준 약식 진단 (약식 체크리스트 + 인터뷰)- 현수준 : Initial0 -> Initial1
테스트 영역 Initial Activated Managed
1. Methodology & Standard Guide 방법론 및 표준 가이드
2. Test Strategy & Test Planning 테스트 전략과 계획
3. Commitment & Communication 커뮤니케이션
4. Test Organization 테스트 조직
5. Test Training Program 테스트 교육 프로그램
6. Test Lifecycle 테스트 라이프 싸이클
7. Test Design and Execution 테스트 설계 및 실행
8. Peer Reviews 동료 검토
9. Non-functional Testing 비기능 테스팅
10. Regression testing 회귀 테스팅
11. Defect Mgmt. 결함 관리
12. Test Process Mgmt. 테스트 프로세스 관리
13. Test Measurement 테스트 측정
14. Test Skill & Tools 테스트 스킬과 툴
15. Test Environment 테스트 환경
16. Testware Mgmt. 테스트웨어 관리
개선계획 수립 1/2개선 우선순위
개선 중요도
개선난이도
1순위
9.비기능테스팅
쉬움
어려움
11.결함관리
2.테스트 전략과 계획
3.커뮤니케이션
4.테스트 조직6.테스트 라이프 싸이클
15.테스트 환경
7.테스트설계및실행
10.회귀 테스팅
8.동료검토
보통
개선계획 수립 2/2- 단기, 중/장기로 계획 수립
테스트 영역7.테스트설계및실행
10.회귀 테스팅
11.결함관리15.테스트 환경
9.비기능테스팅
8.동료검토3.커뮤니케이션
2.테스트 전략과 계획
6.테스트 라이프 싸이클
4.테스트 조직
개선 방안
- 현재별도의테스트 활동이없음. (※조직의특성이나 규모상별도의 테스트조직이나프로세스를거창하게 잡기는어려워 보임. 개발팀 자체크로스 테스트, 버그헌팅 등의활동 검토)
- 테스트시나리오작성(테스트를어떻게 할 지미리 고민하면서흐름도 정제)
- 테스트 실행도UI레벨에서개발자의 자체테스트 외에는다른 활동이없는데 상세수준에서테스트를 보완
-변경에 따른회귀 테스트자동화 적용 검토
-자산으로 향후사용되는 현장프로젝트에가이드 될 수있는 회귀 테스트셋을제공했으면…
- 명시적인테스트 활동 및이 과정에서의결함관리가 되고있지 않음우선적으로는
결함을 등록하고공유하는수준으로 결함관리를 접근
개발 환경이 아닌테스트를 위한별도의 환경이구성되어야명시적인 테스트활동, 결함의 발견, 재현 등이 가능함
성능, 멀티브라우저호환성, 웹 접근성등 재사용모듈로서비기능적인요구사항을만족하도록 하는테스트 수행
* 해당 항목은Initial 레벨의개선항목은아니지만 조직의특성 상 동료간의검토가 쉽고 타개선 활동보다 그효과가 클 수있어서 개선영역으로 선정 함
테스트 진단 모델상으로는기본적인항목이나조직이나 모듈의특성상 고객, 개발자, 분석/설계자, 테스터라는다양한 역할자가존재하지는않아서우선순위를 다소낮게 선정 함
마찬가지로 진단모델 상으로는중요도가 높지만조직의 특성 상우선순위를 낮게선정함.
재사용모듈 및깃든샘 시스템에대해 테스트전략과 이에 따른상세 절차 수립이필요 함
과제 시작과함께 테스트절차가 정의되고같이 진행되어야함
테스트 담당자등의 테스트를수행하려는 역할, 조직이 필요 함.
초기 단계에서는별도의 테스트전담 인력 외에기존 개발자 중에특정 역할을겸직하는 경우도가능 함.
중,장기 개선
단기(1개월)
아키텍처 레벨 개선 전략
- 1순위 : UI 레벨에서 개발자와의 짝 테스트 설계/수행
2순위 : 내부 스프링 서비스 레이어에서 Junit 단위테스트
3순위 : RESTful API 레벨에서 API 테스트
RDMBS
DAO implementations
DAO interfaces
Service implementations
Service interfaces
Other remote interfaces
Data AccessLayer
ServiceLayer
PresentationLayer
개별 화면에 대한 매뉴얼 / 자동화 테스트
Controller에 대한 테스트
Service에 대한 테스트
DAO 에 대한 테스트
Controller
REST API
RESTful API 테스트UI
√
11
22
33
44
55
√
√
우선순위 : 중DAO가 SQL문을 실행해 DB에 CRUD 기능을 수행하는측면에서 별도 테스트가 필요
우선순위 : 상사용자의 요청에 대해 비즈니스 로직 및 DAO를호출하여 실제 해당 기능을 수행하는 주요 클래스로별도 테스트가 필요 함
우선순위 : 하Controller 자체는 UI의 요청 값을 Service에잘 전달하기 위한 목적으로 Service 레벨 테스트와 비교해봤을 때 테스트 방법이 어렵고 유지보수가 어려워 중요도
가 떨어짐
우선순위 : 상재사용 모듈 및 다양한 클라이언트 방식(웹, 폰 등)을 지원한다는 측면에서 REST API 레벨에서의테스트 강화가 필요 함
우선순위 : 상화면 매뉴얼 테스트는 현재 품질이 떨어진다는 측면에서가장 강화가 필요한 영역임. 이후 항구적인 테스트 수준향상을 위해 테스터-개발자 짝으로 테스트를 진행할 필요 있음
우선순위 : 중화면 테스트 자동화는 재사용 모듈로서 BP관점에서 적용할 가치가 있으며,멀티 브라우저 테스트 자동화를 통해 테스트 공수를 크게 절감할 수 있음
1. 단위 테스트 개선 - JUnit
- 단위테스트(Service Layer)
1순위로 Service 레이어에 대해 Junit 테스트 코드 작성 가이드
테스트 코드 구성
FaroServiceTestCase- 테스트 수행 전 스프링프레임워크의 설정 파일 로딩- 매 테스트 후 테스트 이전 상태로DB 초기화- 특정 쿼리문을 직접 수행 가능한인터페이스 제공 등
SampleServiceTest@Autowired로 객체 주입 후- 기본적인 테스트- 다른 흐름 테스트- 잘못된 키 값 등의 테스트- 필수입력 누락 등의 테스트…
SampleTestData- 테스트에 사용되는 데이터를분리하여 다른 테스트에서도참조할 수 있도록 정의(추가로 엑셀 또는 DB에서가져올 수 있게 보완 가능)
기본 교육(2015.02.25)
소스 파악 및테스트 구조화
실제 코드대상샘플 코드 작성 상세 가이드 짝 프로그래밍
(테스트 코드)
‘짜장면’을 만들며배우는 테스트 기본과정(1일)
CodeMngService- 코드 전체 조회- 코드 검색- 코드 등록, 수정, 삭제…
AbsractTestData- 테스트 데이터를 DB, 엑셀 등으로부터 관리할 수 있도록 지원하는 추상 클래스
짝 프로그래밍(대상: 테스트 코드)
총 7명 대상, 각 30분씩
짝짝짝짝 개발자개발자개발자개발자 일시일시일시일시 대상대상대상대상 Service 내용내용내용내용(요약요약요약요약)
A3/17(화) 13:00
메뉴관리
. 유효하지 않은 키로 삭제 시도했을 때의 수행 결과등 추가 케이스 식별
. assert문 추가를 통한 상세 결과 검증
B3/19(목) 14:30
업무그룹관리
. 검색/조회, 삭제 등에 대한 추가 케이스 식별
. assert문 추가를 통한 상세 결과 검증
. 수정, 삭제 등 기능수행 시 필수 키 값이 누락되어도 정상수행(건수 0)된 것처럼 동작하는 건 등에 대한 요건
C,D,E3/19(목)15:00
로그관리
F3/19(목)15:30
업무그룹 사용자관
리
G3/20(금)10:30
업무그룹 관리
. assert문 추가를 통한 상세결과 검증
. 기능 수행시 필수 키 값이 누락되어도 정상수행으로 보이는현상 공유
H3/20(금)11:00
역할관리. 삭제 수행 시 연관된 2개 테이블의 데이터도 같이 삭제되는지 확인하도록 테스트 코드 보완
짝 프로그래밍 주요 내용(0) 가장 기본적인 테스트 케이스만 작성하여 추가 케이스 작성
(1) (필수) 값이 없는 경우 어떤 Exception이 발생하는지와 이에 대한 체크 테스트
(2) 다양한 상황에 대한 동작 확인 테스트
- 기존 등록한 내용(코드명 등)과 동일한 내용으로 등록할 때
동작 확인
- 업데이트할 때 해당 키가 존재하지 않을 때 동작 확인
- 삭제할 때 해당 건이 존재하지 않을 때 동작 확인
- 삭제할 때 키 값에 아무 것도 넣지 않고 시도했을
때의 동작 확인
(3) 스프링프레임워크가 제공하는 유틸리티를 이용한 테스트 방법
- CRUD 수행 시 DB에 직접 쿼리한 결과와 수행 결과 비교
(예: insertSaveCodeInfoTest_01 - 등록 전 23건, 등록 후 24건인지 확인)
(4) 테스트 코드 주석 가이드
(어떤 테스트인지 표시하고 향후 자동으로 명세서 및 결과 보고서가 생성되도록 툴 적용 예정)
DB상의 NOT NULL누락 시 H2 DB에서 임의의값으로 변환하고 Exception이 발생하지 않는 것으로 보임서버단에서 로직 상의 필수 값은 체크하지 않음
서버단에서 별도 체크 없음
별도 Exception을 발생시키지 않고 성공한 것처럼 리턴
임의의 값으로 변환한 후 성공한 것처럼 리턴(위와 같음)
※ 제품 특성을 고려했을 때의 서버단 이슈사항
화면
RDMBS
DAO implementations
Service implementations
업무그룹 조회(키: 업무그룹 sq)
서버단에 해당 키 없이 조회, 삭제등을 수행하는 경우 0건 등으로 정상 수행하고 특정 알림 없이 진행
등록 등에서 필수 값을 안 넣는 경우 DBMS레벨의 SQLException이발생 -> 화면단에서는 전체 에러페이지 등으로 구분이 안 될 것으
로 보임
파라미터가 아예 없음
파라미터는 있는데 값이 null
파라미터는 있는데 값이 빈 값
서버 단은 독립적으로 품질 수준을 갖춰야 하는가?서버 단은 독립적으로 품질 수준을 갖춰야 하는가?
파라미터는 있는데 값이 맞지않는 값(포멧?, 다른 테이블의 유효값?)
현재 대부분의 체크 로직 등이 UI에만 존재하는데 서버 자체적으로도체크 및 정의된 Exception 으로 처리를 해 주어야 함
현재 대부분의 체크 로직 등이 UI에만 존재하는데 서버 자체적으로도체크 및 정의된 Exception 으로 처리를 해 주어야 함
2. RESTful Open API 테스트 개선 - RestAssured
제품의 Restful API 요건- 서버의 기능을 RESTful 웹서비스 방식으로 구현하여 다양한 클라이언트에 동일한 기능을 제공
- 클라이언트는 각 API별로 정해진 형태에 맞게 호출 및 결과 확인
- API 영역 테스트를 위해 Junit 기반의 REST Assured를 이용
웹 UI
스마트폰 앱
RDMBS
DAO implementations
DAO interfaces
Service implementations
Service interfaces
Controller
FARO 서버
REST API
코드 검색 기능을 호출하기 위해서는 아래 URL 및 POST방식,
정해진 파라미터를 JSON 형태로 넣어 호출
. URI : http://xxx/admin/codeMgn/searchCodeInfo
. 방식 : POST
. 요청 BODY(JSON)
- codeNm(검색할 코드명)
※ REST Assured란 ?- 오픈소스, RESTful 웹 서비스 방식을 지원하는 테스트 툴
- REST API를 Junit 에서 쉽게 호출 및 검증할 수 있음
- 사이트 : http://code.google.com/p/rest-assured/
( 예 ) get 방식으로 /lotto 요청했을 때 다음과 같은 응답(JSON)을 받았다고 하면
Junit 코드에서는 get(“/lotto”) 로 호출하고 그 결과 값에 대해 다양하게 확인 가능
REST API 테스트 PILOT 수행- 코드 관리 > 수정 API 에 대해 테스트 수행(※ 다른 API까지 전체 확산은 일정 및 표준 수립이 먼저 필요한 부분이 있어 보류 함)
. TC명 : 기본01
. 설명 : 키값은 CodeSq 이며, 모든 파라미터에 기본 값을 넣고 수정
. 기대결과 : 200 성공, . 실제결과 : 성공
. TC명 : 기본02
. 설명 : 존재하지 않는 키값(CodeSq=INV_000000)
. 기대결과 : 400(상세에러코드 : BAD REQUEST 또는 존재하지 않는 키값입니다). 실제결과 : 200 정상 반환
. TC명 : 기본03
. 설명 : 코드명을 제한 길이보다 길게 입력하는 경우(30바이트에 50바이트 초과). 기대결과 : 400(상세: BAD REQUEST 또는 파라미터 길이가 유효하지 않습니다. 실제결과 : 500(DB 에러가 그대로 반환)
. TC명 : 기본04
. 설명 : 필수입력(CodeNm 등) 이 빈값”” 으로 수정하는 경우
. 기대결과 : 빈 값으로 수정되어야 할 것으로 보이나, 기존 입력 값으로그대로 유지 됨. 실제결과 : 기존 입력 값 그대로 유지
. TC명 : 기본05
. 설명 : 요청 BODY 없이 요청하는 경우
. 기대결과 : 400(상세에러코드 : BAD REQUEST)
. 실제결과 : 400 에러 코드 반환되나, 응답에 html 에러 페이지가Response에 담겨서 반환 됨(확인 필요)
테스터
서버
REST API
웹 화면
[URI]: http://서버IP/faro/admin/codeMgn/saveCodeInfo[Method]: POST[요청값]codeSq: codeNm: codeDescription: codeLevelNo: codeOrderNo: parentCodeSq:
REST API 테스트 구성
[ 테스트 프로젝트 ]
[ 테스트 수행 결과 ]
DefaultClassRestAPITestCase
- 호출 IP 설정기타 공통 작업 수행
UpdatecodeInfoAPITest
test01updateCodetest02UpdateInvalidCodetest3UpdateInvalidCodetest04UpdateNotEnoughCodetest05UpdateNoCode
CodeMngRestAPITestCase
- 테스트 setUp을 위한 insert call, tearDown을 위한 delete call- 수정 후 수정된 값을 확인하기 위한 search call 등
[ 테스트 케이스 예 ][ 테스트 클래스 구성 ]
REST API 주요내용※ “코드관리>수정” API에 대해 Pilot 으로 수행하였으며, 현재 추가 수행은 보류
※ Pilot으로 수행한 별도 이클립스 프로젝트는 압축하여 파일 형태로 전달 예정
- 향후 클라이언트 개발을 위해 API 정의서가 제공되어야 할 것으로 보임
(PILOT 수행 시에는 개발되어 있는 화면에서 호출한 후 SoapUI 테스트 툴의 부가 기능을 이용해
REST API 호출 정보를 가져와서 수행 함)
- 서버의 REST API 레벨에서 자체적인 에러 처리가 필요함. 이에 따른 응답(에러)코드 정의가 필요 함
- 현재 POST 방식이 아닌 다른 Method(PUT, DELETE)를 선택하는 경우에도 기능을 정상 수행하는데
다른 Method 호출을 막아야 할 것으로 보임
- 현재 REST API에 대한 인증/보안/권한 체크 등이 누락되어 확인하지 않음
※ REST API Best Pracitce 중 일부- METHOD 종류(GET/POST/PUT/DELETE)를 알맞게
http://www.restapitutorial.com/lessons/httpmethods.html
- URL 주소는 자원(RESOURCE)에 맞게http://www.restapitutorial.com/lessons/restfulresourcenaming.html
- 에러코드를 적절히 설정(예: 400 Bad Request)http://www.restapitutorial.com/httpstatuscodes.html
코드 수정 API에 대한 결함 내용
(1) 존재하지 않는 코드(CodeSq)에 대해 수정 시도 시 200 정상 수행 코드가 반환 됨.
적절한 에러코드 및 상세 메시지를 통해 클라이언트에게 적절한 동작을 가이드 할 수 있어야 함
(2) DB에서 허용된 값보다 긴 입력 값으로 요청 시 500 에러코드 및 DB 에러 메시지가 그대로
리턴되는데 DB에러에 대해 내부에서 별도 Exception 처리 필요
(3) 코드 수정 기능 수행 시 코드명에 빈 값(“”)을 입력하면 입력한 빈 값으로 수정되지 않고 기존 값이
그대로 남아 있음. 상세 원인 파악 필요.
(4) (추가 확인 필요) 요청 Body가 존재하지 않는 등 잘못된 요청을 할 때 응답에 특정
HTML (에러 페이지)이 담겨져 반환되는데 의도한 부분인지 확인 필요
※ 일반적인 REST API 명세서 구성
- 클라이언트 개발자를 위한 API 명세서
- 클라이언트를 위한 상세 응답코드 및 메시지 정책
RESTful API스펙
API 설명
입력 파라미터 정보 (이름, 타입, 필수여부, 설명 등)- query 파라미터- Body(JSON / XML)
URI 및 METHOD 타입
출력 파라미터 정보 (이름, 타입, 필수여부, 설명 등)
호출 URI 샘플
파라미터 샘플
출력 결과 샘플
응답 코드 설명
[ 일반적인 REST API 스펙 문서 구조 ]
3. 테스트 설계(시나리오) 개선
현행 요건 파악을 위한 흐름 도식화
[ 흐름을 도식으로 표현하여 관련자와 확인 ]
테스트 설계 보완 절차개발팀이 사전에 작성한 테스트 시나리오가 있었으나 단순 사용자 매뉴얼 수준
과제팀이 작성한테스트 시나리오
양식, 시나리오 작성 목적작성 팁, 추가 검증 항목(절차, 기대결과 보완)
(1) 각 업무(사용자관리, 역할관리, 업무그룹관리 등)별
테스트 시나리오 외에 업무 통합 관점의 테스트 단계 식별 및 시나리
오 작성
(2) 기능 설명서가 아닌 실제 테스트 실행을 위한 시나리오가 되기 위
해
테스트 데이터와 상세 기대결과, 수행 절차를 보완
(3) 누락된 테스트 – 페이징 조회, 정렬 기능 검증, 검색어 체크 등 –
보완
(4) 업무적인 요건에 대한 테스트 추가
- 각 관리 항목에 이름이 같은 경우 이에 대한 체크가 수행 되는지
- 여러 연관관계가 맺어진 상태에서 특정 항목을 삭제했을 때의
동작은 어떻게 되는지
- 메뉴관리처럼 하위에 실제 데이터가 존재하는 경우 삭제했을 때의
동작은 어떻게 되는지
테스트 설계 보완 전/후 비교비교를 위해 도식화
[ 보완전 ]: 네비게이션 방법 위주 ] : 페이징 처리 확인, 정렬, 검색,
동일한 이름 수정 등 추가: (추가케이스) 여러 사용자(관리자)가 동시에 기능을처리하려고 할 때 의도하지 않은 상황이 발생하지 않는지 확인
[ 보완 후 ]
검증검증검증검증 항목항목항목항목 추가추가추가추가 다수다수다수다수 사용자사용자사용자사용자흐름흐름흐름흐름((((동시성동시성동시성동시성))))시나리오시나리오시나리오시나리오 추가추가추가추가
4. UI 테스트 개선 (매뉴얼 테스트)� UI 매뉴얼 테스트
짝(개발자-테스터)으로 수행하여 개발/테스트 역량 강화
: 각 개발자 별로 1~2회 각 30분씩 짝 테스트 수행
[ 수행방식 ]
개발자와 테스트 전문인력이 같이 테스트를 수행
30분 동안 각 15분씩 Observer, Operator로 수행
※ Observer : 테스트 대상에 대한 테스트 케이스를 구상하고
Operator에게 해당 테스트 수행 지시
Operator : 실제 화면에서 테스트를 수행하고, 결함을 보고
※ Observer는 간단한 테스트 Charter를 작성
[ 기대효과 ]
개발자는 테스터의 테스트 방식을 짧은 기간에 습득
테스터는 개발 대상에 대한 이해도를 높임
개발자-테스터 간의 커뮤니케이션 개선
This is how I test software
Got it
개발자는 테스트를, 테스터는 개발을 학습
짝 테스트 수행 결과- 개발자 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 브라우저 리사이즈 시 조회 영역은 정상 확장되나, 하단 데이터 영역이 확장되지 않는 현상 발생
5. 결함관리
- 단기적으로는 개발 관리 시스템의 Issues 기능을 이용하여 결함 및
조치 방법 개발 팀원 간에 공유
6. 테스트 자동화 환경 구축(Jenkins)- 기존 emma 대신 Jacoco를 Maven pom.xml에 추가하여 테스트 수행 및 커버리지 측정
pom.xmlpom.xmlpom.xmlpom.xmlJenkinsJenkinsJenkinsJenkins
향후 계획
- 수행 내용에 대한 성과 리뷰 및 확대 수행(REST API)
- 단기개선 건 중 미수행 건 - GUI 테스트 자동화
- 그 외 중장기 개선 계획 수행
(a)결함 관리 : 결함 관리 시스템 도입, 각 결함에 대한 유형, 심각도 정의, 결함 라이프싸이클 도입 등을 통한 결함 자산화
(b) 테스트 환경 : 개발과 분리된 테스트 환경, 자동 수행 환경 구축 등(c) 비기능 테스트 : 성능, 웹 접근성, 멀티브라우저 테스트 등(d) 테스트 전략과 계획, 테스트 라이프 싸이클, 커뮤니케이션 : 전체 테스트 전략 및
개발 프로세스에 따른 테스트 프로세스, 테스트 관련 역할자간 역할과 책임 정의(e) 동료 검토 : 동료에 의한 분석, 설계, 개발 산출물 검토 및 보완 프로세스 도입
(예: 개발 말미에 개발자간에 크로스 테스트 등)(f) 테스트 조직 : 별도 테스트 담당자/조직 구성, 업무 정의, 테스트 자산화
미수행건 수행 개요 – GUI & 멀티브라우저 테스트
- Selenium 등을 활용하여 다양한 브라우저에서 테스트를 자동으로 수행할 수 있는
스크립트 작성 지원
Selenium-Core
테스트 대상 UI
+
Selenium스크립트
1) Record
2) 스크립트 Export
3) 스크립트 보완
4) 테스트 수행
CI 서버SeleniumRC 서버
단기 개선에 포함되었으나 리소스 부족으로
중기 계획으로 분류
※ 멀티브라우저 테스트를 위한 처리- Junit으로 Selenium 스크립트를 Export
- 수행 IP, 브라우저 정보를 특정 시스템 변수 값을 참조하도록 하고, 테스트 수행 시에는 이 변수 값을
조정하여 동적으로 멀티 브라우저 테스트 수행
selenium = new DefaultSelenium("localhost", 4444, "*chrome", "https://www.google.co.kr/");
*chrome -> 파이어폭스 브라우저*googlechrome -> 크롬 브라우저*iexplore -> 인터넷 익스플로러*opera -> 오페라 브라우저*safari*custom 직접경로지정
수행 회고 (2pages) ※ 각 항목별로 파란색은 좋았던 점, 빨간색은 나빴던/아쉬웠던 점
1. JUnit 가이드 및 짝 프로그래밍
(A) Junit 테스트 코드를 어떻게 코딩해야 되는지 알려 준 점
(B) JUnit 샘플과 방법을 보여주고 테스트코드를 생성하니 생성에 너무너무 수월했습니다
(C) Junit 테스트 코드를 좀 더 깔끔하게 정제해 준 점, 페어테스트 진행
(A) 제가 사전 지식이 별로 없어서 준비가 많이 안 됐던 것 같네요
(B) 짝테스트 이전에 먼저 테스트케이스사용에 대한 설명에 시간할애를 많이 해서 아쉽습니다.
제가 준비를 많이 해놓았으면 더 좋았을 것 같습니다
(C) 페어 테스트 진행 시 테스트시나리오 등을 참조하여 업무플로우 대로 진행해보아도 좋을 것
같습니다. 개별 Junit 뿐만이 아니라 빌드되어 전체적으로 돌아가는 모습도 같이 리뷰해 보아도 좋을
것 같습니다
2. 테스트 설계 보완
(A) 테스트 케이스를 세부적으로 보완해 준 점
(B) 보완한 것을 보고 보완하니 하기가 수월했어요
(C) 좀 더 상세하게 보완해 준 점
(A) 내부적으로 테스트 설계를 변경했는데 이 부분이 공유되지 못한 점이 아쉬워요
(B) 최종 시나리오가 나왔을 때 한번에 보였으면 더 좋았을 것 같습니다. 자주바뀌어서ㅠ
3. 화면에 대한 짝(개발자-테스터) 테스트
(A) 미처 생각지 못한 버그도 찾아내 준 점
(B) 짝테스트는 Junit보다 화면 테스트할 때 도움이 많이 되었습니다. 다른 사례에서 비슷한 문제의
해결방법에 대해서 들은 것이 좋았습니다.
(C) 짧은 시간에 버그를 많이 잡아준 점
(B) 화면 짝테스트 30분은 시간이 좀 짧아서 더 많이 찾을 수 있었는데 아쉬웠습니다
4. 전체적인 진행, 회의 준비, 지원하러 온 사람 등에 대해.
(A) 각 활동마다 30분 씩 시간 맞추어서 하신 점도 정말 좋았습니다
(B) 미리 테스트케이스를 준비해 놓고 테스트를 받은 것이 도움이 된 것 같습니다
(B) 짝 테스트시 커맨더랑 아바타가 아니고 같이 동작해보고 얘기하는 시간도 있으면 좋을 것 같습니다.
개발자가 커맨더가 되면 매일 하던 방법으로 테스트 하게 되는 것 같아서요.
…… 하략 ……
감. 사. 합. 니. 다.
약식 진단 체크리스트 1/2
테스트 영역 설명 Initial Activated Managed
1. Methodology & Standard Guide
방법론 및 표준가이드
개발 방법론이 정의되고 테일러링되어 적용되는지. 테스트 활동은정의되어 있는지
없음 정의되어 있음 담당자가 정의되고, 사용된자산이 재사용되는가
2. Test Strategy & Test Planning
테스트 전략과계획
비즈니스 요구 및 목적에부합하는 테스트 목적과 각테스트 단계, 내역이 정의되어있는가
정의 해당 내용이 관련자 협의 및승인을 거쳐 공식적으로수행
테스트 전략 담당자가정의되고 위험기반 테스트전략이 수립
3. Commitment & Communication
커뮤니케이션 의사결정(협의)에 대한 진행기준이 마련되어 있고 테스트인력이 같이 참여하는가
테스트 인력은 의사결정건들에 대해 인지하고 있다
관련자들은 테스트가 필요한일로 인식하고 있고 품질을확인하고자 하는 의지가있는가
같이 참여
4. Test Organization 테스트 조직 테스트 역할자, 조직이 정의되어있고 정해진 테스트 활동을 수행하는가
테스트 역할자 정의되고정해진 활동을 수행
테스트 활동이 테스트 수행이전부터 수행된다
테스트 조직으로서 다른조직과 협업
5. Test Training Program
테스트 교육프로그램
테스트 교육에 대해 필요가식별되고 교육 계획이 수립되고운영되는가
없음 전략적으로 테스트 교육계획을 수립하고 운영
조직 내 테스트 교육담당자가 존재
6. Test Lifecycle 테스트 라이프싸이클
테스트 활동, 프로세스가 정의되고모니터링 되고 조정이 되는가
테스트 업무환경 기준이정의된 수준
개발 라이프 싸이클에상응되는 테스트라이프싸이클이 별도정의되고 수행된다.각 역할자의 역할이정의되고 수행된다
각 테스트 활동은 계획 대비모니터링 되고 분석된리스크에 따라 관리 되는가
7. Test Design and Execution
테스트 설계 및실행
각 테스트 레벨별 목적에 맞게테스트 설계가 수행되고 일정에따라 설계, 실행이 수행되는지모니터링 되는가테스트 인시던트는 식별되고관리되며 조치되는가
테스트 설계가 수행되고 각테스트에 사용되는 테스트데이터가 식별되고 생성한다
테스트 베이시스와 대상을분석하여 테스트 설계를수행하고, 이 설계는 제3자가쉽게 이해 가능하다테스트 레벨별 목적에 따라테스트가 설계되고 중복이없다
테스트 설계 및 실이 일정에따라 실행되는지모니터링되고 정기 점검, 보고된다테스트 시작/종료 조건에따라 실제 테스트가수행된다테스트 설계 내용이자산화된다
8. Peer Reviews 동료 검토 동료에 의해 업무 산출물이검토되도록 정의되고 수행하고모니터링 하는
없음 동료 검토 기준, 조건, 시작/종료 조건등이정의되고 이대로 수행되는가
동료 검토 수행이모니터링된다. 테스트인력이 테스트 베이시스등을 검토하고 이 내용이반영된다
가중치0.5
가중치0.5
가중치0.5
가중치0.5
가중치0.5
가중치0.5
가중치0.5
가중치0.5
가중치0.5
가중치0.5
가중치0.5
가중치0.5
가중치2.0
가중치2.0
약식 진단 체크리스트 2/2
테스트 영역 설명 Initial Activated Managed
9. Non-functional Testing
비기능 테스팅 비기능 테스트 영역 및 방법이정의되고 설계되며 수행되는가
비기능 테스트 대상 및방법이 정의되어 있고 비기능테스트 설계가 수행된다
비기능 테스트 설계는우선순위화되어 있고요구사항, 각 내역간추적성이 확보되어 있다
10. Regression testing 회귀 테스팅 조직 관점에서 회귀테스트 기준, 절차가 정의되고 그 결과가모니터링되고 자산화된다
없음 조직차원에서 회귀테스트 범위, 대상, 방식, 절차 등이 포함된기준, 가이드가 존재한다회귀 테스트가 기준에 따라수행된다
회귀테스트 역량을 갖고 있는담당자가 정의되어 있고 회귀테스트 내용(결과)는 자산화되어있다
11. Defect Mgmt. 결함 관리 결함이 체계적으로 분류되어관리되고 결함현황에 대한 모니터링, 정기 회의 등이 이루어 지는가
결함의 분류, 유형, 상태 등필요한 항목들이 정의되고담당자를 포함한 내용들이시스템을 통해 관리된다
결함의 라이프사이클이정의되고 적용되며 라이프사이클은 각 역할자, 조직간의책임을 명확히 구분하고 있다
결함 현황, 이슈, 관련자 협의 등을지원할 결함 관리자가 존재한다정기적으로 결함관련 회의가 열리고논의된다
12. Test Process Mgmt. 테스트 프로세스관리
테스트 관리가 정의되고 테스트관리자에 의해 수행되는가
없음 테스트 관리활동이 정의되고수행된다
테스트 프로세스 관리를 담당할관리자가 별도로 존재하고, 테스트진척, 성과, 이슈가 테스트 계획서상에 정의된 마일스톤에 따라리뷰가 진행된다
13. Test Measurement 테스트 측정 각종 테스트 지표가 정의되고측정되며, 모니터링되는가
없음 적절한 테스트 지표가 정의되고측정되고 관리된다
요구사항에 대한 테스트 커버리지가측정되고 모니터링 된다테스트 지표는 툴 기반으로제공된다
14. Test Skill & Tools 테스트 스킬과툴
조직에 필요한 테스트 스킬과 툴이정의되고 가이드되고 있는가테스트 스킬과 툴이 테스트를돕는지 모니터링되고 조정되는가
없음 필요한 테스트 툴과 기법은식별되고 기준/가이드되고 있다테스트 인력 및 관련자들은툴의 필요성 및 ROI에 대해 잘이해하고 있다
테스트 툴은 테스트를 더 효과적, 효율적으로 하기 위해 사용되고이런 활용현황이 모니터링된다. 툴/기법에 대한 피드백이 있고 이에따라 조정된다
15. Test Environment 테스트 환경 테스트를 수행하기 위한 환경이식별되고 담당자와 절차가 별도로존재하여 지원되는가
필요한 테스트 환경이식별되고 사용할 수 있다
테스트 데이터, 기대치, 제약사항 등 테스트 환경요구사항이 식별되어 있다
테스트 환경 구성을 하기 위한절차와 담당자가 별도로 정의되어있다테스트 환경 준비가 되었는지확인하는 테스트가 있다
16. Testware Mgmt. 테스트웨어 관리 테스트 활동에 필요한 모든 테스트웨어(대상 프로그램, 테스트베이시스, 도구 등)가 정의되고역량이 확보된 담당자에 의해관리되는가
없음 모든 테스트웨어가 정의되어있다. 테스트 수행 인력은 모든테스트웨어에 대한 정의, 기준, 활용방법을 알고 있다
별도 역량을 가진 담당자가지정되어 있다. 테스트 웨어 관리절차가 정의되고 수행되며 모니터링, 보고 된다
가중치0.5
가중치0.5
가중치0.5
가중치0.5
가중치0.5
가중치0.5