(스크랩) 소프트웨어 제품 테스트 수행 방법: 예제를 들어 설명한 전체 프로세스

SW 테스트 이론

(스크랩) 소프트웨어 제품 테스트 수행 방법: 예제를 들어 설명한 전체 프로세스

genycho 2025. 4. 14. 09:59

(* 내 스스로의 강점으로 제일 먼저 언급하곤 하는 게 제품의 비즈니스, 기술 기반으로 테스트 전략/계획을 수립한다는 말을 한다.

이 관점의 글로 보여서 스크랩해 봤다.

(*) 글 내용 중 -

"많은 경우, 팀은 소프트웨어 제품을 다른 소프트웨어와 동일하게 취급하며,
이는 여러 문제의 시작입니다.
소프트웨어 제품 테스트는 가치를 더하기 위해 맞춤형 테스트 스타일과 전략이 필요합니다.
이것이 왜 중요한지, 그리고 제품 개발이 아무리 좋은 시기라 할지라도
왜 복잡하고, 복잡하며, 복합적이라고 생각하는지 잠시 설명하겠습니다."

. 원제목 : How to Perform Software Product Testing: A Complete Process with Examples

. 작성자 : (By Vijay - 과거 글을 일괄 업데이트 하는 듯 하다.)

. 작성일 : (April 1, 2025 - 과거 글을 일괄 업데이트 한 듯 하다.)

. URL : https://www.softwaretestinghelp.com/how-perform-software-product-testing/

서론.

소프트웨어 제품은 적절하고 정확한 테스트를 위해 고유한 접근 방식이 필요합니다.

많은 경우, 팀은 소프트웨어 제품을 다른 소프트웨어(예: 특정 고객이나 팀을 위해 구축된 내부 애플리케이션, 일반 대중이 접근할 수 없는 애플리케이션, 수익을 창출하지 않는 애플리케이션)와 동일하게 취급하며, 이는 여러 문제의 시작입니다.

소프트웨어 제품 테스트는 가치를 더하기 위해 맞춤형 테스트 스타일과 전략이 필요합니다.

소프트웨어 제품 개발 및 유지 관리는 그 자체로 복잡한 생태계이며, 성공하려면 테스터는 적응해야 합니다.

이것이 왜 중요한지, 그리고 제품 개발이 아무리 좋은 시기라 할지라도 왜 복잡하고, 복잡하며, 복합적이라고 생각하는지 잠시 설명하겠습니다.

소프트웨어 제품 개발 위협(*Challenge)

소프트웨어 제품 개발팀이 직면하는 몇 가지 과제는 다음과 같습니다.

#1) 사용자 인구 통계, 기기, 환경, 플랫폼 등에 대한 통제력 부족

: 특정 이해관계자를 위해 개발된 소프트웨어와 달리 소프트웨어 제품은 통제되고 예측 가능한 상황에서 사용되지 않습니다.

고려해야 할 요소가 너무 많습니다.

#2) 모호한 제품 비전

: 제품의 동작 방식과 기능은 끊임없이 변화하며, 성숙 단계로 나아가는 과정이 가시적이지 않습니다.

또한 제품이 너무 빠르게 성장하여 통제 불능 상태에 빠지고 팀이 통제력을 상실할 수도 있습니다.

#3) 공격적인 일정

: 소프트웨어 제품 시장의 치열한 경쟁으로 인해 모든 것이 빠르게 진행되어야 하며, 팀은 경쟁사보다 한발 앞서 나가야 합니다.

그렇지 않으면 경쟁에서 뒤처질 수밖에 없습니다.

#4) 실패에 대한 두려움

: 소프트웨어 제품은 대개 혁신적입니다. 하지만 성공이 항상 보장되는 것은 아닙니다.

이것이 바로 기업들이 예산, 기술, 인프라 등 모든 면에서 전력을 다할 수 없는 이유입니다.

실패에 대한 어느 정도의 면역성을 확보하거나 손익분기점을 맞추기 위해 기업들은 종종 투자를 자제해야 합니다.

#5) 실행 가능한 피드백 부족

: 이해관계자, 비즈니스 사용자, 또는 고객이 존재하지 않기 때문에 최종 사용자가 무엇을 좋아하고 싫어하는지 파악하기 어렵습니다.

기업들은 끊임없이 추측 게임을 벌이며, 소프트웨어에 대한 자신들의 기대와 고객이 원하는 것 사이의 간극을 메우는 데 어려움을 겪는 경우가 많습니다.

이러한 과제는 제품 개발, 마케팅, 유지 보수의 모든 영역에 영향을 미치며, 제품 테스트에도 본질적으로 영향을 미칩니다.

경쟁에서 앞서 나가려면 이러한 유형의 테스트에서 다섯 가지 핵심 사항을 고려해야 합니다.

- 개발 및 출시 속도
- 제품의 단기 및 장기 목표
- 경쟁의 범위와 특성
- 대상 고객 및 그들의 환경
- 요구 사항 - 기능, 성능, 보안, 사용성, 구성 등

자세히 살펴보기 전에 제품 수명 주기를 알아보겠습니다.

(제품 수명 주기는 일반적인 제품 수명 주기이며 소프트웨어 제품에만 국한되지는 않지만, 소프트웨어는 유사한 패턴을 따릅니다.)

좋은 제품 테스트 전략/접근법은 제품 수명 주기의 현재 단계를 고려해야 합니다.
>> Product Introduction > Product Growth > Product Maturity > Product Decline >>

>> (제품 소개) > (제품 성장) > (제품 성숙) > 제품 쇠락 >>

좋은 제품 테스트 전략/접근 방식은 제품 수명 주기의 현재 단계를 고려해야 합니다.

(참고 글) 좋은 테스트 전략 문서를 작성하는 방법.

https://www.softwaretestinghelp.com/writing-test-strategy-document-template/

예: XYZ 회사의 제품은 'TrackFast'라는 결함 추적 소프트웨어입니다.

이 제품은 신제품이며, 첫 번째 버전은 클라우드 및 온프레미스 솔루션으로 출시될 예정입니다.

TrackFast는 다른 결함 관리 시스템과 마찬가지로 작동하며 모바일 및 웹 접속 모두에 적합하게 설계되었습니다.

현재 2주에서 4주까지의 스프린트 기간 동안 제품이 여러 부분으로 나뉘어 개발됩니다.

여러분은 'TrackFast'가 고객에게 출시되기 전에 테스트 팀에서 테스트하고 있습니다.

테스트에는 기능, 성능 및 보안 점검이 포함됩니다.

요약하자면, 이는 여러분이 작업하는 매개변수입니다. 또는 원하는 경우, 이것이 여러분의 맥락입니다.

[ SDLC method ]

- Agile

- DevOps

[ High level Specs ]

- Cloud and On Premise version

- Mobile and Web based

- Compatible with mostly used browsers and devices

[ Acceptance Criteria ]

- On par with the current defect(competition)

- Performance should be as per the standards.

- Clean and secure interface

1단계) 제품 소개

TrackFast가 처음으로 시장에 출시되는 만큼, 좋은 첫인상을 남기는 것이 중요합니다.

따라서 모든 것을 꼼꼼히, 모든 각도에서 테스트해야 합니다.

이는 향후 테스트를 위한 토대를 마련하는 데에도 도움이 됩니다.

이 시점에서 효과적인 테스트 전략은 다음과 같은 내용을 포함해야 합니다.
- TrackFast의 단기 목표를 검증하는 테스트.

"정상적으로 출시되기 위해 무엇이 필요한가"를 테스트의 최우선 과제로 삼아야 합니다.

모든 기능을 철저히 테스트하기 위해 종단 간(End-to-end) 테스트(프런트엔드, 미들웨어, 백엔드)를 생성합니다.

- TrackFast를 경쟁 제품과 비교하는 테스트

(이상적으로는 제품 소유자가 담당하지만, 테스터로서도 의견을 제시할 수 있습니다.

소프트웨어에 이미 유사한 기능이 있다면 이 단계는 더 쉽습니다.

예를 들어, TrackFast를 Bugzilla, JIRA 또는 기타 레거시 시스템과 비교하는 것은 쉽습니다.

하지만 아기가 언제 배고프거나 짜증을 낼지 예측하는 것과 같이 특이한 기능을 하는 앱을 만든다고 가정해 보겠습니다. :)

기준점으로 사용할 애플리케이션을 찾기가 어려울 수 있습니다.)

- 플랫폼, 브라우저 및 기기 호환성 테스트

- 설치, 설정 및 속도 향상 용이성 테스트

- 성능, 보안 및 사용성 테스트

- 통합 테스트

: 다른 시스템과의 연동 여부를 확인합니다.

간단한 통합 사례로, 결함 추적 시스템은 이메일 클라이언트와 상호 작용하여 알림을 보내는 경우가 많습니다.

- 회귀 계획

: 향후 회귀 주기에 포함될 것으로 생각되는 중요한 테스트에 플래그를 지정하거나 표시하고 향후 릴리스를 위해 자동화하는 것을 고려하는 것이 좋습니다.
- 알려진 문제에 대한 계획을 세우세요(백로그에 추가할 것인지, CR로 처리할 것인지 등).

- 제품이 다음 수명 주기 단계로 진행됨에 따라 변경할 수 있는 유연성을 확보하세요.

제품 출시까지 오랜 시간이 소요될 수 있으므로, 가능한 한 모든 시간을 활용하여 작업을 철저히 수행하세요.

하지만 이 단계에서는 2~4주 스프린트마다 제품의 일부가 준비되어 있으며, 대부분의 경우 모든 스프린트가 코드 배포로 이어지는 것은 아닙니다.

따라서 마지막 스프린트 테스트를 '완료'로 간주하지 마세요.

릴리스될 때까지 모든 스프린트에서 중요 테스트를 반복하세요.

각 스프린트에서 해당 시점까지 진행된 전체 제품을 테스트하세요.

2단계) 제품 성장

초기 프로젝트 도입 후 모든 것이 순조롭게 진행된다면 제품 성장은 빠르게 진행되는 분야이므로 활동이 급증할 것으로 예상됩니다.

이제 거대한 상어들과 함께 헤엄치고 있는 셈이며, 따라가지 못하면 먹혀버릴 것입니다.

이 단계에서는 릴리스 주기가 짧아지고, 소프트웨어 개선 사항의 수는 늘어나며, 회귀 현상은 거의 감당할 수 없을 정도로 심해집니다.

제품 테스트 전략은 소프트웨어 개발 속도에 맞춰 적용되어야 하며, 병목 현상이 되어서는 안 됩니다.

다음 사항들이 도움이 될 수 있습니다.
- 프로젝트의 장기적인 목표를 염두에 두십시오.

지금 당장 끝내는 것이 아니라, 기능을 활용하고 그 기능과 함께 성장하는 것이 중요합니다.
- 조기 테스트(Test Early)

: 새로운 요구 사항이 있을 때까지 테스트를 미루는 대신 TDD 또는 BDD를 고려하세요.

- 회귀 자동화 및 강화

:시스템에 테스트되지 않은 지뢰가 남지 않도록 자동화된 회귀 분석 도구를 구축하세요.

- 비즈니스/제품 담당자가 테스트에 참여하고 싶다면 Cucumber와 같은 비즈니스 언어 기반 자동화 도구를 고려해 보세요.

- 사용성 및 사이트 디자인을 테스트의 핵심으로 삼으세요. 기능을 추가할수록 사이트는 더욱 깔끔해 보여야 합니다.

- 주요 릴리스가 출시되거나 아키텍처에 상당한 변경이 있을 때(신규 서버 도입 등) 성능 및 보안 테스트를 수행하세요. 대부분의 소프트웨어 시스템은 매 릴리스마다 이러한 테스트가 필요하지 않습니다.

- 경쟁사와 지속적으로 소통하고 제품 비전을 파악하세요.

- 즉각적인 피드백과 수정을 위해 페어링 테스트를 도입하세요. 가능하면 제품 담당자도 참여시키세요.

- 변경 사항 및 알려진 문제에 대비하세요.

- 고객 피드백을 수집하고 지속적인 성장을 위해 개선 제안으로 활용할 수 있는지 확인하세요.

(다시 한번 말씀드리지만, 이는 QA 팀의 주된 책임은 아니지만, 모든 구성원이 중요합니다.)

3단계) 제품 성숙도

제품이 여기까지 왔다는 것을 축하합니다. 이 시점에서는 기능이 자주 변경되지 않습니다.

제품 팀은 더 많은 비즈니스를 유치하거나 마케팅 활동에 더욱 집중할 것입니다.

하지만 제품 개발과 테스트는 중단될 필요가 없으며, 종종 중단되지 않습니다.

따라서 테스트 팀은 다음과 같은 작업을 수행할 수 있습니다.
- 테스트 전략을 성숙시키는 데 집중하세요.

이 시점에 이르면 회귀 분석 도구, 테스트 설계 방법, 테스트 관리 관행이 기름칠이 잘 된 기계처럼 원활하게 작동할 것입니다.

- 세부적인 부분에 집중하세요.

전반적으로 제품은 잘 작동하고 잘 동작하고 있지만, "신은 디테일에 있다"라는 말이 있듯이 시스템 품질을 향상시킬 수 있는 아주 작은 문제라도 찾아내야 합니다.

- 고객 피드백을 고려하세요.

- 성능과 보안을 주기적으로 테스트하세요.

- 마지막 테스트 이후 출시된 새로운 기기, 플랫폼, 브라우저를 고려하세요.

- 이제 시간도 있고 여유도 있으니 사용자 설명서와 FAQ 페이지를 테스트하세요.

- 새로운 제품, 테스트 도구, 서비스 또는 프로세스를 시험해 보세요. 이제 가능합니다.

- 아무리 작은 릴리스라도 모든 릴리스에서 설치 프로세스를 테스트하고 최종 사용자에게 얼마나 쉬운지 또는 어려운지에 대한 통계를 확보하세요.

- 무슨 일을 하든 자만하지 마세요.

4단계) 제품 쇠퇴/제품 성장으로의 회귀

요즘 제품 담당자와 기업들은 현명하게 제품을 그대로 유지하면서도 사용자의 충성도를 유지할 수 없다는 것을 잘 알고 있습니다. 세상은 너무나 빠르게 변하고 제품 또한 마찬가지입니다.

TrackFast는 가만히 앉아서만 있을 수 없습니다.

지속적인 시장 점유율을 확보하고 선두 자리를 지키려면 진화해야 합니다.

좋든 싫든, 페이스북은 사람들을 연결하는 단순한 소셜 네트워크로 시작했지만, 그 자체로 수많은 다른 플랫폼과 통합되고 최신 상태를 유지하는 거대한 소프트웨어 플랫폼입니다.

TrackFast 또한 진화해야 합니다.

안정적이고 효과적인 결함 추적 시스템임을 입증한 후, 진화하지 않으면 쇠퇴할 것입니다.

따라서 XYZ 회사는 TrackFast를 소프트웨어 개발 프로세스의 결함뿐만 아니라 IT/테스트 팀(예: JIRA)이 아닌 비즈니스에서 발생하는 모든 인시던트나 사례를 추적하는 데 사용할 수 있는 일반적인 티켓팅 시스템으로 개선하기로 결정했습니다.

바퀴(*Wheel, 싸이클)가 완전히 돌아 당신은 마치 시스템을 완전히 새로운 시스템처럼 여기고 제품 소개 섹션에서 논의했던 전략을 따르게 됩니다.

이제 당신은 더 많은 경험과 노하우를 쌓았을 뿐입니다.

하지만 새로운 바퀴가 돌 때마다 새로운 도전이 찾아온다는 것을 기억하세요. 그러니 항상 예리하게 대비하세요 🙂

성공적인 제품 테스터가 되는 비결

- 제품 테스터는 뛰어난 사업 감각과 신속한 개발 모델에 대한 이해를 갖춰야 하며, 도구를 실험하는 것을 두려워하지 않고 필요에 따라 스스로 코딩하는 능력을 갖춘 최고의 테스터여야 합니다.

이러한 요소들은 모든 유형의 테스트에 긍정적인 영향을 미칠 수 있지만, 특히 이러한 유형의 테스트에서는 절대적으로 필요합니다.

- 또 다른 중요한 자질은 제품 테스터가 제품을 믿고 진심으로 성공하기를 바라는 것입니다.

테스터로서 소프트웨어가 완전히 쓰레기라고 생각하면 개선을 위한 어떤 노력도 할 수 없을 것입니다.

- 제품/사업 소유자의 비전을 공유하세요.

제품의 미래와 발전 방향을 알지 못한다면 테스트는 매우 제한적일 것입니다.

- 교차 기능 기술(Cross-functional skills)은 유익합니다.

DB 테스트 방법, 성능 벤치마크 수행 방법, 보안 인증서 활성화 방법, 배포 방법 등을 숙지하세요.

호기심을 갖고 탐구하세요.

- 경계를 정하지 마세요.

사용자 설명서 평가나 FAQ 확인이 당신의 일이 아니고 테크니컬 라이터가 해야 한다고 생각하지 마세요.

물론 테크니컬 라이터는 해야 하고, 또 그렇게 할 것입니다.

하지만 제품을 속속들이 아는 내부자의 입장에서 생각해 보면, 당신의 피드백은 매우 유용합니다.

- 최종 사용자의 피드백을 구하세요.

당신 다음으로 테스트할 대상은 실시간 사용자입니다.

그들이 어떤 문제에 직면하고 있는지 알고 이해하세요.

이를 통해 테스트 설계를 개선하고 다음 테스트에서 이러한 문제를 방지하기 위해 무엇을 해야 할지 알 수 있습니다.

- 빠르게 작업하고 의사 결정권을 가지세요.
- 기술 부채를 피하세요. 빠르게 진행되는 개발 및 테스트 환경에서는 탐색적 테스트만 하다가 향후 릴리스를 위한 기준점을 놓치기 쉽습니다. 이런 일이 발생하지 않도록 하세요. 추적, 추적 및 측정을 위해 뼈대 문서를 유지하세요.

결론

서비스형 소프트웨어와 제품형 소프트웨어 테스트간의 가장 큰 차이점을 살펴보겠습니다.

서비스형 소프트웨어의 경우, 테스트 전략이 수립되면 이후 모든 테스트에 적용됩니다.

반면, 제품의 경우, 테스트 전략은 제품의 현재 수명 주기 단계와 시장 동향(신규 기기, 신규 브라우저 등)의 변화에 따라 변경되어야 합니다.

제품 테스트 전략은 변화에 훨씬 더 유연해야 합니다.