변하지 않는 것은 없습니다. QA도 그렇게 되어야 합니다.

어떤 업무든지 그것을 진행하는데 필요한 일련의 규칙들이 존재할 수 있습니다.
이러한 규칙들은 해당 업무를 수월하게 진행 할 수 있게 돕거나 원만한 협업이 진행 될 수 있도록 돕게되죠.

QA업무에도 이러한 규칙들이 존재합니다.
업데이트 릴리즈 프로세스라던지 테스트케이스 작성규칙, 버그티켓 작성 규칙 등이 해당 할 수 있습니다.
저는 이러한 규칙은 회사마다 팀 빌딩 시 프로세스가 다를 수 있어 차이는 있으나 한 회사에서는 불변이라고 생각했습니다.
그래서 프로세스를 벗어난 예외적 상황을 요청하거나 기존에 하지 않았던 업무를 요청할 경우 방어적인 태도를 보인적도 있었습니다.

하지만 예전부터 꾸준히 드는 생각은
"조직은 끊임없이 변하고 있는데 QA조직은 변화하지 않는 것이 옳은 것인가?" 라는 것이였습니다.
애자일이 생겨난지 20년이 지났습니다.
린(Lean) 한 조직이 계속해서 화두가 되고있습니다.
빠른 개발과 피드백을 통한 변화를 끊임없이 해야하는 상황이 이미 자리잡은지 오래입니다.

조직은 문서 작성보다는 협업을 통한 빠른 개발을, 더 빠른 주기의 업데이트를 원하고있습니다.
속도와 실행이 중요한 상황입니다.
이런 상황에서 QA조직이 더 구체적인 명세를 지속적으로 요청하거나 Sign Off 권한을 지나치게 행사하여 속도를 저해한다면 조직에 도움이 아니라 방해가 될 수 있다는 생각이 들었습니다.

QA조직도 변해야한다고 생각합니다.
더 잦은 업데이트를 가능하게 하도록 테스트 자동화 파이프라인을 만들거나 기존 BVT케이스보다도 더 빠르게 Critical 이상 급의 이슈를 체크 할 수있는 테스트케이스를 최적화하는 작업. 명세보다는 커뮤니케이션이나 협업 과정을 통해 기능을 파악하고 이해할 수 있는 방법들이 필요하다고 생각됩니다.

이렇게 속도만 쫓으면 안정성이 저해될 것이라고 생각할 수있습니다. 물론 합리적인 판단입니다. 실제로도 안정성은 하락하게 될 것입니다. 하지만 하락한 안정성 보다 빠른 업데이트를 통한 유저경험 개선과 A/B테스트 진행이 더 가치있다고 판단하고 있습니다.
극적으로 안정성이 하락한다면 물론 별도의 장치가 필요하지만 수용가능한만큼의 안정성 하락은 전략이 되는 것 입니다.
그리고 속도가 빠른 조직은 이슈가 발생해도 빠른 대응력을 보여줍니다. 물론 문제 상황을 유저가 겪게 하지 않는 것이 가장 좋지만 문제를 겪더라도 소수의 유저이거나 짧은 시간동안만 겪게하는 "빠른회복 전략"을 운용한다고 할 수 있습니다.

최근 몇년간 근무했던 회사들은 정말 속도가 빨랐습니다. 속도가 빠른 만큼 변화도 잦았습니다. 과거의 저는 이러한 변화속에서 변화없는 우직한 모습의 QA였습니다. 하지만 이제는 이러한 변화속에 녹아들기 위해 노력하고 있습니다.
예전에는 제품의 안정성을 확보하려는 것만이 주된 목적이였다면 이제는 회사와 제품 모두에 도움을 주는 QA조직이 되는 것이 목적이 되었습니다.

오늘도 더 기민하고 유동적인 QA조직을 만들기 위한 고민을 해봅니다.