반응형 Essay/Software QA 일지2 Software Issue Life Cycle - Status 개선 사례 수 년전, 당시 팀원들과 함께 개발 Task 및 Issue Task의 상태(Stauts)에 대해 위와 같이 정의하고 관리를 해오고 있었다. 아래와 같이 정의한 시점에는 Task의 양이 많지 않았고, 제품의 수나 제품 버전 또한 그리 많지 않은 상황이었다. 그 당시에는 아래와 같이 구분해도 충분히 커뮤니케이션 및 History 관리에 무리가 없었던 수준이었다. 하지만 수 년이 지난 현재에는 개발/검증 담당자들 또한 많은 변화가 있었고, Task가 워낙 다양하고 많아지게 되었고, 그러다 보니 Task의 History 관리 측면에서 일부 혼선이 발생하고 있었다. 그 중 가장 구별에 혼선이 발생했던 Status는 "Invalid" 로 정의했던 Status 였다. 해당 Task가 잘못 리포트 되었던 Task인 경.. 2022. 1. 9. 릴리즈 단계 정리 (alpha, RC, RTM) 작년에 개발팀과 검증팀이 협업을 한지 1년 남짓된 상태라 급한대로 RC, RTM 버전만 분리하여 운영하였는데, 제품의 버전이 올라감에 따라 복잡도도 올라가고, 파트너가 많아지다 보니 RC 버전 검증 기간에 신규 개발건들이 반영되는 등.. side-effect를 일으킬 수 있는 요소들이 점차 증가하게 되었다. 실제로 작년말 릴리즈 된 버전에 검증 중에 변경된 feature로 인해 side-effect가 발생하였고, 추가 bugfix 버전을 릴리즈 하는 일이 벌어지기도 하였다. 이렇게 버전 컨트롤이 점점 쉽지 않은 상황에 제품의 완성도를 높이기 위해서는 RC 버전에 대한 코드 프리징이 우선되어야 겠다는 판단이 들었고, 소프트웨어 배포 생명주기(Link)를 참고하여 현 회사에서 현실적으로 도입 효과가 가장 커.. 2021. 9. 19. 이전 1 다음 반응형
