"내일 당장 테스트를 시작해야 하는 상황인데, 테스트 기간은 야근을 해도 부족할 정도로 짧다.

그런데 비즈니스적으로 중요한 스펙이 포함되어 있어 많은 기능과 연결되어 있어서

테스트를 가볍게 할 수 없는 상태이고, 마감 기한은 절대로 미루거나 조절할 수 없는 상황이다.

이럴 때 나는 어떠한 전략을 세울것인가?" 라는 질문을 받았을 때 사실 머릿속이 하얘진 경험이 있다.

 

내일 당장 테스트를 들어가야하니 자동화를 설계하거나 코딩을 할 수 있는 시간도 없을테고,

중요한 스펙이라고 했으니 애드훅 테스트나 몽키 테스트와 같은 방법을 사용할 수 없는 상황이다.

 

결론적으론 "우선순위가 높은 부분을 먼저 테스트하고 나머지는 체크리스트로 진행한다." 로 마무리했지만,

그 이후로도 가끔 효율적인 테스트 프로세스에서 할 수 있는 방법이 더 있을까? 하고 고민해 보았다.

결론적으로 내가 생각한 전략은 아래와 같다.


  1. 우선순위를 설정하자.
    1. 비즈니스적으로 가장 중요한 기능, 사용자가 가장 많이 사용하는 기능 등을 먼저 테스트한다.
    2. 이를 통해서 주요 리스크를 최적화하는 동시에 최소한의 안정적인 품질을 보증할 수 있다.
  2. 리스크 기반 테스트를 사용하자.
    1. 문맥적으로 우선순위를 설정하는 것과 비슷한 늬앙스이긴 하다.
    2. 리스크 기반 테스트는 프로젝트 시간, 비용, 자원에 제한이 있어 자원을 최적화 할때 좋은 방법이다.
    3. 일반적으로 "장애 발성 가능성 x 장애로 인한 영향" 이 가장 큰 것부터 우선순위를 지정한다.
  3. 테스트 케이스를 정리 및 최적화한다.
    1. 중복되거나 덜 중요한 테스트케이스를 제외하고 핵심적인 테스트 스위트를 선택한다.
    2. 테스트 범위를 줄이면서도 품질을 유지할 수 있다는 장점이 있다.
  4. 다양한 도구를 활용하자.
    1. 이슈 및 버그 추적 시스템을 적극적으로 사용하면 이슈 관리에 들어가는 시간을 줄일 수 있다.
    2. 나는 다른 협업툴을 주로 사용했지만, 일반적으로는 Jira 를 손에 꼽을 수 있다.
  5. 테스트 커버리지 맵을 작성한다.
    1. 테스트 커버리지 맵은 테스트할 기능이 얼마나 테스트되었는지(커버리지) 를 표현한 도구이다.
    2. 테스트의 우선순위에 맞춰 누락된 부분을 쉽게 식별할 수 있다.
    3. 리소스의 효율적인 관리 및 개발자/기획자분들과 커뮤니케이션에 객관적 지표를 보여줄 수 있다.
    4. 표, 그래프, 매트릭스 등 다양한 표현 방법을 사용하여 직관적으로 보여주도록 한다.
  6. 커뮤니케이션을 효율적으로 하자.
    1. 협업에 있어서 중요하다고 강조해도 부족한 것은 커뮤니케이션이다.
    2. 팀원들과 긴밀히 협력하고 테스트 진행상황을 지속적으로 공유함으로써 빠른 대응이 가능하다.
    3. 특히 팀원들간의 유대감은 테스트 진행 상황을 투명하게 관리하는 데 좋은 기반이 된다.
    4. 배달의 민족의 문화 중 "잡담을 많이 나누는 것이 경쟁력이다." 를 참고하면 좋을것 같다. (좋아하는 글이다.)
  7. 개발 완료된 기능부터 병행 테스트를 한다.
    1. 개발팀과 원활히 커뮤니케이션하며 병행 테스트 함으로써 시간 효율을 극대화할 수 있다.
    2. 다만 위 경우, 테스트 관리가 복잡해질 수 있는데, 이럴 때 테스트 커버리지 맵을 사용하면 도움이 된다.

이렇게 내가 생각하는, 효율적인 테스트 프로세스를 위한 전략은 위와 같다.

조금 더 준비할 시간이 많아진다는 가정 하에 자동화를 도입, 새로운 도구 사용, 테스트케이스를 최적화 등 

다양한 방법이 있겠지만, 사실 협업에서는 시간이 충분히 주어지는 경우가 드물다.

최근에 좋은 글을 발견했는데, 품질비용 모델의 발전이라는 글을 읽은 적이 있다.

개발자에서 아키텍처로 스터디를 진행하면서 품질비용이라는 개념에 대해 알게 되었는데,

전통적 품질 모델은 실패비용과 예방비용이 서로 반비례의 관계를 가지고 있어, 최적의 품질비용 선이 있었다.

그러나 새로운 품질비용 곡선에서는 예방에 더 많은 중요성을 부여하고 있는 것을 볼 수 있다.

문제 발생 전 예방을 통해, 수정 비용을 줄이는 동시에 전체 개발 과정의 효율성을 향상시킬 수 있는 장점이 있다.


먼저 문제 발생 후에 생기는 기업 이미지나 신뢰성의 타격과 같은 숨겨진 품질 비용을 무시할 수 없다.

또한 소프트웨어 개발 라이프사이클에서 초기 단계에 결함을 발견하면, 수정비용과 노력이 적게 들어가기 때문에

예방과 더불이 초기 단계에서의 품질 확보와 주기적인 평가 활동이 과거보다 더욱 중요해 졌다고 생각한다.

 

참고 링크

리스크 기반 테스트 : https://kairoka-sqa.tistory.com/25 

우아한 형제들 문화 : https://www.woowahan.com/company/culture

품질비용 모델의 발전 : https://m.blog.naver.com/bs2k/221493859576