1. 팀원들에게 동기 부여하라(Motivate your staff)
Testers who are excited and committed to the testing effort will be far more productive and effective than those who are not. New test managers should motivate their employees by showing them respect, asking their advice, giving them challenging assignments, providing meaningful training, rewarding their efforts, and banishing “zero defect” mentality.
테스팅 업무에 흥미를 느끼고 전념하는 테스터가 그렇지 못한 테스터에 비해 훨씬 더 효율적이며 효과적으로 업무를 진행한다. 테스트 매니저는 그들을 존중한다는 것을 보여주고, 그들에게 조언을 구하며, 새로운 업무에 도전할 기회를 주고, 중요한 교육을 제공하고, 그들의 노력에 보상을 해주고, “제로 디펙트(zero defect)”라는 개념을 일소함으로써 테스터들에게 업무에 대한 동기를 부여 할 수 있다.
2. 멘토가 될만한 상급 관리자를 찾아라(Find a senior management mentor)
A senior manager acting as a testing advocate for both you and your testing group can help obtain buy-in from other senior managers on the value of testing and its role in the entire organization. Additionally, a senior management mentor can help grease the skids when test managers need assistance in budgeting, training, conflict resolution, etc.
당신과 당신의 테스팅 조직을 옹호해 줄 수 있는 상급 관리자가 있다면 다른 상급 관리자들로부터 테스팅과 회사에서 테스트 조직이 가지고 있는 가치를 환기시킬 수 있을 것이다. 여기에 더해, 상급 관리자 멘토는 테스터 매니저가 재정이나 교육 등의 지원이 필요할 때, 혹은 다른 부서와의 갈등을 해소해 줄 사람이 필요할 때와 같은 상황에서 원활하게 난관을 헤쳐나갈 수 있도록 지원해 줄 것이다.
3. 개발자를 당신의 고객으로 생각하라(Treat the developers like your customers)
Test managers need to forge relationships with the developers, requirements specifiers, etc. Since we are measuring the quality of the product created by the developers, they, too, are interested in our results and should be treated as customers. Remember, when all is said and done, the developers and testers usually have the same goal: shipping a useful, high-quality product in a timely fashion.
테스트 매니저는 개발자나, 요구사항을 명세하는 사람들과의 관계를 돈독하게 가질 필요가 있다. 우리가 개발자에 의해 창조되는 제품의 품질을 측정하는 것처럼, 그들도 역시 우리가 만들어내는 테스트 결과에 흥미를 가지고 있으므로, 그들 역시 고객처럼 다루어져야 한다. 모든 사람들이 이렇게 말하고 또 실제로도 그렇긴 하지만, 개발자와 테스터는 일반적으로 같은 목적을 가지고 있다는 것을 항상 기억하라. 고객에게 유용하면서도 높은 품질을 가진 제품을 적절한 시점에 출시하는 것이 바로 그것이다.
4. 전략을 수립하라(Develop a strategy)
Most people immediately think of a formal document when the word strategy is mentioned, and indeed that may be required. In other cases, however, the strategy might be notes on a whiteboard or simply a conversation. In strategy decisions, test managers should include all stakeholders—developers, users, testers, etc. Examples of strategy topics to discuss include: how to choose tests, how to determine relative risk, contingencies, scheduling, staffing, CM, metrics used to measure testing status, effectiveness, etc.
‘전략’이라는 단어가 언급되면 대부분의 사람들이 즉각 정형화된 문서를 떠올리게 되는데, 실제로도 그런 정형화된 문서가 전략 수립에 있어 필요하다. 문서와 다른 형태로 ‘전략’이 나타나기도 하는데, 때로는 화이트보드에 기록되기도 하고, 때로는 간단하게 대화 중간에 나올 수도 있다. 전략을 수립함에 있어서, 테스트 매니저는 개발자, 사용자, 테스터와 같은 모든 이해당사자들을 고려해야만 한다. 전략에 포함될 만한 주제로는 다음과 같은 것들이 있다. 어떻게 테스트를 선택할 것인가? 어떻게 관련된 위험을 결정할 것인가? 이 밖에도 우발적인 사건(contingencies), 스케쥴, 스태핑, CM, 테스트 상황을 측정하기 위해 사용될 메트릭, 효율성 등이 포함될 수 있다.
5. 테스팅 관리에 필요한 메트릭을 선택하라. 하지만 그것에 너무 집착하지는 마라(Choose the metrics you need to manage testing, but don’t go overboard)
Test managers need basic metrics to measure test effectiveness, status, resources, and the quality of the product being tested. Managers may very well determine that they need more metrics than these, but it is usually better to start simple and add metrics when their need is actually identified. Discontinue metrics that are currently being collected but are unused.
테스트 매니저는 테스트되고 있는 제품에 대한 테스트 효율, 상황, 리소스 그리고 품질을 측정하기 위해 기본적인 메트릭이 필요하다. 매니저들은 기본적인 메트릭보다 더 많은 메트릭이 필요할 때 이를 잘 결정해야 하며, 실제적으로 무엇이 필요한지가 규명되고 나서 간단하게 메트릭을 추가하는 것이 훨씬 이득이다. 사용되지 않으면서도 지금도 수집되고 있는 메트릭 사용을 당장 중지하라.
6. 가능한한 자동화하라, 하지만 툴을 맹신하지 마라(Automate when possible, but don’t fall in love with your tools)
Tools have the ability to make testing groups more effective and efficient and should be used when the need for these tools has been justified. The test manager should ensure that the tool helps him implement his strategy. The tendency to use a tool just because you bought it is not normally fruitful.
툴은 테스트를 수행하는 조직을 좀 더 효율적이고 효과적으로 만들어 주는 능력을 가지고 있으며, 사용하는 툴이 팀의 요구에 합당하다고 판단이 될 때에만 사용되어야 한다. 테스트 매니저는 툴이 자신의 전략을 수행하는 데 도움이 된다는 것을 확신해야만 한다. 단지 당신이 그 툴을 구매했다는 이유만으로 툴을 사용하려는 것은 기대할 만한 성과를 가져다주지 못한다.
7. 테스팅의 효율성을 측정하라(Measure the effectiveness of your testing)
If a test manager complains of lack of time and/or resources for the testing effort, my first question is always “How effective is your testing?” New test managers should choose at least two different metrics—e.g., functional coverage, code coverage, DDP, and defect age—that help measure the effectiveness of the testing effort.
만약 테스트 매니저가 테스트 업무에 필요한 시간과 리소스가 부족하다고 불만을 드러낼 때, 그에 대한 나의 첫 질문은 항상 “당신은 얼마나 효율적으로 테스팅을 진행하나요?” 이다. 새로운 테스트 매니저는 적어도 2개 이상의 다른 메트릭을 선택해야 한다. 예를 들어, 기능적 커버리지, 코드 커버리지, DDP[1] 그리고 결함 일지(Defect age)[2] 등이 여기에 속한다. 이러한 메트릭들이 테스트 업무의 효율성을 측정할 수 있도록 도와줄 것이다.
8. 테스트 환경에 투자하라(Invest in your test environment)
Many new test managers will learn quickly that they spend an inordinate amount of time lobbying for resources for test environments and determining how to create and populate them, refresh them, etc. At the very least, this is inefficient. Some managers may even discover that the inaccuracies in their environment invalidate some of their testing or at least make the results suspect.
많은 신임 테스트 매니저들이 그들의 테스트 환경에 리소스를 더 투입해 달라고 로비하는 것과 어떻게 테스트 환경을 만들고 가꾸는지, 어떻게 환경을 새롭게 꾸밀 것인지에 대해 결정하는 것과 같은 일에 과도한 시간을 투자해야 한다는 것을 빠르게 배우게 될 것이다. 최소한 한 번은, 이런 고민들이 아무 쓸모없는 것이 될 것이다. 몇몇 매니저들은 테스트 환경이 내재하고 있는 부정확함으로 인해 그들의 테스팅을 아무 효과도 없는 것으로 만들거나, 최소한 그 결과를 의심스럽도록 만든다는 것을 발견하게 될 것이다.
9. CCB에 참석하라(Get a “seat” on the Change Control Board(CCB))
All too often, testers are omitted from the process of determining the relative effort to implement fixes. While testing, testers learn a great deal about the systems, and this insight is useful in determining the priority of fixes and enhancements. If your company has a formal CCB, the test manager should be a participant on the board. If there is no formal CCB, then the test manager should take part in the informal decision-making process of which bugs and enhancements should be given the highest priority.
너무나도 자주, 테스터들은 문제를 수정하는 것과 관계된 작업에서 무언가를 결정하는 프로세스에서 빠져있기 마련이다. 테스팅이 진행되는 동안, 테스터들은 시스템에 관해 많은 것을 배우게 되며, 이러한 고찰은 수정 사항의 우선순위를 결정하거나 이를 상향 조정하는 것과 같은 결정에 유용하게 사용될 수 있다. 만약 당신의 회사가 정형화된 CCB를 수행하고 있다면, 테스트 매니저가 그 모임에 참석해야 한다. 만약 정형화된 CCB가 없다면, 어느 버그와 수정 사항에 대해 높은 우선 순위를 부과해야하는지를 결정하는 비정형화된 의사 결정 프로세스에라도 참여해야 한다.
10. 끊임없이 테스트를 개선하라(Continuously improve the way you test)
Organizations are rarely static, so test managers should be committed to a continuous process improvement initiative. Any improvement initiatives should include participation by as many team members as possible. Needed improvements can be identified during post-project reviews or by using formal techniques like test point insertion.
테스트 매니저는 처음부터 지속적으로 테스트를 개선하는 프로세스를 수행해야만 한다. 개선의 제안은 반드시 가능한한 많은 팀 구성원들의 참여한 상황에서 이루어져야 한다. 필요한 개선은 프로젝트 이후의 리뷰 혹은 테스트 포인트 삽입(Test point insertion)과 같은 정형화된 기법을 통해서 규명된다.
'QA' 카테고리의 다른 글
| [TIG 카툰]KGC2009 - 버그의 비중에 따른 개발자의 반응 (2) | 2009.10.17 |
|---|---|
| 탐색적 테스팅에 관한 짧은 고찰 - Exploratory Testing Explained (0) | 2009.10.06 |
| 당신은 소프트웨어 테스트 전문가인가? (0) | 2009.09.04 |
| 저는 기획이 하고 싶습니다 (6) | 2009.08.30 |
| 스모크 테스트의 어원과 의미 (4) | 2009.07.26 |
