Khi osCMax đã được chọn làm Nền tảng đích, việc xác thực phải chứng minh nhiều hơn việc bản ghi đã xuất hiện. Đây là môi trường legacy nhạy với cách triển khai, nên kết quả chỉ đáng tin khi dữ liệu đã di chuyển có thể được chính bản osCMax đích diễn giải và sử dụng đúng cách.
Vì vậy, quá trình xác thực cần tách bốn lớp: bản ghi dự kiến có tồn tại hay không, các mối quan hệ có chính xác hay không, Cửa hàng đích có sử dụng được chúng trong tình huống kinh doanh thực tế hay không, và phần triển khai riêng trên đích đã sẵn sàng đến mức nào để đưa ra quyết định vận hành.
Xác nhận môi trường osCMax đích trước khi diễn giải kết quả dữ liệu
Trước khi đánh giá dữ liệu, hãy xác nhận bản osCMax, cơ sở dữ liệu, môi trường vận hành, các gói mở rộng, template và module bắt buộc đúng với môi trường đã được dùng để lập kế hoạch.
Nếu môi trường đích thay đổi sau khi quan hệ dữ liệu nguồn-đích đã được quyết định, kết quả dữ liệu có thể không còn mang cùng ý nghĩa. Khi đó, cần dừng việc phê duyệt cho đến khi đích đến ổn định đủ để kiểm chứng.
Điều kiện đạt gồm:
- cơ sở dữ liệu và codebase đích đúng bản đã thống nhất;
- các trường/bảng đích bắt buộc tồn tại;
- module sở hữu dữ liệu di chuyển dữ liệu đã được cài và cấu hình đủ để đọc dữ liệu đó;
- người rà soát phân biệt được vấn đề thuộc di chuyển dữ liệu với vấn đề thuộc phần triển khai trên đích.
Xác thực Products, Categories, attributes và ý nghĩa của mặt hàng có thể bán
Không nên xác thực danh mục chỉ dựa trên số lượng Products.
Dùng những Products đại diện để kiểm tra:
- tiêu đề, mô tả, SKU/model, giá, tồn kho, thuế và trạng thái hiển thị;
- quan hệ Categories và cách browse;
- manufacturers và Reviews nếu nằm trong phạm vi;
- attributes/tùy chọn và những lựa chọn khách hàng có thể thực hiện;
- ảnh hưởng của lựa chọn đến giá, trọng lượng, tồn kho, hình ảnh hoặc model;
- specials và giá theo nhóm Customers khi đã được chấp nhận;
- đường dẫn media và cách hiển thị trên storefront khi phần triển khai đã đủ sẵn sàng để kiểm thử;
- mã định danh Products mà hệ thống ngoài cần tiếp tục sử dụng.
Products chỉ đạt yêu cầu khi khách hàng hoặc nhân viên vận hành có thể hiểu và sử dụng đúng cấu hình mặt hàng cần bán, không chỉ khi bản ghi Products cha tồn tại.
Xác thực Customers và ý nghĩa thương mại của các nhóm
Với Customers, cần kiểm tra định danh, địa chỉ, nhóm khách hàng, ngữ cảnh thuế/wholesale và những mã tham chiếu bên ngoài bắt buộc.
Nếu nhóm Customers ảnh hưởng đến giá, trạng thái hiển thị, thuế, trạng thái phê duyệt hoặc quyền truy cập, hãy dùng tài khoản đại diện để kiểm tra kết quả thực tế. Chỉ sao chép đúng tên nhóm nhưng không tạo đúng cách xử lý thương mại trên đích không được xem là duy trì đúng ý nghĩa thương mại.
Mật khẩu cũng phải được diễn giải theo phạm vi di chuyển dữ liệu được hỗ trợ và mô hình xác thực của đích. Bản ghi Customers tồn tại trong cơ sở dữ liệu không chứng minh khách hàng có thể đăng nhập bằng thông tin xác thực cũ.
Xác thực lịch sử đơn hàng như dữ liệu về giao dịch đã xảy ra
Lịch sử đơn hàng phải tiếp tục dễ hiểu mà không cần dùng Cửa hàng nguồn như lớp giải thích bổ sung.
Chọn Orders đại diện có:
- nhiều Products và tùy chọn khác nhau;
- cách tính thuế khác nhau;
- giảm giá, Coupons, vouchers hoặc surcharge;
- nhãn thanh toán và vận chuyển khác nhau;
- trạng thái hoặc lịch sử trạng thái khác thường;
- ghi chú của Customers/nhân viên;
- mã giao dịch hoặc tham chiếu xử lý đơn hàng bên ngoài nếu cần giữ.
Nhân viên phải giải thích được khách đã mua gì, bị tính phí thế nào, số tiền được hình thành từ đâu và giao dịch đã trải qua những trạng thái nào.
Không dùng lịch sử đơn hàng để chứng minh checkout hiện tại đã sẵn sàng. Thanh toán, vận chuyển, thuế, tồn kho, email, hoàn tiền và quy trình xuất dữ liệu cần bằng chứng cấu hình riêng trên Cửa hàng đích.
Xác thực nội dung, template và SEO theo đúng nơi sở hữu
Nội dung phải được rà soát theo cấu trúc sở hữu trên đích.
Kiểm tra mô tả Products/Categories quan trọng, trang thông tin, nội dung bài viết/tin tức khi nằm trong phạm vi, trang chính sách, metadata, URL, redirects và các đích liên kết nội bộ. Với khối hiển thị thuộc template, tệp ngôn ngữ, InfoBox hoặc module trên đích, hãy xác thực chúng như phụ thuộc triển khai thay vì biến chúng thành bản ghi CMS được di chuyển dữ liệu.
Với SEO, cần xác nhận mục đích quan trọng từ nguồn đi đến một đích hữu ích trên osCMax. Redirect trả về đúng mã kỹ thuật chưa đủ nếu trang đích không còn phục vụ cùng nhu cầu tìm kiếm hoặc nhu cầu của khách hàng.
Xác thực dữ liệu thuộc gói mở rộng và dữ liệu tùy chỉnh cùng nơi sử dụng
Một trường hoặc bảng tùy chỉnh không đạt yêu cầu chỉ vì giá trị đã nằm trong cơ sở dữ liệu. Cần chứng minh module, mã tùy chỉnh, báo cáo hoặc hệ thống ngoài trên đích có thể dùng giá trị đó đúng mục đích.
Với từng cấu trúc đã được chấp nhận, xác nhận:
- trường/bảng và kiểu dữ liệu trên đích;
- quan hệ từ nguồn sang đích;
- module, mã, báo cáo hoặc hệ thống ngoài sử dụng dữ liệu;
- kết quả mà người dùng hoặc quy trình vận hành mong đợi;
- thay đổi sau đó trên đích có thể làm sai ý nghĩa đã di chuyển dữ liệu hay không.
Nếu chưa có nơi sử dụng để kiểm thử, hãy giữ hạng mục ở trạng thái Theo dõi hoặc Chặn tùy mức độ ảnh hưởng, thay vì cho qua chỉ dựa trên dữ liệu.
Xác thực mã định danh ngoài và tham chiếu tích hợp
ERP, CRM, kho, kế toán, marketplace, nhà cung cấp, hệ thống thanh toán hoặc vận chuyển có thể phụ thuộc vào mã định danh ổn định khác với ID do osCMax sinh.
Khi có điều kiện kiểm thử kết nối, hãy dùng bản ghi đại diện để xác nhận từ đầu đến cuối. Đảm bảo ID bên ngoài trỏ đúng Products, Customers, Orders hoặc bản ghi tương ứng trên đích và vẫn tuân theo yêu cầu về tính duy nhất/định dạng.
Việc triển khai tích hợp vẫn tách khỏi dữ liệu di chuyển dữ liệu. Kết quả xác thực cần nói rõ phần kiểm tra đang chứng minh mã định danh đã được di chuyển dữ liệu, kết nối đang vận hành thực tế hay cả hai.
Xác thực lại dữ liệu chịu ảnh hưởng bởi điều chỉnh di chuyển dữ liệu
Nếu di chuyển dữ liệu đã được chấp nhận có dùng lọc dữ liệu, chuyển dữ liệu giữa các trường, biến đổi giá trị hoặc cách xử lý riêng đã thống nhất, phần kết quả bị ảnh hưởng cần được xác thực lại có mục tiêu.
Ví dụ:
- dữ liệu được lọc: xác nhận đúng bản ghi được đưa vào hoặc loại ra;
- đưa dữ liệu giữa các trường: xác nhận giá trị đến đúng trường osCMax đã định;
- biến đổi giá trị: xác nhận giá trị nguồn đại diện tạo đúng giá trị đích mong muốn;
- xử lý riêng: xác nhận kết quả kinh doanh đã thống nhất, không chỉ artifact kỹ thuật.
Các lần di chuyển dữ liệu sau cũng cần xác thực lại mọi kết quả bị ảnh hưởng bởi cấu hình thay đổi hoặc bản ghi mới.
Dùng Đạt, Theo dõi và Chặn như trạng thái quyết định
| Trạng thái | Ý nghĩa | Hàm ý với việc đưa cửa hàng vào hoạt động |
|---|---|---|
| Đạt | Bản ghi/quan hệ đúng, nơi sở hữu rõ và cách sử dụng mong muốn có thể lặp lại. | Hạng mục đã rà soát có thể hỗ trợ vận hành. |
| Theo dõi | Kết quả hiện tại sử dụng được và công việc còn lại không thể thay đổi ý nghĩa dữ liệu đã chấp nhận. | Có thể tiếp tục nếu người phụ trách và bước theo dõi đã được kiểm soát. |
| Chặn | Ý nghĩa, quan hệ, nơi sử dụng, môi trường đích hoặc hành vi bắt buộc vẫn chưa được giải quyết. | Không phê duyệt hạng mục bị ảnh hưởng. |
Trạng thái Chặn không phải khác biệt về giao diện nhỏ. Đây là điều kiện chưa được giải quyết có thể khiến kết quả trên đích trở nên sai lệch hoặc không sử dụng được.
Bàn giao trước vận hành phải tách dữ liệu khỏi phần triển khai
Bản bàn giao xác thực cuối cùng nên phân loại mọi vấn đề còn lại theo đúng nơi sở hữu:
- dữ liệu di chuyển dữ liệu;
- cấu hình Cửa hàng đích trên osCMax;
- thiết lập module/gói mở rộng;
- template/môi trường vận hành;
- hệ thống bên ngoài/tích hợp;
- hạng mục di chuyển dữ liệu riêng đã được chấp nhận;
- phần được chủ động loại bỏ.
Cách phân loại này ngăn một khoảng trống trong triển khai đích bị giấu bên trong Di chuyển QA, đồng thời ngăn lỗi di chuyển dữ liệu bị bỏ qua với lý do “chỉ là cấu hình”.
Bàn giao chỉ đạt khi mỗi vấn đề quan trọng có người phụ trách, kết quả đã quan sát, kết quả mong đợi, mức độ ảnh hưởng, hướng khắc phục và yêu cầu xác thực lại.
Kết luận
Xác thực osCMax chỉ hoàn thành khi Cửa hàng đích thực sự có thể sử dụng dữ liệu đã di chuyển dữ liệu đúng với ý nghĩa mong muốn. Số lượng và việc dữ liệu tồn tại trong cơ sở dữ liệu là kiểm tra cần thiết nhưng không chứng minh lựa chọn Products, cách xử lý nhóm Customers, thông tin lịch sử đơn hàng, nơi sở hữu nội dung/SEO, nơi dùng dữ liệu tùy chỉnh hoặc các mã tham chiếu bên ngoài đều đúng.
Bằng chứng mạnh nhất nối từng bản ghi đại diện với hành vi trên đích hoặc quy trình kinh doanh phụ thuộc vào bản ghi đó, đồng thời giữ module, template, môi trường vận hành, checkout và tích hợp như những trách nhiệm triển khai riêng. Đây mới là tiêu chuẩn phù hợp cho quyết định đưa Cửa hàng đích vào hoạt động.
Câu hỏi thường gặp
Số lượng bản ghi khớp với nguồn có đủ để xác thực Di chuyển sang osCMax không?
Số lượng khớp với nguồn chưa đủ để xác thực kết quả chuyển đổi sang osCMax. Số lượng giúp kiểm tra mức độ bao phủ, nhưng các mối quan hệ đại diện và cách dữ liệu được sử dụng trong nghiệp vụ vẫn phải chính xác.
Với Products phức tạp, nên kiểm tra gì trước?
Hãy kiểm tra định danh mặt hàng có thể bán, attributes/tùy chọn, ảnh hưởng đến giá/tồn kho, media, quan hệ Categories và những trường do gói mở rộng sở hữu có tác động đến việc mua hàng.
Nên xác thực lịch sử đơn hàng như thế nào?
Hãy xác nhận chi tiết mặt hàng, các thành phần tổng tiền, trạng thái, ghi chú, nhãn thanh toán/vận chuyển và mã tham chiếu cần thiết vẫn dễ hiểu. Checkout hiện tại phải được xác thực riêng.
Mọi module trên đích có cần nằm trong Di chuyển QA không?
Chỉ khi module sử dụng dữ liệu di chuyển dữ liệu đã được chấp nhận hoặc mức độ sẵn sàng của module là điều kiện để đánh giá kết quả dữ liệu. Việc cài đặt/cấu hình module vẫn thuộc phần triển khai trên đích.
Khi nào một hạng mục Theo dõi có thể vẫn được chấp nhận trước vận hành?
Chỉ khi kết quả hiện tại sử dụng được, công việc còn lại có người phụ trách rõ và công việc đó không thể làm thay đổi ý nghĩa dữ liệu đã được chấp nhận hay gây ra lỗi quan trọng khi vận hành.