공지사항

6월 실사례 기반 보안 점검 한달 동안 2개 제품을 쉼없이 검증했다. 특이하게도 BE, FE 관련자 분들이 모두 처음 - 그분들 인생에서도 처음 - 별도 QA 테스트를 받는 분들이어서, '당연히 이 정도는 알고 있겠지,'하고 거기에 더해 설명한 내용들이실제로는 전혀 같은 이해 정도를 갖고 있지 않았고,제품별로 각각 2,3주 진행하는 동안 설명, 또 설명을 반복해야 했다. ​이런 상황들을 (앞으로는) 조금이나마 완화해 보고자, 2개 제품 중 1개 제품 검증 과정을 날짜별로 정리해서 팀 내 세미나로 진행해 봤다. 제목 : 테스팅 상세 절차(B제품 검증사례 기반) 소개 및 코드프리징 설명​개요/목적(1) 5,6월 A 제품, B제품(C제품) 최종 실사례 기반 보안 점검 E2E QA 테스트를 진행할 때 실제 어떤 절차로 진행하는지 설명/공유가 필요한 상황 ⇒ 6월에 3주동안 진행한 B제품 사례로 설명 (2) ‘코드 프리징’ 을 통한 제품/서비스 안정화 의도와 설명도 필요 ​전체 수행 절차 ​​​사전-2개월전쯤[1-1] 사전에 전체 테스트 계획(Notion) 작성/공유초기 테스트 계획의 주요 내용 테스트 대상/목적 확인테스트 종류(레벨), 방법 확인개발일정, 테스트 일정 확인이해관계자 확인 -R&R 정의기타 - 테스트 자동화, 비기능 테스트 등​​1주차 - 테스트 계획 (테스트 수행 2주전)[1-2] (6/4(화), D-2주) 팀 내 실무자들과 QA 테스트(E2E) 착수 회의논의하는 내용 테스트 대상은 ~~ 부분입니다. 맞을까요?테스트는 언제부터 시작 가능할까요? 실사례 기반 보안 점검 그럼 코드 형상 프리징은 다음주 금요일까지로.테스트는 어떤 환경에서 수행 가능할까요? 어떤 브랜치가 배포될까요.“결함 관리는 Jira에 xx, xy, zx, zy 프로젝트로 구분해서 각각 관리합시다”테스트는 첫째주는 쭉 진행하다가 저희끼리 내부리뷰하고, 둘째주는 조치하고 조치확인 테스트 합니다​2주차 - 테스트설계, API 테스트 [2-1] 테스트 분석/케이스 설계- B제품의 경우 시간이 없어서 TC 정의(타이틀만)만 우선 진행 (그림 2-1) ​[2-2] API 테스트 - 시간에 몰려 점점 기본 케이스만 작성스크립트, jenkins, slack python/pytest/requests 로 API 스펙에 따라 테스트 작성(그림 2-21) (그림 2-22) (그림 2-23) (그림 2-24) ​[2-3] (6/11(화)) 개발협력업체 포함 FE, BE 등 실사례 기반 보안 점검 실무자들에게 테스트 착수 설명 회의QA 테스트 착수 공유개발 협력업체에 전주에 확정된 테스트 수행 개요/ 상세 방법 설명테스트 기간 상세 일정 및 활동테스트 대상/범위, 제외되는 부분 설명코드 형상 관리 설명 및 코드 프리징 요청, 조치 기간 조치 정기 반영 설명테스트 환경결함관리 방법/Jira 사용법​​3주차 - 1차 테스트 , 내부 결함리뷰 회의 - D-day[3-1] 테스트 수행기능성/사용성/신뢰성 관점 테스트, 결함 심각도?테스트 결과 입력, jira 결함 입력(*)결함 심각도 분류 기준- (a) Critical(치명결함) : 제품 전체에 기능적으로 영향을 주거나, 제품의 주요 value를 만족시킬 수 없게 만드는 결함- (b) Major(중결함) : 실사례 기반 보안 점검 제품의 주요 기능이 동작하지 않음. 사용성/보안 관점에서 중대한 문제를 발생- (c) Minor(경결함) : 제품의 보조 기능이 동작하지 않음. 주요 기능이 부분적으로 수행불가(다른 방법으로 주요 기능 수행 가능). 사용자에게 일반적인 불편함을 발생- (d) Trivial(단순결함) : 단순 UI성 결함(오타, 정렬 등), 실제 발생하기 어려움 등- (e) Enhancement(권고사항) : 개선 의견 ​[3-2] (6/20(목)) 팀 내부 결함 리뷰 회의결함 설명 및 (1)수정할지 여부(2)이번에(~6월말) 수정할지, 이후에 수정할지(3)수정한다면 어느쪽에서, 어떤 식으로 수정할지​[3-3] 확정된 결함 건은 개발 협력 업체 Jira 프로젝트로 이동 및 담당자 지정​​4주차 - 조치/조치확인 테스트, 테스트 결과 보고 실사례 기반 보안 점검 [4-1] 조치 건 정기배포(월,수,금(오전)) 등 계획목적 : 코드 변경 체크, 짧은 싸이클의 조치확인 테스트 유지를 위해월, 수, 금(오전) 3회 조치건 코드 배포​[4-2] 월, 수, 금(오전) 정기 배포 후 조치확인 테스트상세 정책각 배포시 기존 코드 형상 vs 변경 코드 형상 확인 후 결함 건 외 수정 내용 확인 후 추가 재테스트 수행조치확인 테스트 - 조치 안됨(ReOpen), 조치미흡, Side-Effect 발생은 신규로 등록(사례) gitlab 코드 compare 체크 및 변경 영역(재테스트) 확인 예(슬랙)​[4-3] 최종 결함 조치확인 관리최종 테스트 완료를 위한 잔여 건 논의(당일 내 필수조치, 보류 방안 검토 실사례 기반 보안 점검 등)보류, Known-issue 구분 등 조치보류(Deferred) : 필요한 사전작업 미비(정책 정의, 디자인 설계 등), 심각도/발생빈도 대비 수정 공수가 큰 건 등에 대해 최종 보류 처리known-issue (Cancel) : 결함은 맞으나 수정이 불필요하다고 생각하는 건에 대해 Label 추가하여 기록​[4-4] (6/28(금)) 테스트 결과 보고결과보고 항목이해관계자 모두에게 -예: Notion: B제품 테스트 결과 내용을 이메일/메신저/별도 회의 등을 통해 공유테스트 결과보고 항목 테스트 일정(최종)최종 코드 형상(커밋 id)테스트 결과 : TC 수행률, 통과율, 결함률,결함조치율,보류 또는 known-issue로 분류한 이슈 상세 등​2. 코드 프리징 이론과 실사례테스트 수행 전 코드 프리징에 대해 전혀 모르는 분들이 실사례 기반 보안 점검 있어, 이론적인 내용부터 설명. ​사내 챗봇에 질문한 결과 <=테스트 수행 전 개발 완료를 요청, 코드 최종 반영 이후 코드 프리징(*)을 선언하고 신규 기능 개발 등은 최대한 배제 ​​B 제품 사례. - 코드 프리징을 기본으로 하고, 결함 조치 반영 시에도 코드 변경 검토를 엄격하게 진행 최종 재테스트 일정이 없기 때문에, 1차 테스트 후 코드 변경을 엄격하게 리뷰하고, 결함 수정건만 수정, 기능 추가/코드 리팩토링 등은 최소화(원칙적으로 금지) - 변경 부분에 대해서만 재테스트 ​​(코드 변경 검토의 예)-캡처 미제공 ​​​​​​​​​​​(그림 2-21) (그림 2-22) (그림 2-23) (그림 2-24) ​