by Claire Reckless
가끔 정말 좋은 글을 읽다 보면 바로 번역해보고 싶다라는 생각이 들 때가 있습니다.
So, What is Software Testing? 도 그런 글 중의 하나입니다. 오랫동안 이어져온 소프트웨어 테스팅에 대한 정의와 철학이 잘 정리되어 있는 글입니다. 모쪼록 테스팅이란 직업과 아이덴티티에 대해 고민하고 계신 분들에게 도움이 되길 바랍니다.
번역과 블로그 포스팅에 대해서는 원 저자인 Claire Reckless와 Ministry of Testing 측의 허락을 받았습니다.
Happy Testing!
‘소프트웨어 테스팅이 뭘까?’라는 질문을 받는다면 뭐라고 답할 수 있을까? 단 몇 줄로 대답하기란 결코 쉬운 일이 아닐 것이다.
소프트웨어 테스팅이 무엇인지, 그리고 테스터가 어떤 일을 하는지에 대해 여러 오해가 있어왔다. 심지어 테스터들 스스로도 그러한 오해를 조장하는 데 일조해 왔다. 테스팅은 하나의 스킬로, 하나의 직업군으로 끊임없이 진화해왔다. 이 글에서는 소프트웨어 테스팅이 어떤 모습이어야 하는지, 그리고 어떤 모습이 되어서는 안되는지에 대해서 알아보기로 한다.
소프트웨어 테스팅은 이런 것이다
조사(Investigation)
‘조사’라는 단어를 사전에서 찾아보면 ‘구조적인 사고와 밀접한 관찰을 통해 어떤 사물을 공부하거나 살펴보는 것’[1]이라고 정의하고 있다.
테스팅 과정은 당연히 조사 과정이어야 한다. 때론 기대 결과를 예측할 수 없는 경우도 있지만 다른 사람들이 올바른 의사 결정을 할 수 있도록 정보를 제공해 주는 것이야 말로 우리가 하는 일 그 자체다. 이는 테스팅이 단순히 명시된 기대 결과와 실제 결과를 비교하는 것 그 이상의 일이라는 것을 의미한다. 늘 비판적으로 사고하고, 쉽지 않은 질문을 던지며, 어떤 리스크가 있는지 인지하고, 면밀하게 관찰하기 전에는 사소해 보이는 것들이 더 중요하고 좀 더 깊은 조사가 필요하다는 것을 주지하고 있어야 한다.
탐색(Exploration)
현실에서 절대 충족될 수 없는 요구사항들을 늘 존재하기 마련이다. 아울러 일반적이고 추상적인 요구사항들 중에는 딱히 언급되지 않거나 생략되는 것들도 부지기수다. 아무리 요구사항이 포괄적이라고 하더라도 모든 요구사항이 궁극적으로 정리되어 있는 목록은 존재할 수 없다. 소프트웨어가 수행할 모든 일을 완벽하게 파악하는 것도 불가능하다. 탐색적 테스팅이 필요한 이유가 바로 이것이다.
탐색적 테스팅은 학습과 테스트 설계, 그리고 테스트 수행을 동시에 하는 것으로 정의된다.[2] 테스터는 애플리케이션을 탐색하면서 새로운 정보를 찾아냄과 동시에 이를 학습하고, 지속적으로 테스트 해야 할 새로운 것들을 찾아낸다. 탐색적 테스팅은 테스터 혼자서도 수행이 가능하며 때로는 두 사람이 짝을 지어서도 수행이 가능하다. 개발자와 짝을 이뤄 탐색적 테스팅을 수행하는 것도 가능하다.
소프트웨어 테스팅이라는 작업이 단순히 테스터가 미리 준비된 테스트를 수행하거나, 혹은 Pass와 Fail로 양분될 수 있는 테스트 케이스를 수행하는 작업으로 인지되어서는 안된다. 테스팅을 통해 유저 스토리나 요구사항들이 이 당연히 구현되어 있다는 것을 확인하는 것도 중요하지만, ‘거부 기준(rejection criteria)’을 기반으로 인수 테스팅을 수행해 보는 것도 도움이 될 것이다. 인수 기준을 충족하지 못하는 경우 제품을 인수하지 못하는 것은 당연하다. 하지만 이를 충족한다고 해서 제품에 문제가 없다는 것을 의미하지는 않는다.
확인하고 검증하는 작업은 반드시 탐색과 조사와 결합되어 수행되어야 하며, 항상 ‘만일 제품에 이런 일이 발생한다면 어떻게 될까?’라는 질문을 염두에 두고 수행해야 한다. 이런 질문은 테스트를 시작하기 전에는 그 답을 알 수 없으며, 사전에 작성된 테스트 케이스만 가지고는 커버할 수 없는 영역들이다.
완화(Mitigation)
우리가 테스트를 수행하는 이유는 소프트웨어에서 발생하는 이슈와 리스크, 그리고 이와 관련된 정보를 발견해 이들을 제거하기 위한 것이다. 궁극적으로는 이런 활동을 통해 사용자들이 부정적인 경험을 하지 않도록 하는 것이 목적이다. 여기에는 아래와 같은 행동들이 포함된다.
● 버그 수정
● 최초 요구사항을 재평가하고 변경하기
● 제품 안에서 활용 가능한 사용자 지원 제공하기
● 사용자 문서 작성하기
● 이해관계자들과 알려진 이슈에 대해 커뮤니케이션하기
아무리 간단한 소프트웨어라고 하더라도 사용자에게 발생할 가능성이 있는 모든 이슈를 완벽하게 제거하는 것은 불가능하다. 하지만 테스팅을 통해 이런 이슈를 경험하게 되는 리스크를 줄이거나 해당 이슈의 심각도를 낮추는 것은 가능해진다.
가치 있는 일(Valuable)
소프트웨어 테스팅은 소프트웨어 개발 과정 안에서 그 자체로 가치 있는 일이지만 때로는 그 자체가 가지고 있는 예측 불가능함과 창조적인 면으로 인해 쉽게 오해의 대상이 되었다.
개발자들은 작업 산출물로 코드를 작성하며, 분석가들은 요구사항이나 문서를 작성한다. 하지만 테스터의 산출물은 구체적으로 측정하기 곤란한 경우가 많다. 그로 인해 테스터들은 그들의 업무 계획이나 업무 진행 정도, 그리고 산출물에 대해 힘들고 어렵게 커뮤니케이션하는 경우가 빈번하다. 이런 점들로 인해 테스팅을 잘 모르는 사람들은 테스터들이 어떤 일을 하는지, 또한 어떤 방식으로 그 일을 수행했으며, 또 그 이유는 무엇인지 이해하기 힘들어 하는 경향이 있다. 이런 점들로 인해 테스터와 테스팅의 진정한 가치에 대해 의문을 가지는 사람들이 생기는 것이다. 한 사람의 테스터도 없이 개발자 들로만 소프트웨어 개발을 진행하는 회사들이 있을 정도다.
테스터들의 산출물을 정량적으로 측정할 수 없다는 이유로 테스트 케이스를 측정의 도구로 삼으려는 사람들이 있다. 확실히 테스트 케이스는 유형의 자산이며 측정이 가능한 산출물이다. 하지만 테스팅의 가치는 테스트 케이스의 가치를 넘어서는 것이다. 탐색적 테스팅이 수행되는 동안에는 사전에 정의된 일련의 테스트 케이스가 필요하지 않을 수도 있다. 테스터들은 사전에 정의된 경로를 따라가지 않아도 더 흥미진진한 결함을 발견하고는 한다.
이런 이유로 사람들은 측정 가능한 지표들, 예를 들어 등록된 버그의 숫자, 작성되고 수행된 테스트 케이스의 양과 같은 지표에 의존해 테스팅의 가치를 평가하려고 한다. 제품의 품질을 측정하기 위해 고유한 지표를 마련하기도 하고, 더 나아가 개발자와 테스터를 평가하기 위한 지표를 따로 작성하기도 한다. 하지만 이런 지표들은 때로는 엉뚱한 것에 초점이 맞춰 지기도 하고, 때로는 오해를 사기도 한다.
테스팅은 단지 코드가 작성되는 단계뿐만 아니라, 모든 개발 단계에서 가치가 있는 일이다. 아래와 같은 것들이 테스트 대상에 포함될 수 있다.
● 아이디어
● 요구사항
● 디자인
● 가정
● 문서
● 인프라스트럭쳐
● 프로세스
질문을 던지고, 탐색하고, 이런 모든 일들을 비판적으로 받아들이는 것이야 말로 테스터라는 직업이 하는 일이다. 이런 과정을 통해 개발 후반에서나 드러날 버그를 좀 더 빨리 찾아낼 수 있게 되는 것이다.
커뮤니케이션
테스터가 수행하는 일에서 큰 비중을 차지하는 것 중의 하나가 바로 커뮤니케이션이다. 테스터는 소프트웨어 제품의 품질에 관한 정보를 제공하는 일을 하는 사람들이다. 따라서 올바른 의사결정이 이루어 질 수 있도록 이런 정보를 정확하게 전달하는 일이 아주 중요하다.
어떤 사람들은 단순히 몇 가지 테크니컬한 스킬만을 가지고 테스터로 일을 시작하겠지만, 실무에서 다른 사람과 원활하게 커뮤니케이션하는 능력과 전달하고자 하는 바를 명확하게 전달하는 능력은 그 어느 스킬보다도 중요하다.
테스터들은 애매모호한 부분이 없도록 정확한 단어를 적재적소에 사용해 매끄러운 말과 문장을 만들고, 이를 통해 오해가 원인이 되어 발생하는 리스크를 미연에 방지할 수 있어야 한다. 항상 말하려는 의도와 말이 일치하는 것이 아니다. 종종 그럴 것이라는 가정 하에 커뮤니케이션이 수행되며 이런 불충분하고 어설픈 커뮤니케이션으로 인해 부적절한 행동이 취해지게 되는 것이다.
서로 다른 지위에서 서로 다른 역할을 수행하고, 서로 다른 지식을 가진 사람들과 정기적으로 커뮤니케이션할 필요가 있다.
● 개발자 – 그들이 만든 소프트웨어 제품에 대해 질문을 던지고 그에 대한 지식을 습득해야 한다. 기술적인 면을 이해하기 위해 우리가 발견한 버그와 해당 버그들을 어떻게 재현할 수 있는지에 대해 설명해 줄 필요가 있다.
● Product Owner – 요구사항을 정확하게 이해하기 위해, 유즈 케이스에 대해 질문하고 유저 시나리오와 관련된 정보를 제공한다. 이들에게 필요한 정보를 제공함으로써 제품 배포에 관한 적절한 의사 결정을 하도록 만들 수 있다.
● 테스터 – 팀 단위로 일하는 테스터라면 동료들과 이슈에 관해 논의하고, 이를 통해 의사 결정을 진행하는 것이 아주 중요하다. 신규 입사자나 주니어 테스터를 훈련시키거나 이들이 난관에 부딪혀 도움이 필요하다면 그들이 어떤 일을 수행해야 하는지 정확하게 설명해 줄 필요가 있다.
● 사용자/고객 – 이들이 원하는 바가 무엇인지, 그리고 이들이 겪고 있는 이슈들은 어떤 것인지 정확하게 인지하고 있어야 한다. 만약 고객 지원 업무까지 함께 수행하고 있다면, 사용자와 고객들이 이해할 수 있는 방식으로 트러블슈팅 혹은 문제를 해결하는 방법을 설명할 수 있어야 한다.
● 매니저 – 어떤 일이 완료되었고 어떤 일이 아직 완료되지 않았는지를 적절하게 보고해야 한다. 관련된 리스크와 결과, 기간도 함께 보고되어야 한다. 어떤 제안을 하고 싶다면 그 아이디어와 이로 인해 어떤 영향이 발생할 것인지를 명확하게 설명할 수 있어야 한다.
서면 커뮤니케이션 역시 구두로 커뮤니케이션하는 것만큼이나 중요하다. 휘황찬란한 표현을 사용해 문서를 만드는 것이 어려운 일은 아니지만, 결국은 아무도 읽지않는 불필요한 문서로 판명되는 일도 빈번하게 발생한다. 커뮤니케이션의 상대방에게, 프로세스에, 그리고 프로젝트 전체에 가장 효율적이고 적합한 커뮤니케이션을 수행할 수 있도록 노력해야 한다.
잠재적으로 영구하다
모든 테스팅은 일종의 샘플링이다. 아주 작은 제품이 아닌 이상, 입력 가능한 값에 기반해 상상할 수 없을 정도로 수많은 파라미터를 생성할 수 있다. 어떻게 지금 수행하는 테스트가 가장 중요한 것이라고 확신할 수 있을까? 모든 것을 테스트한다는 것은 절대 불가능한 명제다.
결국 제품의 일부분만 테스팅 될 수 밖에 없고 이로 인해 어떤 부분을 테스트 해야할지 결정하는 일이 매우 중요하며 이것 자체가 우리의 일임을 깨달아야 한다. 또한 그 이유와 과정을 다른 사람들에게 충분히 설명할 수 있어야 한다.
테스팅이 그래서는 안되는 것들
간단하다
테스팅은 종종 누구나 할 수 있는 일로 간주되고는 한다. 누구나 제품을 탐색할 수 있고, 이에 대한 질문을 던질 수 있으며, 단계별로 테스트 케이스를 수행할 수 있고 요구 사항이 실제로 구현되었는지 확인할 수 있다는 측면에서는 부인할 수 없는 사실이다. 하지만 이러한 일들을 체계적인 방식으로 탁월하게 수행하기 위해서는 스킬이 필요하다.
많은 사람들이 테스트 케이스를 작성할 때 ‘누구나 쉽게 이해하고 이를 수행할 수 있어야 한다’라고 말한다. 이런 말로 인해 테스팅이 아주 간단하다는 잘못된 인식이 더해졌다. 우리는 단지 인수 기준에 적합한 테스트 케이스를 작성한 것뿐이다. 그렇지 않나? 탐색적 테스팅을 수행하는 테스터들에게는 이 말이 그대로 적용되기 힘들다.
검증은 간단한 일이 아니다. 어떤 것들이 검증되어야 하는지 결정하고 이를 자동화하는 업무는 그야말로 단순함과는 거리가 먼 일들이다. 이런 일들을 수행하기 위해서는 자동화 프레임워크와 코드의 작동 원리, API 동작 원리, 그리고 셀레늄과 같은 툴에 대한 이해가 필수적이다. 이해하고 활용할 수 있어야 하는 기술의 범위가 상당한 것이다. 여기에 더해 어떤 경우에 테스트 자동화가 유리하며, 또 어떤 경우에는 그렇지 않은지 판단할 수도 있어야 한다.
탐색적 테스팅 역시 간단한 일이 아니다. 탐색적 테스팅은 단순한 애드혹 테스트도 아니며, 소프트웨어에서 어떤 일이 일어나는지 보기 위해 단순히 소프트웨어를 가지고 노는 일도 아니다. 탐색적 테스팅은 구조적이며 기술적인 행위다. 애플리케이션을 좀 더 깊게 탐색하기 위해서는 제품에 사용된 아키텍처와 기술에 대한 이해가 필요할 뿐만 아니라, 각기 다른 사용자들이 어떤 생각을 가지고 제품을 사용하는지에 대한 심리적인 이해도 필요하다.
자동화로 대체 가능하다
“이제 더 이상 사람이 수행하는 테스트는 필요하지 않다. 모든 테스팅을 자동화할 수 있기 때문이다.” 최근 들어 트위터나 인터넷 포럼, 기사에서 이와 같은 주장을 쉽게 발견할 수 있다. 테스팅은 그 자체가 어느 정도 탐색적이고 조사가 필요한 행위이므로, 자동화로 모든 것을 대체할 수 없다. 현재의 컴퓨터는 사람과 똑같은 방식으로 제품을 탐색할 수 없다.
자동화가 가능한 것은 개별적인 검증 업무에 국한된다. 아무리 동일한 검증 과정이라고 하더라도 컴퓨터가 수행하는 경우와 사람이 수행하는 경우는 엄밀하게 말하자면 동일할 수 없다. 사람은 하나의 프로시저가 수행되는 동안 다른 일도 수행이 가능하며, 뭔가 잘못되어 가고 있다는 것을 느끼고 사전에 더 신경을 쓸 수 있고, 단순한 Pass와 Fail이 아닌 그 이상의 피드백을 제공할 수 있다. 컴퓨터는 사전에 작성되거나 프로그램된 작업만을 수행할 수 있다. 테스트 전략이라는 큰 범위에서 본다면 테스트 자동화만큼 유용한 기법도 없다. 하지만 현재 이 시점에서 사람을 대체할 수 있는 정도는 결코 아니다. 자동화를 통해 할 수 있는 일은 사람이 할 수 있는 일과 극명하게 다르다.
테스터는 그들의 작업을 원활하게 수행하기 위해 테스트 자동화 툴을 포함하는 여러 툴을 사용할 수 있어야 한다. 데이터를 생성하고, 반복적인 동작을 수행하고, 테스트 산출물을 분석하기 위해 툴을 커스터마이징해야 하는 경우도 있을 것이다. 툴을 사용해 우리가 수행하는 작업을 조금 더 쉽게 만드는 것이야말로 가장 유용하게 툴을 사용하는 방법이다. 우리의 자리를 대체하는 것이 아니다.
품질을 높인다
테스터는 절대, 품질을 직접 변경하는 그 어떤 행동도 수행하지 않는다. 테스트를 수행한다고 해서 제품의 근간이 되는 코드가 변경되는 것이 아니므로, 소프트웨어의 품질은 테스트 이전과 이후 동일하다. 소프트웨어의 품질은 개발자의 어떤 행동에 의해 변경되며, 우리가 테스트를 수행한다고 해서 제품의 품질을 바꿀 수 있는 것은 아니다.
소프트웨어 개발 단계에서 테스팅을 수행할 때만 품질에 신경을 써야하는 것은 아니다. 소프트웨어 제품의 라이프사이클 내내 항상 품질을 염두에 두어야 하며, 팀의 모든 구성원들이 제품의 품질에 책임을 져야 한다. 테스터들은 고유의 스킬을 사용해 모든 단계에서 다른 사람들과 협력한다. 하지만 테스팅이 단순히 우리만 수행하는 일이 되어서는 안된다. 모든 팀이 수행하는 업무이기도 해야한다.
테스팅을 통해서, 혹은 그 다음에 이어지는 개발자의 수정을 통해 그 결과로 제품의 품질이 향상되었을 거라는 가정을 해서도 안된다. 모든 것을 테스트할 수 있는 것이 아니므로, 이슈가 발생하지만 실제로는 우리가 테스트하지 못한 부분도 있을 것이다. 어떤 변경이나 인지하지 못하는 원인으로 인해 품질은 더 나빠질 수 있지만 이슈가 발생하기 전까지는 우리는 그 사실을 알 수 없다. 또한 정확하지 못한 요구사항 정의로 인해 테스터들은 제품이 배포할 수 있을 정도로 충분한 품질을 가지고 있다고 판단한 반면, 실제 엔드 유저들은 제품의 품질이 형편없다고 생각할 수도 있다. 보는 관점에 따라 품질이 달라질 수도 있는 것이다.
품질은 ‘어떤 사람에게 중요한 가치’로 정의된다. 일반적으로 품질은 측정하기 쉽지 않다. 따라서 불가능하지는 않겠지만, 단순히 테스트만을 통해 품질을 향상시킬 수 있다고 말하긴 힘든 일이다.
늘 똑 같은 일만 수행하고, 상상력이 부족한 일이며, 국한된 역할에만 어울린다
아주 높은 비율로, 가장 흥미로운 버그들은 탐색적 테스팅 세션 기간에 발견된다. 동일한 일련의 테스트를 계속 반복해서 수행하는 것은 곧 새롭고 흥미로운 정보를 찾아낼 가능성이 낮다는 것을 의미하며, 만일 이런 테스트들을 수동으로 수행하고 있다면 그 가능성은 더 커진다.
테스팅에 있어서 모든 곳에 적용할 수 있는 베스트 프랙티스란 존재하지 않는다. 해당 산업과 정황에 맞는 적절한 테스트를 찾아내려고 노력할 필요가 있다.
테스트를 수행하는 새롭고 창조적인 방법을 찾아내는 것 역시 테스터가 수행해야 하는 역할이다. 다양한 실험을 통해 가장 적합한 툴을 찾아내고, 새로운 스킬과 기술을 습득하며, 프로젝트에 도움이 되는 일을 수행함으로써 늘 학습하며 늘 새로운 스킬을 익힐 수 있을 것이다.
프로젝트의 성공에 있어서 필수적이다
테스터 없이도 성공하는 프로젝트는 부지기수다. 테스터가 없더라도 개발 단계에서 누군가는 테스트를 수행한다. 개발자는 그들이 작성한 코드를, 이해관계자들은 그들이 만든 요구사항이 제대로 지켜지고 있는지 궁금해 할 것이다. 엔드 유저 역시 제품이 배포되기 전에 테스트 할 수 있는 기회를 가질 수 있다. 사람들은 그들이 깨닫지 못하는 그 순간에도, 자연스럽게 테스트를 수행하고 있는 것이다.
절대 끝나지 않는다
절대 끝나지 않는다는 것은, 테스트해야 하는 애플리케이션을 대상으로 모든 테스트를 수행하는 것이 불가능하다는 것을 의미한다. 모든 조합을 테스트하거나, 사용자가 취할 수 있는 모든 액션을 취해보거나, 모든 환경적 변수를 적용해 보거나, 가능한 모든 데이터 값을 적용하거나, 코드의 모든 경로와 모든 변수를 시험해 본다는 것은 비현실적인 일이다. 이런 관점에서 본다면 테스팅은 절대 종료될 수 없다. 항상 어느 부분을 테스트하지 않은 상태로 남겨둬야 할지 고민해야 한다. 대부분의 프로젝트가 시간과 예산, 인력과 리소스의 제한을 가지고 있다. 테스터들은 이런 제한의 범위 안에서 그들이 수행할 수 있는 가장 효율적인 테스트를 수행해야 하는 것이다.
테스터에게 요구되는 스킬 중 하나는 어떤 것을 테스트할지 결정하는 것이다. 어떤 것을 테스팅하지 않음으로써 발생하는 영향을 이해하고, 테스팅을 통해 낮은 리스크로 판명된 일부 혹은 전부를 제외함으로써 발생하는 리스크를 판별할 필요가 있다.
궁극적으로 테스팅은 제품 배포 권한을 가진 관리자들이 그에 대한 충분한 정보를 얻는 시점에서 종료된다.
소프트웨어 테스팅인 우리가 알아본 그 이상의 어떤 것이다
이 글에서는 소프트웨어 테스팅의 일부에 대해서만 다뤘다. 모든 것을 다루자면 아마 이 글은 끝나지 않을지도 모르겠다. 테스팅에 관한 단 하나만의 정의는 존재하지 않으며, 테스터가 수행하는 일들을 단지 몇 줄의 문장으로 정리하는 것은 불가능에 가깝다. 인터넷에서 ‘소프트웨어 테스팅이란 무엇인가’를 검색해보면 테스팅은 버그를 발견할 목적으로 소프트웨어를 수행해 보는 것이라는 내용의 결과물을 수도 없이 쏟아낸다. 하지만 이미 우리가 알고 있듯이, 테스팅은 그 보다 더 많은 의미를 포함하고 있는 그 무엇이다.
참고할 만한 글
1. Explaining Testing To Anybody - James Bach
2. Software Testing Club - So What Is Testing ?
3. The Impossibility of Complete Testing - Cem Kaner
4. Exploratory Testing - James Bach
5. Acceptance Tests : Let’s Change the Title Too - Michael Bolton
6. The Rapid Software Testing Guide to What You Meant To Say - Michael Bolton
7. Exploratory Testing Explained - James Bach
8. Explore It - Elisabeth Hendrickson
About Claire Reckless
이 글의 저자인 Claire Reckless는 Avecto에서 엔드포인트 보안 소프트웨어의 테스터로 근무하고 있다. 사람들이 좀 더 나은 테스터가 되도록 돕는 일에 그녀의 열정을 쏟아 붓고 있다. 그녀의 전문 분야에는 재무 및 ERP 소프트웨어 분야도 포함된다. Claire는 맨체스터에서 그녀의 남편 Rob과 그녀의 고양이 Max, 강아지 Ted와 함께 살고 있다. 시간날 때마다 달리기를 좋아한다. 그녀의 트위터에서도 그녀를 만나볼 수 있다.
[1] 원 글에는 investigation이라는 단어에 대한 미리엄 웹스터 사전의 정의 https://www.merriam-webster.com/dictionary/investigation 를 소개하고 있다.
'QA' 카테고리의 다른 글
| [번역] 소프트웨어 테스팅의 미래 (4) | 2017.10.26 |
|---|---|
| [번역] 테스터의 커리어 패스 (6) | 2017.08.25 |
| [번역] QA는 테스터인가 아닌가 (0) | 2015.09.21 |
| [번역] Part 4: 받아들이고, 조정하고 개선하라 – 바이오웨어의 애자일 QA 스타일 (6) | 2015.05.21 |
| [번역] Part 3: 바이오웨어 QA – 진실함, 문제를 해결해 나가는 문화 – 그리고 재미! (4) | 2014.05.20 |
