차례
관련 블로그
수동 테스트는 끝났다고 말하는 사람들이 있습니다. 하지만 진실은 좀 더 복잡합니다. 더 자세한 내용은 계속 읽어보세요.
1897년, 전설적인 미국 풍자 작가 마크 트웨인이 사망했다는 보도가 있었습니다. 사실 그는 건강했습니다. 생전에 트웨인과 함께 있었음에도 불구하고 그의 부고 기사가 게재된 것에 대해 의견을 묻자, 그는 "내 사망 보도는 과장된 것입니다."라고 답했습니다.
수동 테스트 업계에서는 가끔씩 수동 테스트가 더 이상 유효하지 않다는 보고서를 접하게 됩니다. 아니, 최소한 생명 유지 장치에 의존하는 수준이라고 할 수도 있겠죠. 이런 기사들은 항상 겁에 질린 수동 테스터들을 낚아채려는 의도로 상당한 공포감을 안겨줍니다.
많은 기업이 테스트 자동화에 기대를 걸고 있습니다. "차세대 혁신입니다."라고들 합니다. 정말 그럴까요? 테스트 자동화는 20년 넘게 존재해 왔습니다. "100% 자동화를 목표로 합니다." 여러분은 어떠신가요? 우리는 그것이 거의 불가능하다는 것을 알고 있습니다. 하지만 만약 이것이 사실이라면, 많은 수동 테스터들이 일자리를 잃게 될 것입니다. 사실, 기업이 100% 자동화를 목표로 삼는 것도, 수동 테스터가 자신의 기술을 포기하는 것도 현명하지 않습니다.
의 세계에서 DevOps웹 및 모바일 앱의 버그를 발견하려면 테스트 자동화가 필수적입니다. 동시에 수동 테스트는 웹 및 모바일 앱 테스트 전략의 중요한 부분입니다. 수동 테스트는 QA 팀원이 오류를 더 잘 발견하는 데 도움이 되며, 결국 많은 자동화 테스트가 수동 테스트 작업을 통해 개발됩니다.
수동 또는 자동화
QA 테스터는 사용자가 앱과 상호 작용하는 방식을 정확히 재현하고 싶어합니다. 이는 즉시 가능하지 않습니다. 자동 테스트 혼자. 그래서 견고한 웹과 모바일 테스트 전략은 다양한 테스트 방법을 사용합니다. 그 결과, 모든 앱 요구 사항이 충족되었습니다.
조금 더 자세히 살펴보겠습니다.
- 테스트 자동화 – 수동 테스트에는 너무 지루하고 시간이 많이 걸리는 일상적이고 반복적인 시나리오를 테스트하는 데 더 적합합니다.
- 수동 테스트 – 자동화된 테스트가 사람이 앱과 상호 작용하는 정확한 방식을 복제할 수 없는 시나리오에 가장 적합합니다.
흥미롭게도 QA 팀이 수동으로만 수행할 수 있는 몇 가지 테스트 형태가 있습니다. 또한, 자동화된 테스트 프로젝트를 설정하고 결과를 분석하려면 어차피 사람의 개입이 필요합니다.
자동화된 테스트가 도입되면서 수동 테스트가 더 이상 유효하지 않다고 여겨지는 것은 불공평해 보입니다. 물론 두 가지 형태 모두 장점이 있지만, 수동 테스트가 여전히 중요한 이유를 좀 더 자세히 살펴보겠습니다.
일부 테스트는 수동으로 수행해야 합니다.
훌륭한 UX를 제공해야 한다는 필요성은 수동 테스트가 여전히 필수적인 이유를 증명하기에 충분할 수 있습니다. 인간의 상호작용은 여전히 기능을 테스트하는 가장 효과적인 방법입니다. 시나리오를 자동화할 수 없는 경우도 많습니다. 기술적 한계가 있거나 기능이 너무 복잡한 경우도 있습니다. 또 다른 가능성은 자동화 비용이 앱을 수동으로 테스트하는 비용보다 훨씬 클 수 있다는 것입니다.
스모크 테스팅을 자동화할 수는 있지만, 수동 팀에 맡기는 것이 더 좋습니다. 앱을 빠르게 살펴보고 다음 테스트 단계에 실제로 적합한지 확인하는 것이 더 빠릅니다. 이러한 프로그램을 위한 스크립트를 작성하는 데는 훨씬 더 많은 시간이 소요될 뿐만 아니라, 어차피 테스트 스크립트는 장기적으로 재사용할 수 없습니다.
사람들에게주는 힘
자동화된 테스트는 반복적인 테스트를 처리하고, 나머지 팀원들이 수동 테스트를 수행할 수 있도록 시간을 확보하는 동시에 테스트 자체를 효율적으로 운영합니다. UX와 사용성을 테스트하는 경우 수동 테스트는 그 어느 때보다 필수적입니다. UX를 수동으로 테스트하는 테스터는 직관과 본능을 활용하여 제대로 작동하지 않거나 효율성을 개선해야 하는 기능을 파악합니다. 이러한 부적절한 사용자 경로를 발견하면 테스터는 개발자와 소통하여 잠재적인 변경 사항을 논의해야 합니다.
UX 테스트는 앱 제작 및 테스트에 참여하는 팀보다 훨씬 더 큰 힘을 발휘합니다. 최고의 수동 사용성 테스트는 개별 빌드와 관련 없는 사람들로부터 이루어집니다. 그렇게 하면 사전 지식 없이도 앱과 상호 작용할 수 있습니다. 문제가 발생하면 바로 이 사람들이 문제를 찾아낼 것입니다.
사용자도 마찬가지입니다. 사용자가 발견한 버그를 보고하면 수동 테스터가 즉시 버그를 재현할 수 있습니다. 그런 다음 버그 보고서를 제출하고 프로세스가 계속 진행됩니다.
잘못된 곳에서 버그를 찾는 중
특정 사용 사례를 테스트하다 보면 QA 팀이 예상치 못한 버그를 발견하는 경우가 많습니다. 이 부분이 얼마나 중요한지 아무리 강조해도 지나치지 않습니다. 어떤 경우에는 특정 빌드의 버그 대부분이 테스터에 의해 발견되기도 합니다. 자동화된 테스트가 찾을 수 있는 것은 프로그래밍된 버그뿐입니다.
탐색적 테스트는 사용성 문제를 발견하는 데 있어 인간적인 접근 방식을 기반으로 합니다. 더 나아가, 수동 테스터는 아무런 제약을 받지 않습니다. 즉흥적이고 주도적으로 상호작용하고 자동 테스트가 다루지 않는 영역까지 탐색할 수 있는 자유가 주어집니다. 무언가 잘못되었을 때 이를 감지하려면 약간의 상식이 필요하며, 바로 이러한 인간적인 상호작용이 수동 테스트와 전반적인 테스트를 더욱 효과적으로 만듭니다.
자동화의 가격
자동화된 테스트 프로젝트를 진행하려면 사용하는 도구에 대한 비용을 지불해야 하며, 그 외에도 유지 관리 및 관리 관련 비용이 발생합니다. 설정 및 처리 시간 또한 여기에 영향을 미칩니다. 주요 제품이나 장기 프로젝트의 경우 이러한 비용은 투자할 만한 가치가 있습니다. 이러한 프로젝트에서 자동화된 스크립트는 반복적인 테스트를 제공하기 때문에 큰 도움이 됩니다.
소규모 프로젝트의 경우 수동 테스트를 통해 시간과 비용을 절약할 수 있습니다. 자동화된 테스트가 실행되는 동안 테스터와 QA 담당자는 다른 곳에 집중할 수 있습니다. 하지만 자동화된 테스트 스위트를 실행할 때 테스트 자체에 버그가 있는 경우, 검증된 수동 테스트를 통해 문제를 해결할 수 있습니다.
테스트 주기 후반부에 시간이 매우 중요할 때 수동 테스트를 사용하면 테스트의 잠재력을 최대한 발휘할 수 있습니다. 자동 테스트를 실행하기 전에 앱이 설정에 포함되어 있는지 수동으로 검사하는 것이 좋습니다. 자동 테스트 스크립트에서 누락된 마지막 순간의 버그나 결함을 발견할 수 있습니다.
접근성 테스트
이전에 여러 블로그에서 논의했듯이, 사용자가 기기를 사용하거나 웹사이트에 접속하는 데 어려움을 겪는 경우, 해당 서비스를 제공해야 합니다.
접근성 테스트 장애인 고객이 귀하의 웹이나 모바일 앱을 더 쉽게 사용할 수 있도록 어떤 구체적인 개선 사항을 제시합니다.
이를 보장하는 한 가지 방법은 프로세스에 접근성 테스트를 추가하는 것입니다. 이러한 유형의 테스트에서는 가치 판단을 필요로 하기 때문에 인간 상호작용이 가장 효과적입니다. 또한, 장애가 있는 사람들로 구성된 포커스 그룹으로부터 귀중한 의견을 얻을 수도 있습니다.
중요한 수동 테스트 사용 사례
위에서 살펴본 바와 같이, 자동화 테스트가 불가능한 경우에도 수동 테스트는 여전히 중요합니다. 따라서 자동화 테스트가 더 화려하고 많은 관심을 받고 있지만, 수동 테스트는 여전히 SDLC와 관련이 있습니다.
수동 스크립트가 자동화된 스크립트보다 도움이 되는 몇 가지 사용 사례는 다음과 같습니다.
WiFi 로그오프 및 로그인, 여러 앱 동시 실행, 기기 권한 설정 등 몇 가지 사용 사례를 더 살펴보겠습니다.
- 버그 복제 – 테스터는 버그 보고서를 읽고, 기기를 가져와서 복제하기만 하면 됩니다. 프레임워크, 요구 사항 또는 시나리오를 설정할 필요가 없습니다.
- 기기 호환성 – 특정 장치/OS 조합에 문제가 있는 경우 실시간으로 수동으로 테스트하세요.
- UI/UX 상호 작용 – 이러한 시나리오를 수동으로 테스트하면 실제 사용자가 앱과 상호 작용하는 방식을 이해하고 더 많은 버그를 잡을 수 있습니다.
- 대기 모드 – 네트워크 끊김이나 동기화 부족으로 인해 대기 모드가 앱에 부정적인 영향을 미치지 않는지 수동으로 테스트해 보세요.
- 장치 권한 – QA팀에서 해당 권한이 많이 사용되지 않을 것이라고 판단하면 일반적으로 수동으로 테스트합니다.
- 앱 연결 – 실제 네트워크 환경을 대상으로 수동으로 테스트합니다.
- 제스처 – 탐색 문제가 있는지 확인하려면 수동으로 테스트해야 합니다.
- 성능 시험 – 다른 앱과 상호작용할 때 앱 동작을 수동으로 테스트합니다.
수동 테스트는 계속됩니다
웹 및 모바일 앱 테스트에는 자동 테스트와 수동 테스트 방법이 모두 포함되어야 합니다. 자동화와 수동 테스트의 비율은 테스트 대상 앱에 따라 달라집니다. 버그, 결함, 오류에 대한 가치 판단을 내릴 때는 수동 테스트를 활용하세요. 반대로, 자동 테스트는 테스터가 테스트의 지루한 부분에서 벗어나도록 해줍니다.
UI 상호작용, 버그 재현, 성능 테스트 시 수동 테스트는 대체될 수 없습니다. 더 나아가, 접근성과 제스처 테스트는 다른 어떤 방법보다 효과적으로 수행할 수 있습니다.
이 모든 것 중 가장 좋은 부분은 다음과 같습니다. Digital.ai Continuous Testing 클라우드에서 수백 대의 장치에 대해 이러한 유형의 수동 테스트를 실행할 수 있습니다. 웨비나를 확인하고 2021년에 클라우드 테스트가 얼마나 중요한지 알아보세요.