@ 2009-05-16 @

메모장_좋은 테스트가 되기 위한 요건

출처; www.wisestone.kr/ 리처리(자료실)

역할을 수행할 적임자란 일반적인 기준이 아닌, 그 역할에 따라 요구되어지는 특별한 조건과 기준을 만족시키는 사람이라 하겠다. 테스터도 그들의 역할에 따라 요구되어지는 나름의 조건이 있다. 그러한 요건을 갖춘 사람이 좋은 테스터라 할 수 있다.

좋은 테스터의 요건 #

이제 소개할 조건은 어느 곳으로 부터 인정을 받아 권위가 있거나 절대적인 것은 아니다. 하지만 테스팅을 업으로 하는 필자로써는 상당히 납득이 가는 재미있는 조건이라 생각된다. (Craig&Jaskiel, Systematic Software Testing, Artech House Publishers)

• 탐구적인가?
테스트는 의구심을 가지고 문제를 가정하여 그 문제를 찾아 가는 사람이다. 이런 업무에 반드시 필요한 것이 탐구심이다. 깊이 문제를 파고자 하는 성향이 없다면 테스터로써 부적합하다.
• 능동적인가?
악의적인 마음만 먹는다면 아무리 양질의 SW라고 하더라도 수많은 버그를 찾아(?)낼 수 있으며, 문제가 많은 SW라도 버그를 찾지 못할 수 있을 것이다. 버그를 많이 찾았다고 테스트 업무를 열심히 한것은 아니다. 또한 버그를 많이 찾지 못했다고 테스트를 소홀히 한것 역시 아니다.
발견된 버그의 갯수는 SW 자체의 품질에 근간을 두고 있으며, 이러한 까닭에 테스터의 업무 성과를 단순히 버그의 갯수로 판단하기 어렵다. 이러한 테스트 업무의 특성을 고려할때 능동적인 태도야 말로 테스터에게 필요한 조건이다.
• 머리회전이 빠른가?
탐구적이고 능동적인것 만큼 필요한 것이 명석한 두뇌라 하겠다. 어리석고 능동적인 사람과 일해본 사람이라면 모두 이 요건에 공감할 것이다.

• 기능 또는 비즈니스 지식이 있는가?
지금 당신이 테스트하는 SW가 누구에게 무엇을 위해 사용되는 SW인지 인지하고 있는가? 얼리어답터를 대상으로 그들의 입소문을 이용해 시장에 진입하고자 하는 솔루션이라면, 지금 그 아키텍쳐의 옳고 그름을 논할 것이 아니라 얼마나 그들이 관심을 가지고 있는 바로 그 신 기능에 대해 테스트해야 한다.
그러기 위해서는 해당 SW의 비즈니스 목표를 꼭 알 필요가 있다.

• 섬세한가?
테스트 업무는 잘 짜여진 틀안에서 헛점을 찾는 일이다. 둔한 감각을 가진 사람은 스쳐 지나가는 헛점을 잡아내기 어렵다. 정말 둔한 사람이라면 눈 앞에 보이는 버그도 찾지 못할 것이다.

• 논리적 사고를 가졌는가?
SW의 버그는 그냥 발생하지 않는다. 반드시 그 발생의 원인이 있으며, 많은 클래스와 복잡하게 얽힌 함수의 연관관계를 통해 문제가 발생되는 것이다. 이러한 문제의 원인을 찾기 위해선 훌륭한 논리적 사고가 필요하다.
• 오픈 마인드를 가졌는가?
테스터의 쓴 비판의 수용을 위해 개발자도 오픈 마인드를 가져야 한다. 개발자의 논리적이고 타당한 변명(?)을 수용하기 위해 테스터도 오픈 마인드를 가져야 한다.

• 스트레스를 잘 다스리는가?
개발팀과의 잦은 마찰, 반복적인 회귀 테스트, 출시를 앞둔 상황에서의 빠듯한 일정. 이 모든것이 테스터에게 스트레스이다. 테스터는 스트레스를 잘 다스려야 한다!

• 프로그래머가 되기를 원하지 않지만 기술적인 지식을 가졌는가?
모든 전산을 공부한 엔지니어가 프로그래머가 되길 원하는 것은 아니다. 일부는 시스템 운영, 일부는 기획의 일을 한다. 테스팅도 그들이 선택할 수 있는 좋은 역할이다. 테스터에게 있어 뛰어난 기술력은 두말할 필요 없이 중요한 조건이다.

• 테스트 대상 SW를 아는가?
테스트해야할 대상 SW를 안다면 더할 나위 없이 좋은 테스터가 될 수있다. 평소에 그 SW를 사용했다면 더욱 좋다. 이미 SW의 문제점을 알고 있을 수도 있으며, 테스트를 위해 SW를 공부하고 분석하는 비용도 줄일 수 있다. 그래서 좋은 테스터의 후보로 사용자를 꼽기도 한다.

• 테스트 경험이 있는가?
어쩌면 오랜 개발 경력을 가진 개발자보다 이제 막 엔지니어로써의 첫발을 내 딛은 초보 엔지니어도 좋은 테스터가 될 가능성이 높다. 그들은 학교에서 오래된 개발자들이 듣지 못한 '테스트'에 대한 이론을 들었을 가능성이 높기 때문이다. 실제로 강원대학등 몇몇 대학에서 전산학과 정규 교육 과정으로 SW테스트를 가르치기 시작했다. 하지만 명심할 것은 가능성이라는 것이다.
가장 좋은 요건은 실제 그런 테스트를 해본 적이 있는가 하는 것이다. 테스트 경험이 있는 사람이야 말로 가장 좋은 테스터이다.

• 상식적인가?
비상식적인 테스터의 비상식적인 논리로 인한 비상식적인 오류. 이 SW를 사용할 사람들이 상식적이라고 가정하자! 또한 비상식적인 논리로는 누구와도 커뮤니케이션 할 수 없다.

• 팀 플레이에 익숙한가?
테스트는 혼자서 하는 일이 아니다. 여럿이 함께 모여 팀을 이뤄 일을 한다. 설령 혼자 테스트를 수행한다 하더라도, SW를 개발한 개발자와 한팀이나 다름없다. 팀 플레이에 익숙하다는 것은 좋은 커뮤니케이션 실력과 깊은 배려심을 가지고 있다는 것이다. 테스터는 어떤 상황에서도 혼자서 할 수 있는 일이 아니므로 팀 플레이에 익숙한 사람이어야 한다.

• 좋은 인간성을 가졌는가?
좋은 인간성이야 무슨 일을 하든 필요하겠지만 테스터 역시 좋은 인간성은 필요한 조건이다. 앞서 언급한 팀 플레이의 기술적 요건 많큼 좋은 인간성도 사람과 사람의 커뮤니케이션을 위한 중요한 조건이라 하겠다.

• 정략적인 기민함을 가졌는가?
네거티브한 일을 하는 테스트 업무의 특성상 필연적으로 의견 충돌을 겪을수 밖에 없다. 또한 신제품의 경우 출시 시점의 제품의 품질에 대해 갑론을박이 있을 수 있다. 테스터는 현 시점의 품질로 출시가 가능한지 여부 또한 논의해야 한다. 이러한 논의에 정략적인 기민함이 필요하다. 우직한 성품으로 회사의 사활이 걸린 제품 출시를 품질이 완벽하지 않다는 이유로 무조건 막을 수는 없는것이 아닌가.
• 유연한 사고를 가졌는가?
테스트란 업무는 틀에 박힌 정형적인 업무가 아니다. 사용자는 SW가 제공하는 많은 기능을 어떤 조합과 절차로 사용할지 예상하기 어렵다. 또한 일반적으로 논리의 흐름을 가진 프로그램 코드는 만들어진 논리의 흐름에 따라 동작하는 경우에 문제를 일으킬 확률이 적다.
버그는 그러한 흐름이 깨어질때 발생하는 경우가 많다. 이러한 SW의 특성상 유연한 사고는 필수적이다. 테스트의 한 테크닉으로 Ad-Hoc 방식이 있을 정도로 말이다.

• 소프트웨어 개발 라이프사이클을 알고 있는가?
필자가 언제나 강력하게 주장하는 바가 있다. 개발자와 테스터는 좋은 제품을 만들기 위해 노력하는, 한배를 탄 운명 공동체라는 것이다. 테스터도 좋은 SW를 개발하고자 하는 절차에 참여하고 있는 사람이다. 당연히 개발의 라이프사이클을 알고 있어야 한다.

---