[QA] 소프트웨어 QA란?
- 5 minsQA (Quality Assurance)
우선 들어가기 앞서 한마디하자면,
해당 글은 QA에대해 썩 훌륭하게 설명된 글이 아닐 수 있음을 감안하길 바란다.
이번에 회사에서 QA부서를 신설하며 이쪽으로 업무배정을 받게 되었고,
기존에 하던 업무(분산 DB 솔루션 개발)와 성격도 꽤 다른만큼,
나또한 신입의 마음가짐으로 이제 막 공부를 시작하는 단계이다.
그 과정에서 혼자 공부하며 고민하고 정리한 내용을 포스팅하고자 한다.
QA = 테스터 ?
사실 처음 QA업무를 배정받았을 때에는, 막연히 ‘테스터’ 정도로만 생각했다.
하지만 공부를 시작해보니 이는 마치 ‘소프트웨어 엔지니어’, ‘시스템 아키텍쳐’ 처럼,
‘소프트웨어 QA’ 라는 하나의 큼직한 카테고리로 분류되어 있다는 것을 알게되었다.
또한, “테스트는 QA를 위한 하나의 과정에 지나지 않는다” 라는 느낌을 받았다.
그렇다고 테스트가 중요하지 않다는 말은 절대 아니니 오해가 없으면 좋겠다.
단지, QA = 테스터 라는 명제는 거짓이라는 의미이다.
그래서 하는일이 뭔데?
내가 이해한 바로, QA란 ‘품질 개선’ 혹은 ‘품질 관리’ 정도로 받아들여진다.
하지만,
A: “회사에서 어떤 일을 하시나요?”
B: “QA 업무를 맡고있습니다”
A: “QA가 뭐죠?”
B: “소프트웨어 품질 개선 업무를 맡고있습니다”
위의 대화에서 B가 정확히 어떤 일을 하는지 감이 오는가?
이는 메시가 본인을 단순히 ‘운동선수입니다’ 라고 소개하는 것보다 훨씬 추상적으로 들린다.
‘품질’이라는 단어 하나만으로도 상당히 추상적으로 다가오는데,
거기에 ‘개선’이라는 또다른 추상추상한(?) 단어가 합쳐졌으니 그럴만도 하다.
소프트웨어 품질?
“소프트웨어의 품질이란 뭘 의미할까?”
질문을 조금 바꿔서,
“품질이 좋은 소프트웨어란 무엇을 의미할까?”
스스로에게 질문을 던져보았고, 몇 가지 대답이 나왔다.
1. 적절한 디자인패턴을 적재적소에 적용해 확장성있고 유지보수가 용이한 코드일까?
코드레벨에서 생각해본다면 그럴 수도 있을 것 같다.
Python 코드라고 가정한다면 PEP8 규칙을 잘 지킨 깔끔한 코드라고 볼 수도 있겠고,
수많은 모듈간 각자의 역할이 명확히 정의되어 있으며,
코드간 의존성을 최소화함으로써 확장성이 뛰어나 훌륭한 마이크로 아키텍쳐가 구현된 코드라고 볼 수도 있겠다.
2. 기존의 소프트웨어에서 제공하지 않던 새로운 기능, 혹은 같은 기능을 훨씬 편하게 제공하는 소프트웨어 일까?
이번엔 코드레벨이 아닌 사용자 레벨에서 생각해봤다.
기능의 측면에서 생각해 본다면 이 또한 그럴 수도 있을 것 같다.
도저히 유지보수가 불가능할 정도로 난해하고 복잡해 확장성이 제로에 수렴하는 코드일지라도,
이는 어디까지나 개발자간에 논의되는 문제일 뿐이다.
사용자 입장에서는 기능이 훌륭하다면 상관 없을것이다.
만약 페이스북의 코드가 알고보니 초급 개발자가 연습삼아 개발한 끔찍한 스파게티 코드로 이루어져 있다고해서,
사용자들이 페이스북을 품질 낮은 소프트웨어라고 판단할까?
3. 기존의 소프트웨어보다 성능상 매우 뛰어난 소프트웨어?
마지막으로, 성능적인 측면에서 보자면, 이 또한 그럴 수도 있을 것 같다.
포토샵이나 파이널컷과 같은 유용한 프로그램들과 똑같은 기능을 제공하면서,
메모리 사용량을 5배 이상 줄여 동시에 수십개의 작업이 가능하도록 개선하였으며,
심지어 1분짜리 고화질 영상을 편집하고 렌더링하는데 10초밖에 걸리지 않는다면?
누구도 이것을 품질 낮은 소프트웨어라고 판단하지는 않을 것이다.
즉, 소프트웨어 품질이란 한 마디로 정의할 수는 없지만,
품질 좋은 소프트웨어란 결국 코드, 기능, 성능, 나아가 UI/UX적인 측면까지 포함해서,
개발자와 사용자 모두의 만족을 충족시켜 위아더 월드(?)를 이룩할 수 있는 소프트웨어가 아닐까한다.
그래서?
앞서 떠든 내용을 정리해보자면 이렇다.
좋은 품질의 소프트웨어란 결국 그냥 ‘좋은 소프트웨어’ 이다.
그리고 좋은 소프트웨어란 다시 코드, 기능, 성능부터 시작해 UI/UX까지,
더 나아가 원활한 서비스 제공 및 쾌적한 운용까지 포함해,
매우 다양한 측면에서 개발자와 사용자 모두의 요구를 충족시키는 소프트웨어이다.
앞서 QA란 품질 ‘개선’이라고 말하지 않았는가?
즉, 소프트웨어 QA의 역할은,
소프트웨어 개선을 위해 사실상 필요한 모든 영역을 모니터링하고 서포팅하는 것이다.
맥도날드에서 햄버거를 맛있게 만들어 잘 팔기 위해 단순히 재료의 유통기한만 신경쓰는것이 아니다.
패티의 굽기는 어느정도로 할지, 양배추에 얹는 드레싱은 어느정도가 적당할지, 신상 햄버거의 이름을 어떻게 지을지,
나아가 매장의 위치는 어디가 좋을지, 직원들의 유니폼은 어떤색이 좋을지, 무인시스템에 삼성페이를 지원할지 등등…
같은 맥락에서,
좋은 소프트웨어를 만들기 위해서는 코드, 기능, 성능, UI/UX, 서비스, 장애대응매뉴얼 등등 상당히 많은 부분을 신경써야 할 것이다.
물론 이것은 기획 및 개발시에 각 담당자가 신경써야하는 부분이긴 하지만,
신경쓰고 신경써도 미처 신경쓰지 못한 부분까지 신경쓰려고 노력해 개선해내는것이 바로 QA의 역할이 아닐까 싶다.
다시, QA = 테스터 ?
앞에서 QA의 역할에 대해 열심히 떠들어댔다.
그렇다면 왜 QA는 단순히 테스터가 아닌지 다시 한 번 생각해보자.
앞서 QA가 커버해야하는 영역은 상당히 넓고 복합적인 부분이라는 점을 강조했다.
하지만 이 모든 것을 한 명의 QA 담당자가 전부 커버하기란 사실상 무리가 있으므로,
코드레벨에서의 품질 개선을 담당하는 QA가 (아마도) 따로 있을 것이고,
이 담당자에게는 테스트코드를 작성하는 것이 중요한 업무중 하나가 될 수도 있다.
코드의 품질을 위해 직접 테스트코드를 작성할 수도 있을 것이며,
개발자가 테스트코드를 잘 작성할 수 있도록 편리한 테스트 환경을 제공할 수도 있을 것이다.
하지만 코드레벨이 아닌 기능적인 품질을 높이고자 하는 측면에서는,
일명 ‘기능 QA 담당자’는 비슷한 여러 소프트웨어들의 매뉴얼를 찾아 그들의 기능을 분석할 것이며,
사용자들에게 개발중인 소프트웨어의 프로토타입을 사용하게 해보고 그 반응을 취합해 더 나은 방향으로 기능을 개선시킬수도 있다.
같은 맥락에서 성능을 담당하는 QA, UI/UX 쪽을 담당하는 QA, 서비스 운영을 담당하는 QA는 모두 각자의 역할이 있을 것이다.
혹은 작은 소프트웨어라면 한두명의 QA담당자가 이러한 일련의 업무들을 도맡아 할 수도 있을것이다.
그렇기때문에 앞서 QA = 테스트 라는 명제는 잘못되었다고 말한것이다.
마무리하며
노파심에 다시 말하지만, 나는 이제 막 QA공부를 시작한 생초짜이다.
따라서 내가 적는 글들은 그냥 내가 생각한 것들은 두서없이 적어내려가는 것일 뿐이므로,
이것이 ‘소프트웨어 QA의 정의’ 라던가 ‘소프트웨어 QA시 고려해야할 3가지 원칙’ 같은 것은 절대 아니다.
오히려 이 글에 틀린 부분이 많아서 QA를 전문적으로 담당하고 계신 선배분들이 댓글로 많은 부분을 지적하고, 조언 해주었으면 좋겠다.
사실 어떻게보면 소프트웨어 QA는 소프트웨어 개발자를 포함하는 개념 같이 느껴지기도 한다.
필요할 때에는 직접 개발도 해야하고, 테스트도 작성해야 하니까 말이다.
만약 데드라인이 임박한 상태에서 개발인력이 부족해 코드 품질이 떨어질 위기라면,
기꺼이 한 명의 개발자로써 힘이 닿는 모든 부분을 서포트를 해주어야한다.
2년 6개월 전,
아무것도 모르는 상태로 처음 입사해 python, git, linux, vagrant, hadoop 등등… 생소한 기술들을 공부하고,
분산 DB 솔루션 개발이라는 업무를 맡았을때의 막막함과 설레임이 섞여있던 그 감정이 다시 비슷하게 느껴진다.
좋은 개발자는 무엇일까에 대한 고민을 수없이 해왔다.
이제는 좋은 QA 담당자란 무엇일까에 대한 고민을 수없이 해야할 것 같다.
나는 좋은 QA 담당자가 될 수 있을까? 나는 좋은 개발자가 될 수 있을까?
좋은 QA란 무엇일까? 좋은 개발자란 무엇일까?
아, 그러고보니 좋은 개발자가 좋은 소프트웨어를 만들어내는 사람이라면,
결국 두 질문에 대한 답은 같은 방향을 가리키고 있을 것 같다.
코딩장이
-장이: [접사] ‘그것과 관련된 기술을 가진 사람’의 뜻을 더하는 접미사.