Bạn vẫn xem được các bài đã đăng mà không cần đăng nhập.
Ba tiêu chí phân biệt UAT với Pilot, khi nào gộp được hai giai đoạn và khi nào không, cùng cách viết kịch bản UAT theo nghiệp vụ.
Dự án trễ hai tuần. Trong buổi họp tiến độ, có người đề xuất bỏ giai đoạn pilot vì UAT đã chạy xong rồi, và ai cũng thấy đề xuất đó hợp lý, hai bước nghe khá giống nhau, cùng là cho người dùng thử hệ thống, mà thời gian thì không còn.
Đề xuất đó hợp lý hay không phụ thuộc vào hai điều kiện rất cụ thể. Nhưng để trả lời được thì trước hết phải thấy rõ hai bước này chặn hai loại lỗi khác nhau.
Cách gọi này không phải để nghe cho hay. Nó phản ánh đúng chức năng: mỗi bước bắt được một nhóm vấn đề mà bước kia không bắt được, và bỏ đi một lớp thì nhóm vấn đề tương ứng sẽ đi thẳng tới ngày go-live.
UAT bắt lỗi ở tầng chức năng: hệ thống có làm đúng như thiết kế không, luồng có chạy thông không, tính năng vừa phát triển có đáp ứng yêu cầu không.
Pilot bắt lỗi ở tầng vận hành: với dữ liệu thật, với khối lượng thật, với những con người thật sự sẽ dùng hệ thống hằng ngày, thì nó còn chạy được không.
Hai tầng đó không thay thế nhau. Một hệ thống có thể vượt qua UAT hoàn hảo rồi vỡ ở tuần đầu vận hành, và ngược lại thì hiếm hơn nhưng cũng có.
Tiêu chí | UAT | Pilot |
|---|---|---|
Đối tượng | Key user, thường là đội IT, dùng thử một phần tính năng | Toàn bộ người dùng nghiệp vụ trải nghiệm hệ thống |
Dữ liệu | Dữ liệu mẫu | Dữ liệu thật |
Thời điểm | Trong hoặc sau mỗi sprint | Thường trước go-live khoảng hai tuần |
Ba dòng này nhìn thì đơn giản, nhưng mỗi dòng đều kéo theo một hệ quả mà nếu không thấy thì bạn sẽ đánh giá sai mức độ quan trọng của pilot.
Đầu tiên là về đối tượng. Người tham gia UAT thường là đội IT hoặc một nhóm được chọn, và điểm chung của nhóm này là họ quen công nghệ: gặp một màn hình lạ thì họ mò ra, gặp một thông báo lỗi thì họ đọc hiểu, trong khi người dùng nghiệp vụ thật thì không như vậy, do đó những vướng mắc của họ thuộc loại mà đội IT không bao giờ gặp phải và cũng không nghĩ ra được để mà thử.
Tiếp theo là về thời điểm. UAT chạy theo từng sprint nên nó kiểm tra từng phần, còn pilot chạy một lần trên toàn bộ hệ thống; và cần lưu ý rằng rất nhiều lỗi chỉ xuất hiện ở chỗ nối giữa các phần, ví dụ đơn hàng tạo ở phân hệ này, giao hàng ở phân hệ kia, hóa đơn ở phân hệ thứ ba. Do đó, nếu không có bước nào chạy xuyên suốt thì những chỗ nối đó không ai đi qua trước ngày go-live.
Đây là khác biệt lớn nhất giữa hai bước, và cũng là lý do khó thay thế pilot nhất.
Dữ liệu mẫu che giấu ba loại vấn đề.
Và cần lưu ý một chuyện quan trọng hơn cả ba loại trên: bug thì xử lý được, còn sai dữ liệu mới là thứ phiền phức, bởi trong hệ thống ERP các phân hệ liên kết với nhau nên một bản ghi sai sẽ kéo theo cả chuỗi. Một bản ghi danh mục trỏ tới bản ghi cha đã bị xóa, hay một khách hàng có công nợ đầu kỳ lệch so với sổ kế toán, những chuyện đó chỉ lộ ra khi dữ liệu thật được đổ vào, và pilot chính là lúc phát hiện chúng khi hậu quả còn giới hạn ở một nhóm người thay vì cả doanh nghiệp.
Có một giới hạn của UAT mà không kỹ thuật nào bù được: người tham gia biết đây là thử.
Khi biết là thử, họ thao tác theo kịch bản, họ không sợ làm sai, và họ không đem vào những thói quen thật của mình. Họ cũng không có áp lực thời gian, trong khi ở vận hành thật thì một nhân viên cửa hàng có ba phút cho mỗi khách và sẽ tìm mọi đường tắt.
Pilot thu hẹp khoảng cách đó vì nó chạy trên dữ liệu thật và có nhiều người dùng thật tham gia. Nhưng ngay cả pilot cũng chưa phải vận hành thật, nên bạn vẫn nên chuẩn bị tinh thần rằng tuần đầu go-live sẽ có một đợt vấn đề nữa, và phần lớn trong đó không phải bug.
Thực tế hiện nay nhiều nơi gộp hai bước làm một để tiết kiệm thời gian, và tôi không cho rằng đó luôn là sai. Câu hỏi là bạn có biết mình đang đánh đổi cái gì không.
Gộp được khi hai điều kiện cùng đúng. Điều kiện thứ nhất là người dùng quen công nghệ, tức nhóm sẽ vận hành hệ thống có nền tảng đủ để tự xoay xở với một giao diện mới. Đồng thời, điều kiện thứ hai là khối lượng dữ liệu không lớn và tương đối sạch, thường gặp ở doanh nghiệp mới thành lập hoặc doanh nghiệp trước đó đã dùng một hệ thống có cấu trúc chứ không phải chỉ dùng Excel.
Ngược lại thì không gộp được. Với người dùng ít tiếp xúc với phần mềm như công nhân xưởng, nhân viên kho, nhân viên cửa hàng, bắt buộc phải có một giai đoạn họ chạm vào hệ thống thật trước ngày go-live. Bên cạnh đó, dữ liệu quá lớn hoặc quá không chuẩn cũng là điều kiện bắt buộc phải tách, bởi đó chính là nhóm vấn đề mà chỉ pilot mới lộ ra được.
Trong trường hợp bạn buộc phải cắt vì lịch, cách cắt ít rủi ro nhất không phải là bỏ hẳn pilot mà là thu hẹp nó: chọn một chi nhánh hoặc một nhóm nghiệp vụ, chạy thật trên dữ liệu thật trong một tuần, rồi mới mở rộng. Cách này giữ được đúng thứ mà pilot sinh ra để làm, chỉ nhỏ lại về quy mô.
Đây là tài liệu quyết định buổi UAT có giá trị hay không, và cũng là tài liệu hay bị bỏ nhất.
Không có kịch bản thì người dùng sẽ chỉ thử những gì họ nghĩ ra, mà những gì họ nghĩ ra thường là các thao tác đơn giản nhất, còn đúng những luồng quan trọng và phức tạp thì không ai chạm tới, đơn giản vì không ai nghĩ tới chúng.
Nguyên tắc viết thì chỉ có một, nhưng nó đổi hoàn toàn chất lượng của buổi test: kịch bản đi theo nghiệp vụ, không đi theo tính năng. Một kịch bản không phải là "kiểm tra chức năng tạo đơn hàng", mà là "khách gọi đặt mười thùng hàng, trong đó có hai mã đang hết tồn, khách yêu cầu giao trước phần có sẵn" rồi để người dùng tự đi từ đầu tới cuối. Cách viết này bắt được chỗ nối giữa các phân hệ, và nó cũng dễ cho người dùng vì đó chính là tình huống họ gặp hằng ngày.
Mỗi kịch bản cần điều kiện trước, các bước, dữ liệu dùng để thử, và kết quả mong đợi. Kết quả mong đợi phải viết ở tầng nghiệp vụ chứ không ở tầng màn hình: không phải "hệ thống hiện thông báo thành công", mà "tồn kho giảm đúng số lượng đã giao và phần còn lại nằm ở phiếu chờ".
Và nên có sẵn một chỗ để người dùng ghi lại vướng mắc ngay trong lúc chạy. Người dùng sẽ có phản hồi ở mọi giai đoạn của dự án: lúc khảo sát, lúc phát triển, lúc UAT, lúc đào tạo, lúc go-live. Do đó, bạn nên chuẩn bị chỗ ghi nhận từ đầu thì tới cuối bạn có một danh sách thay vì một trí nhớ.
Ba việc, và cả ba đều là chuyện tổ chức chứ không phải chuyện kỹ thuật.
Đầu tiên, không cho đội phát triển deploy lên trong ngày có buổi test hoặc buổi đào tạo, và hôm trước đó nên chốt lại rồi kiểm tra một lượt. Không làm việc này thì sẽ có lúc người dùng đang thao tác giữa chừng thì màn hình đổi, mà niềm tin vào hệ thống thì mất nhanh hơn nhiều so với tốc độ bạn sửa lỗi.
Tiếp theo, dựng môi trường riêng cho việc test và đào tạo, tách khỏi môi trường mà đội phát triển đang deploy; một số nơi còn dựng riêng hẳn một bản cho khách dùng trong suốt giai đoạn UAT.
Và cuối cùng, nếu có thay đổi nào ảnh hưởng tới thứ khách đã quen thì phải báo trước. Người dùng vào thấy màn hình khác đi mà không ai nói gì thì họ sẽ báo đó là lỗi, và bạn mất cả buổi giải thích thay vì mất một tin nhắn.
Kết thúc pilot thì phải có một quyết định, và quyết định đó cần tiêu chí đo lường.
Ở mức tối thiểu thì tiêu chí phải chạm được ba chỗ:
Cách đặt ngưỡng cho từng nhóm, ai là người ký, và phương án quay lui thì tôi để ở bài về checklist go-live, vì cả ba đều thuộc về danh sách chuẩn bị cho ngày đó.
Sau khi quyết định go thì công việc chuyển sang một danh sách khác, và danh sách đó có phần của cả hai bên chứ không chỉ của đội triển khai.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận