Tiêu chuẩn Chất lượng Phần mềm

1 Thấu hiểu mục tiêu kinh doanh

Phát triển Hướng hành vi (BDD) là một quy trình phát triển phần mềm giúp hài hòa giữa lợi ích kinh doanh và chuyên môn kỹ thuật. Khách hàng trao đổi về nhu cầu kinh doanh thông qua các kịch bản ví dụ cụ thể; đây là cách hiệu quả để diễn đạt nhu cầu, nhận diện các giả định sai lệch và đảm bảo mọi khía cạnh đều được xem xét. Điều này giúp tránh được các lỗi sai và việc phải làm lại trong các giai đoạn sau. Các chuyên gia trải nghiệm người dùng (UX) cũng có thể tham gia vào giai đoạn tìm hiểu yêu cầu để hiểu rõ hơn về người dùng của hệ thống trong tương lai.

2 Xác định và mô tả tính năng

Các đội ngũ SA (Kiến trúc sư hệ thống), DEV (Lập trình viên) và QA (Kiểm định chất lượng) diễn đạt các yêu cầu kinh doanh dưới dạng các tính năng. Tuy nhiên, họ đặc biệt chú trọng vào việc thấu hiểu giá trị kinh doanh và động lực đằng sau mỗi tính năng. Các câu chuyện kịch bản được mô tả theo cách nhấn mạnh vào yêu cầu và giá trị sẽ được bàn giao.

Thông thường, các tính năng này do bộ phận BA (Phân tích nghiệp vụ) soạn thảo dưới sự phối hợp của khách hàng và đội ngũ phát triển, sau đó được đưa vào danh sách chờ (Product Backlog) như một tài liệu chính thức.

3 Làm việc ngược từ kết quả đầu ra

Trước hết, chúng tôi tập trung vào việc tính năng đó sẽ hoạt động như thế nào khi hoàn tất. Ví dụ, để nộp đơn xin nghỉ phép trực tuyến, kết quả đầu ra có thể bao gồm:

• Một đơn xin nghỉ phép được gửi đến bộ phận nhân sự.
• Số ngày nghỉ và loại hình nghỉ phép được gửi email đến bộ phận nhân sự hoặc trưởng nhóm.
• Số ngày nghỉ sẽ được khấu trừ tương ứng vào quỹ phép của nhân viên.

Việc tập trung vào kết quả đầu ra giúp dồn toàn lực để làm cho tính năng hoạt động đúng mục tiêu, đảm bảo phần mềm luôn thỏa mãn các điều kiện đã đặt ra ngay từ đầu giai đoạn.

4 Khám phá và xây dựng sơ đồ quy trình nghiệp vụ

Sau khi nắm rõ kết quả đầu ra, đội ngũ thường sử dụng các kỹ thuật như sơ đồ hóa câu chuyện (story mapping) hoặc sơ đồ hóa quy trình (process mapping) để hiểu luồng vận hành xuyên suốt hệ thống. Cách này giúp xác định phương thức nhanh nhất để bàn giao một tính năng hữu dụng và đảm bảo không có bước nào bị bỏ sót.

Quy trình đơn giản cho tính năng gửi đơn xin nghỉ phép trực tuyến có thể như sau:

Mỗi hoạt động trong luồng quy trình sẽ mở ra các cuộc thảo luận về các biến thể, các luồng thay thế và các trường hợp biên. Ví dụ, khi xem xét bước “kiểm tra loại phép”, chúng ta có thể nhận thấy việc kiểm tra này phụ thuộc vào loại nhân viên và các chế độ nghỉ khác nhau như nghỉ thai sản hay các diện nghỉ khác.

5 Định nghĩa tính năng bằng ngôn ngữ Gherkin

Các thành viên tham gia vào một tính năng cụ thể sẽ họp lại để thảo luận chi tiết các yêu cầu. Thành phần thường gồm đại diện kinh doanh (BA), lập trình viên và kiểm thử viên. Mục tiêu là để đội ngũ hiểu sâu về các quy tắc nghiệp vụ và tiêu chí chấp nhận (acceptance criteria), đồng thời chủ động phát hiện những điểm phức tạp hoặc rủi ro có thể gây trở ngại cho quá trình phát triển sau này.

Các tiêu chí chấp nhận thường được diễn đạt theo cấu trúc “Given-When-Then” (Cho phép – Khi – Thì), ví dụ:

6 Kiểm thử tự động

Các đặc tả kỹ thuật giờ đây đã sẵn sàng để kiểm thử. Việc kiểm thử tự động có thể được thực hiện bởi kỹ sư kiểm thử, lập trình viên hoặc sự phối hợp của cả hai. Trong mọi trường hợp, công tác tự động hóa luôn được bắt đầu sớm nhất có thể và thường tiến hành song song hoặc ngay sau khi lập trình.

7 Bàn giao

Mục tiêu của BDD là bàn giao các tính năng có giá trị cho doanh nghiệp nhanh hơn và thường xuyên hơn. Bằng cách kết hợp BDD và các tiêu chí chấp nhận tự động, đội ngũ có thể chứng minh được tính truy xuất nguồn gốc rõ ràng giữa kết quả bàn giao (đã được kiểm thử) và các yêu cầu được thảo luận ban đầu.

8 Hoàn tất tiêu chí chấp nhận

Kiểm thử tự động là bắt buộc để chứng minh các yêu cầu trong tiêu chí chấp nhận đã được đáp ứng. Nói cách khác, quá trình phát triển chỉ được coi là hoàn tất khi phần mềm đã được kiểm thử và vượt qua các tiêu chí chấp nhận. Cách lập kế hoạch và kiểm thử dựa trên mục tiêu rõ ràng này giúp giảm thiểu số lượng lỗi cần sửa sau khi kết thúc Sprint, giúp lập trình viên tập trung nguồn lực vào các tính năng mới.

9 Kiểm thử hồi quy (Regression Tests)

Bộ kiểm thử hồi quy là tập hợp các bài kiểm tra được thiết kế để đảm bảo phần mềm vẫn hoạt động chính xác sau khi trải qua các thay đổi hoặc chỉnh sửa. Bộ kiểm thử này được tổ chức theo các tính năng và năng lực của hệ thống, đóng vai trò như một dạng tài liệu chức năng, mô tả không chỉ hệ thống làm được gì mà còn cả những mục tiêu kinh doanh mà nó đang hướng tới.