Microsoft에서 약 20여년간 품질관리 테스트 업무와 자동 테스트 업무를 담당했던 Alan page 와 Brent Jensen 가 Modern Testing Principle 이라는 것을 작성하였습니다.
그들은 아래의 7가지의 원칙들로 하여금, 테스터들, 특히 Agile team에서의 테스터들이 좀 더 빠른 일정으로 프로덕트를 Delivery하고 팀의 품질 문화를 개선할 수 있을 것이라 생각하였습니다.
※특정 단어가 들어가면 비공개처리되는 velog의 bug성 filtering으로 인하여 특정 단어를 user 로 치환하였습니다. 원문에 대해서는 글 제일 하단의 링크에서 확인하실 수 있습니다.
1. Our priority is improving the business
우리의 우선 순위는 비즈니스를 개선하는 것 입니다.
애자일 팀의 테스터는 종종 필요없는 비용으로 간주됩니다. 팀에게 있어서 좋은 테스트 정신은 비용이 아닌 부가 가치입니다. Modern tester는 팀에 가치를 부여합니다.
테스터들은 데이터 / 고객 중심적입니다. 업무의 효율화를 추구하며 delivery process의 속도를 높이고, 고객에게 빨리 가치를 제공하기를 원합니다.
2. We accelerate the team, and use models like Lean Thinking and the Theory of Constraints to help identify, prioritize and mitigate bottlenecks from the system.
Lean thinking is a transformational framework that aims to provide a new way to think about how to organize human activities to deliver more benefits to society and value to individuals while eliminating waste. The term “lean thinking” was coined by James P. Womack and Daniel T. Jones to capture the essence of their in-depth study of Toyota's fabled Toyota Production System.
The theory of constraints (TOC) is a management paradigm that views any manageable system as being limited in achieving more of its goals by a very small number of constraints.
팀을 가속화하고 Lean thinking, Theory of Constraint와 같은 모델을 사용하여 프로세스를 단순하게 만들고, 병목 현상을 식별하여 우선 순위를 지정하고 재배치하여 병목 현상을 완화하도록 노력합니다.
테스터들은 테스트를 덜 수행합니다. 그러면서 더 나은 품질을 제공해야합니다. 개발자들은 더 많은 테스트를 수행하도록 하고, 테스터들은 개발자들에게 더 작은 단위의 많은 테스트를 진행할 수 있도록 코칭합니다. 혼자하는 작업보다, 짝을 맺어 진행하는 Pair-testing 활동을 통해 좀 더 빠르게, 좀 더 좋은 품질을 구성원이 만들어 나갈 수 있습니다.
3. We are a force for continuous improvement, helping the team adapt and optimize in oder to succeed, rather than providing a safety net to catch failures.
테스터들은 실패를 잡아내는 안전망을 제공하기 보다는 지속적인 개선과 팀이 성공하기 위해 적응하고 최적화하기 위한 활동들을 진행합니다.
좀 더 작은 단위의 코드 집약적인 테스트를 개발자가 직접 진행하도록 진행하고, 테스터가 팀의 전반적인 테스트를 코칭하고 이끌도록 점진적으로 전환하는 것이 팀 프로젝트에 있어서 품질이 향상될 것 입니다.
테스터는 더이상 버그를 잡아내는 마지막 방어선이 아닌, 고객이 프로덕트를 사용하도록 붙잡고 우리의 프로덕트를 먼저 사용할 수 있도록 전략을 주도하는 첫번째 공격라인입니다.
4. We care deeply about the quality culture of our team, and we coach, lead and nurture the team towards a more mature quality culture.
테스터들은 팀의 품질 문화에 깊은 관심을 가지며, 보다 성숙한 품질 문화를 향해 팀을 코치하고 지도 및 육성해나아갑니다.
성숙한 품질 문화를 만들어나가는 것은, 테스터 혼자서 품질을 담당하기 보다는 품질에 대한 커뮤니티를 만드는 것이 중요합니다. 협력적이고 혁신적인 커뮤니티의 구성원들은, 다른 구성원들과의 공감력을 발전시키고 이러한 협업을 통해 프로젝트와 프로젝트의 아이디어를 성장시킵니다.
구성원들은 커뮤니티에서 자신들의 지식을 공유하며 구성원들이 업무를 진행함에 있어서 어려움을 느끼게하지 않고 공개적으로 문제해결을 위해 토론할 수 있게 됩니다.
5. We believe that the user is the only one capable to judge and evaluate the quality of our product
테스터들은 오직 고객만이 제품의 품질을 판단하고 평가할 수 있다고 믿어야합니다.
고객으로부터의 평가는 현대의 테스트에 있어서 절대적으로 중요합니다. 고객으로부터의 Feedback을 수집하거나, 고객으로부터 직간접적으로 데이터를 수집함으로 인해 팀이 고객에게 응답하는 방식을 정할 수 있습니다.
이러한 방법은 수익을 창출하고 고객에게 서비스를 제공하는데 중점을 두는 모든 프로덕트의 개발 프로세스를 정할 수도 있습니다.
6. We use data extensively to deeply understand user usage and then close the gaps between product hypotheses and business impact.
데이터를 최대한 적극적로 사용하여 고객의 사용패턴을 분석하고 이해하여 제품의 기획 설계 단계에서의 가정과 비즈니스 영향도 간의 갭을 줄여나갑니다.
데이터는 최근의 테스트에서는 핵심입니다. 데이터 없이는 고객이 무엇을 하고 있고, 실제로 무엇을 선호하는 지 추측할 수 밖에 없습니다. 아무도 사용하고 싶지 않거나, 사용하지 않는 기능을 계속해서 제공하고 있는 것은, 장기적으로 고객에게 최적의 가치를 제공할 수 없습니다.
좋은 데이터가 있어야 합니다.
수집되는 데이터를 이해하고, 가공하는 것으로 데이터 사용의 중요성을 이해할 수 있을 것 입니다.
이렇게 수집하고 가공한 데이터를 이용하여 팀은 지속적이고 예측 가능한 피드백 루프를 만들어 제품의 기획과 비즈니스 영향 간의 격차를 좁히고, 좀 더 고객들이 원하는 프로덕트를 만들 수 있습니다.
7. We expand testing abilities and know-how across the team; understanding that this may reduce or eliminate the need for a dedicated testing specialist.
테스터들은 테스트 능력과 노하우를 팀 전체로 확장해나갑니다. 이것은 테스트 전문가의 필요성을 줄이거나 없앨 수 있음을 의미합니다.
테스터를 그만두고 개발자가 되어야 하나요?
아닙니다. 업무에 좀 더 집중하세요. 자기계발을 해나가며 지식을 습득하고, 비즈니스에 좀 더 공헌할 수 있도록 해야합니다. 전문가는 (Generalists) 많은 것에 대해 알고 있습니다. 품질 문화를 주도해야 합니다. 개선해야할 사항들을 찾아내고, 배움과 변화에 대해 좀 더 적극적으로 마주해야 합니다.
Summary
이 원칙을 작성한 Alan Page와 Brent Jensen 은 Agile team에서의 Tester에 대해,
단순히 TestPlan을 세우고, Testcase만을 작성하고, Test를 수행하는 것에서 좀 더 나아가,
- 팀 전체에 품질에 대한 의식을 가지게 하고,
- 개발자들과의 협업을 통해 품질의 향상을 도모하고,
- 더 넓게는 CS에서의 반응을 분석하여
- Product team에게 Improvement point를 제공하는, Multi-player로의 활동
을 제안하고 있습니다.
프로덕트의 지속적인 제공을 위해서는 Unit test 단계와 Intergration Test 단계에서의 Coverage를 끌어올려야 하는 것은 널리 알려져 있습니다만, 개발자들은 자신이 작성한 코드에 대해 자신이 테스트 코드를 작성하기 때문에 테스트 관점이 부족할 수 있습니다.
이 부분에 대해 테스터가 직접 테스트 코드를 작성하는 관점에 대해 개발자에게 코칭을 해주고 커버리지를 끌어올릴 수 있도록 지도하는 역할을 강조하고 있습니다.
End to End test 단계를 최대한 줄임으로 인하여 프로덕트 배포 주기를 짧게 가져갈 수 있을 것 입니다.
Ref.
