직원이 사용하기 전에 비즈니스 앱을 위한 현실적인 테스트 데이터 만들기

직원이 앱을 사용하기 시작하면 완성도 높은 데모가 실패하는 이유

완성도 높은 데모는 보통 빈 화면이나 완벽하게 정리된 몇 개의 레코드만 사용합니다. 모든 고객에게 완전한 이름이 있고, 모든 주문에는 명확한 상태가 표시되며, 모든 사람이 의도한 경로를 따릅니다. 이런 데모로 앱이 업무 흐름을 표시할 수 있다는 점은 보여 줄 수 있습니다. 하지만 바쁜 화요일에 직원들이 실제로 사용할 수 있는지는 증명하지 못합니다.

실제 업무는 훨씬 복잡합니다. 영업 담당자가 전화번호 없이 연락처를 저장한 뒤, 나중에 올바른 이메일 주소를 입력할 수도 있습니다. 운영 관리자가 «Acme»를 검색했는데 비슷한 레코드가 6개 나올 수도 있습니다. 고객이 마음을 바꿔 누군가 이미 종료한 요청을 다시 열어야 할 수도 있습니다. 현실적인 테스트 데이터는 이런 상황이 운영 환경에서 혼란을 일으키기 전에 발견하게 해 줍니다.

빈 화면은 실무적인 질문도 감춥니다. 직원이 무엇부터 입력해야 하는지 알 수 있을까요? 초안과 제출된 요청을 구분할 수 있을까요? 필수 필드가 비어 있을 때 앱이 무엇이 부족한지 설명해 줄까요? 발표자는 모든 단계를 이미 알고 있기 때문에 이런 문제를 지나칠 수 있습니다.

공유 레코드가 업무 흐름을 바꿉니다

여러 사람이 같은 앱을 사용할 때만 드러나는 문제도 많습니다. 한 직원이 고객 레코드를 수정하는 동안 다른 직원은 이전 버전을 보고 있을 수 있습니다. 관리자는 모든 요청을 봐야 하지만 직원은 자신이 맡은 요청만 봐야 할 수도 있습니다. 누군가 레코드의 상태를 바꾸면서 다음 사람을 위한 메모를 남기지 않을 수도 있습니다.

믿을 만한 활동이 담긴 데이터로 공동 작업을 테스트하세요. 이름이 비슷한 레코드, 정보가 덜 채워진 레코드, 오래된 날짜, 중복 레코드, 수정이 필요한 정보를 만들어 보세요. 그런 다음 2~3명의 테스터에게 같은 레코드를 동시에 처리하게 하세요. 변경 사항이 덮어써지는지, 담당자가 누구인지 명확한지, 상태 라벨이 이해하기 쉬운지, 검색 결과를 정렬하기 어려운지 살펴보세요.

Koder.ai를 사용하면 채팅으로 웹, 서버, 모바일 앱을 만들 수 있습니다. 하지만 빠른 개발이 일반적인 사람들의 행동을 테스트할 필요까지 없애 주지는 않습니다. 팀 전체가 앱에 의존하기 전에 실제 업무 습관을 기준으로 첫 번째 버전을 테스트하세요.

테스트 데이터와 실제 정보를 분리하세요

테스트할 때는 가상의 이름, 이메일 주소, 전화번호, 회사 정보를 사용하세요. «TEST - Northside Supplies»처럼 레코드에 분명한 표시를 붙여 실제 고객으로 착각하지 않게 하세요. 고객 목록, 직원 기록, 재무 정보, 비공개 메모를 테스트 환경에 복사하지 마세요.

복제한 레코드를 많이 만드는 것보다 작고 다양한 테스트 데이터가 더 효과적입니다. 일반적인 사례, 일부만 작성된 레코드, 중복 레코드, 누구나 알아볼 수 있는 실수를 몇 가지 포함하세요. 그러면 직원들이 실제 정보에 위험을 주지 않으면서 직접 시도하고 실수하고 이해하기 어려운 부분을 알려 줄 수 있습니다.

직원이 실제로 하는 업무부터 시작하세요

비즈니스 앱은 평범한 화요일에 사람들이 처리하는 업무를 기준으로 테스트해야 합니다. 직원들이 실제로 쓰는 표현으로 구체적인 업무를 적어 보세요. 영업 담당자가 주문을 입력합니다. 관리자가 환불을 승인합니다. 고객 담당자가 고객의 전화번호를 수정합니다. «주문 화면 테스트»처럼 넓은 표현보다 이런 내용이 훨씬 좋은 출발점입니다.

각 업무를 시작점, 행동, 예상 결과가 분명한 짧은 시나리오로 바꾸세요. 기술적인 도움 없이도 동료가 읽고 이해할 수 있을 만큼 쉽게 작성해야 합니다.

예를 들어 다음과 같습니다. «배송되지 않은 주문의 배송 주소를 바꿔 달라는 고객의 전화를 받았다. 영업 담당자는 주문을 찾고 주소를 수정한 뒤 저장한다. 그리고 주문 확인서에 새 주소가 표시되는지 확인한다.» 이 시나리오를 보면 어떤 레코드를 준비해야 하고 변경 후 앱에 무엇이 표시되어야 하는지 알 수 있습니다.

직원들이 하루 종일 반복하는 일상 업무에 대부분의 관심을 기울이세요. 결과를 바꾸는 작은 차이도 기록해야 합니다. 신규 고객인지 기존 고객인지, 상품이 1개인지 5개인지, 청구서가 전액 결제됐는지 일부만 결제됐는지 등이 여기에 해당합니다. 완성도 높은 데모는 완벽한 레코드 하나를 사용하는 경우가 많지만 실제 업무는 거의 그렇지 않습니다.

자주 발생하지 않는 업무도 테스트하세요. 직원이 절차를 잊을 수도 있고, 앱을 처음 만든 사람이 그런 업무를 한 번도 시도하지 않았을 수도 있습니다. 다음과 같은 업무를 포함하세요.

• 한 달을 마감하고 연체된 청구서 확인하기
• 잘못된 고객으로 입력된 주문 수정하기
• 관리자 승인 후 환불 처리하기
• 퇴사한 직원이 맡고 있던 업무 재배정하기
• 재무팀이나 감사 담당자를 위한 보고서 내보내기

Koder.ai로 앱을 만들었다면 개발 중에 이런 시나리오를 직접적인 채팅 요청으로 작성하세요. 직원을 초대하기 전에 준비한 레코드로 반복해서 실행하고, 각 시나리오 옆에 예상 결과를 적어 두세요.

좋은 시나리오에는 분명한 완료 기준이 있습니다. «고객 정보 업데이트»는 너무 막연합니다. «고객의 청구 이메일을 변경하고 레코드를 저장한 뒤 다음 청구서에 해당 이메일이 사용되는지 확인한다»라고 쓰면 테스터가 확인할 구체적인 내용이 생깁니다.

일상적인 비즈니스 데이터와 비슷한 레코드를 만드세요

빈 앱은 데모에서 깔끔해 보여도 평범한 화요일에는 문제를 일으킬 수 있습니다. 직원은 흔한 이름의 고객을 찾고, 연체된 청구서를 확인하고, 공급업체 메모를 살펴보고, 두 번 담당자가 바뀐 레코드도 이해할 수 있어야 합니다.

샘플 레코드를 회사에서 다루는 정보와 비슷하게 만드세요. 가상의 이름과 연락처를 사용하고, 고객이나 직원 데이터를 복사하지 마세요. 신규 고객, 장기 고객, 정보가 부족한 공급업체, 부서를 옮긴 직원, 여러 메모가 있는 레코드처럼 적절히 섞어 구성하세요.

날짜, 금액, 상태에는 차이가 있어야 합니다. 모든 청구서의 합계가 같고 모든 요청이 «진행 중»이라면 정렬, 필터, 보고서가 제대로 작동하는지 알 수 없습니다. 여러 달에 걸친 레코드를 만들고 앱에 맞춰 초안, 발송됨, 결제 완료, 지연, 취소, 보관됨과 같은 다양한 금액과 상태를 넣으세요.

현실적인 패턴을 소수만 넣어도 똑같은 항목 수백 개를 만드는 것보다 많은 문제를 찾을 수 있습니다.

• 한 고객에게 같은 날 주문이 2개 있습니다.
• 한 공급업체에 오래된 전화번호가 있고, 변경 내용을 설명하는 최근 메모가 있습니다.
• 퇴사한 직원이 과거 레코드에는 표시되지만 새 업무를 받을 수는 없습니다.
• 여러 고객이 같은 성이나 회사명을 공유합니다.
• 큰 금액 하나가 소액의 일반 거래 여러 건 옆에 표시됩니다.

오래된 레코드도 일부러 추가하세요. 최근 항목 5개만 검색되는 결과로는 직원이 지난해 요청을 찾을 수 있는지, 월간 보고서가 정보를 올바르게 묶는지 알기 어렵습니다. 오래된 데이터는 어색한 날짜 형식, 보관된 상태, 현재 담당자가 없는 레코드도 드러냅니다.

메모는 간단하지만 실제처럼 작성하세요. «고객이 배송을 두 번으로 나눠 달라고 요청함»이 «테스트 메모 14»보다 훨씬 유용합니다. 내부 테스트라도 실제 주소, 계좌 번호, 전화번호, 비공개 의견을 테스트 앱에 넣지 마세요.

팀을 초대하기 전에 사용자와 권한을 모델링하세요

모든 사람이 같은 화면과 버튼을 보면 앱이 문제를 일으킵니다. 현실적인 테스트에는 실제 사람도 포함되어야 합니다. 레코드를 입력하는 직원, 승인하는 관리자, 진행 상황만 확인하는 사람이 필요합니다.

직함만으로 역할을 정하지 말고 매일 하는 업무를 기준으로 역할을 정의하세요. «관리자»라는 직함을 가진 두 사람도 서로 다른 접근 권한이 필요할 수 있습니다. 영업 관리자는 할인을 승인할 수 있어야 하지만 급여 정보는 보면 안 됩니다. 회계 담당자는 청구서를 만들 수 있어야 하지만 고객의 신용 한도는 변경하면 안 됩니다.

각 역할이 할 수 있는 일을 적은 다음 그 역할의 계정으로 모든 작업을 테스트하세요. 사용자가 필요한 레코드를 보고, 만들고, 수정할 수 있는지 확인하는 동시에 제한된 필드와 작업은 사용할 수 없게 되어 있는지 살펴보세요. 보고서, 파일, 설정, 내보내기, 알림도 테스트해야 합니다. 비공개 데이터가 기본 레코드 페이지가 아니라 이런 영역에 나타나는 경우가 많기 때문입니다.

의도한 경로만 테스트하지 마세요. 제한된 권한을 가진 직원으로 로그인하고 검색으로 레코드를 연 다음 저장된 브라우저 주소로도 접근해 보세요. 앱은 해당 작업을 차단해야 합니다. 메뉴 항목을 숨기는 것만으로는 잘못된 사용자가 접근할 수 있는 페이지를 보호할 수 없습니다.

관리자 계정도 만들고 신중하게 테스트하세요. 관리자는 대개 권한을 변경하고 모든 레코드를 보고 데이터를 삭제할 수 있습니다. 직원 계정의 설정이 잘못되었을 때 관리자가 접근 권한을 복구할 수 있는지 확인하세요.

2주 동안 일하는 계약직처럼 임시 계정도 추가하세요. 해당 업무에 필요한 레코드와 작업만 허용해야 합니다. 임시 근무 기간이 끝나면 이미 입력한 업무를 삭제하지 않고도 해당 사용자의 접근 권한이 사라져야 합니다.

Koder.ai의 플래닝 모드에서 직원을 초대하기 전에 역할을 설명하세요. 별도의 테스트 계정을 만들고 각 계정으로 같은 짧은 업무를 반복하세요. 앱이 빠르게 바뀌는 동안 권한 문제를 수정하는 편이 훨씬 쉽습니다.

일반적인 업무 흐름에서 어색한 사례를 테스트하세요

대부분의 앱 문제는 깔끔한 데모가 아니라 일반적인 업무 중간에 나타납니다. 일상 업무와 비슷한 날짜, 이름, 메모, 금액을 넣고 업무 흐름의 모든 단계에 해당하는 레코드를 준비하세요.

주문 앱이라면 아무도 건드리지 않은 신규 주문, 직원이 처리 중인 주문, 관리자가 승인한 주문, 지난달에 팀이 종료한 주문을 각각 만드세요. 각 단계에서 직원이 어떤 필드를 수정할 수 있는지 확인하세요. 종료된 주문에서 배송 주소를 수정했다고 주문이 조용히 «진행 중»으로 돌아가면 안 됩니다.

실제 업무에서 발생하는 예외를 테스트하세요.

• 직원이 업무를 시작한 뒤 주문을 취소하기
• 앱이 결제 완료로 기록한 뒤 결제를 반송 처리하기
• 만료일이 지난 요청 열기
• 업무 흐름에서 요구하는 첨부 파일 없이 레코드 제출하기
• 정보가 아직 부족한 항목 승인 시도하기

두 사람이 같은 항목을 바꾸는 상황은 별도로 테스트해야 합니다. 한 직원에게 고객의 전화번호를 수정하게 하고 다른 직원에게 주문 상태를 바꾸게 하세요. 앱은 결과를 명확하게 보여 줘야 합니다. 두 변경 사항을 모두 저장하거나, 두 번째 사용자에게 레코드가 변경되었다고 알리거나, 새로 고침을 요구할 수 있습니다. 하지만 한 사람의 작업을 알림 없이 숨겨서는 안 됩니다.

나중에 문제가 생기면 상태 기록이 중요합니다. 다음과 같은 간단한 순서를 테스트해 보세요. Sam이 9시 10분에 요청을 만들고, Priya가 9시 25분에 승인한 뒤, 고객의 전화를 받은 Sam이 10시에 취소합니다. 요청에 접근할 수 있는 직원은 누가 언제 어떤 변경을 했는지, 앱이 수집한 사유가 무엇인지 확인할 수 있어야 합니다. 동시에 긴 메모 기록을 모두 읽지 않아도 현재 상태를 알 수 있어야 합니다.

Koder.ai 앱이라면 테스트 버전을 만들기 전에 이런 상황을 쉬운 말로 설명하세요. 화면이 완성되어 보이는지만 확인하지 말고 실제 업무처럼 실행하세요.

일부러 잘못된 입력을 넣어 보세요

직원은 누구나 일상적인 실수를 합니다. 필드를 빠뜨리거나, 공백이 들어간 전화번호를 붙여 넣거나, 부호가 잘못된 금액을 입력할 수 있습니다. 실제 레코드가 앱에 들어오기 전에 이런 실수를 포함하세요. 깨끗한 데모 데이터에서만 작동하는 폼은 바쁜 업무일에 문제를 일으킵니다.

같은 폼을 여러 번 사용하되 매번 한 가지 세부 내용만 바꿔 보세요. 어떤 확인 작업이 실패했는지, 안내 문구가 문제를 해결하는 데 도움이 되는지 쉽게 확인할 수 있습니다.

• 조건부 필드를 포함해 필수 필드를 비워 두기
• 긴 고객 메모와 기호, 악센트, 줄바꿈, 이모지가 포함된 텍스트 붙여 넣기
• 미래 일정에 과거 날짜 입력하기, 음수 청구 금액 입력하기, 소수점 자릿수를 너무 많이 입력하기
• 다른 레코드에서 이미 사용 중인 이메일 주소 제출하기
• 공백, 쉼표, 통화 기호가 포함된 숫자 붙여 넣기

앱은 주의가 필요한 내용을 쉬운 말로 설명해야 합니다. «전화번호는 숫자 10자리 이상으로 입력하세요»는 다음 행동을 알려 줍니다. «유효성 검사 오류»는 그렇지 않습니다. 가능하면 메시지를 해당 필드 가까이에 표시하고, 사용자가 제출을 시도한 뒤에도 계속 보이게 하세요.

폼의 나머지 내용이 어떻게 되는지도 확인하세요. Maria가 신규 고객을 입력하는 데 5분을 썼는데 우편번호 하나를 잘못 입력했다고 가정해 보세요. 앱은 올바르게 입력한 메모, 연락처, 선택 항목을 보존해야 합니다. Maria는 처음부터 다시 시작하지 않고 한 필드만 고쳐 다시 제출할 수 있어야 합니다.

제출이 차단되었다면 다음 행동으로 이어지는 경로가 분명해야 합니다. 표시된 필드를 수정하거나, 안전하게 취소하거나, 업무가 끝나지 않았다면 초안으로 저장할 수 있어야 합니다. 직원이 읽기 전에 사라지는 오류 팝업이나 실패 후 응답하지 않는 버튼은 피하세요.

Koder.ai로 만들 때는 각 폼을 요청할 때 이런 사례를 포함하세요. 명확한 필드 규칙, 중복 확인, 읽기 쉬운 오류 메시지, 제출 실패 후 입력 내용 보존을 요청하세요. 그런 다음 목록에 적은 잘못된 값을 그대로 넣어 앱을 테스트하세요.

현실적인 직원 시나리오 하나를 처음부터 끝까지 실행해 보세요

직원 12명이 있는 난방 및 배관 회사를 생각해 보세요. 이 회사는 하나의 앱에서 고객, 서비스 작업, 청구서, 결제를 관리합니다.

사무실 관리자인 Maya가 라디에이터 누수 문제로 Jordan Lee에게서 전화를 받습니다. Maya가 Jordan을 검색하자 «Jordan Lee»와 같은 주소의 «J. Lee»라는 고객 레코드 2개가 나옵니다. Maya는 하나를 선택해 수요일 오전 작업을 만들고, 신고된 문제를 추가한 뒤 기술자 Sam을 배정합니다.

작업은 «예약됨» 상태로 시작합니다. Sam은 현장에서 휴대폰으로 앱을 열고 사진을 추가한 뒤 상태를 «작업 완료»로 바꾸고 부품과 인건비를 입력합니다. 이 라벨은 최종 상태처럼 들리지만 Maya는 앱이 청구서를 만들기 전에 요금을 확인해야 합니다. 직원은 «작업 완료»를 «청구 준비 완료»로 이해할 수 있고, Sam은 단지 현장을 떠났다는 뜻으로 사용할 수도 있습니다.

«사무실 검토 대기»처럼 더 명확한 상태를 사용하세요. 그러면 Maya가 다음에 할 일을 알 수 있고, 누군가 가격을 확인하기 전에 앱이 청구서를 보내는 일도 막을 수 있습니다.

Maya는 Jordan에게 45일 연체된 이전 청구서가 있다는 사실을 발견합니다. 새 작업은 청구 전에 관리자의 승인을 받아야 한다고 판단합니다. 관리자인 Priya는 Sam의 메모를 검토하고 이전 수리가 실패했기 때문에 할인을 승인합니다.

이 시나리오로 앱이 실제 결정을 처리할 수 있는지 확인할 수 있습니다.

• Maya는 중복 가능성이 있는 고객을 확인하고 병합하거나 검토 대상으로 표시할 수 있어야 합니다.
• Sam은 자신에게 배정된 작업을 수정할 수 있어야 하지만 청구 금액을 수정하거나 할인을 승인해서는 안 됩니다.
• Priya는 관련 없는 급여나 회사 설정에 접근하지 않고 작업을 승인할 수 있어야 합니다.
• 연체된 청구서는 Maya가 새 청구서를 보내기 전에 표시되어야 하지만 긴급한 수리 업무를 막아서는 안 됩니다.
• 각 상태는 다음에 누가 행동해야 하고 어떤 작업이 남아 있는지 알려 줘야 합니다.

거리 주소, 다양한 작업 메모, 18.75달러의 부품 비용, 서로 다른 결제 날짜의 청구서처럼 실제와 비슷한 레코드로 시나리오를 실행하세요. 테스터들에게 따로 작업하게 한 다음 각 상태를 어떻게 이해했는지 비교해 보세요.

Sam이 휴대폰에서 할인을 승인할 수 있다면 권한 규칙을 수정하세요. Maya가 «작업 완료»가 청구 완료인지 현장 작업만 끝났다는 뜻인지 알 수 없다면 직원들이 의존하기 전에 상태 이름을 바꾸세요.

간단한 테스트 세션을 진행하고 결과를 기록하세요

짧고 집중적인 테스트 세션은 완성도 높은 데모에서 놓치는 문제를 자주 찾아냅니다. 각 테스터에게 고객 추가, 비용 승인, 연체된 청구서 찾기처럼 일반적인 업무 하나를 맡기세요. 테스터가 혼자 작업하게 하고 클릭할 때마다 방법을 알려 주지는 마세요.

테스터가 멈추거나 잘못된 메뉴를 선택하거나 라벨의 의미를 물으면 기록하세요. 이런 순간은 앱에 더 명확한 표현이나 더 간단한 경로가 필요하다는 신호입니다.

간단한 이슈 목록을 유지하세요. 소규모 팀이라면 공유 테이블이 적절합니다. 문제가 발생한 페이지, 사용한 작업과 샘플 레코드, 예상 결과, 실제 결과, 사용자 역할을 기록하세요. 문제를 수정하는 사람이 추측하지 않고 재현할 수 있어야 합니다.

세션이 끝나기 전에 이슈의 우선순위를 정하세요. 먼저 앱을 사용할 수 없게 만드는 차단 문제를 처리하고, 그다음 비공개 데이터를 노출하거나 보기만 해야 하는 사용자가 레코드를 수정할 수 있게 하는 권한 문제를 처리하세요. 이해하기 어려운 라벨과 불필요한 클릭도 중요하지만 보통 같은 수준으로 긴급하게 대응할 필요는 없습니다.

수정 후에는 같은 역할, 같은 샘플 레코드, 같은 단계로 정확히 다시 테스트하세요. 검색 결과나 내보내기처럼 관련된 페이지도 확인해야 합니다. 고객 페이지 하나를 수정해도 다른 곳에 같은 문제가 남아 있을 수 있습니다.

Koder.ai는 스냅샷과 롤백을 지원하므로 큰 변경 전에 작동이 확인된 버전을 유지하는 데 도움이 됩니다. 새 역할과 업무 흐름이 추가될 때도 이슈 목록을 계속 활용할 수 있도록 프로젝트와 함께 보관하세요.

첫 직원 배포 전에 이 항목을 확인하세요

현실적인 샘플 레코드를 사용해 앱의 사본을 검토하세요. 완성도 높은 화면도 접수 담당자, 관리자, 재무 담당자가 바쁜 아침에 동시에 사용하면 제대로 작동하지 않을 수 있습니다.

각자 자신의 역할로 로그인해 처음부터 끝까지 일반적인 업무를 완료하게 하세요. 영업 직원은 고객을 추가하고, 거래를 수정하고, 과거 대화를 검색하고, 후속 조치를 만들 수 있습니다. 관리자는 같은 거래를 검토하고 계정 설정을 수정하지 않은 채 할인을 승인할 수 있어야 합니다.

각 역할이 일상 업무를 완료할 수 있는지, 제한된 작업을 계속 사용할 수 없는지, 민감한 필드가 잘못된 사용자에게 숨겨지는지 확인하세요. 레코드가 충분히 쌓인 상태에서 검색, 필터, 내보내기, 보고서, 모바일 화면도 테스트해야 앱이 약간 복잡한 상황에서도 작동하는지 알 수 있습니다.

권한 테스트는 메뉴 버튼이 숨겨졌는지만 확인해서는 부족합니다. 일반 직원이 청구서를 삭제하면 안 된다면 그 직원으로 로그인해 청구서가 표시되는 모든 화면에서 삭제를 시도하세요. 앱은 작업을 차단하고 이유를 설명해야 합니다.

중복된 고객 이름, 오래된 종료 레코드, 비어 있는 선택 필드, 여러 달에 걸친 날짜, 긴 메모를 추가하세요. «Smith»를 검색하고, 상태로 필터링하고, 보고서를 정렬하고, 같은 결과를 휴대폰에서 열어 보세요. 샘플 데이터가 적으면 레코드가 쌓였을 때 나타나는 느린 페이지, 헷갈리는 라벨, 작동하지 않는 필터를 놓치기 쉽습니다.

각 권한 수준에 별도의 테스트 계정을 만들고 하나의 로그인을 공유하지 마세요. 그래야 접근 문제를 쉽게 재현하고 수정할 수 있습니다.

실제 비즈니스 데이터를 가져오기 전에 모든 테스트 계정과 샘플 레코드를 삭제하세요. 테스트용 이메일 주소, 전화번호, 첨부 파일, 내보낸 파일도 모두 사라졌는지 확인하세요. 그런 다음 팀이 배포를 시작할 때 사용할 기준점이 되도록 깨끗한 스냅샷을 만드세요.

다음 테스트를 준비하세요

테스트를 출시 전에 한 번만 하는 작업으로 생각하지 말고 반복 가능한 주기로 운영하세요. 고객 레코드 만들기, 담당자 지정, 상태 업데이트처럼 직원들이 자주 사용하는 업무 흐름 하나를 고르세요. 모든 화면에 무작위 샘플 데이터를 채우는 대신 의미 있는 변경이 있을 때마다 해당 경로를 테스트하세요.

재사용할 수 있는 가상 레코드 묶음을 유지하세요. 일반 고객, 연락처가 2개인 고객, 연체된 청구서, 중복처럼 보이는 이름, 선택 정보가 빠진 레코드처럼 각 레코드에 분명한 목적을 부여하세요. 같은 데이터를 사용하면 예상 동작이 바뀐 부분을 쉽게 찾을 수 있습니다.

묶음을 하나의 공유 장소에 보관하고 각 테스트의 예상 결과를 적으세요. 계정 관리자는 고객 전화번호를 수정할 수 있어야 하지만 급여 필드는 보면 안 됩니다. 재무 담당자는 청구서를 볼 수 있어야 하지만 고객 레코드를 삭제해서는 안 됩니다. 짧고 구체적인 예상 결과가 있으면 어떤 결과가 버그인지 두고 논쟁할 일이 줄어듭니다.

다음 버전을 만들기 전에 Koder.ai 플래닝 모드를 사용하세요. 직원 역할, 정확한 업무, 수정 가능한 필드, 유효성 검사 규칙을 설명합니다. 예를 들면 다음과 같습니다. «고객 지원 상담원은 티켓을 만들고, 고객을 선택하고, 메모를 추가하고, 우선순위를 정할 수 있다. 다른 팀에 배정된 티켓은 종료할 수 없다. 제목은 필수로 입력하게 하고 후속 연락 날짜가 과거이면 거부한다.»

계획에 실제 업무가 반영된 뒤 변경 사항을 만드세요. 그런 다음 잘못된 입력을 포함한 가상 레코드로 업무 흐름을 반복하세요. 큰 변경 전에는 스냅샷을 만들고 소규모 그룹이 새 버전을 테스트하게 하세요. 문제가 생기면 수정하는 동안 롤백하세요.

간단한 테스트 로그에는 날짜와 버전, 사용한 업무 흐름과 레코드, 예상 결과와 실제 결과, 테스터, 지금 수정할지 나중에 수정할지 유지할지에 대한 결정을 포함하세요. 권한, 필드, 업무 흐름을 추가할 때마다 직원이 의존하기 전에 관련 사례를 다시 실행하세요.