UNIT, INTEGRATION, ACCEPTANCE TEST
출처 : 단위 테스트 vs 통합 테스트 vs 인수 테스트
단위 테스트 (Unit Test)
단위 테스트는 응용 프로그램에서 테스트 가능한 가장 작은 소프트웨어를 실행하여 예상대로 동작하는지 확인하는 테스트이다.
...
단위 테스트에서 테스트 대상 단위의 크기는 엄격하게 정해져 있지 않다. 하지만, 일반적으로 클래스 또는 메소드 수준으로 정해진다. 단위의 크기가 작을수록 단위의 복잡성이 낮아진다. 따라서, 단위 테스트를 활용하여 동작을 표현하기 더 쉬워진다. 즉, 테스트 대상 단위의 크기를 작게 설정해서 단위 테스트를 최대한 간단하고 디버깅하기 쉽게 작성해야 한다.
...
소프트웨어를 개발할 때, 소프트웨어 내부 구조나 구현 방법을 고려하여 개발자 관점에서 테스트한다. 그러므로 단위 테스트는 소프트웨어 내부 코드에 관련한 지식을 반드시 알고 있어야 하는 화이트박스 테스트이다.
통합 테스트 (Integration Test)
통합 테스트는 단위 테스트보다 더 큰 동작을 달성하기 위해 여러 모듈들을 모아 이들이 의도대로 협력하는지 확인하는 테스트이다.
...
통합 테스트는 단위 테스트와 달리 개발자가 변경할 수 없는 부분(ex. 외부 라이브러리)까지 묶어 검증할 때 사용한다. 이는 DB에 접근하거나 전체 코드와 다양한 환경이 제대로 작동하는지 확인하는데 필요한 모든 작업을 수행할 수 있다. 그러나, 통합 테스트가 응용 프로그램이 완전하게 작동하는 걸 무조건 증명하지는 않는다.
...
통합 테스트의 장점은 단위 테스트에서 발견하기 어려운 버그를 찾을 수 있다는 점이다. 예를 들어, 통합 테스트에서는 환경 버그(ex. 싱글 코어 CPU에서는 잘 실행되나 쿼드 코어 CPU에서는 잘 실행되지 않음)이 발생할 수 있다.
...
한편, 통합 테스트의 단점은 단위 테스트보다 더 많은 코드를 테스트하기 때문에 신뢰성이 떨어질 수 있다는 점이다. 또, 어디서 에러가 발생했는지 확인하기 쉽지 않아 유지보수하기 힘들다는 점도 있다.
인수 테스트 (Acceptance Test)
인수 테스트는 사용자 스토리(시나리오)에 맞춰 수행하는 테스트이다.
...
앞선 두 테스트들과 달리 비즈니스 쪽에 초점을 둔다. 프로젝트에 참여하는 사람들(ex. 기획자, 클라이언트 대표, 개발자 등)이 토의해서 시나리오를 만들고, 개발자는 이에 의거해서 코드를 작성한다. 개발자가 직접 시나리오를 제작할 수도 있지만, 다른 의사소통집단으로부터 시나리오를 받아(인수) 개발한다는 의미를 가지고 있다.
...
인수 테스트는 애자일 개발 방법론에서 파생했다. 특히, 익스트림 프로그래밍(XP)에서 사용하는 용어이다. 이는 시나리오가 정상적으로 동작하는지를 테스트하기 때문에 통합 테스트와는 분류가 다르다. 시나리오에서 요구하는 것은 누가, 어떤 목적으로, 무엇을 하는가이다. 개발을 하다 보면 이런 기능은 API를 통해 드러난다. 인수 테스트는 주로 이 API를 확인하는 방식으로 이뤄진다.
...
결국, 인수 테스트는 소프트웨어 인수를 목적으로 하는 테스트이다. 소프트웨어를 인수하기 전에 명세한 요구사항(인수 조건)대로 잘 작동하는지 검증이 필요하다.
...
소프트웨어를 인수할 때, 소프트웨어 내부 구조나 구현 방법을 고려하기보다는 실제 사용자 관점에서 테스트하는 경우가 많다. 따라서, 인수 테스트는 소프트웨어 내부 코드에 관심을 가지지 않는 블랙박스 테스트이다. 실제 사용자 관점에서 테스트할 때 주로 E2E(End-to-End) 형식을 이용해서 확인한다.
Quality Assuarance
출처 : 앱 개발회사의 QA 진행 / QA란? / 앱 검수하기 / 앱 사전테스트
"QA는 Quality Assurance의 약자로 품질 보증이라는 뜻을 갖고 있습니다. 개발 과정에서의 QA는 개발 마무리 단계에서 필수로 진행해야 하는 단계인데요."
..."각자 환경에서 QA를 진행하며 작동이 되는지, 오류가 발생한다면 어떤 오류가 발생하는지, UX적으로 불편한 사항이 있는지 등을 중점적으로 체크했습니다."
..."오류사항들은 개발자분들이 놓치지 않고 처리할 수 있도록 지라(Jira)에도 함께 작성했는데요. 지라의 하위 이슈 기능을 통해 업무의 진행도를 수시로 체크할 수 있습니다."
..."저희는 오류가 많지 않아서 한 에픽 안에서 모두 정리를 끝냈지만 정리할 것이 많은 경우에는 카테고리별로 에픽을 나누어서 정리하는 것도 좋은 방법입니다. 한꺼번에 이슈들을 넣어놓게 되면 아이폰에서 발생한 이슈인지, 안드로이드에서 발생했는지, 웹에서 발생했는지 모바일에서 발생했는지 등 헷갈릴 수 있는 경우가 많기 때문입니다."
..."그리고 오류가 발생하는 부분에서 어떤 개발적 오류가 있었는지를 체크해보는 시간을 가졌습니다. 함께 피드백을 진행하며 당장 고칠 수 있는 부분은 고쳐나갔습니다. 마무리 과정에서 발견된 오류들이기 때문에 대부분이 아주 미세한 오류들이어서 빠르게 수정을 진행할 수 있었습니다. 🙂"
..."개발자분들은 주로 기능적인 문제, 어떠한 부분에서 기능이 제대로 작동을 하는지에 대해 디테일하게 진행했습니다.
..."또한 QA에서 기획과 일치하는 결과물이 나왔는지에도 중점을 두었습니다."
..."디자인적인 부분에서도 QA를 진행했습니다. 우선은 마진(Margin)이 정확하게 들어가있는지를 체크했는데요. 여기서 마진은 박스의 바깥 여백을 뜻합니다. 마진은 개발의 영역이긴 하지만 보여지는 부분이기 때문에 디자인적 요소라고 칭했습니다.🙂"
..."마지막으로는 UX적인 부분을 고려했습니다. 개발 단계에서는 미처 체크하지 못했던 UX적인 면을 중점으로 체크했습니다. 유저가 이용하면서 불편한 점이 있겠다 싶은 부분들을 체크하고, 수정했습니다. 앱의 플로우가 부드럽게 진행되는지를 체크하여 중간 과정에서 첨삭을 진행했습니다."
Qaulity Assistant
출처 : QA != 통합테스트
우리는 앞으로도 더 많은 일을 해야하고 …
... 다시 한 번 더 말씀드리지만, QA는 통합테스트와 대치할 수 없는 단어입니다.
QA는 통합테스트만 하는 일을 의미하지 않습니다.
품질(Quality) 관점에서 테스트는 극히 일부 밖으로 보이는 영역일 뿐, 우리는 더 많은 일들을 해야합니다.
사용자에게 어떻게 하면 극대의 가치를 전달할 수 있도록 잘 만들어질 수 있나 사용자의 입장에서, 기술 관점에서 모두 신경써야 합니다.
상황1. (한 달도 넘게 진행된 프로젝트 내용을 미리 공유받지 못한 상황에서) "다음주 오픈 예정인데 일주일만 QA해주세요."
..
"QA는 프로젝트 시작과 끝 전반에 걸쳐 품질을 저해할 수 있는 요소를 찾아내고 알리고 해결을 돕는 활동들을 의미합니다."
...
"상황2. "QA했는데 왜 운영 이슈가 계속 나와요? (QA한 거 맞나요?)""
...
"이 경우 버튼을 누르자마자 기능 동작을 하지 않는 등 엉망진창인 상태에서 올 때가 가끔 있습니다.
이 때, 저희는 의사결정을 할 수 있는 분께 프로젝트 일정을 더 늘려야한다, 개발 완료가 되지 않았다고 알립니다.
하지만 프로젝트를 처음부터 참여하지 않은 탓일까요? 얼마 만큼의 일정이 더 필요하고 얼마 만큼 구현이 덜 되었는지 근거가 부족할 때가 많습니다."
...
상황3. QA담당자가 프로젝트 킥오프 회의와 회고 회의들에서 누락되는 상황.
...
"QA는 테스트만 하는 활동이 아닙니다.
프로젝트의 목적과 목표에 어긋나지 않으면서도 소프트웨어와 기술을 바탕으로 사용자에게 최고의 품질(가치)을 제공하기 위해 노력하는 활동입니다."
...
"킥오프 회의에서 프로젝트의 목적과 목표를 듣지 못했다면, 적절한 활동을 하지 못할 것입니다.
회고 회의에서 이번 프로젝트가 어땠는지에 대해 듣지 못한다면, 다음 어떤 활동을 할지 발전이 없을 것입니다."
