Dev Log Island

웹 개발자의 KPI(Key Performance Indicator)는 개인의 업무 성과와 팀 목표를 측정하는 데 도움이 됩니다.
아래는 일반적인 주니어 웹 개발자를 위한 KPI 항목입니다:

1. 코드 품질 및 생산성
   • 코드 리뷰 피드백 반영률: 코드 리뷰에서 지적된 사항을 얼마나 잘 반영했는지.
   • 주간/월간 코드 기여도: 작성한 코드의 라인 수보다는 기능의 완성도와 기여도를 평가.
   • 버그 발생률: 작성한 코드에서 발견된 버그의 수.
   • 테스트 커버리지 향상: 테스트 작성 여부와 코드 커버리지 증가율.

2. 프로젝트 완료 및 기여
   • 기한 준수율: 맡은 작업이나 프로젝트를 제때 완료한 비율.
   • 작업 완료 건수: 주어진 업무(예: Jira 티켓, Git 이슈) 처리 수량.
   • 기능 구현의 정확성: 요구사항을 충족하며 기능을 개발한 정도.

3. 학습 및 성장
   • 새로운 기술 습득: 업무와 관련된 새로운 기술, 프레임워크, 툴을 학습한 정도.
   • 교육 참여: 팀 내 세미나, 워크숍 또는 외부 교육 프로그램 참여율.
   • 지식 공유: 팀원들에게 학습한 내용을 공유하거나, 문서화한 빈도.

4. 협업 및 커뮤니케이션
   • 커뮤니케이션 명확성: 팀원 및 이해관계자와 명확히 소통하는 능력.
   • 팀워크 기여도: 코드 리뷰 참여, 동료와의 협업 빈도 및 품질.
   • 이슈 해결 참여: 문제를 발견하고 해결하는 데 기여한 빈도.

5. 운영 및 유지보수
   • 배포 안정성: 개발한 코드가 운영 환경에서 문제 없이 배포된 비율.
   • 긴급 문제 해결 기여: 운영 환경에서 발생한 문제를 얼마나 효과적으로 지원했는지.
   • 기존 코드 개선: 리팩토링, 성능 최적화 등 기존 코드에 대한 기여.

6. 사용자 중심 개발
   • 사용자 피드백 반영률: 사용자 요구사항을 코드에 잘 반영했는지.
   • UX/UI 향상 기여도: 사용자 경험과 인터페이스 개선 기여.

KPI 예시

주니어 개발자 KPI 설정 팁

1. 구체적이고 측정 가능하게: 모호한 목표 대신 측정 가능한 목표로 설정.
2. 성과와 성장의 균형: 단순히 업무량뿐 아니라, 개인의 성장과 학습도 포함.
3. 주기적인 리뷰: 분기별 또는 월간으로 KPI를 점검하여 조정.
4. 팀과 회사 목표 연계: 개인 목표가 팀 및 회사 목표와 맞물리도록 설정.

😊

1. 테스트 프로세스

테스트 프로세스는 테스트와 관련된 활동이 체계적으로 진행되어 의도된 테스트 목적과 목표를 달성할 수 있도록 모든 구성요소를 엮어주는 역할을 함.

테스트 프로세스 5 단계

  계획/제어 -> 분석/설계 -> 구현/실행 -> 완료/리포팅 -> 마감

테스트 프로세스는 계획/제어, 분석/설계, 구현/실행, 완료/리포팅, 마감 5단계로 구성.

1. 계획과 제어 :
   테스트 계획 수립은 테스트 목표와 임무를 달성하기 위해 이를 확인하고 필요한 활동을 정의.
   테스트 제어는 계획 대비 실제 신행 상황을 비교하는 지속적인 활동.
2. 분석과 설계 :
   테스트 분석과 설계는 일반적이고 추상적인 테스트 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환.
3. 구현과 실행 :
   테스트 구현과 실행은 가장 효율적이고 효과적으로 테스트스를 실행하기 위하여 테스트 케이스를 조합하고 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시져를 명세화.
4. 완료 조건과 리포팅 :
   초기에 정의된 테스트 목표에 비해 어느 정도 실제 테스트가 수행되었는지를 평가.
5. 테스트 마감 :
   완료된 테스트에서 발견된 사실 및 수집된 데이터, 경험을 취합하고 축적.

2. TC 작성 절차

  문서 수집 -> TC 작성 -> 내부 검토 -> 커버리지 분석 -> 승인

1. 참조 문서 수집 :
   테스트 계획서에 명시된 테스트 케이스 작성 지침과 수준을 고려,
   테스트 설계에 필요한 분석 및 설계 문서 수집.
2. TC 작성 :
   테스트 설계 기법을 이용하여 TC를 작성.
3. 내부 검토 :
   PM, 아키텍트, 디자이너, 기획자, 개발자, QA 담당자가 작성된 TC의 적정성 검토.
4. 요구사항 대비 커버리지 분석 :
   TC가 어느 정도 요구사항을 반영하는가에 대한 분석.
   기본적으로 테스트 가능한 요구사항은 모두 TC에 반영되어있는지 확인.
5. 승인 :
   작성된 TC를 클라이언트(현업), 기획자 및 PM에게 승인을 받음.

3. TC 구성요소

• 식별 번호 :
  TC의 고유 식별자.
• 이슈 번호, 제목 :
  제목과 이슈 번호를 기입. (Redmine NO., Jira NO.)
• 요약 (Description) :
  TC의 목표 등 요약된 정보
• 사전 조건 (Precondition) :
  테스트 수행에 필요한 조건 및 실행환경. (선행 조건, 전제조건)
• 종속성 (Dependencies) :
  테스트 요구사항 또는 기타 TC에 대한 의존성 판단.
• 수행 절차 (Test Step) :
  TC를 수행하기 위한 정확한 단계.
• 기대 결과 (Expect Result) :
  절차대로 진행 시 테스트 통과 여부를 결정하는 기대 결과.
• 실제 결과 (Actual Result, PASS / FAIL) :
  테스트 수행 후 실제 결과.
• 비고 (Remark, Note, Comment) :
  기타 비고 사항을 기입.
• 그 외 :
  우선순위, 모듈 이름, 테스트 설계자, 설계일, 테스트 수행자, 수행일 등

구성 요소는 조직이나 프로젝트에 따라 변경/추가/삭제 될 수 있다.

4. TC 작성 시 주의 점 및 장/단점

주의점

• 절차의 누락 :
  테스트 절차를 정확하게 입력하지 않을 경우 테스트 수행의 어려움이 생기는 테이스 발생 가능.
• 장황한 설명 :
  TC 작성 시 상세하고 충분한 정보를 제공해야 하지만, 너무 많은 단어와 불필요한 설명으로 소통의 오류 유발 가능.
• 전문 용어의 과다 사용 :
  TC 작성 시, 직군간 소통이 불가능한 전문용어를 과다사용시 테스트 수행에 어려움이 있을 수 있음.
• 분명하지 않은 PASS/FAIL 기준 :
  테스트 수행 후 테스트 결과가 통과인지 실패인지 예상 결과에 정확히 기입하지 않아 결과 판단에 어려움 유발 가능.

단점

• TC 작성 시간이 수행 시간보다 오래 걸릴 수 있음.
• 기능 변화에 따른 TC 변경 :
  기능을 자주 변경한다면 추후 테스트 케이스의 통제에 어려움이 생기게 될 수 있음.
• 배경 지식 판단의 어려움 :
  TC를 작성하는 사람은 테스트 하는 기능을 잘 알고 있으나, 테스트 수행자는 배경 지식이 없을 경우 테스트 수행 시간이 길어지거나 수행에 어려움이 있을 수 있음.

장점

• 이력 참조 :
  TC는 어플리케이션 런칭 후에도 사용, 유지보수 팀과 추후 어플리케이션의 버전을 담당자의 테스트 이력 참고가 가능.
• 테스트 진행 상황 추적 :
  TC를 문서화 하면 수행한 TC의 수, 통과/실패 수, 과업 범위 별 케이스 수, 테스트 커버리지 등의 정보를 추적/확인 가능.
• 반복성 :
  잘 작성된 TC는 누구나 반복적으로 수행 가능.

5. TC 정렬

TC의 정렬은 업부의 효율과 연결될 수 있다. 테스트의 흐름, 테스트 환경 등을 고려해서 정렬 하도록 하자.

흐름이 이어지는 TC 정렬

환경이 비슷한 TC 정렬