dev + qa = hq sw dev + qa = hq sw

코드 리뷰 사람에 의해 수동적으로 수행되는 정적 분석 과정 예. 피어 리뷰, 워크스루, 팀 리뷰, 코드 인스펙션 등 코드 인스펙션 완성된 코드에 대한 검토를 통해서 코드 상에 존재하는 잠재적인 문제를 발견하는 과정 Deadlock에 대한 검출, Lock Contention과 같은 병목 구간에 대한 검출, Memory Leak이나 Connection Leak과 같은 자원 누수에 대한 검출과 코딩 스타일(변수명이나 메서드명 규칙 등)에 대한 가이드 수행 정적 분석 자동화된 도구에 의해서 이루어지는 정적 분석 과정 잘 알려진 버그에 대해서 리포팅 (예. Connection Leak - JDBC Connection Pool에서 Connection을 사용한 후 Pool에 돌려놓지 않아서 생기는 문제) 코딩 표준에..

요구사항 수집 및 분석 단계 가장 신경써야하는 QA 활동 단계 (조기 식별 및 해결 = 비용, 리스크 ↓) 고객 또는 비즈니스 요구사항에서 품질 목표를 도출 고객 및 비즈니스 요구사항 → 품질, 테스트 요구사항 (테스트 관점에서 재정의) 기능성 & 비기능성 요구사항 분류 테스트 요구사항 정의서 작성 (= 모든 품질 활동의 주축) 설계 단계 테스트 아키텍처, 리스크 분석, 품질 목표 설정 테스트 계획서 작성 구현 단계 정적 분석 (표준 및 형상관리 검증) 테스트를 위해 이슈 분석 및 관리 단위 테스트 & 통합 테스트에서 발견되는 버그 → 이슈 이슈 해결에 따라 테스트 아키텍처 및 설계 보완 (+ 리스크 확인) 테스트 단계 시스템 테스트 & 인수 테스트 수행 고객에게 제품 전달 또는 공식 배포까지 품질 상태..

버그 제품의 가치를 위협하는 제품 내의 문제 소프트웨어 기능이나 성능에 영향을 미치는 결점 대부분, 테스터에 의해 유닛테스트에서 발견됨 이슈 테스트, 프로젝트, 비지니스까지 위협하는 문제 테스트를 어렵고 느리게 만드는 제품/프로젝트 내에 존재하는 문제 코드에서만의 문제 X 결함(defect) 시스템 또는 소프트웨어 응용 프로그램의 실제 및 예상 결과의 편차 요구사항이나 명세를 충족시키지 못 하는 결점 개발자에 의해 발생 및 해결 소프트웨어의 무능력, 비효율성을 나타냄 오류 → 결함 → 장애 (결함이 반드시 장애를 일으키진 X) 유형 산술적(Arithmetic) 결함 산술식에서의 실수 / 액세스 작업 또는 지식 부족으로 인해 발생 / 작성한 코드를 볼 수 없어서 생기는 코드 혼잡(congestion) 논리..

결함 수명 주기 = 버그 수명 주기 '결함 수명의 여러 상태를 포함하는 주기' 예상 행동 ≠ 실제 행동 → 결함 결함 상태 신규(New): 새로운 결함이 발견되면, '신규' 상태가 되며 후반 단계에서 이 결함에 대한 유효성 검사, 테스트 수행 지정(Assigned): 새로 생성된 결함이 개발 팀에 할당됨 (아직 해결 X) 오픈: 결함 해결 중 (결함 분석 프로세스 + 수정 작업) 중복(Duplicate): 결함이 2번 이상 반복 또는 동일한 버그 개념에 해당 거절(Rejected): 진짜 결함이 아니라고 판단 연기(Deferred): 최우선 순위 X, 다음 릴리즈에서 해결 버그 아님: 결함이 애플리케이션 기능에 영향을 주지 않는 경우 해결(Fixed): 개발자가 필요한 코드를 변경하고, 변경사항 확인 재..

품질 컴포넌트나 시스템이 다양한 이해관계자의 명시적/묵시적 요구를 충족시키는 정도 품질 관리(Quality Management) - 품질과 관련하여 조직을 감독하고 통제하는 조정 활동. 품질 관련 감독과 통제에는 일반적으로 [품질 정책과 품질 목표 수립, 품질 계획, 품질 제어, 품질 보증 및 품질 개선]이 포함. 품질 측면에서 조직이 나아가야 하는 방향 제시 및 제어 하는 모든 활동. 품질 보증(Quality Assurance) - 프로세스를 지속적이고 일관되게 향상 및 유지 관리. 조직적 측면에서 [품질 관리, 프로덕션 프로세스의 일관성을 모니터링]에 더 중점을 둠. QC 작업을 가능하게 함. 품질 관리(Quality Management)의 일환으로, 품질 요구사항이 준수될 것이라는 신뢰를 제공하는데..

이어지는 시리즈 소프트웨어 결함 리포트 소프트웨어 결함 리포트: 분석 소프트웨어 결함 리포트: 보고 소프트웨어 결함 리포트: 내용 소프트웨어 결함 리포트: 트랙, 재시험, 마감 소프트웨어 결함 리포트 과정 분석 리포트 트랙 재테스트 종료(Close) 결함 트래킹 과정을 가지기 결함 리뷰 보드에 의해 다뤄지기 독립적으로 결정을 내리게 한다면, 실수가 생길 수 있는 환경을 만들게 됨 보드에 리드 테스터(또는 모든 테스터)를 포함하기 이해관계자, 개발 및 관리팀, 비지니스 분석과 데이터베이스팀도 포함된다 결함들에 진전이 있는지 확인하기 결함 재테스팅 개발팀이 결함을 가져갔고, 리서치했으며, 해결 표시를 하였다면 → 해결되었는지 재테스트 한다! 재테스트는 3가지의 결과를 가지고 있다 문제가 실제로 해결되었다 종..

이어지는 시리즈 소프트웨어 결함 리포트 소프트웨어 결함 리포트: 분석 소프트웨어 결함 리포트: 보고 소프트웨어 결함 리포트: 내용 소프트웨어 결함 리포트: 트랙, 재시험, 마감 소프트웨어 결함 리포트 구성요소 정보 식별 문제 설명 다양한 상태 지표(indicator) 주석(comments) 기타 정보 지원 정보 정보 식별 고유 번호 또는 ID 트레킹 시스템이 있을 경우, 자동으로 ID 부여 / 없을 경우, 수동으로 번호 지정 제출자 어떻게 제출자를 트랙할 건지에 따라 결정한다. 오픈 시스템인 경우, 사용자들도 제출자가 될 수 있음 제출 일자 결함이 얼마나 오래 됐는지 알 수 있음 이에 반하는 프로그램 또는 제품 제품 버전 또는 개정(revision) 문제 설명 제목 - 최소한의 단어수로 문제를 이해할 ..

이어지는 시리즈 소프트웨어 결함 리포트 소프트웨어 결함 리포트: 분석 소프트웨어 결함 리포트: 보고 소프트웨어 결함 리포트: 내용 소프트웨어 결함 리포트: 트랙, 재시험, 마감 테스팅 중 발견한 결함 반드시 기록! 결함은 [코드 작성 중, 정적 분석, 리뷰, 동적 테스팅, 제품 사용 중] 에 보고 가능 결함은 [코드나 운영 중인 시스템 & 요구사항, 사용자스토리 & 인수조건, 개발 문서, 테스트 문서, 사용자 메뉴얼, 설치 가이드]와 같은 문서에서 이슈로 보고 가능 소프트웨어 결함 보고 1. 중복되지 않는지 확인 → 이미 보고된 문제가 아닌지 (검색 가능 결함 트레킹 시스템) 2. 개발자와 상의 → 개발자가 결함 리포트에 입력하지 않도록 설득하지 못 하게 하기! 3. 시스템에 입력 → 결함 트레킹 시스템..