가상화 데스크탑을 이용한 테스트를 포함하여, 각종 테스트들을 지원해주는 Saucelabs의 기사를 번역해 올립니다.
Software Testing for Organization that have no QA team
대부분의 사람들은 소프트웨어 테스트에 대해 말할 때, 품질보증 엔지니어(QA Engineer) 및 해당 팀에서 소프트웨어 테스트와 소프트웨어 품질의 최적화를 전담해야한다고 말합니다.
그러나 현실적으로는 모든 조직에 QA team이 있는 것은 아닙니다. 여러분의 회사에 전임 QA team이나 소프트웨어 테스트 전문가가 없는 경우, 소프트웨어 배포 시에 해당 역할을 해야하기 위해 열심히 일해야할 것 입니다.
사라진 QA Team
일부 기업에서는 QA엔지니어를 고용하는 것에 큰 가치가 있다고 판단하지 않습니다. 어떤 사람들은 DevOps flow로 인하여 전임 QA팀을 만들 필요가 없다고 생각할지도 모릅니다. 물론 일부 기업은 정말 작아서 풀타임 QA 엔지니어를 고용할 정도의 여유가 없을 수 있습니다.
한정된 범위 안에서 기업은 프리랜서 QA엔지니어와 협력하여 테스터의 부재를 메꿀 수도 있습니다. 당신의 회사에서 매우 작은 소프트웨어 개발을 진행하고 있는 경우라면 제대로 굴러갈지도 모르겠으나, 그것은 실용적이지 않으며 제대로된 CI/CD 파이프라인에 대한 책임자가 없으므로 운용되기도 어려울 수 있습니다. 프리랜서 QA엔지니어가 존재한다는 것은, 풀타임 스태프에 QA엔지니어를 고용하는 것으로 발생하는 일관성과 완전한 커버리지가 부족할 수 있다는 것을 의미합니다.
소프트웨어 테스트의 경험이 있는 개발자를 고용하는 것으로 이 갭을 어느정도 메꿀 수는 있을 것 입니다. 다만, 그러한 개발자를 찾는 것이 어렵습니다. 또한 일반적으로는 그러한 경험을 가진 개발자의 몸값이 매우 비싸기 때문에, 많은 경우에는 풀타임 QA 스태프를 고용합니다.
QA team 없이 QA진행하기
다행스럽게도, 풀타임 QA team이 없다고하여 조직이 소프트웨어 품질을 타협하지 않으면 안되는 것은 아닙니다. 적절한 어프로치를 통해 개발자와 그 외 관계자들을 이용하여 QA 엔지니어의 부재를 막을 수도 있습니다. 조금은 무섭게 들릴지도 모르겠지만, 전혀 무섭거나 그렇지 않습니다. QA team이 있는 경우에도 QA엔지니어와 개발자나 기타 관계자들과 긴밀하게 연계할 필요가 있습니다.
즉, 이것이야말로 DevOps인 것 입니다.
전임 QA Team이 없는 경우에 바뀌는 것은, 개발자와 IT 엔지니어가 QA운용보다 더 적극적으로 임무를 수행할 필요가 있습니다. QA엔지니어와 단순히 커뮤니케이션을 하고, 협력하는 것 뿐만 아니라, 소프트웨어 테스트와 소프트웨어 품질의 최적화를 실제로 체험할 필요가 있습니다.
다음과 같은 전력과 실전은, QA경험없이도 개발자와 기타 관계자가 QA를 진행할 때 도움이 될 것 입니다.
개발자는 자동 테스트를 작성합니다.
개발자는 이미 코딩방법을 알고 있으며, 매일 하는 일이빈다. 따라서 자동화된 테스트 프레임워크를 배우고, 테스트 코드를 작성하는 것은 그들에게는 큰 문제는 아닙니다. 관계자들 중 개발자가 있는 경우, 자동 테스트를 작성하기 위해서는 반드시 QA엔지니어가 필요한 것은 아닙니다.
(QA 관련 인원이 있다고 하더라도 개발자는 언제든지 자동 테스트의 생성을 지원할 수 있습니다.)
IT엔지니어 (기타 관계자) 는 Shift-right 테스트로 공헌할 수 있습니다.
Shift-Right 테스트란, Production환경 (실제 운용환경)에서 테스트를 하는 것을 의미합니다. 어떤 면에서는 IT엔지니어 (혹은 운영 관계자)가 어플리케이션을 Monitoring하는 의미에서, 이미 실행중인 테스트이기도 합니다. 운영 관계자들이 좀 더 실전적인 역할을 다하기 위해서는 문제를 감시하는 것 뿐만 아니라, 실제 운용 시의 각종 데이터를 기반으로 소프트웨어 전체의 품질을 향상하는 방법을 찾도록 시켜야합니다.
계속적인 Feedback
풀타임 QA Team이 없다면, 개발자가 실제 운영환경에서 발생하는 소프트웨어 푸질 문제에 대해 확실히 아는 것은 어렵습니다. 또한 운영팀에서는 개발자가 어플리케이션 동작을 어떻게 기대하고 있는지 아는 방법도 별로 없습니다. 때문에 각 팀이 다른 팀과 소프트웨어 품질의 문제에 대해 계속해서 대화할 수 있도록, 직접적인 계속적 피드백 루프를 확립하는 것이 중요합니다.
소프트웨어 품질에 관한 Ownership
팀의 문화적인 관점에서, 모든 개발자와 운영자들은 소프트웨어 품질에 관한 소유권을 공유할 필요가 있습니다. 풀타임 Qa Team이 있다하더라도, 이것은 어느정도 필요합니다. 그러나 QA팀이 없는 경우라면, 소프트웨어 테스트와 품질을 주로 관리하는 사람이 아무도 없게 됩니다. 때문에 QA를 완전히 소유하는 것은 개발자와 운영팀이 됩니다.
효과적이어야 할 것.
개발자나 운영팀이 QA의식을 가짐으로 인해서 많은 작업이 발생하고 시간이 소요되는 것이라 생각되는 경우라면, 이러한 분위기를 정착시키는 것은 매우 어려울 것입니다. 때문에 테스트의 자동화 (사람이 수동으로 테스트를 실행하기 위해 시간을 소비할 필요가 없다), 확장 디버그 (테스트 결과를 알기 쉽게 빠르게 알려줌), 병렬 테스트 (한 번에 많은 테스트를 동시에 실행) 등을 구성해야할 필요가 있습니다.
이상적인 세계라면 모든 기업에 QA엔지니어가 있는 대규모의 다이나믹한 팀이 있을 것이고, 해당 조직은 CI/CD Pipeline으로 보내지는 모든 Code release의 품질을 완성시키기 위해 매일 시간을 투자하고 있을 것입니다.
그러나 현실은 많은 조직이 QA Team이 전혀없거나, 모든 QA업무를 처리하기 위한 충분한 크기의 팀이 없기도 합니다. 때문에 QA를 소프트웨어 엔지니어링에 관계하는 모든 사람의 책무로 하는 것이 매우 중요합니다.
