QA가 전문적인 분야로 인식되어 가면서 QA 전문가와 테스터에 대한 개념과 업무에 대한 이론이 더욱 자리 잡아가고 있다. 단순히 테스트만 하는 테스터와 QA 전문가를 분류하는 기준은 명확하게 말할 수 있다. "QA가 무엇인가?" 이 물음에 답할 수 있느냐이다. 소프트웨어 테스트라는 업무를 진행하면서 단순히 테스트만 진행했다면 대답하기 어려울 것이다. 단순히 테스트만 한 테스터가 있다면 아래의 테스팅 노하우를 읽어보는 것을 권하고 싶다. 그리고 한번쯤은 왜라는 의문점을 스스로 가져보길 바란다. 이 포스트를 주의 깊게 읽어보면 테스트 활동을 실천하고 적용해 볼 수 있다. 이후에 경험을 통해 모든 사례를 배울 수 있고 실패하는 사례도 경험의 과정이고 배움이라는 것을 인지해야 한다.
경험을 통해 배운 20가지 최선의 소프트웨어 테스트 업무 노하우
1) 소프트웨어 요구 사항과 설계 단계에서 테스트팀의 권한을 확보해야 한다.
이 방법으로 테스트팀이 애플리케이션 의존도에 대해 아는 것이 상세한 테스트 커버리지를 달성 시킬 수 있다. 만약 테스트팀이 개발 수명 주기에서 이런 부분을 요청받지 못했다면 관리자나 담당자에게 모든 프로세스 결정이나 관련 회의에 대해 테스트팀을 포함시켜 달라고 요청해야 한다.
2) 사용자 요구 사항 문서에 대한 이의 제기를 생략한다.
사용자가 어플에 필요하지 않거나 요구하지 않으려고 했던 것을 명시하지는 않는다.
3) 테스트 결과를 철저히 분석해서 인지한다.
테스트 결과만 보고 지나치면 안 된다. 마지막 테스트 결과는 ‘Pass’ 이거나 ‘Fail’일수 있다. ‘Fail’의 근본적인 원인을 해결하려는 것이 문제의 해결책으로 당신을 안내할 것이다. 테스터가 단순히 결함을 보고하는 것이 아닌 해결책을 제시한다면 인정받을 것이다.
4) 테스트 대상이 되는 소프트웨어의 테스트 범위를 항상 최대로 잡아서 노하우를 터득한다.
100% 테스트 범위를 충족하는 것은 불가능하지만 항상 근접하게 시도할 수 있다.
5) 최대 테스트 범위를 확실히 하기 위해서 테스트 중인 어플의 비슷한 기능을 모듈화한다.
각각의 단위 모듈 별로 테스트케이스를 작성한다. 예를 들면 만약 웹사이트 어플을 모듈별로 나눴다고 가정하고 ‘사용자 정보 수락’이라는 하나의 모듈이 있다. 테스트 케이스 작성을 위해 ‘유저 정보’ 화면을 UI 테스트, 보안 테스트, 기능 테스트 등과 같은 항목으로 분류할 수 있다. 테스트 데이터에 대해서 모든 폼 영역 유형과 사이즈, 유효한 값과 부정적인 값을 적용하고 모든 테스트 범위를 충족하는 테스트 케이스를 작성한다.
이 방법은 당신이 모든 요구 사항을 테스트 가능하게 할 뿐만 아니라 결함을 예방할 수 있다. 테스트를 진행하기에 앞서 테스트 케이스를 준비해 둔다면 더 효율적인 테스트 진행이 가능하다.
7) 테스트 케이스 설계 시 요구 사항에 따른 유효한 조건의 기능을 먼저 작성한다.
그다음 유효하지 않은 조건의 테스트 케이스를 작성한다. 이렇게 하는 이유는 정상동작을 알아야 비정상동작에 대한 인지가 가능하며 유효한 조건에 만족하지 않는 것은 1 결함으로 판단해야한다.
이 방법으로 테스트 대상의 예상되는 동작과 예상하지 않는 동작에 대해 포함할수 있다.
8) 개발자에게 테스트 케이스를 코딩보다 먼저 인지하게 해라. 더 많은 결함을 발견할 생각에 테스트 케이스를 테스트 버전 어플이 나올 때까지 숨겨 놓고 기다리지 말고 개발자에게 테스트케이스를 리뷰하도록 공유한다. 개발자가 품질 있는 어플을 개발하면 재작업 시간을 절약시킬 것이다.
9) "개발자는 자신의 코드를 테스트하지 않는다."라는 것을 염두해 두자.
개발된 어플의 기본적인 단위 테스트가 끝나면 개발자는 테스터에게 테스트용 어플을 전달한다. 하지만 당신은 개발자에게 테스트 용 어플을 전달하라고 강요해서는 안된다. 처리할 시간을 줘야 한다. 관리자를 포함한 모든 사람들이 언제 모듈과 업데이트가 언제 테스트를 위해 전달되는지 알고 있으며, 그들은 그에 따라 테스트 시간을 추정 할 것이다. 이것이 애자일 프로젝트(Agile Project) 환경에서의 전형적인 상황이다.
10) 결함을 찾을 수 있다는 긍정적인 생각을 하고 테스트를 진행해라.
사전에 테스트 대상에 결함이 없을 거라고 생각하고 진행하면 안 된다. 결함을 발견한다는 인지를 하고 테스트를 진행하면, 분명히 검출하기 어려운 결함을 발견하게 될 것이다.
11) 우선순위와 중요도가 높은 테스트 업무를 시간이 다 돼서 진행하지 말자.
테스트 업무에 높고 낮은 우선순위를 정해서 이에 따라서 테스트 업무를 진행해야 한다. 우선순위를 정하기 위해 리스크와 관련된 것을 분석한다.
12) 엄격한 응답시간이 요구되는 어플들은 성능 테스트를 철저히 진행해라.
성능 테스트는 많은 어플의 중요한 부분이다. 전수 검사에서 성능 테스트는 요구되는 다량의 데이터가 부족하기 때문에 대부분 생략되는 부분이다. 테스트 대상에 대해 성능 테스트를 할 수 있는 방법을 찾아야 한다. 만약 성능 테스트 데이터를 생성하기 어려운 상황일 경우에는 기본적인 스크립트를 작성하거나 담당 개발자에게 요청하여 테스트를 진행한다.
13) 리그레이션 테스트(Regression Test)를 위해 테스트 케이스를 구분하고 그룹화한다.
이슈가 발생한 부분에 대해서 분석해서 해당 영역에 관련된 기능과 테스트 케이스를 구분할 수 있다면 재 테스트는 효율적이고 신속하게 진행될 수 있다. 하지만 관련 기능을 구분할 때에는 상황과 프로그램의 복잡도에 따라서 개발자 혹은 프로젝트 관리자와 협업이 필요하며 신중하게 분석해야 한다. 잘못 분석한다면 치명적인 결함을 테스트하지 않을 수 있다.
14) 리그레이션 테스트를 진행할 때는 이전 결함 히스토리와 그래프를 사용한다.
어떤 모듈에서 결함이 많이 발생했는지 등을 측정해서 기록해야 한다. 그래프는 어플의 많은 결함 발생할 부분을 예측하는데 도움이 될 수 있다.
15) 테스트 업무 진행 중 알게 된 새로운 용어와 개념을 메모해라.
테스트 시 기록 문서를 열어두어야 한다. 테스트 진행 상황과 소견을 기록한다. 최종 테스트 결과 보고를 준비할 때 이 문서를 참고한다. 이 습관은 모호하지 않은 상세한 테스트 완료 보고서를 제공하는데 도움이 될 것이다.
16) 테스트 중 개발자나 테스터로 인해서 변경된 코드 기반에 대해 기록한다.
이것은 실제 운영 중인 프로젝트에서 변경된 사항이 실제 사용 중인 프로세스에 영향을 미치지 않게 하기 위한 개발과 테스트 환경의 필수적인 사항이다. 테스트 목적을 위한 모든 변경된 코드 내용을 메모하고 최종 배포할 때 변경되고 삭제된 사항들이 적용된 정보가 사용자에게 전달될 수 있도록 해야 한다.
17) 테스트 환경과 개발자는 독립적으로 유지해라.
이것은 관련 문서나 Release Note에 빠진 어떤 구성요소를 찾기 위해 필수적인 사항이다. 가끔 개발자들은 시스템이나 어플의 구성요소로 변경하는데 해당 사항에 대한 언급을 잊는경우가 있다. 개발자들이 테스트 환경에 대한 접근을 할수 없다면 뜻하지 않게 구성요소를 잘못 변경하는 일은 없을 것이고 놓쳤던 사항들은 정해진 단계에서 발견될 것이다.
18) 애매모호하지 않은 명확하고 기술적인 결함 보고서를 작성해라.
결함의 증상만 전달하지 말고 미치는 영향과 가능한 해결책을 제안해야 한다.
19) 소프트웨어에 대해 더 많은 정보를 얻기 위해 개발자와 원활한 의사소통을 유지해라.
언제든 가능하면 분쟁을 해결하기 위해 직접 대면해서 이야기하고 오해를 피해야 한다. 하지만 요구 사항을 받아 들이거나 분쟁이 해결되었을 경우에 구두로만 하지 말고 이메일 같은 서면으로도 기록을 해두자
20) 테스트 팀은 최선의 테스트 사례와 경험을 다른 팀에게 공유해야 한다.
테스트 업무는 창의적이고 도전적인 업무라는 것을 잊으면 안 된다. 이 도전적인 과제가 어떻게 전개될지는 본인의 능력과 경험에 따라 달라진다고 생각한다.
경험을 통해 배운 20가지 최선의 소프트웨어 테스트 업무 노하우
1) 소프트웨어 요구 사항과 설계 단계에서 테스트팀의 권한을 확보해야 한다.
이 방법으로 테스트팀이 애플리케이션 의존도에 대해 아는 것이 상세한 테스트 커버리지를 달성 시킬 수 있다. 만약 테스트팀이 개발 수명 주기에서 이런 부분을 요청받지 못했다면 관리자나 담당자에게 모든 프로세스 결정이나 관련 회의에 대해 테스트팀을 포함시켜 달라고 요청해야 한다.
2) 사용자 요구 사항 문서에 대한 이의 제기를 생략한다.
사용자가 어플에 필요하지 않거나 요구하지 않으려고 했던 것을 명시하지는 않는다.
3) 테스트 결과를 철저히 분석해서 인지한다.
테스트 결과만 보고 지나치면 안 된다. 마지막 테스트 결과는 ‘Pass’ 이거나 ‘Fail’일수 있다. ‘Fail’의 근본적인 원인을 해결하려는 것이 문제의 해결책으로 당신을 안내할 것이다. 테스터가 단순히 결함을 보고하는 것이 아닌 해결책을 제시한다면 인정받을 것이다.
4) 테스트 대상이 되는 소프트웨어의 테스트 범위를 항상 최대로 잡아서 노하우를 터득한다.
100% 테스트 범위를 충족하는 것은 불가능하지만 항상 근접하게 시도할 수 있다.
5) 최대 테스트 범위를 확실히 하기 위해서 테스트 중인 어플의 비슷한 기능을 모듈화한다.
각각의 단위 모듈 별로 테스트케이스를 작성한다. 예를 들면 만약 웹사이트 어플을 모듈별로 나눴다고 가정하고 ‘사용자 정보 수락’이라는 하나의 모듈이 있다. 테스트 케이스 작성을 위해 ‘유저 정보’ 화면을 UI 테스트, 보안 테스트, 기능 테스트 등과 같은 항목으로 분류할 수 있다. 테스트 데이터에 대해서 모든 폼 영역 유형과 사이즈, 유효한 값과 부정적인 값을 적용하고 모든 테스트 범위를 충족하는 테스트 케이스를 작성한다.
이 방법은 당신이 모든 요구 사항을 테스트 가능하게 할 뿐만 아니라 결함을 예방할 수 있다. 테스트를 진행하기에 앞서 테스트 케이스를 준비해 둔다면 더 효율적인 테스트 진행이 가능하다.
7) 테스트 케이스 설계 시 요구 사항에 따른 유효한 조건의 기능을 먼저 작성한다.
그다음 유효하지 않은 조건의 테스트 케이스를 작성한다. 이렇게 하는 이유는 정상동작을 알아야 비정상동작에 대한 인지가 가능하며 유효한 조건에 만족하지 않는 것은 1 결함으로 판단해야한다.
이 방법으로 테스트 대상의 예상되는 동작과 예상하지 않는 동작에 대해 포함할수 있다.
8) 개발자에게 테스트 케이스를 코딩보다 먼저 인지하게 해라. 더 많은 결함을 발견할 생각에 테스트 케이스를 테스트 버전 어플이 나올 때까지 숨겨 놓고 기다리지 말고 개발자에게 테스트케이스를 리뷰하도록 공유한다. 개발자가 품질 있는 어플을 개발하면 재작업 시간을 절약시킬 것이다.
9) "개발자는 자신의 코드를 테스트하지 않는다."라는 것을 염두해 두자.
개발된 어플의 기본적인 단위 테스트가 끝나면 개발자는 테스터에게 테스트용 어플을 전달한다. 하지만 당신은 개발자에게 테스트 용 어플을 전달하라고 강요해서는 안된다. 처리할 시간을 줘야 한다. 관리자를 포함한 모든 사람들이 언제 모듈과 업데이트가 언제 테스트를 위해 전달되는지 알고 있으며, 그들은 그에 따라 테스트 시간을 추정 할 것이다. 이것이 애자일 프로젝트(Agile Project) 환경에서의 전형적인 상황이다.
10) 결함을 찾을 수 있다는 긍정적인 생각을 하고 테스트를 진행해라.
사전에 테스트 대상에 결함이 없을 거라고 생각하고 진행하면 안 된다. 결함을 발견한다는 인지를 하고 테스트를 진행하면, 분명히 검출하기 어려운 결함을 발견하게 될 것이다.
11) 우선순위와 중요도가 높은 테스트 업무를 시간이 다 돼서 진행하지 말자.
테스트 업무에 높고 낮은 우선순위를 정해서 이에 따라서 테스트 업무를 진행해야 한다. 우선순위를 정하기 위해 리스크와 관련된 것을 분석한다.
12) 엄격한 응답시간이 요구되는 어플들은 성능 테스트를 철저히 진행해라.
성능 테스트는 많은 어플의 중요한 부분이다. 전수 검사에서 성능 테스트는 요구되는 다량의 데이터가 부족하기 때문에 대부분 생략되는 부분이다. 테스트 대상에 대해 성능 테스트를 할 수 있는 방법을 찾아야 한다. 만약 성능 테스트 데이터를 생성하기 어려운 상황일 경우에는 기본적인 스크립트를 작성하거나 담당 개발자에게 요청하여 테스트를 진행한다.
13) 리그레이션 테스트(Regression Test)를 위해 테스트 케이스를 구분하고 그룹화한다.
이슈가 발생한 부분에 대해서 분석해서 해당 영역에 관련된 기능과 테스트 케이스를 구분할 수 있다면 재 테스트는 효율적이고 신속하게 진행될 수 있다. 하지만 관련 기능을 구분할 때에는 상황과 프로그램의 복잡도에 따라서 개발자 혹은 프로젝트 관리자와 협업이 필요하며 신중하게 분석해야 한다. 잘못 분석한다면 치명적인 결함을 테스트하지 않을 수 있다.
14) 리그레이션 테스트를 진행할 때는 이전 결함 히스토리와 그래프를 사용한다.
어떤 모듈에서 결함이 많이 발생했는지 등을 측정해서 기록해야 한다. 그래프는 어플의 많은 결함 발생할 부분을 예측하는데 도움이 될 수 있다.
15) 테스트 업무 진행 중 알게 된 새로운 용어와 개념을 메모해라.
테스트 시 기록 문서를 열어두어야 한다. 테스트 진행 상황과 소견을 기록한다. 최종 테스트 결과 보고를 준비할 때 이 문서를 참고한다. 이 습관은 모호하지 않은 상세한 테스트 완료 보고서를 제공하는데 도움이 될 것이다.
16) 테스트 중 개발자나 테스터로 인해서 변경된 코드 기반에 대해 기록한다.
이것은 실제 운영 중인 프로젝트에서 변경된 사항이 실제 사용 중인 프로세스에 영향을 미치지 않게 하기 위한 개발과 테스트 환경의 필수적인 사항이다. 테스트 목적을 위한 모든 변경된 코드 내용을 메모하고 최종 배포할 때 변경되고 삭제된 사항들이 적용된 정보가 사용자에게 전달될 수 있도록 해야 한다.
17) 테스트 환경과 개발자는 독립적으로 유지해라.
이것은 관련 문서나 Release Note에 빠진 어떤 구성요소를 찾기 위해 필수적인 사항이다. 가끔 개발자들은 시스템이나 어플의 구성요소로 변경하는데 해당 사항에 대한 언급을 잊는경우가 있다. 개발자들이 테스트 환경에 대한 접근을 할수 없다면 뜻하지 않게 구성요소를 잘못 변경하는 일은 없을 것이고 놓쳤던 사항들은 정해진 단계에서 발견될 것이다.
18) 애매모호하지 않은 명확하고 기술적인 결함 보고서를 작성해라.
결함의 증상만 전달하지 말고 미치는 영향과 가능한 해결책을 제안해야 한다.
19) 소프트웨어에 대해 더 많은 정보를 얻기 위해 개발자와 원활한 의사소통을 유지해라.
언제든 가능하면 분쟁을 해결하기 위해 직접 대면해서 이야기하고 오해를 피해야 한다. 하지만 요구 사항을 받아 들이거나 분쟁이 해결되었을 경우에 구두로만 하지 말고 이메일 같은 서면으로도 기록을 해두자
20) 테스트 팀은 최선의 테스트 사례와 경험을 다른 팀에게 공유해야 한다.
테스트 업무는 창의적이고 도전적인 업무라는 것을 잊으면 안 된다. 이 도전적인 과제가 어떻게 전개될지는 본인의 능력과 경험에 따라 달라진다고 생각한다.
Yteoflav0consuMilwaukee Jonny Pearson Prima Cartoonizer 4.4.3
답글삭제PassFab Activation Unlocker 4.0.6.7
Wondershare UniConverter 14.1.1.77
Microsoft Office
citconsfalract