[스압주의] QA 톺아보기 (+WEST program)

 현재 한국정부가 지원하는 WEST프로그램을 통해 미국에 파견되있다. 보통 소프트웨어 인턴십으로 선발이 잘 되지 않고 마케팅직무로 선발된다는데 스폰서와 관계를 잘 쌓은 덕분인지 운이 좋게 소프트웨어 인턴십을 수행할 수 있는 회사에서 오퍼레터를 받게 되었다. 8개월의 장기인턴이고, 회사가 제조업베이스라 슈퍼바이저는 QA를 먼저 배우라고 지시했다. Shadowing work를 하며 한 달 반을 보낸뒤, 드디어 내가 기여할 일이 생겼다. 그 전에 소프트웨어엔지니어링 강의 때 들어만 본 Quality Assurance 업무가 무엇인지 다시 한 번 머리 속으로 정리하고 기록해두려 한다.

 

 당연히 QA는 중요하다. QA가 제대로 이루어지지 않으면 생각도 못했던 자본 손실이 나타날 수 있다. 테스터는 여러가지 일을 담당 하는데, 좋거나 나쁜 사건에 대해 조사하고, 정보를 수집하면서 자신이 담당하는 시스템에 대해 배우고 있으며 문제가 발생할 수 있는 위치를 예측하는 데 도움이 되는 데이터 기반으로 분석을 수행하기도 한다. 또한, 이 모든 정보를 수집한 후 그들은 팀과 이해 관계자에게 의사 결정과 관련된 시스템에 대한 정보를 알린다. 테스터는 종종 여러 프로젝트와 팀에서 일어나는 일에 대해 알고 조직 경계를 넘어 정보 전달자 역할을 한다. 일부 테스터는 자동화 기술을 사용하여 특정 테스트를 자동화하고 다른 유형의 테스트에 집중할 수 있는 시간을 줄 수 있다. 테스트는 범위가 광범위하다.

 

Common Testing Organizational Models

 - 아웃소싱

 - QA부서

 - 테스터가 프로젝트나 프로덕트 임에 배정된 경우

 - 테스터가 완전히 프로젝트나 프로덕트에 통합된 경우 (보통 애자일 방법론에서)

 

Tightly Intergrated

: 테스터와 머지 팀의 통합을 강조하는 접근 방식을 통해 테스터는 개발 내내 팀을 지원하고 해당 팀의 전담 리소스가 될 수 있다.

 

Separated Tester

: 테스터를 분리하는 접근 방식은 배포 후, 버그 및 기타 문제 찾기에 중점을 둔다. 이 접근 방식은 전용 리소스보다 유동적인 리소스를 실용적으로 만들고 테스터 측에서 외부인의 편견 없는 관점을 유지하는 데 도움이 된다고 주장된다.

 

The Gatekeeper

: 회사에서 전통적인 QA부서가 있는 경우, QA담당자가 릴리스를 승인하거나 거부한다. 게이트키퍼 모델은 개발자와 테스터 간의 협력 관계에 비해 약간 더 적대적인 관계를 조장할 수 있으며 이 역할이 계약상 필요할 수 있지만 대부분의 애자일 소프트웨어 개발 테스트 전문가들은 이를 권장하진 않는다. 테스터를 위한 게이트키퍼 역할에 대한 쉬운 대안은 테스터가 특정 릴리스와 관련된 위험에 대한 정보를 팀에 제공하고 팀 전체 또는 제품 소유자가 해당 데이터를 기반으로 결정을 내리도록 하는 것이다.

 

Five-fold Testing System

 1) Testers: 누가 테스트를 진행하는지

 2) Coverage: 무엇이 테스트 되는지

 3) Potential Problems: 왜 테스트 하는지

 4) Activities: 어떻게 테스트 할 것인지

 5) Evaluation: 어떻게 결과를 판단 할 것인지

 

Black Box Testing

: 테스트 주인 시스템이 내부적으로 구축되는 방식에 대한 지식 없이 수행된다. 테스터가 최종 사용자의 관점, 새로운 관점을 완전히 채택하는 데 도움이 된다.

 

White Box Testing

: 시스템이 어떻게 구축되었는지 또는 시스템의 사전 사용에 대한 지식으로 수행된다. 테스터는 해당 지식 때문에 실제 최종 사용자와 같은 방식으로 애플리케이션을 경험하는 것이 어렵다.

 

계획이나 특정 목표 없이 애리케이션을 테스트하는 것을 Ad-hoc 테스트라고 부른다.

 

Test Planning

 - 테스트할 대상과 방법을 정의하는 데 시간을 할애해야 한다.

 - 테스트 계획에는 구체적이고 세부화된 목표가 포함되며 테스트 계획은 일반적으로 특정 릴리스, 특정 반복 또는 스프린트의 작업 또는 단일 새 기능을 테스트하는 것과 관련이 있다.

 - 너무 많은 계획과 문서화는 때떄로 낭비가 될 수 있음을 주의해야 한다. 따라서 상황에 맞게 최대한 간결하게 계획해야 한다.

 테스트에 대한 일반적인 접근 방식은 시스템의 일부에 대한 입력 및 출력의 관점에서 보는 것이다.

 

Planning Test Data

 - Equivalence partitioning: 일반적으로 사양에 따라 입력 필드의 가능한 값을 등가 그룹으로 나눈다. 등가 분할을 사용하면 각 그룹에서 하나 이상의  값으로 테스트한다.

 - Boundary Testing: 행동 변화의 경계에서 테스트 데이터를 선택하는 것을 포함한다.

 - All singles, all pairs: 여러 필드 값의 조합을 테스트하는 데 사용된다. 모든 변수의 가능한 모든 값을 한 번 이상 사용하거나 모든 값 쌍을 한 번 이상 사용하려고 해야한다. 이러한 기술은 일반적으로 각 필드에 대해 제한된 수의 불연속 값이 있는 선택 상자 또는 옵션 필드가 있는 경우에 사용된다. 

 

Decision Tables (의사결정 테이블)

: 각 테스트 케이스에 대한 입력과 예상 출력을 테이블 형식으로 나열하며, 요약되어 있어 빠르게 스캔하고 이해하기 쉽다. 각각 행으로 설명되는 고유한 테스트 케이스가 있다. 예상되는 출력 열에는 열 이름 끝에 물음표가 있으며 이는 일반적인 형식이다. 테스트할 특정 데이터를 선택하는 데 도움이 되도록 동등 분할 및 동작 경계가 여기에서 사용되었다. 자동화된 테스트 도구를 사용하면 종종 의사결정 테이블 형식을 사용하여 컴퓨터 실행 테스트를 실행할 수 있지만 테스트 중에 시스템과 인간의 상호 작용을 안내하는 데에도 유용하다.

 

State Transition Testing

: 시스템은 사용 중 상태를 변경하는 경우가 많으며 이는 테스트를 위한 좋은 기반이기도 하다. 

 - 상태 전환 테스트는 입력으로 어떤 형태의 이벤트로 인해 상태 전환이 발생하고 해당 입력의 결과로 시스템이 변경되는 상태가 출력이기 때문에 다른 종류의 입력/출력 테스트다.

 - 테스터는 종종 테스트 중인 시스템 또는 해당 시스템의 특정 부분이 어떤 상태에 있을 수 있는지 고려해야 한다.

 - 상태 전환 다이어그램은 이를 표현하는 일반적인 방법이며 귀중한 테스트 보조 도구가 될 수 있다. 각 상자는 애플리케이션이 있을 수 있는 상태이고 화살표는 시스템이 한 상태에서 다른 상태로 전환되도록 하는 이벤트이다. 테스터는 시스템 사양에서 이러한 다이어그램을 찾을 수 있지만 테스터가 시스템을 탐색하고 배울 때 생성할 수 있는 좋은 아티팩트 일 수도 있다.

 

Test Script

 - 입력 데이터, 수행해야 하는 시스템과의 각 상호 작용 및 차야 할 예상 결과가 포함된 테스트에 대한 단계별 설명이다.

 - 테스트 스크립트는 회귀 테스트의 일반적인 형태이다. 새 릴리스에 대한 변경 사항이 적용된 후에도 이전 기능이 시스템에서 계속 작동하는지 확인하기 위해 실행할 테스트 스크립트를 선택한다.

 - 테스트 스크립트를 한 사람이 작성하고 나중에 다른 사람이 수행하는 것은 업계에서 드문 일이 아니다. 이와 같은 테스트 스크립트를 실행하는 데 많은 기술이 필요하지 않기 때문이다. 스크립트를 작성하려면 기술이 필요하지만 실행하는 것은 매우 무의미 하다.

 - 테스트 스크립트는 종종 도구에 기록되며 이러한 도구는 종종 실행 기록을 보관할 수도 있다.

→ 장점: 다른 사람들이 쉽게 반복할 수 있기 때문에 회귀에 대해 원하는 중요한 테스트를 누구나 정확하게 복제할 수 있도록 한다. 그것들은 또한 당신이 그것들을 측정할 수 있도록 문서인 유물이다.

→ 단점: 이러한 스크립트는 프로젝트가 진행됨에 따라 누적되는 경향이 있으며 제품이 증가할 때마다 수동으로 실행하는 데 시간이 점점 더 걸린다. 더 심각하게, 테스트 스크립트는 시스템에 대해 똑같은 것을 똑같은 방식으로 계속해서 테스트하고 있다. 새로운 문제나 이전에 발견되지 않은 문제를 찾는 것은 과거에 작동했던 스크립트를 수동으로 실행하는 데 모든 시간을 소비하는 경우 이를 놓칠 가능성이 높다. 일반적으로 테스트 스크립트에 대한 강조는 창의성을 약화시킬 수 있다. 또 다른 문제는 시스템을 변경하면 높은 수준의 세부 사항으로 인해 스크립트 단계가 무효화될 수 있다는 것다. 스크립트를 최신 상태로 유지하는 데 시간이 많이 걸릴 수 있다. 테스트 중에 혼란을 일으킬 수 있는 무언가를 시도하는 경우 일반적으로 테스트 환경에서 시도하는 것이 가장 좋다.

 

Improving Script Effectiveness

 - 데이터 입력의 특이성을 줄임으로써 스크립트를 실행하는 사람이 더 창의적이 되도록 할 수 있다.

 - 테스가 각 단계에서 취해야 하는 작업을 좀 더 추상적으로 지정하여 더 많은 창의성을 제공할 뿐만 아니라 단계의 취약성을 줄일 수 있다. 이로 인해 테스터가 스크립트를 유지 관리하기 쉽게 만드는 것 외에도 사용성 문제를 알 수 있다.

 - 스크립트에 대해 더 높은 수준의 세분성을 시도할 수 있다.

 - 또한 스크립트를 분류하거나 태그를 지정하여 특정 기능 세트 또는 특정 유형의 데이터에 대한 스크립트의 추적 가능성을 허용할 수 있다. 이는 모든 스크립트를 실행하는 것보다 특정 시점에서 실행하는 데 가장 가치 있는 스크립트를 대상으로 지정하는 데 도움이 될 수 있다.

 

Exploratory Testing (탐색적 테스팅)

 - 특정 기술보다는 테스팅을 위한 접근 방식이나 사고방식에 가깝다.

 - 이를 통해 테스터는 현재 목표와 테스트하면서 배우고 관찰한 내용을 기반으로 테스트 대상과 방법을 발전시키고 다양화 할 수 있다.

 - 테스터가 테스트 중에 접선을 직관하고 탐색하거나 메모하도록 장려하기 위해 스크립트 테스트에 초점을 맞춘 것에 대한 응답으로 적어도 어느 정도 업계에 나타났다.

 - 여러 유형의 테스트 활동과 기술이 포함될 수 있다.

 - 탐색 테스트 세션 중에 경계 테스트를 수행하거나 사용성을 관찰할 수 있다.

 - 탐색적 테스트는 종종 동시 학습, 테스트 설계, 실행 및 해석으로 설명된다.

 

Not equivalent to ad-hoc testing

 - 테스터가 각 탐색 테스트에 대해 염두에 두고 있는 임무 또는 목표가 있다.

 - 탐색적 테스트를 위한 준비에는 테스트 데이터 설정, 이해 관계자 또는 최종 사용자 인터뷰 또는 기타 유형의 연구가 포함될 수 있다.

 - 테스터는 세부적으로 작성된 테스트 스크립트를 실행할 때보다 훨씬 더 자유롭게 일탈하고 즉흥적으로 실행할 수 있다.

 

Professional Bug Reporting

 1) 먼저 중요한 세부 정보를 캡처한다.

 -- 잠재적인 결함에 대해 어떤 정보를 기록해야 하는지 미리 설정한다.

 -- 기록하는 데이터는 개발자가 문제의 본질을 이해하고 문제를 직접 재현하는 데 도움이 되는 정보여야 한다.

 -- 문제를 발견한 환경, 문제를 생성하기 위해 취한 단계, 시스템에 입력한 정확한 데이터, 최종 사용자에게 미칠 수 있는 잠재적 영향, 문제가 나타날 때의 스크린샷은 모두 매우 일반적인 데이터 포인트이다.

 2) 서면 기록과 구두로 다른 사람에게 문제를 알릴 때 비난하는 어조를 피해야한다.

 -- 잠적인 버그에 대한 대화는 양쪽에서 쉽게 방어적이 될 수 있으므로 가능한 한 사실에 입각한 정중함을 유지해야한다.

 3) 테스터가 버그에 대한 통찰력이 있는 경우 버그의 잠재적 영향을 설명하는 것이 좋다.

 -- 테스터는 수정될 사항을 결정하지 않고 해당 결정을 내리는 데 도움이 되는 정보를 제공한다.

 4) 버그를 분류하면 기능에 대한 추적 가능성을 통해 시간이 지남에 따라 추세를 파악할 수 있다.

 

What's a Bug?

 - 테스터로서 직면하는 문제 중 하나는 버그라는 용어의 일반적인 사용이지만 발견한 모든 것이 버그는 아니다.

 - 모든 종류의 가능한 품질 격차는 이 일반적인 버그 제목 아래에 묶이게 되는데, 그 이유는 그러한 문제를 고하는 데 사용할 추적 시스템이 이를 버그 또는 결함이라고 부를 것이기 때문이다.

 - 재현할 수 없는 버그는 여전히 문제일 수 있으며 가능한 한 정보를 제공해야 한다.

 

Automated Testing as a Career

 - 자동화 테스터는 기본적으로 프로그래머 또는 개발자이며, 이제 이력서와 채용 공고에서 "Software Developer in Test"라는 직업 타이틀을 찾을 수 있다. 테스트 중인 소프트웨어 개발자는 일반적으로 이 과정이 초점을 맞춘 조사적 의미의 전문 테스터가 아니다. 테스트 중인 소프트웨어 개발자는 종종 전문 테스터 및 기타 팀 구성원이 자동화하는 것이 가장 중요하다고 생각하는 테스트를 자동화한다.

 - 하지만 전문 테스터는 자동화를 누가 수행하는지에 관계없이 사람이 주도하는 테스트가 도구와 자동화로 어떻게 보완될 수 있는지 이해하는 것이 중요하다.

 

Common Types of Automated Tests

 - Unit Tests: 기능 구현의 일부로 개발자가 작성한다. 그들은 코드가 상당히 낮은 수준에서 수행한다고 생각하는 작업을 수행하는지 확인한다.

 - Executable Functional Specifications: 실행 가능한 기능 사양은 고객 또는 테스터가 작성할 수 있지만 개발자는 해당 사양을 테스트 중인 코드에 연결한다. 기본적으로 요구 사항의 일부는 표 형식 또는 특수 키워드가 포함된 영어 문장으로 표현되며 이러한 요구 사항은 시스템의 실제 코드에 대해 실행, 실행되어 시스템이 예상 결과를 반환하는지 확인할 수 있다. 이것은 비즈니스 규칙이 올바르게 이해되고 구현되었는지 확인하는 좋은 방법이다.

 - End-End or "UI' Tests: 배포된 환경(일반적으로 개발 또는 테스트 환경)에서 애플리케이션의 사용자 인터페이스를 실행하고 스크립크에서 수행한 각 작업이 UI에서 예상한 결과로 이어지는지 확인하는 실행 가능한 스크립트이다. 작성된 회귀테스트 스크립트는 종종 이러한 유형의 자동화로 변경되는 대상이 된다. Selenium과 같은 도구는 이러한 역할에 적합하며 컴퓨터가 사용자 인터페이스를 통해 회귀 테스트를 수행하도록 하고 인간 테스터의 시간을 절약할 수 있는 좋은 방법이다.

 

Automated Test Strategies

 - 일반적으로 원하는 회귀 테스트를 모두 자동화하는 것은 실용적이지 않거나 바람직하지 않으므로 자동화할 항목인 우선순위 지정은 선택한다.

 - 반복적으로 확인해야 할 중요한 항목과 자동화하기 쉽고 입력을 제공하기 쉬운 항목을 선택하고 프로그램 출력을 확인하도록 힌다.

 - 개발자가 도와줄 수 있다. 프로그래밍 및 자동화에 능숙한 테스터가 필요하며 이는 업계의 추세이지만 드물고 직원의 개발자는 프로그래밍 및 자동화에 능숙하다.

 - 반면 전문 테스터는 자동화가 확인하지 못하는 문제를 찾을 수 있는 분석 및 조사 기술을 보유하고 있다. 전문 테스터의 프로그래밍에 더 많은 시간을 할애할수록 감지되지 않은 잠재적인 문제가 있을 수 있는 위치를 탐색하고 생각하는 횟수가 줄어든다.

 

<Non-functional Test>

Performance Testing

 - 성능(Performance) 테스트는 일반적으로 애플리케이션에서 일부 사용자 시나리오를 완료하는 데 걸리는 시간을 측정한다. 기본적으로 작업 성취 관점에서 애플리케이션이 단일 사용자에게 얼마나 반응하는지 측정한다.

 - 부하(Load) 테스트와 스트레스(Stress) 테스트는 비슷하지만 목표가 약간 다르다. 이 두 가지 유형의 테스트는 모두 시스템의 과부하를 시뮬레이션 한다. 도구는 사용자가 있는 시스템에 대해 트래픽을 생성하는 데 사용된다. 부하 테스트는 최대 로드에서 시스템이 어떻게 수행되는지에 초점을 맞추고 스트레스 테스트는 시스템이 처리할 수 있는 사용자 또는 트래픽의 상한을 찾기 위해 의도적으로 시스템을 중단하려고 시도힌다.

 - 시스템의 확장 또는 확장 기능을 검사하는 확정성(Scalability) 테스트도 있다.

 

Security Testing

 - 침투(Penetration) 테스트는 존재할 수 있는 악용 가능한 취약점을 발견하기 위해 배포된 시스템에 대한 시뮬레이션된 공격이다.

 - 구성 요소 취약성 분석(Component Vulnerability Analysis)은 테스터가 알고 있어야 하는 훌륭한 영역이다. 이것은 또한 도구 지원이며 도구는 응용 프로그램에서 사용하는 모든 오픈 소스 구성 요소에서 알려진 게시된 취약점을 검색한다.

 - API 보안 테스트는 애플리케이션의 비지니스 API를 조사하여 취약점을 찾는다. 제품에 UI와 별도로 API가 있는 경우 보안 방법을 알고 있는 것이 좋다.

 - 정적 분석(Static Analysis)은 도구가 애플리케이션의 소스 코드를 검사하여 안전하지 않은 사례를 찾는 화이트박스 기술이다. 각 기술 스택에는 이 공간에 고유한 도구가 있다.

 

→ 이와 같이 비기능 테스트는 광범위한 영역이며 어떤 종류의 비기능적 특성이 귀하가 담당하는 시스템에 가장 중요한지 생각하는 것이 좋습니다.

 

 여기서 부터는 애자일 소프트웨어 개발 방법론에 널리 사용되며 전문 소프트웨어 테스터에게 고유한 기회와 과제를 제시한다. 애자일에 대한 테스트를 독특하게 만드는 가장 중요한 원인은 테스터가 종종 개발 팀의 일부로 완전히 통합된다는 사실이다.

 

Testers as Part of an Agile Team

→ 장점

 - 릴리스가 제품을 출시할 준비가 되었을 때보다 훨씬 더 일찍 소프트웨어 라이프사이클에서 테스트하고 피드백을 제공할 수 있다.

 - 기능의 테스트 가능성과 전체 시스템에 영향을 줄 수 있다.

 - 테스트 노력을 알리기 위해 시스템에 대한 화이트 박스 지식을 얻는다.

 - 전체 시스템을 테스트하거나 한 번의 대규모 테스트로 시스템의 모든 측면을 릴리스할 필요가 없다. 시스템이 발전함에 따라 점진적으로 테스트할 수 있다.

→ 단점

 - 일반적으로 소프트웨어 릴리스 사이에는 짧은 주기가 있다. 따라서 점진적으로 테스트하더라도 더 짧은 시간 창에서 테스트 활동을 수행하고 있다.

 - 애자일 팀 구성원으로서 더 많은 회의, 대화 및 책임이 분리된 테스터보다 더 많다.

 - 수행할 수 있는 유용한 활동으로 지식을 얻고 조기 피드백을 제공할 수 있지만 시간이 걸린다.

 - 당신은 또한 약간의 관점을 잃을 수 있다. 시스템을 새로운 관점에서 최종 사용자로 보는 것이 더 어려울 수 있다.

 

Testing Activities Over Time