본 글은 필자가 굉장히 좋은 개발 문화를 가진 스타트업에서 잠시 근무할 당시 작성하였던 글에 추가로 이야기를 덧 붙인 내용입니다. 해당 회사의 SQE(Software Quality Engineer)들이 업데이트 받아 보셨으면 좋겠네요. ^^
인수기준
인수기준(Acceptance Criteria)는 인수 테스트(Acceptance Testing)을 진행할 때 그 기준이 되는 항목을 말하는 것으로, 하드웨어든 소프트웨어든 최종 인수자 혹은 사용자를 대변한 요구사항의 검증을 목적으로 사용한다. 대부분의 업계에서 인수기준은 해당 도메인의 전문가를 통해 수립한다. 위키피디아에서는 이들을 Subject-matter Expert 혹은 Domain Expert라 칭한다. 그리고 필자는 이런 도메인 언어와 개발 언어 사이를 넘나들며 의사소통을 조율하는 역할을 BA(Business Analyst)라 칭한다.
인수기준은 시장 요구사항, 사업 요구사항, 고객 요구사항, 개발 요구사항 등을 고려하여 이루어져야 하는데, 이 부분에서 문제가 발생하는 것은 대한민국에 SRS(System Requirement Specification)을 전문적으로 작성할 수 있는 사람이 많지 않은 부분이 근본적인 이슈이다. 또한, 테스트 전문가들이 품질 전문가 수준으로 향상되지 못하기 있기 때문에 개발에 대한 세부 스펙(Detailed System Specification)을 기준으로 테스트를 수행하기 보다는 요구사항에 대한 기획(Design Specification)을 중심으로 테스트를 수행하고 있는 부분이 이런 문제를 발생시키는 주요 원인이다.
우리나라에 SRS 작성할 만큼의 전문가가 많지 않다는 부분은 김익환 대표님 강의에서 발췌하였다. 블로그는 아래 링크 참고.
대한민국의 상황
2015년 현재 대한민국에는 전체 소프트웨어 각 분야에 전문적인 BA(Business Analyst)는 시장에서 구하기 힘들다고 보면 되며, 한국에서 이 역할을 가장 잘 알고 수행할 수 있는 부서는 기획(Specification Design)부서이다. 하지만 이들은 ‘요구사항에 대한 기획'을 수행하므로 실질적으로 시스템의 세부 내역까지 기획하는 것은 어려운 상황이기도 하다. 기획 팀장 혼자 모든 일을 처리할 수는 없다. 또한 사업 기획은 회사 매출과 제품 영향도를 기반으로 사업 품질을 향상시키는 부서이지, 제품의 세부 개발 요구사항들을 개발하고 처리하는 부서는 아니다.
그러므로 일단적으로 QA라고 알려진 품질 부서는 기획부서와 협업하여 시스템 내부의 기획(System Specification)들을 추적하기 시작하는 것이 좋다. 즉, 이가 없으면 잇몸으로, BA를 구하기 힘든 한국 시장의 특성을 인정하고 기획 부서와 품질 부서가 서로 가교 역할이 되어 BA 업무를 수행할 수 있다. 그 시작이 바로 인수기준개발(Develop Acceptance Criteria)이다.
좋은 인수 기준이란?
좋은 인수 기준의 개발이란 “코딩한 대로 작동하는가" 가 아니라, “의도했던 대로 작동하는가" 이다.
“아직 시장에 한 번도 없던 기능에 대해 어떻게 사용자의 의도를 파악할 수 있는가"라는 질문이 바로 인수기준 개발 시에 원초적으로 제기되는 의문이며, 이 부분에 대한 효과적인 해결 방법이 없기 때문에 대부분의 테스트 조직에서는 기능 작동 여부에 역량을 집중하고 있었다. 하지만 세상은 애자일 방식의 점진-반복 접근과 경량화된 문서화가 유행이 되어가고 있으다. 따라서 명세기반(Specification based)의 테스트는 탐색적(Exploratory) 테스트로 변화하였고, 탐색적 테스트 수행에 대한 핵심으로 인수기준 수립에 대한 중요성이 부각 되고 있다.
“It Works as Coded” --> “It Works as Intended.”
http://www.seguetech.com/blog/2013/03/25/characteristics-good-agile-acceptance-criteria
인수기준 개발 방향과 가이드
인수기준 개발을 TDD 방식으로 하던, Positive Testing 방식으로 하던 크게 상관은 없다. 접근 방식을 일률화할 필요는 없으며, 조직의 상황과 제품의 특성에 맞게, 그리고 조직 구성원들의 프로세스 방식에 맞게 규칙을 정하고 수립하면 된다. 다만 인수기준 개발은 개발 시작 전, 늦어도 개발 시작과 동시에 개발되기 시작되어야 한다. 개발이 완료된 후 인수기준을 개발하는 것은 초기 요구사항과 개발 산출물을 비교할 수 없으므로 의미가 없는 활동이 된다.
개념적으로 개발팀에서의 인수기준은 BDD(Behavior Driven Development) 방식을 많이 차용한다. 요구사항을 분석하여 되어야할 기능과 되지 않아야 할 기능을 분류하여, 이를 기반으로 설계하고 TDD 방식으로 개발한다. 명확한 데이터를 이용하여 요구사항을 검증해야 하는 경우는 DDT(Data driven testing) 방법을 사용한다.
< 출처 - http://blog.bughuntress.com/automated-testing/automated-testing-with-behavior-driven-testing >
이 글에서는 Behavior Driven, Test Driven, Domain Driven, Data Driven Testing 접근 방법에 대한 자세한 설명과 장단점에 대해서는 논하지 않는다.
http://en.wikipedia.org/wiki/Behavior-driven_development
http://en.wikipedia.org/wiki/Test-driven_development
http://en.wikipedia.org/wiki/Domain-driven_design
http://en.wikipedia.org/wiki/Data-driven_testing
Wikipedia에 설명된 BDD 방식을 차용한 라이브러리는 다음과 같다.
http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)
필자의 경험상 BDD 라이브러리를 이용하여 모든 사용자 이야기(User story)를 템플릿화하고 자동화할 수 있다. 그러나 Assertion은 각 제품마다 다르기 때문에 이에 대한 고려는 되어 있지 않다. 각 제품에 대한 Assertion과 Input validation, Exception 처리 등에는 추가 개발 공수가 발생하게 된다. 또한 BDD는 Model이 되는 형태에 대한 검증이 추가로 발생하게 되므로, 모델이 명확치 않은 제품에는 엄청난 추가 투입 공수가 발생하게 된다. 그러므로 도입 전에 투자 대비 효율에 대한 고려가 필요하다.
인수 기준 개발 시 주의할 점
인수기준 개발을 시작하는 조직에서 주의해야 할 점은 아래와 같다.
1. 대부분의 회사에서 요구사항은 개발하기 적합한 형태로 세분화되거나 전문화되어 있지 않을 가능성이 매우 크다. 그러므로 먼저 인수기준은 요구사항을 가능한 세분화하는 데에서 시작한다.
2. 그 다음은 세분화된 요구사항에 대한 시나리오를 세워야 한다. 사용자 이야기(User story) 수립 시 요구사항 하나로 하나의 이야기가 완성되도록 한다. 불가능할 경우 요구사항을 세분화하여 인수기준을 수립하고 사용자 이야기를 작성한다.
3. 사용자 이야기(User story)를 기획팀에 일임하고 기다리고 있지 말고, 발견한 사용자 이야기를 작성하여 기획팀과 이야기하라. 그리고 개발팀에 해당 내용을 알려줘야 한다.
4. 데이터 기반으로 인수기준이 나오는 경우는 시스템 관점에서 해석해야 한다. 모든 요구사항을 사용자 눈에 보이는 기능 위주로 분석하지 않도록 주의하라.
5. 모든 인수기준은 Testcase의 형태가 아니라 Checklist의 형태로 만든다. (Checklist가 Coverage가 낮다는 고정 관념은 버려라. 테스트를 강의하는 강사들이 자기들 밥그릇 챙기려고 하는 헛소리일 뿐이다.)
6. 버그의 개수는 인수기준 부적합 판정의 기준이 되지 못한다. (버그는 유형을 추적하고 분석하여 내부 기획과 개발의 품질을 향상시키는 데에 사용하라.)
인수 기준 수립 접근 방법
인수기준 수립은 다음과 같은 방식으로 접근하여 개발한다.
1. 사용자 이야기(User story) 도출
- 요구사항은 문서일 수 있고, 아닐 수 있다. 기다리기 보다 요구사항 제기자를 만나라. 만나는 것이 불가능하다면 의사결정권자(대부분 사업 부서)들과 회의하여 명확히 한다.
- 사용자 이야기의 제목을 선정한다. 짧은 요약으로 요구사항을 설명한다.
- 요구사항의 주요 이해관계자가 누구인지 식별한다.
- 사용자 이야기를 구성할 때는 해당 이야기를 통해 주요 이해관계자가 어떤 이득/혜택을 얻게 되는 지를 정의한다.
- 또한 해당 사용자 이야기를 통해 사업에 어떤 영향 줄 지에 대해 정의한다.
- 해당 사용자 이야기에 대한 환경이나 가정한 사항 등을 기술한다.
- 사용자 이야기를 작동되는 특정 사항이 있다면 기술한다.
- 어떤 결과가 나와야 하는 지에 대하여 한 가지 이상 기술한다.
- 도출된 사용자 이야기에 대해 이해관계자(요구사항제출자, 기획, 개발 등 모두)들과 회의하여 공유한다. (이 활동은 BA, 기획, QA 등 누가 해도 상관 없다. 다만, 각 단계에서 모두 활동이 발생해야 한다.)
2. 인수기준 개발
- 도출된 사용자 이야기를 바탕으로 하나의 요구사항이 만족해야 하는 결과 기준을 기술한다.
- 사용자 측면의 기능들만이 아닌, 시스템 측면의 (확장성과 테스트 가능성을 고려한) 비기능 측면까지 고려하여 기술한다.
- 개발된 인수기준은 반드시 프로젝트 이해관계자 모두에게 공유하고 의견을 받는다.
- 인수기준은 변경될 수 있으나, 초기 아이디어를 파기하지 않는다. 초기 아이디어와 결과가 다르다면 회고 시 이유에 대해 공유한다.
결론과 마무리
이렇게 인수기준 개발을 도입한 조직은 결과적으로 시스템에 대한 테스트를 먼저 생각하는 TDD 방식의 접근으로 발전하게 됨을 의미한다.
QA를 없애버린 조직들 대부분 처음에는 개발자들만으로 조직이 잘 돌아가는 것처럼 보이겠지만, 얼마의 시간이 지나면 결과적으로 시스템 내부의 설계가 부족하다는 부분을 깨닫게 된다. 그리고 그 해결책으로 대부분 아키텍트 조직을 만들게 되고, 그 조직은 이내 거대해 진다. 하지만 아키텍트 조직은 테스트/품질 조직이 아니다. 그들이 설계 시 테스트를 모두 구성하는 것은 (다년 간의 테스트 설계에 대한 연습과 관심이 없었다면) 매우 힘들다. 시스템 아키텍트 설계에서 가장 중요한 부분은 Testability이기 때문이다.
우리의 인수 기준도 그런 견지에서 시스템을 어떻게 테스트할 것인 가를 고려하여 개발되어야 한다. 단순히 사용자 눈에 보이는 부분만을 테스트 해서는 제품의 품질도 개발 프로세스도 개선이 되지 않는다.
