* 이 글은 2024년 11월에 Medium에 작성된 내용입니다.
제 블로그에도 기제하기 위해서 동일한 내용을 가져온것 입니다. 앞으로도 이런 글들은 계속됩니다.
애자일은 조직이 제품을 개발하는데 있어서 가지는 포괄적인 철학을 말한다고 할 수 있습니다.
무엇이 더 고객중심적인지, 그것을 위해서 조직은 어떤것을 해야하는지, 그 과정에서 무엇을 감수할 수 있어야 하는지에 대한 내용을 다루며 이것을 위해 팀은 어떤 생각을 가지고 협업하며 제품을 개발해 나가는지 생각해야 합니다.
QA조직도 이러한 생각을 통해 제품과 조직에 기여할 수 있어야 합니다.
하지만 이 과정에서 위에서 말한 감수해야 하는 부분이 생기게 됩니다.
바로 애자일 원칙 중에 하나인 “변화하는 요구사항을 반영하며 유연하게 대응합니다.” 로 인한 부분입니다.
QA조직은 일반적으로 SDLC(Software Development Life Cycle) 후반부에 위치하여 업무를 수행하게 됩니다. (시작부분은 Shift Left로 인해 앞부분으로 올 수 있지만 QA활동의 끝부분은 SDLC의 후반부인 점) 그렇기 때문에 전반부에서 계속해서 수정사항이 발생하는 경우 후반부에 위치한 QA팀은 피해가 발생할 수 있습니다.
계속되는 수정으로 제품의 이해도와 안전성이 저하될 수 있으며, 변경된 스펙을 추적함으로써 발생하는 추가 비용들이 대표적인 피해라고 볼 수 있습니다.
이러한 피해에 유연히 대응하기 위해서 QA조직의 업무 철학이 필요하다고 생각했습니다.
그것이 제가 생각한 “Liqued QA Framework”. 즉 유동형 QA 프레임워크 입니다. 이것은 두가지의 강점을 가진 Framework입니다. 아래서 그 두가지에 대해 이야기 해보겠습니다.
Liqued QA Framework (이하 LQF) 은 RBT (Risk-Based Testing) 와 어느정도 유사한 구조를 가지고 있습니다. RBT는 리스크가 되는 요소에 대한 평가를 통해 해당 프로젝트가 어느정도의 리스크를 가지게 되는지 평가하게 되는데 LQF에서도 QA팀이 업무를 진행하는데 있어 영향을 받는 요소들을 선정하게 됩니다. 다양한 요소들이 있지만 대표적인 것들로 아래의 네가지가 있습니다.
- 스펙변경 (Specification Change)
- 기능복잡도 (Feature Complexity)
- 제품완성도 (Product Maturity)
- 제품사이즈 (Product Size)
그림으로 설명하면 이렇게 될 것 같습니다.
QA활동에 영향을 주는 것은 홈이 파진 모양으로 그렸습니다. 그리고 위에서 말한 4가지 요소가 작성되어 있습니다.
Stability Line이라는 것은 최소한으로 확보되어야 하는 제품의 안정성을 뜻합니다. 저 라인만큼 안정성이 확보되지 않으면 제품에 심각한 결함이 남아있다고 볼 수 있는 것입니다.
이제 이곳에 Liqued QA Framework 라는 이름에 걸맞게 물을 채울 계획입니다.
이 물은 QA의 Resource를 뜻합니다.
QA Resource란 QA 인원, QA 기간등을 아우르는 말입니다. 저는 추가적으로 QA의 도메인 지식이나 경험, 툴 사용과 관련된 숙련도 등도 포함된다고 보고 있으며 그 외에 다양한 요인에 의해서도 영향을 받을 수 있습니다.
QA Resource가 충분할 경우 일정한 안정성이 확보되며 QA활동에 영향을 주는 요인들을 모두 커버할 수 있게 됩니다.
여기서 첫번째 강점이 나옵니다.
액체처럼 “상황에 맞는 유동적인 대응" 이 가능한 것입니다.
지금은 반원 모양의 홈이지만 이것이 별모양이거나 하트모양등 (예시입니다) 일반적인 상황이 아닌 경우에는 일반적인 상황보다 면적이 크기 때문에 Resource는 많이 사용될 수 있으나 모양이 다르니 대응할 수 없다 라고 인식하는 것이 아니라 액체처럼 수용해야 한다는 것입니다.
불가능을 논하는것이 아니라 가능한것을 논의한다면 가능해집니다.
하지만 QA Resource는 한정되어있는데 4가지 요인중에 하나가 필수적인 조건을 충족시키지 못하거나 더 자주 발생하는 경우 그곳에 더 많은 QA Resource가 사용되게 됩니다. 이럴경우 전체적인 품질지표가 낮아지게 되고 이로인해 안정성 확보가 불가능한 경우가 발생하게 됩니다.
이럴경우 추가적인 Resource를 투입하며 수면을 상승시켜 안정성을 확보하는 작업을 해야 합니다. API 테스트를 추가하거나 다른 QA동료의 지원을 받는 방법으로 대처할 수 있습니다.
여기서 두번째 강점이 나옵니다.
액체의 특성상 밑부분은 고르지 못하더라도 가장 상층의 표면은 고르게 형성되어있기 때문에 일정한 수준을 유지하는 것이 매우 용이합니다.
또한 액채도 종류별로 섞이지 않고 층층이 쌓이는 모습이 될 수 있기 때문에 이러한 수준을 균일하게 올리는 것이 가능해집니다.
스펙이 변경된 부분만 안정성을 해결하거나 제품완성도 부분만 해결하는 것이 아닌, 모든 상황을 고려한 균일한 안정성 확보가 가능해 지는 것입니다.
이렇게 두가지 강점을 가지고 있는 Liqued QA Framework에 대해서 이야기 해보았습니다. 이것은 방법론이나 프로세스가 아닙니다. 팀 또는 개인의 철학에 가까운 부분이며 업무를 대하는데 있어서의 마음가짐을 뜻합니다.
우리는 변화를 환영하지만 모든것을 수용할 수는 없습니다. 우리의 리소스를 활용하는 법을 고민하고 부족할 경우 그것을 채우는 방법을 찾아야 합니다.
고객이 더 나은 경험과 원활한 이용을 할 수 있다면 우리는 그 목표를 달성하기 위한 방법을 같이 고민하고 실행해야할 책임이 있는 것입니다.
'QA' 카테고리의 다른 글
| 2024년 한해를 돌아보는 나의 회고 (4) | 2025.01.01 |
|---|---|
| Chrome(크롬) 개발자 도구 쓰로틀링(Throttling) 값 설정으로 네트워크 속도 변경하기 (0) | 2024.11.06 |
| TestRail에서 Test Case (Steps)로 import 되지 않을때 해결방법. (Workaround When Not Imported from "TestRail" to "Test Case (Steps)") (0) | 2024.07.24 |
| 제 3회 QA Korea Conference 티켓팅 시작 (0) | 2024.06.05 |
| 테스트 케이스 내에서 "기능이 정상" 이란 문구에 대한 생각 (0) | 2024.04.10 |
댓글