minyoung

1. 결제 테스트란?결제 테스트는 사용자가 결제를 요청했을 때 의도한 결과대로 처리되는지 확인하는 과정이다. 결제가 정상적으로 완료되는 상황뿐만 아니라 결제에 실패하거나 예상하지 못한 상황이 발생했을 때도 시스템이 올바르게 동작하는지 검증해야 한다.특히 결제 기능은 금액과 거래 정보에 직접적인 영향을 주기 때문에 다양한 상황을 고려한 테스트가 필요하다. 2. 결제 테스트에서 확인하는 항목가장 기본적으로 확인하는 항목은 결제 성공과 실패이다. 정상적인 결제 요청이 승인되는지, 결제 금액과 결제 수단이 올바르게 처리되는지 확인한다. 반대로 결제 요청이 실패했을 때는 실패 상태가 정확하게 표시되고 거래 정보가 잘못 저장되지 않는지도 검증한다.이와 함께 예외 상황에 대한 테스트도 중요하다. 예를 들어 잔액이 부..

1. 연속 클릭 테스트란?웹 서비스를 이용하다 보면 버튼을 한 번 클릭했는데 화면이 바로 반응하지 않아 여러 번 클릭하는 경우가 있다. 사용자는 단순히 응답이 늦다고 생각할 수 있지만, 서비스 내부에서는 하나의 요청이 처리되는 동안 추가 요청이 발생할 수 있다.이러한 상황은 단순한 화면 표시 문제를 넘어 중복 데이터 생성이나 중복 결제와 같은 문제로 이어질 가능성이 있다.따라서 QA 엔지니어는 버튼을 한 번 클릭했을 때의 정상 동작뿐만 아니라 짧은 시간 동안 여러 번 클릭했을 때 서비스가 어떻게 동작하는지도 확인할 필요가 있다. 2. 연속 클릭으로 발생할 수 있는 문제첫 번째는 동일한 요청이 여러 번 전송되는 상황이다. 사용자가 저장 버튼을 빠르게 여러 번 클릭하면 같은 데이터가 중복으로 등록될 수 있다..

QA 업무를 하다 보면 기능이 수정된 이후 해당 부분을 다시 테스트하게 된다. 이때 수정된 결함이 실제로 해결되었는지 확인하는 것과 기존 기능에 문제가 생기지 않았는지를 확인하는 것은 목적이 다르다.수정된 결함이 해결되었는지 다시 확인하는 것은 확인 테스트(Confirmation Test)이고, 수정이나 변경으로 인해 기존에 정상적으로 동작하던 기능에 문제가 발생하지 않았는지 확인하는 것이 회귀 테스트(Regression Test)이다.예를 들어 로그인 과정에서 오류가 발생해 개발자가 해당 부분을 수정했다고 가정해보자. 수정 후 동일한 조건에서 다시 로그인했을 때 오류가 발생하지 않는지 확인하는 것이 확인 테스트다. 이후 로그인 기능의 수정으로 인해 로그아웃, 자동 로그인, 마이페이지 등 기존 기능에 문..

테스트 데이터 요건테스트 데이터는 테스트 케이스를 실행하는 데 필요한 데이터이다. 구체적으로 말하면 테스트 데이터는 테스트 케이스의 선행 조건과 입력에서 사용되는 데이터이다. 테스트 데이터가 하나의 문자, 숫자 등과 같이 단순한 형태라면 테스트 케이스에 직접 테스트 데이터를 명시하고 이러한 테스트 데이터를 준비하기 위한 특별한 작업이 불필요할 수 있다. 하지만 음성, 이미지, 동영상, 대량의 센서 데이터 등과 같이 규모도 크면서 형태가 복잡한 데이터가 테스트 데이터로 필요하다면, 이러한 테스트 데이터에 대한 요건을 구체적으로 정의해야 하고 테스트 환경 구축 및 관리 활동에서 테스트 데이터를 준비하기 위한 특별한 작업이 필요할 수 있다. 테스트 대상에 대한 입력 데이터 : 테스트 케이스를 실행하는 과정에서..

테스트 절차 항목 목적 : 해당 테스트 절차를 통해서 테스트하고자 하는 구체적인 상황을 기술한다.우선순위 : 우선순위를 기술한다. 우선순위가 높은 테스트 절차를 우선 실행한다.시작 작업 : 포함된 테스트 케이스를 실행하기 위하여 준비할 작업을 기술한다.테스트 케이스 목록 : 테스트 절차에 포함된 테스트 케이스를 실행 순서대로 기술한다.종료 및 정리 작업 : 테스트 실행을 종료하는 방법과 종료 후에 수행할 작업을 기술한다.다른 테스트 절차와의 관계 : 다른 테스트 절차와의 실행 순서 측면에서 관계를 기술한다. 시작 작업 테스트 절차 실행은 테스트 절차를 구성하는 테스트 케이스 목록의 각 테스트 케이스를 명시된 순서대로 수행함으로써 진행된다. 만약 테스트 케이스가 실행되는 데 필요한 상태와 그 상태를 준비하..

QA 엔지니어로 업무를 하면서 가장 어려운 순간 중 하나는 오류를 발견했을 때가 아니라, 발견한 현상이 정말 ‘버그’인지 판단해야 할 때이다.처음 QA 업무를 시작했을 때는 예상한 결과와 실제 결과가 다르면 비교적 쉽게 이슈라고 판단했다. 하지만 여러 서비스를 테스트하고 테스트 케이스를 직접 설계하면서 생각이 조금씩 달라졌다. 화면에서 예상과 다른 결과가 나오더라도 그것이 반드시 결함을 의미하는 것은 아니기 때문이다.예를 들어 검색 기능을 테스트한다고 가정해보자. 사용자가 검색어를 입력했는데 내가 생각했던 결과와 다른 데이터가 노출된다면 처음에는 검색 기능에 문제가 있다고 생각할 수 있다. 하지만 실제로는 검색 조건에 따라 정상적으로 필터링된 결과일 수도 있고, 해당 계정의 권한에 따라 조회할 수 있는 ..