소프트웨어 개발과 테스트 - jira

소프트웨어 개발과 테스트 국내도서 저자 : 조대협 출판 : 프리렉 2015.01.15 상세보기

◎ 초어(Chore) : 초어는 개발을 해야 하는 부분이지만 사용자와 직접적으로 관계되지 않는 개발 내용을 정의한다. 

◎ 릴리즈 : 릴리즈는 작동 가능한 서비스 상태로 만드는 것이다. 정확하게 이야기 하면 운영 서비스로 올리는 것을 릴리즈라고 한다. 

◎ 스크럼 마스터 : 스크럼 마스터는 프로젝트 매니저로부터 받은 요구사항을 개발원들에게 나눠주고, 관리하는 역할을 한다. 해당 스크럼 팀의 구현 태스크를 분배하고 관리하는 역할을 한다. 

◎ 시스템 운영 : 흔히 테크 옵스 또는  시스템 운영이라고 이야기하는 분야로, 구현된 하드웨어나 소프트웨어를 포함한 시스템에 대한 운영을 담당한다. 테크 옵스는 시스템의 설치, 설정, 세트업 및 배포와 같이 설치에 대한 전체 프로세스뿐만 아니라 시스템에 대한 모니터링 및 장애 처리까지의 시스템에 대한 기술적인 운영의 전반적인 부분을 담당한다. 

◎ 프로젝트 매니저 : 프로젝트 매니저의 역할은 어떻게든 프로젝트를 성공적으로 끝내는 것이다. 인원이나 일정에 대한 관리 뿐만 아니라, 특히 돈과 위험요소에 대한 관리자 중요하다. 무엇보다 중요한 것은 커뮤니케이션이다. 고객과의 의사소통과 팀원과의 의사소통이 가장 중요한 역할이다. 그 과정에서 리스크들이 자연스럽게 도출되고, 각자의 능력을 최대화해줄 수 있는 방법을 찾을 수 있게 된다. 

◎ 코드 리뷰 : 사람이 직접 소스 코드를 보면서 코드의 품질을 체크하는 프로세스이다. 방식에 따라서 피어 리뷰, 워크스루, 팀 리뷰, 코드 인스펙션 등이 있으며, 비용대비 효과가 매우 큰 방식이다.

◎ 릴리즈의 개념을 먼저 이해하자. 릴리즈는 작동 가능한 서비스 가능한 상태로 만드는 것이다. 정확하게 이야기하면 운영 서비스로 올리는 것을 릴리즈라고 한다. 요즘의 애자일 방법에서는 쇼트 릴리즈라는 전략을 사용하는데, 아주 짧은 주기로 서비스나 소프트웨어를 릴리즈하는 방법이다. 그렇다고 릴리즈마다 매번 운영 환경에 배포하는 것이 아니라 서비스로 배포할 수 있는 형태로 만들거나 어느 정도의 기능 등이 마무리 되었을 때 릴리즈 한다. 

◎ JIRA에 각 이슈에는 코멘트를 달 수 있는 기능이 있는데, 해당 이슈를 해결하는데 필요한 내용이나 다른 사람과 커뮤니케이션한 내용을 붙인다. 이유는, 해당 이슈를 해결하는 데 담당자가 무슨 일을 했는지에 대한 로그를 남기는 것이다. 향후 다른 사람이 해당 업무를 받거나 또는 비슷한 문제를 해결하고자 할 때 선임자가 어떤 식으로 업무를 해결했는지를 찾아볼 수 있도록 하는 것이다. 

◎ JIRA의 가장 큰 특징 중의 하나가 상당히 많은 부분에 대해서 커스터마이징이 가능하다는 것이다. 그 중에서 강력한 기능 중의 하나가 워크플로 기능이다. JIRA 에서는 각각 다른 이슈 타입에 대해서 다른 워크플로를 정의할 수 있도록 지원한다. 

◎ 일반적인 소프트웨어 개발팀의 구조는 소프트웨어를 직접 개발하는 프로젝트 유닛, 전체 프로젝트들을 관리하는 관리조직과 각 개발팀에 공통으로 테스트 등의 지원을 해주는 공통팀과 마지막으로 개발된 시스템을 운영하는 운영팀으로 나눌 수 있다. 

◎ 프로젝트 매니저의 역할은 어떻게든 프로젝트를 성공적으로 끝내는 것이다. 인원이나 일정에 대한 관리뿐만 아니라, 특히 돈과 위험 요소에 대한 관리가 중요하다. 무엇보다 중요한 것은 커뮤니케이션이다. 고객과의 의사소통과 팀원들과의 의사소통이 가장 중요한 역할이다. 그 과정에서 리스크들이 자연스럽게 도출되고, 각자의 능력을 최대화해줄 수 있는 방법을 찾을 수 있게 된다. 

◎ 코드 리뷰란 '코드를 실행하지 않고 사람이 검토하는 과정을 통하여 코드에 숨어 있는 잠재적인 결함을 찾아내고 이를 개선하는 일련의 과정'을 정의한다. 테스팅의 범주에서는 정적인 분석에 속한다. 정상적인 코드 리뷰 기법일수록 결함 발견에 집중하고 소프트웨어 개발 주기의 후반에 위치하지만, 가벼운 코드 리뷰 기법은 결함의 발견뿐만이 아니라, 같은 로직을 여러 관점에서 생각하는 아이디어 회의나, 후배 개발자에게로의 지식 전달 등의 부가적인 목적들도 함께 가지고 있다. 

◎ 코드 리뷰의 기법을 나누는 방법은 크게 얼마나 정석적이고 프로세스적(정형적)이냐에 따라서 Formal/Lightweight 방법으로 나눌 수 있고, 오프라인에서 직접 커뮤니케이션을 하느냐 또는 메신저, 이메일이나 기타 자동화된 코드 리뷰 도구를 사용하느냐에 따라 온라인 리뷰와 오프라인 리뷰로 나눌 수 있다. 

◎ 코드 인스펙션의 전제는 전문성을 가지고 있는 인스펙션 팀이 일정한 프로세스와 패턴에 따라서 개선안을 찾는 작업이다. 즉, 고도로 훈련된 팀과 기간이 필요하고 어느 정도 개발이 완료되어 있는 인스펙션 대상이 있는 것을 전제로 한다. 인스펙션의 시기는 시스템이 개발되어 있는 기점인 릴리즈 때가 유용하다. 

◎ 테스트 환경이란, 테스트 대상이 되는 대상 시스템을 테스트 환경에 배포한 환경과 테스트를 위해 사용되는 부하 발생 도구 등의 테스트 도구, 테스트 과정 중 대상 시스템을 관측하기 위한 모니터링 시스템, 그리고 테스트에서 발견된 결함을 로깅하기 위한 결함 관리 시스템 등으로 구성된다. 

이런 테스트 환경의 구성은 개발팀 또는 테스트 엔지니어가 겸하는 경우가 많은데, 테스트 환경 구축 자체가 많은 시간이 들기 때문에 이를 구축하는 개발자나 테스트 엔지니어의 리소스가 허비되고 이로 인해서 개발일정이나 테스트 일정에 차질을 가지고 올 수 있기 때문에 명시적으로 테스트 환경을 세트업하고 유지하는 역할을 만들 필요가 있다. 

◎ 마이크로 벤치마크란 소규모의 부하 테스트를 의미한다. 비기능적 결함의 특징 중의 하나가 많은 부하가 아니라 소규모 부하를 주더라도 성능 문제나 병목, 안정성, 확장성 등의 문제는 쉽게 드러난다. 소규모 부하에서도 드러날 문제라는 것은 반대로 이야기하면 그 정도로 시스템의 완성도가 떨어진다는 것으로, 중대 결함이 대부분이다. 

마이크로 벤치마크의 가장 큰 특징은 테스트의 주체가 대규모 테스트 팀이 아니라 개발팀이나 소규모 테스트 팀에서 수행한다는 것을 들 수 있으며, 투자 대비 효과가 매우 좋은 테스트 기법이다.