Tạo dữ liệu kiểm thử thực tế cho ứng dụng doanh nghiệp trước khi nhân viên sử dụng

Vì sao bản demo trau chuốt thường thất bại khi nhân viên bắt đầu sử dụng

Một bản demo đẹp mắt thường chỉ dùng các màn hình trống hoặc một vài bản ghi hoàn hảo. Khách hàng nào cũng có đầy đủ họ tên, đơn hàng nào cũng có trạng thái rõ ràng và mọi người đều đi theo đúng quy trình dự kiến. Điều đó chứng minh ứng dụng có thể hiển thị một quy trình. Nó chưa chứng minh nhân viên có thể sử dụng ứng dụng vào một ngày làm việc bận rộn.

Công việc thực tế thường phức tạp hơn. Một nhân viên kinh doanh có thể lưu liên hệ mà không có số điện thoại, rồi quay lại sau để sửa địa chỉ email. Một quản lý vận hành có thể tìm kiếm «Acme» và thấy sáu bản ghi tương tự. Ai đó có thể cần mở lại một yêu cầu đã đóng vì khách hàng đổi ý. Dữ liệu kiểm thử thực tế giúp phát hiện những tình huống này trước khi chúng gây rối trong môi trường chính thức.

Các màn hình trống cũng che giấu nhiều câu hỏi thực tế. Nhân viên có biết nên nhập gì trước không? Họ có phân biệt được bản nháp với yêu cầu đã gửi không? Ứng dụng có giải thích phần còn thiếu khi một trường bắt buộc bị bỏ trống không? Người thuyết trình có thể bỏ qua những khoảng trống này vì họ đã biết mọi bước.

Bản ghi dùng chung làm thay đổi quy trình

Nhiều vấn đề chỉ xuất hiện khi có nhiều người cùng sử dụng một ứng dụng. Một nhân viên cập nhật hồ sơ khách hàng trong khi người khác đang xem phiên bản cũ. Người giám sát cần xem mọi yêu cầu, còn nhân viên chỉ nên thấy yêu cầu của mình. Ai đó thay đổi trạng thái bản ghi nhưng không để lại ghi chú cho người tiếp theo.

Hãy kiểm thử công việc dùng chung bằng hoạt động gần với thực tế. Tạo các bản ghi có tên tương tự, thông tin chưa đầy đủ, ngày cũ, bản sao trùng lặp và dữ liệu cần chỉnh sửa. Sau đó yêu cầu hai hoặc ba người kiểm thử cùng làm việc trên những bản ghi đó. Theo dõi các thay đổi bị ghi đè, quyền sở hữu không rõ ràng, nhãn trạng thái khó hiểu và kết quả tìm kiếm khó sắp xếp.

Koder.ai cho phép các đội tạo ứng dụng web, máy chủ và di động thông qua trò chuyện, nhưng phát triển nhanh không loại bỏ nhu cầu kiểm thử hành vi thông thường của con người. Hãy kiểm thử phiên bản đầu tiên với thói quen làm việc thực tế trước khi cả đội phụ thuộc vào ứng dụng.

Tách dữ liệu kiểm thử khỏi thông tin thật

Trong quá trình kiểm thử, hãy dùng tên, địa chỉ email, số điện thoại và thông tin công ty giả. Gắn nhãn rõ ràng cho bản ghi, chẳng hạn như «TEST - Northside Supplies», để không ai nhầm chúng với khách hàng thật. Không sao chép danh sách khách hàng, hồ sơ nhân viên, thông tin tài chính hoặc ghi chú riêng tư vào môi trường kiểm thử.

Một bộ dữ liệu nhỏ nhưng đa dạng hữu ích hơn một tập hợp lớn gồm các bản ghi sao chép. Hãy đưa vào những ví dụ bình thường, bản ghi hoàn thành một phần, bản sao trùng lặp và một vài lỗi rõ ràng. Nhân viên có thể thử nghiệm, mắc lỗi và báo cáo điều chưa rõ mà không đặt thông tin thật vào nguy cơ.

Bắt đầu từ công việc nhân viên thực sự làm

Ứng dụng doanh nghiệp cần đối mặt với những công việc mọi người xử lý vào một ngày làm việc bình thường. Hãy ghi lại các công việc thật bằng chính cách nhân viên gọi chúng. Nhân viên kinh doanh nhập một đơn hàng. Quản lý phê duyệt khoản hoàn tiền. Người phụ trách tài khoản cập nhật số điện thoại của khách hàng. Đây là điểm bắt đầu tốt hơn những nhãn chung chung như «kiểm thử màn hình đơn hàng».

Biến mỗi công việc thành một kịch bản ngắn với điểm bắt đầu, hành động và kết quả mong đợi rõ ràng. Viết đủ đơn giản để đồng nghiệp có thể đọc mà không cần hỗ trợ kỹ thuật.

Ví dụ: «Một khách hàng gọi điện để thay đổi địa chỉ giao hàng của đơn hàng chưa được gửi đi. Nhân viên kinh doanh tìm đơn hàng, sửa địa chỉ, lưu lại và thấy địa chỉ mới trên xác nhận đơn hàng.» Kịch bản này cho biết bạn cần chuẩn bị những bản ghi nào và ứng dụng phải hiển thị gì sau khi thay đổi.

Các công việc thường ngày cần được chú ý nhiều nhất vì nhân viên lặp lại chúng suốt ngày. Hãy ghi nhận những biến thể nhỏ có thể làm thay đổi kết quả: khách hàng mới hay khách hàng hiện tại, một sản phẩm hay năm sản phẩm, hóa đơn đã thanh toán đủ hay mới thanh toán một phần. Bản demo trau chuốt thường dùng một bản ghi hoàn hảo. Công việc thực tế hiếm khi như vậy.

Cũng hãy kiểm thử những công việc ít gặp hơn. Nhân viên có thể quên các bước, còn người xây dựng ban đầu có thể chưa bao giờ thử chúng. Hãy đưa vào những việc như:

• Kết sổ một tháng và kiểm tra các hóa đơn quá hạn
• Sửa một đơn hàng được nhập dưới nhầm khách hàng
• Xử lý khoản hoàn tiền sau khi quản lý phê duyệt
• Phân công lại công việc đang mở của một nhân viên đã nghỉ
• Xuất báo cáo cho bộ phận tài chính hoặc kiểm toán viên

Nếu xây dựng ứng dụng bằng Koder.ai, hãy viết các kịch bản này thành những yêu cầu trò chuyện trực tiếp trong quá trình phát triển. Lặp lại chúng với các bản ghi đã chuẩn bị trước khi mời nhân viên tham gia, đồng thời đặt kết quả mong đợi bên cạnh từng kịch bản.

Một kịch bản hữu ích cần có điểm kết thúc. «Cập nhật thông tin khách hàng» quá chung chung. «Thay đổi email lập hóa đơn của khách hàng, lưu bản ghi và xác nhận hóa đơn tiếp theo sử dụng địa chỉ email đó» cho người kiểm thử một điều cụ thể để xác minh.

Tạo các bản ghi giống dữ liệu doanh nghiệp hằng ngày

Một ứng dụng trống có thể trông rất gọn gàng trong bản demo nhưng vẫn thất bại vào một ngày làm việc bình thường. Nhân viên cần tìm một khách hàng có tên phổ biến, kiểm tra hóa đơn quá hạn, thấy ghi chú của nhà cung cấp và hiểu một bản ghi đã được chuyển qua tay hai lần.

Hãy làm cho các bản ghi mẫu giống với thông tin doanh nghiệp xử lý. Dùng tên và thông tin liên hệ giả, tuyệt đối không sao chép dữ liệu khách hàng hoặc nhân viên. Tạo một nhóm dữ liệu hợp lý: một khách hàng mới, một khách hàng lâu năm, một nhà cung cấp có thông tin chưa đầy đủ, một nhân viên đã chuyển bộ phận và một bản ghi có nhiều ghi chú.

Ngày tháng, số tiền và trạng thái cần có sự đa dạng. Nếu mọi hóa đơn đều có cùng tổng tiền và mọi yêu cầu đều ở trạng thái «Đang mở», nhân viên không thể biết việc sắp xếp, lọc và báo cáo có hoạt động đúng không. Tạo các bản ghi trải dài nhiều tháng với số tiền và trạng thái khác nhau như bản nháp, đã gửi, đã thanh toán, bị trì hoãn, đã hủy hoặc đã lưu trữ, tùy theo ứng dụng.

Một nhóm nhỏ gồm các mẫu thực tế thường phát hiện được nhiều vấn đề hơn hàng trăm mục giống hệt nhau:

• Một khách hàng có hai đơn hàng trong cùng một ngày.
• Một nhà cung cấp có số điện thoại cũ và một ghi chú mới giải thích thay đổi đó.
• Một nhân viên cũ xuất hiện trong các bản ghi lịch sử nhưng không thể nhận công việc mới.
• Một số khách hàng có cùng họ hoặc cùng tên công ty.
• Một khoản tiền lớn nằm cạnh nhiều giao dịch nhỏ thường ngày.

Cố ý thêm các bản ghi cũ. Kết quả tìm kiếm chỉ có năm mục mới không cho bạn biết nhiều về khả năng nhân viên tìm được yêu cầu của năm ngoái hoặc báo cáo tháng có nhóm thông tin đúng không. Dữ liệu cũ cũng làm lộ các định dạng ngày tháng khó hiểu, trạng thái đã lưu trữ và bản ghi không còn người phụ trách.

Ghi chú nên đơn giản nhưng có vẻ thật. «Khách hàng muốn chia việc giao hàng thành hai lần» hữu ích hơn «Ghi chú kiểm thử 14». Không đưa địa chỉ thật, số tài khoản, số điện thoại hoặc bình luận riêng tư vào ứng dụng kiểm thử, kể cả khi chỉ thử nghiệm nội bộ.

Mô hình hóa người dùng và quyền truy cập trước khi mời cả đội

Ứng dụng sẽ gây rắc rối khi mọi người đều nhìn thấy cùng một màn hình và các nút giống nhau. Kiểm thử thực tế cần những người dùng thực tế: nhân viên nhập bản ghi, quản lý phê duyệt và người chỉ theo dõi tiến độ.

Xác định vai trò dựa trên công việc hằng ngày, không chỉ dựa vào chức danh. Hai người cùng được gọi là «quản lý» có thể cần quyền truy cập khác nhau. Quản lý kinh doanh có thể phê duyệt chiết khấu nhưng không nên xem thông tin lương. Nhân viên kế toán có thể tạo hóa đơn nhưng không nên thay đổi hạn mức tín dụng của khách hàng.

Ghi rõ mỗi vai trò có thể làm gì, sau đó kiểm thử từng hành động bằng tài khoản tương ứng. Kiểm tra xem người dùng có thể xem, tạo và chỉnh sửa những bản ghi cần thiết hay không, đồng thời các trường và hành động bị hạn chế có thực sự không khả dụng không. Cũng kiểm thử báo cáo, tệp, cài đặt, nội dung xuất và thông báo, vì dữ liệu riêng tư thường xuất hiện ở đó chứ không chỉ trên trang bản ghi chính.

Đừng chỉ kiểm thử con đường dự kiến. Đăng nhập bằng tài khoản nhân viên có quyền hạn chế, mở một bản ghi qua tìm kiếm và thử truy cập bản ghi đó bằng địa chỉ trình duyệt đã lưu. Ứng dụng phải chặn hành động này. Ẩn một mục trong menu không bảo vệ được trang nếu người không có quyền vẫn truy cập được.

Hãy thêm tài khoản quản trị viên và kiểm thử cẩn thận. Quản trị viên thường có thể thay đổi quyền, xem mọi bản ghi và xóa dữ liệu. Xác nhận tài khoản này có thể khôi phục quyền truy cập khi tài khoản nhân viên bị đặt sai quyền.

Cũng hãy thêm một tài khoản tạm thời, chẳng hạn như cộng tác viên hỗ trợ trong hai tuần. Chỉ cấp cho tài khoản đó những bản ghi và hành động cần thiết cho công việc. Khi thời gian tạm thời kết thúc, người đó phải mất quyền truy cập mà không làm mất những công việc đã nhập.

Trong chế độ lập kế hoạch của Koder.ai, hãy mô tả vai trò trước khi mời nhân viên. Tạo các tài khoản kiểm thử riêng và lặp lại những công việc ngắn giống nhau trên từng tài khoản. Các vấn đề về quyền dễ sửa hơn khi ứng dụng vẫn đang được thay đổi nhanh chóng.

Kiểm thử những tình huống khó quanh quy trình bình thường

Hầu hết vấn đề của ứng dụng xuất hiện giữa công việc thường ngày, không phải trong một bản demo sạch sẽ. Hãy đưa vào các bản ghi ở mọi giai đoạn của quy trình, với ngày tháng, tên, ghi chú và số tiền gần với công việc thực tế.

Với một ứng dụng đơn hàng, hãy tạo một đơn hàng mới chưa ai xử lý, một đơn hàng nhân viên đang chuẩn bị, một đơn hàng đã được quản lý phê duyệt và một đơn hàng đội ngũ đã đóng vào tháng trước. Kiểm tra những trường nào nhân viên có thể thay đổi ở từng giai đoạn. Một đơn hàng đã đóng không được âm thầm quay lại trạng thái «đang xử lý» chỉ vì ai đó chỉnh sửa địa chỉ giao hàng.

Hãy kiểm thử các ngoại lệ thường xảy ra trong công việc thật:

• Hủy một đơn hàng sau khi nhân viên đã bắt đầu xử lý.
• Đánh dấu một khoản thanh toán là bị trả lại sau khi ứng dụng ghi nhận là đã hoàn tất.
• Mở một yêu cầu sau ngày hết hạn.
• Gửi một bản ghi mà không có tệp đính kèm theo yêu cầu của quy trình.
• Thử phê duyệt một mục vẫn còn thiếu thông tin.

Việc hai người cùng thay đổi một mục cần một bài kiểm thử riêng. Yêu cầu một nhân viên cập nhật số điện thoại của khách hàng trong khi người khác thay đổi trạng thái đơn hàng. Ứng dụng phải làm rõ kết quả. Có thể ứng dụng lưu cả hai thay đổi, cảnh báo người thứ hai rằng bản ghi đã thay đổi hoặc yêu cầu tải lại. Ứng dụng tuyệt đối không được che giấu công việc của một người mà không thông báo.

Lịch sử trạng thái rất quan trọng khi phát sinh câu hỏi sau này. Hãy kiểm thử một chuỗi đơn giản: Sam tạo yêu cầu lúc 9:10, Priya phê duyệt lúc 9:25 và Sam hủy lúc 10:00 sau khi khách hàng gọi điện. Nhân viên có quyền xem yêu cầu phải thấy ai thực hiện từng thay đổi, thời điểm thay đổi và lý do mà ứng dụng ghi nhận. Họ cũng cần thấy trạng thái hiện tại mà không phải đọc một chuỗi ghi chú quá dài.

Với ứng dụng Koder.ai, hãy mô tả những tình huống này bằng ngôn ngữ đơn giản trước khi xây dựng phiên bản kiểm thử. Sau đó thực hiện chúng như các công việc cụ thể thay vì chỉ kiểm tra xem màn hình đã hoàn thiện chưa.

Cố ý nhập dữ liệu sai vào ứng dụng

Nhân viên thường mắc những lỗi rất bình thường: bỏ sót một trường, dán số điện thoại có khoảng trắng thừa hoặc nhập số tiền sai dấu. Hãy đưa những lỗi đó vào quá trình kiểm thử trước khi dữ liệu thật đến ứng dụng. Một biểu mẫu chỉ hoạt động với dữ liệu demo sạch sẽ sẽ thất bại trong một ngày làm việc bận rộn.

Dùng cùng một biểu mẫu nhiều lần và mỗi lần thay đổi một chi tiết. Nhờ vậy, bạn dễ thấy quy tắc nào không đạt và thông báo có giúp người dùng sửa lỗi không.

• Bỏ trống các trường bắt buộc, bao gồm cả trường bắt buộc có điều kiện.
• Dán một ghi chú khách hàng thật dài và văn bản có ký hiệu, dấu, xuống dòng hoặc emoji.
• Nhập ngày trong quá khứ cho một cuộc hẹn tương lai, số tiền hóa đơn âm hoặc quá nhiều chữ số thập phân.
• Gửi một địa chỉ email đã được bản ghi khác sử dụng.
• Dán một số có khoảng trắng, dấu phẩy hoặc ký hiệu tiền tệ.

Ứng dụng phải giải thích phần cần chú ý bằng ngôn ngữ đơn giản. «Nhập số điện thoại có ít nhất 10 chữ số» cho nhân viên biết bước tiếp theo. «Lỗi xác thực» thì không. Khi có thể, hãy đặt thông báo gần trường dữ liệu và giữ thông báo hiển thị sau khi người dùng thử gửi biểu mẫu.

Cũng kiểm tra điều gì xảy ra với phần còn lại của biểu mẫu. Nếu Maria mất năm phút nhập một khách hàng mới rồi gõ sai mã bưu chính, ứng dụng phải giữ lại ghi chú hợp lệ, thông tin liên hệ và các lựa chọn cô ấy đã chọn. Cô ấy chỉ cần sửa một trường và gửi lại thay vì bắt đầu từ đầu.

Khi việc gửi bị chặn, người dùng cần thấy rõ cách tiếp tục: sửa trường được đánh dấu, hủy an toàn hoặc lưu bản nháp khi công việc chưa hoàn tất. Tránh các cửa sổ lỗi biến mất trước khi nhân viên kịp đọc hoặc các nút ngừng phản hồi sau một lần gửi thất bại.

Khi xây dựng bằng Koder.ai, hãy đưa các trường hợp này vào yêu cầu cho từng biểu mẫu. Yêu cầu quy tắc trường rõ ràng, kiểm tra trùng lặp, thông báo lỗi dễ đọc và giữ lại dữ liệu đã nhập sau khi gửi thất bại. Sau đó kiểm thử ứng dụng bằng đúng những giá trị sai đã liệt kê.

Thực hiện một kịch bản nhân viên thực tế

Hãy hình dung một công ty sửa chữa hệ thống sưởi và đường ống với 12 nhân viên. Công ty theo dõi khách hàng, công việc dịch vụ, hóa đơn và thanh toán trong một ứng dụng.

Maya, quản lý văn phòng, nhận cuộc gọi từ Jordan Lee về một bộ tản nhiệt bị rò rỉ. Cô tìm kiếm Jordan và thấy hai hồ sơ khách hàng: «Jordan Lee» và «J. Lee» ở cùng một địa chỉ. Maya chọn một hồ sơ, tạo công việc vào sáng thứ Tư, thêm mô tả sự cố và giao cho kỹ thuật viên Sam.

Công việc bắt đầu ở trạng thái «Đã đặt lịch». Sam mở ứng dụng trên điện thoại khi đến địa điểm. Anh thêm ảnh, đổi trạng thái thành «Đã hoàn tất công việc» và nhập chi phí linh kiện cùng nhân công. Nhãn này nghe có vẻ là bước cuối, nhưng Maya vẫn cần kiểm tra khoản phí trước khi ứng dụng tạo hóa đơn. Nhân viên có thể hiểu «Đã hoàn tất công việc» là «sẵn sàng lập hóa đơn», trong khi Sam chỉ muốn nói rằng anh đã rời địa điểm.

Hãy dùng trạng thái rõ hơn như «Chờ văn phòng xem xét». Khi đó Maya biết chính xác bước tiếp theo và ứng dụng sẽ không gửi hóa đơn trước khi có người kiểm tra giá.

Maya nhận thấy Jordan có một hóa đơn cũ đã quá hạn 45 ngày. Cô quyết định công việc mới cần quản lý phê duyệt trước khi lập hóa đơn. Quản lý của cô, Priya, xem ghi chú của Sam và phê duyệt giảm giá vì lần sửa chữa trước không thành công.

Kịch bản này kiểm tra khả năng xử lý các quyết định thực tế của ứng dụng:

• Maya phải thấy khách hàng có thể bị trùng và có thể gộp hồ sơ hoặc đánh dấu để xem xét.
• Sam có thể cập nhật công việc được giao nhưng không được sửa số tiền hóa đơn hoặc phê duyệt giảm giá.
• Priya có thể phê duyệt công việc mà không được truy cập bảng lương hoặc cài đặt công ty không liên quan.
• Hóa đơn quá hạn phải xuất hiện trước khi Maya gửi hóa đơn mới, nhưng không được ngăn công việc sửa chữa khẩn cấp.
• Mỗi trạng thái phải cho nhân viên biết ai cần hành động tiếp theo và những hành động nào vẫn còn khả dụng.

Chạy kịch bản với các bản ghi có vẻ thật: địa chỉ đường phố, ghi chú công việc đa dạng, một linh kiện có giá 18,75 đô la và các hóa đơn có ngày thanh toán khác nhau. Yêu cầu người kiểm thử làm việc riêng, sau đó so sánh cách họ hiểu từng trạng thái.

Nếu Sam có thể phê duyệt giảm giá trên điện thoại, hãy sửa quy tắc quyền. Nếu Maya không biết «Đã hoàn tất công việc» nghĩa là đã lập hóa đơn hay chỉ hoàn tất tại địa điểm, hãy đổi tên trạng thái trước khi nhân viên phụ thuộc vào nó.

Tổ chức một buổi kiểm thử đơn giản và ghi lại kết quả

Một buổi kiểm thử ngắn và tập trung thường phát hiện những vấn đề mà bản demo trau chuốt bỏ sót. Giao cho mỗi người kiểm thử một công việc bình thường, chẳng hạn như thêm khách hàng, phê duyệt chi phí hoặc tìm hóa đơn quá hạn. Yêu cầu họ làm việc một mình và tránh hướng dẫn từng cú nhấp chuột.

Nếu họ dừng lại, chọn nhầm menu hoặc hỏi một nhãn có nghĩa gì, hãy ghi lại. Những khoảnh khắc đó cho thấy ứng dụng cần cách diễn đạt rõ hơn hoặc một quy trình đơn giản hơn.

Hãy duy trì một nhật ký vấn đề cơ bản. Với đội nhỏ, một bảng dùng chung là đủ. Ghi lại trang xuất hiện vấn đề, hành động và bản ghi mẫu đã dùng, kết quả mong đợi, điều thực tế xảy ra và vai trò người dùng. Người sửa lỗi phải có thể lặp lại vấn đề mà không cần đoán.

Phân loại vấn đề trước khi buổi kiểm thử kết thúc. Đưa các lỗi chặn công việc lên trước, tiếp đến là lỗi quyền có thể làm lộ dữ liệu riêng tư hoặc cho phép ai đó thay đổi bản ghi mà họ chỉ được xem. Nhãn khó hiểu và số lần nhấp thừa vẫn đáng chú ý, nhưng thường không cần phản hồi khẩn cấp như vậy.

Sau khi sửa lỗi, hãy lặp lại đúng bài kiểm thử với cùng vai trò, bản ghi mẫu và các bước. Cũng kiểm tra những trang liên quan như kết quả tìm kiếm và nội dung xuất. Một bản sửa trên trang khách hàng có thể vẫn để lại vấn đề tương tự ở nơi khác.

Koder.ai hỗ trợ bản chụp và khôi phục, giúp đội ngũ giữ lại một phiên bản đã biết là đang hoạt động trước những thay đổi lớn. Hãy lưu nhật ký vấn đề cùng dự án để tiếp tục sử dụng khi có thêm vai trò và quy trình mới.

Dùng danh sách kiểm tra này trước khi triển khai cho nhân viên đầu tiên

Hãy xem xét một bản sao của ứng dụng bằng các bản ghi mẫu gần với thực tế. Một màn hình đẹp vẫn có thể thất bại khi lễ tân, quản lý và nhân viên tài chính cùng làm việc trong một buổi sáng bận rộn.

Yêu cầu mỗi người đăng nhập bằng vai trò của mình và hoàn thành một công việc bình thường từ đầu đến cuối. Nhân viên kinh doanh có thể thêm khách hàng, cập nhật một cơ hội, tìm cuộc trò chuyện cũ và tạo việc cần theo dõi. Quản lý có thể xem cùng cơ hội đó và phê duyệt giảm giá mà không chỉnh sửa cài đặt tài khoản.

Kiểm tra mỗi vai trò có thể hoàn thành công việc hằng ngày, các hành động bị hạn chế vẫn không khả dụng và trường nhạy cảm vẫn được ẩn khỏi người không có quyền. Kiểm thử tìm kiếm, bộ lọc, nội dung xuất, báo cáo và màn hình di động với đủ số lượng bản ghi để ứng dụng trở nên hơi lộn xộn.

Kiểm thử quyền cần nhiều hơn việc thiếu một nút trong menu. Nếu nhân viên thông thường không được xóa hóa đơn, hãy đăng nhập bằng tài khoản đó và thử xóa một hóa đơn từ mọi màn hình có hiển thị hóa đơn. Ứng dụng phải chặn hành động và giải thích lý do.

Thêm các tên khách hàng trùng lặp, bản ghi cũ đã đóng, trường tùy chọn để trống, ngày tháng trải dài nhiều tháng và ghi chú dài. Tìm kiếm «Smith», lọc theo trạng thái, sắp xếp một báo cáo và mở cùng kết quả trên điện thoại. Các bộ dữ liệu nhỏ thường che giấu trang chậm, nhãn khó hiểu và bộ lọc hoạt động sai khi số lượng bản ghi tăng lên.

Tạo tài khoản kiểm thử riêng cho từng cấp quyền thay vì dùng chung một thông tin đăng nhập. Nhờ vậy, vấn đề truy cập dễ được tái hiện và sửa hơn.

Trước khi nhập dữ liệu doanh nghiệp thật, hãy xóa mọi tài khoản kiểm thử và bản ghi mẫu. Xác nhận địa chỉ email, số điện thoại, tệp đính kèm và nội dung xuất dùng cho kiểm thử cũng đã biến mất. Sau đó tạo một bản chụp sạch để đội ngũ có điểm bắt đầu rõ ràng cho quá trình triển khai.

Chuẩn bị cho vòng kiểm thử tiếp theo

Hãy xem kiểm thử là một chu kỳ có thể lặp lại, không phải công việc chỉ làm một lần trước khi ra mắt. Chọn một quy trình nhân viên thường sử dụng, chẳng hạn như tạo hồ sơ khách hàng, giao người phụ trách và cập nhật trạng thái. Kiểm thử quy trình đó sau mỗi thay đổi quan trọng thay vì đổ dữ liệu mẫu ngẫu nhiên vào mọi màn hình.

Giữ một bộ bản ghi giả có thể tái sử dụng. Gán cho mỗi bản ghi một mục đích rõ ràng: khách hàng bình thường, khách hàng có hai liên hệ, hóa đơn quá hạn, tên trông giống bản sao hoặc bản ghi thiếu thông tin tùy chọn. Dùng cùng một bộ dữ liệu giúp dễ nhận ra những thay đổi trong kết quả mong đợi.

Lưu bộ dữ liệu ở một nơi dùng chung và ghi lại kết quả mong đợi cho từng bài kiểm thử. Người quản lý tài khoản có thể sửa số điện thoại khách hàng nhưng không được thấy các trường lương. Người dùng tài chính có thể xem hóa đơn nhưng không được xóa hồ sơ khách hàng. Những kỳ vọng ngắn gọn giúp tránh tranh luận về việc một kết quả có phải lỗi hay không.

Hãy dùng chế độ lập kế hoạch của Koder.ai trước khi xây dựng phiên bản tiếp theo. Mô tả vai trò nhân viên, công việc chính xác, các trường có thể chỉnh sửa và quy tắc xác thực. Ví dụ: «Nhân viên hỗ trợ có thể tạo phiếu, chọn khách hàng, thêm ghi chú và đặt mức độ ưu tiên. Nhân viên không thể đóng phiếu được giao cho đội khác. Bắt buộc nhập tiêu đề và từ chối ngày trong quá khứ cho các cuộc gọi cần theo dõi.»

Chỉ xây dựng thay đổi sau khi kế hoạch phản ánh đúng công việc thực tế. Sau đó lặp lại quy trình với các bản ghi giả, bao gồm cả dữ liệu nhập sai. Trước một thay đổi lớn, hãy tạo bản chụp và để một nhóm nhỏ kiểm thử phiên bản mới. Nếu thay đổi gây ra vấn đề, hãy khôi phục phiên bản cũ trong khi sửa lỗi.

Một nhật ký kiểm thử đơn giản nên có ngày và phiên bản, quy trình và bản ghi đã dùng, kết quả mong đợi và thực tế, người kiểm thử, cùng quyết định sửa ngay, điều chỉnh sau hoặc giữ nguyên. Khi thêm quyền, trường hoặc quy trình, hãy chạy lại các trường hợp liên quan trước khi nhân viên phụ thuộc vào chúng.