[QA : 업무 프로세스 관리] “개발 초기에 테스팅을 시작하라.”

개발 초기에 테스팅 적용하기

테스팅의 원리[3] - “개발 초기에 테스팅을 시작하라.” 라고하는데, 테스트는 개발이 완료된 후

 

소프트웨어 배포 생명 주기

소프트웨어 배포 생명 주기를 확인하고, 빌드 전 QA 혹은 테스터가 무엇을 해야 하는지 한번 생각해 봅시다.

 

개발 초기라고 하면 보통은 요구사항 분석부터 생각할 수도 있겠지만 이건 프로젝트 전체를 봤을 때 이므로 지금은 작게 한번 생각을 해보려 합니다. 개인적으로 생각하는 현실에서의 개발 초기는 배포 전 개발이 시작하는 때. 즉 이슈가 발생한 시점이라고 할 수 있습니다.

 

이슈가 발생하면 분석하고, 필요시 소스 수정으로 인한 변경 개발을 하게 될 텐데요.

이 시점들을 구분해 놓은 것이 아래 소프트웨어 배포 생명 주기 이미지입니다.

소프트웨어 배포 생명 주기

Free Alpha	프리 알파(Pre-Alpha)는 테스트 이전의 소프트웨어 프로젝트 기간 동안 수행되는 모든 활동을 가리킨다. 이 활동에는 요구사항 분석, 소프트웨어 설계, 소프트웨어 개발, 유닛 테스트를 포함할 수 있다. 일반적인 오픈 소스 개발 환경에서는 프리 알파 버전에 몇 가지 종류가 있다. 마일스톤(Milestone) 버전에는 특정한 집합의 기능이 포함되며 기능이 완성되자마자 공개된다.
Alpha	알파(Alpha) 또는 개발판은 소프트웨어 생명 주기의 한 단계로, 소프트웨어 테스트를 시작하는 첫 단계이기도 하다. 알파 소프트웨어는 불안정할 수 있고 충돌이나 데이터 손실을 일으킬 수 있다.
Beta	베타(Beta) 또는 시험판은 알파의 뒤를 잇는 소프트웨어 개발 단계이다. 소프트웨어가 기능을 완성할 때 일반적으로 이 단계가 시작된다. 베타 단계의 소프트웨어는 일반적으로 속도/성능 문제와 더불어 온전히 완성된 소프트웨어보다 더 많은 버그가 존재한다. 베타 버전은 많은 유저에게 (주로 무료로) 시험 사용을 하도록 하여 사용성이나 디자인, 성능 등에 관하여 의견을 받고 그것들을 소프트웨어의 개발에 반영하거나 미처 다 발견할 수 없었던 불편한 점을 보고해 수정하여, 정식 버전을 보다 좋게 완성하는 것을 목적으로 하고 있다. 종종 베타 소프트웨어는 기밀유지 협약을 걸 때가 있으며, MMORPG의 경우 무료라고 하는 특성을 살려, 고객 획득이나 마케팅의 수단으로써 이용하는 경우도 있다. 베타의 종류 시험은 크게 나누어 개방형 시험(오픈 베타)과 폐쇄형 시험(클로즈 베타)으로 나뉘며, 개방형 시험의 경우 일반인에게 시험판을 공개하고 시험 사용을 협력받으며, 폐쇄형 시험의 경우, 개발자의 지인이나 전 판의 사용자 혹은 공개 모집한 사용자로 수를 제한하여 시험 사용을 협력받는다.
RC	출시 후보(Release Candidate, RC)는 마지막 제품이 될 가능성이 있는 시험판으로, 상당한 버그가 나타나지 않으면 출시할 준비가 되었음을 의미한다.
RTM	RTM(Release to Manufacturing)은 소프트웨어가 고객에게 배송 및 제공될 준비가 되었음을 뜻하는 용어이다. 이 용어는 배송 구조나 배송량을 정의하지는 않으며, 단지 제품 품질이 대량 생산을 하기에 충분함을 정의한다.
GA	GA(General Availability, General Acceptance)는 필요한 모든 상업화 활동이 완료되어 웹이나 물리 매체를 통해 시장에서 이용할 수 있게 됨을 의미한다. GA와 거의 비슷한 의미의 다른 용어로 FCS(First Customer Shipment)가 있다. 썬마이크로시스템즈와 시스코와 같은 일부 기업들은 자사의 소프트웨어 버전에 FCS라는 용어를 사용한다.

우리는 배포 전 이슈를 해결하기 위해 노력을 합니다.

 

이슈를 분석하고, 디버깅하고, 테스트하고 문제가 없다고 판단되면 배포를 하게 됩니다.

프로젝트가 아닌 애자일에서 스크럼 단위로 개발 초기에 테스트를 한다라는 것을 생각하게 되면, 위와 같은 결론을 내릴 수 있습니다.

 

실무에서 개발 초기 테스팅

위와 같은 전재로 현실에서 테스팅을 어떻게 하고 있는지 사례를 말씀드리도록 하겠습니다.

 

프로젝트 관점에서 그러니까 요구사항 분석에서 리뷰를 통해 결함을 찾는다고 합니다.

네 맞습니다. 회의나 의견을 나누면서 결함을 찾고 있는데요. 보통은 요구사항을 수집하는 시점에는 QA가 참석하지 않습니다.

 

현업과 PM, 사업관리자, 개발 관리자의 관리자급 사람들이 모여서 요구사항을 논의합니다.

 

QA가 리뷰를 하는 시점은 보편적으로 화면 설계서가 프로토타입으로 나왔을 때쯤입니다.

어떤 기능이 만들어지는구나? 저 기능 테스트하려면 어떤 환경 필요하겠구나? 테스트 케이스는 이렇게 설계해야겠구나? 환경 없는데 저건 테스트 어떻게 하지? 테스트 환경 만들어 주실 수 있나요? 등등 이죠.

 

그리고 대부분의 QA나 테스터분들은 Beta 버전쯤 테스트를 시작할 수 있을 겁니다.

이론에서는 개발 초기에 테스트하라고 하는데 우리가 테스트하는 시점은 Beta에요. 그게 현실입니다.

 

프로젝트 관점에서는 Beta 시점에 테스트하는 게 보편적입니다.

 

그렇다면 Alpha 시점에는 왜 QA나 테스터가 하지 않을까요?

QA나 테스터는 Alpha 버전을 테스트하자고 하면 하나같이 "QA or 테스트할 수준이 아니네요" 할 겁니다.

개발 초기에 테스트하라는데 습관적으로 저렇게 얘기하고 있습니다.

 

그렇다면 Alpha 버전에 테스트는 어떻게 해야 할까요?

 

방법이 간단하지만 쉽지는 않습니다.

간단하게 요약하면 개발자를 테스트하도록 해야 합니다.

• 방법 1 : 빌드 전 코드 단 통합 테스트하도록 유닛 테스트 코드 삽입
• 방법 2 : 기능 명세서 기반 체크리스트 수행
• 방법 3 : 시스템이 필요 > 워크 플로워에 개발자 테스트 상태 삽입

 

방법 1 : 빌드 전 코드 단 통합 테스트하도록 유닛 테스트 코드 삽입

1. 여기서 말하는 통합 테스트는 가장 기본적인 기능 시나리오로 구성된 테스트 코드 테스트를 말합니다.

2. 통합 시나리오 테스트를 코드 단에 구축해서 빌드되게 하는 것입니다.

3. 소스 빌드를 시작하면 CI에서 통합 시나리오 테스트 코드 수행 후 빌드가 완료될 수 있도록 하는 것입니다.

- ex) 회원 가입 > 로그인 > 상품 구매 > 결제 > 로그 아웃

 

실제로 QA에서 통합 테스트 시나리오를 작성하고, 시나리오에 대한 테스트 코드를 작성하여 구축한 경험이 있습니다.

- 빌드 안정성을 확보 할 수 있음

- 기본 기능에 대한 리그레이션 후 빌드함.

 

하지만 이 방법은 개발팀의 의지가 있어야 합니다.

QA에서 필요하다고 하면 개발팀은 필요성을 느끼기는 하지만 급하지 않기 때문에 차일피일 미루다가 안 하는 경우가 더 많습니다.

 

필자도 해당 방법을 쓰는 회사는 단 한 회사가 있었고, 완벽하지 않았어도 시도한 회사(Medit)는 있었습니다.

 

 

방법 2 : 기능 명세서 기반 체크리스트 수행

이 방법은 가장 현실적인 방법입니다.

1. 기능 명세서를 기반으로 체크리스트를 작성하고, 빌드 전 체크리스트 확인 후 빌드를 수행하는 방법입니다.

2. 체크리스트의 작성은 개발자가 해도 좋고, 필요에 따라 QA가 작성하는 경우도 있습니다.

3. 누가 작성하는 것은 중요하지 않으며, 빌드 전 기능에 대한 체크가 이루어졌다는 게 중요한 포인트입니다.

 

이 방법은 개발자의 신뢰도가 중요합니다.

테스트하지 않고, 테스트했다고 체크해서 빌드하면 확인할 방법은 없기 때문입니다.

 

 

방법 3 : 시스템이 필요 > 워크플로워에 개발자 테스트 상태 삽입

방법 2를 보완한 방법으로 시스템의 워크플로워에 개발자 테스트 상태를 넣는 방법입니다.

 

ex) 테스트 프로세스

Open > Analysis > In Progress > Checked > Resolved > Tested > Closed

 

여기서 Checked는 개발자 테스트를 의미합니다.

개발자 테스트 후 소스 커밋&머지가 될 수 있도록 구성하는 것이 가장 바람직합니다.

 

실제로 경험해봤을 때는 시스템 구축에 비용이 들겠지만 이슈 관리 도구를 사용하고 있다면 가장 좋은 방법이라 할 수 있습니다.

 

 

결론

"개발 초기에 테스팅하라" 프로젝트 범위로 보면 QA가 프로젝트 초기에 참여해서 혹은 리뷰를 통해 발견하는 결함은 알 수 없는 영역입니다. 

 

그렇다면 현실적인 개발 초기에 테스팅하라라는 것은 위에서도 언급했듯이 프로젝트가 아닌 이슈가 발생한 시점입니다.

이슈를 해결하기 위해 분석하고, 분석한 내용을 공유하는 것도 초기에 테스팅을 한다고 할 수 있습니다.

 

그리고 가장 현실적으로 개발 초기의 테스팅은 바로 빌드 전이라는 것을 말씀드리고 싶은데요.

 

보통 QA나 테스터는 빌드 후 테스팅을 많이 수행하고 있습니다.

그전에 무슨 일이 있었는지는 공유도 잘 되지 않고, 어디서 어떻게 변경이 있었는지도 잘 모르는 상태로 빌드를 받게 됩니다.

 

빌드를 기준으로 봤을 때 빌드 전 테스팅을 할 수 있도록 가이드하고, 할 수 있는 방법을 개발자에게 알려 주도록 합시다. 알려 주는 정도, 혹은 권고로 반영되지 않으면 프로세스를 정립해서 의무화하도록 합시다. 

 

PS : 실제 경험을 바탕으로 작성되었으며, "개발 초기에 테스팅하라"라는 원리의 사례를 말씀드렸습니다. 사실 간단한 일이지만 이행하기는 정말 어려운 일입니다. 일보다는 사람을 설득해야 하는 일이기 때문인데요. 초기 품질을 어느 정도 확보하기 위해서는 꼭 필요한 절차이니 검토해 보시기 바랍니다.

 

---

 

Related References

What is Early Testing and Why to Start Testing Early in SDLC (Practical)

요약 : 애자일 프로세스, 프로세스, 프로세스 마이닝, 소프트웨어 qa, 웹 qa, 앱 qa