Agile 방법론에서 QA 프로세스의 단계를 정리해 보고, 원칙이나 주요 활동, 장단점에 대해 정리해 보도록 하겠습니다. 실제 업무에 사용했던 내용도 있고, 이번 포스팅으로 공부한 내용을 정리한 부분도 있습니다.
다른 의견이 있으시면 댓글로 의견 남겨주시면 감사하겠습니다 😎
이번 포스팅에서는 업무를 진행할 때 가장 많이 들었던 Agile 방법론에 대해 간단하게 생각해보고 QA 프로세스 관련 포스팅을 진행해보려고 합니다. Agile 방법론으로 업무를 진행했다~ Jira를 통해서 소통했다 등등 자주 들었지만 명확하게 설명하기 어려웠던 내용들을 정리해 보면서 학습해보려고 합니다.
Agile 방법론이란 ?
Agile이라는 단어 자체는 "기민한" 혹은 "민첩한"이라는 의미를 가지고 있습니다. 이 단어를 소프트웨어 개발 방법론과 연결한다면, 빠르게 변화하는 요구사항에 유연하고 신속하게 대응하는 개발 방식을 의미합니다.
그림처럼 계획 단계부터 배포까지 짧은 단위로 반복해서 수행하는 방식을 말하며 하나의 주기를 "스프린트(Sprint)"라고 명칭 합니다. 스프린트는 짧으면 1주 길면 4주 정도의 기간으로 설정되며, 구체적인 목표를 설정하고 목표를 달성하기 위해 기능 개발 및 테스트를 수행합니다.
하나의 스프린트가 종료되면 다음 스프린트를 계획하는 방식으로 진행되며, 짧은 주기로 스프린트를 반복하는 이유는 다음과 같습니다.
[짧은 주기로 스프린트 반복하는 이유]
- 빠른 피드백, 지속적인 개선 사이클
- 짧은 단위의 스프린트는 기능 개발도 빠르게 이뤄지고 고객에게 빠르게 보여줄 수 있는 환경을 제공합니다.
- 이런 환경은 고객의 피드백을 빠르게 받을 수 있다는 장점이 있습니다.
- 스프린트마다 회고를 통해서 개선 사항을 확인하고, 더 나은 성과를 낼 수 있도록 프로세스 개선과 장기적인 팀 역량 향상에 도움 되는 방식입니다.
- 변화에 유연한 대응
- 고객의 요구사항이나 우선순위가 바뀌는 경우 빠르게 대응할 수 있는 전략입니다.
- 짧은 단위의 스프린트를 진행하기 때문에 상황이 바뀌더라도 다음 스프린트에서 즉각적으로 대응할 수 있습니다.
- 위험 관리나 문제를 조기 발견하기에 용이
- 개발 과정에서 발생할 수 있는 위험 요소를 더 빠르게 식별하고 해결할 수 있는 방안을 만들 수 있습니다.
- 긴 주기의 프로젝트는 테스트나 배포가 늦어지기 때문에 문제 발견 시 해결하기 위해 더 많은 공수가 들어갈 수 있으나, 짧은 주기의 스프린트로 문제가 발생했을 때 빠르게 대응할 수 있다는 장점이 있습니다.
물론 짧은 주기의 스프린트 방식은 단점도 있습니다.
[Agile 스프린트의 단점]
- 시간적 압박으로 인한 스트레스
- 단기적인 성과나 결과물을 도출해야 하기 때문에 목표를 달성하기 위해 빠르게 작업해야 하며, 팀에 지속적인 스트레스가 쌓일 수 있고, 계속되는 스프린트 때문에 번아웃이 발생할 가능성이 높습니다.
- 스프린트 중간 발생되는 변화 관리의 어려움
- 다음 스프린트에 해결할 수 있는 이슈는 괜찮을 수 있지만, 스프린트 중간에 요구사항이 변경되어 즉각 반영해야 하는 경우 다시 일정 계획을 구상해야 하기 때문에 혼란을 겪을 수 있습니다.
- 변경된 항목을 스프린트 기간 내에 달성하려고 하는 경우 품질 저하로 이어질 수 있습니다.
- 빈번한 회귀 테스트 부담
- 짧은 주기의 스프린트는 결과물도 자주 발생하기 때문에 테스트도 자주 수행해야 합니다. 자동화 테스트 환경이 구성되어 있으면 괜찮을 수 있으나, 환경이 부족한 경우 수작업으로 테스트를 수행해야 하기 때문에 과도한 테스트 작업이 수행되어야 할 수 있습니다.
- 커뮤니케이션 과부하
- 매일 진행 상황을 공유하고, 계획, 리뷰 회의 등 잦은 회의가 있을 수 있습니다. 업무를 수행해야 할 시간에도 회의를 진행해야 한다면, 개발 작업에 투입할 시간이 줄어들어 생산성 저하로 이어질 수 있습니다.
이처럼 빠른 주기로 돌아가는 Agile 방법론은 장단점이 명확하기 때문에 업무 방식에 따라 유연하게 적용해야 효과적일 것 같습니다. 하지만 대부분 회사에서 Agile 방식으로 업무를 진행하는 것을 보면 확실한 효과와 공수 관리 등 장점의 효과가 두드러지기 때문에 더 잘 사용하려고 하는 것 같습니다.
Agile 방법론에서 QA 프로세스 진행 방식
지속적인 통합 과정에서 QA는 기존 SDLC 방식을 축약하여 스프린트마다 반복적으로 수행한다고 생각하면 될 것 같습니다.
스프린트가 진행되는 기간 중 QA의 프로세스 단계에 대해 정리해 보겠습니다.
- 스프린트 계획 회의 참여
- 기획팀의 요구사항 회의에 참여하여 요구사항을 정의 및 분석하여 잠재적 리스크를 예측합니다.
- 테스트 설계
- 기능 요구사항에 맞춰 테스트 케이스를 설계하는 업무를 진행합니다.
- 테스트 자동화 도구가 있다면 회귀 테스트나 반복적인 작업에 도움 되는 스크립트도 작성, 개선하는 작업을 진행합니다.
- 개발 및 테스트 수행
- 개발자가 코드를 작성하면 QA는 바로 테스트를 시작하며, 수동 테스트와 자동화 테스트를 함께 진행하여 결함을 신속하게 찾아낼 수 있도록 업무를 진행합니다.
- 테스트 중 발견된 결함은 즉각적으로 보고하여 개발자가 바로 수정할 수 있는 환경을 제공해 주는 역할을 수행합니다.
- 테스트 자동화 환경이 있다면 지속적인 회귀 테스트를 지원하여 제품의 품질을 관리합니다.
- 스프린트 회고 및 리뷰와 피드백
- 테스트 결과를 보고하고, 스프린트 동안 발생한 문제점을 분석하여 팀원에게 공유해 줍니다.
- 개선해야 할 사항을 도출하고 다음 스프린트에 효율성을 높일 수 있는 방안을 논의합니다.
이처럼 Agile QA의 역할은 제품 개발 시 빠른 피드백으로 신속한 결함 수정 환경을 제공하며, 회고를 통한 지속적인 프로세스 개선하여 효율적인 업무 진행할 수 있는 환경을 구성합니다. 효율적인 업무를 진행하기 위한 도구는 아래와 같습니다.
[QA에서 주로 사용되는 도구]
- Jira: 스프린트 관리 및 버그 추적을 위한 도구
- Selenium, Playwright: 자동화 테스트 도구
- Jenkins, GitLab CI/CD: 지속적인 통합 및 배포 도구
- TestRail: 테스트 케이스 관리 도구
Agile 환경에서 QA를 수월하게 진행하기 위해서는 반복적인 업무를 수행할 수 있는 테스트 자동화 환경이 가장 중요시되는 부분인 것 같습니다.
그리고, 빠르게 변화하는 개발 환경에 맞춰 기획팀과 개발팀과의 협업 및 의사소통은 소프트웨어 품질을 보장하는데 중요한 역할을 하기 때문에 원활한 의사소통이 이루어지는 것은 필수적이라고 생각됩니다.
SDLC와 Agile 스프린트를 비교하자면 아래와 같습니다.
SDLC와 Agile 스프린트 비교
| SDLC (Waterfall) | Agile 스프린트 |
| 각 단계가 순차적으로 진행 | 모든 단계가 스프린트 내에서 반복 |
| 요구사항이 처음부터 끝까지 고정됨 | 요구사항이 매 스프린트마다 변경될 수 있음 |
| 한 번 개발이 시작되면 요구사항 변경이 어렵다 | 개발 도중에도 요구사항이 자유롭게 변경 가능 |
| 테스트는 개발 후 나중에 진행 | 테스트는 개발과 동시에 진행 |
| 피드백을 받기까지 시간이 걸림 | 스프린트마다 빠른 피드백을 통해 개선 가능 |
| 한 번에 큰 규모의 릴리즈 | 각 스프린트가 끝날 때마다 작은 규모의 릴리즈 |
스프린트는 단기간에 빠르게 일처리 하는 것이지만 매번 달리기만 한다면 지쳐서 더 이상 뛰지 못하는 상황이 올 수 있습니다. 장점도 많지만 단점도 명확하기 때문에 업무 성향에 맞게 유연하게 프로세스를 구축하는 것이 가장 좋을 것 같습니다.
'QA > 업무 방식' 카테고리의 다른 글
| TC(Test Case)는 어떤 기준으로 작성하나요? (2) | 2024.12.09 |
|---|---|
| UI/UX에 도움 되는 사이트 정리 (0) | 2024.07.07 |
| 테스트 중 결함 등록 방식 공유 (0) | 2024.06.13 |
| 기능 테스트 케이스 작성 방식 (1) | 2024.06.11 |
| 소프트웨어 개발 생명 주기 정리 및 QA의 역할 (3) (0) | 2024.06.05 |
