Nghề QA trong thế giới Agile (Part 1)

Scrum là một quy trình quản lý và kiểm soát được áp dụng trong các dự án phát triển phần mềm giúp loại bỏ những công đoạn phức tạp và chỉ tập trung vào việc cung cấp các tính năng nghiệp vụ cốt lõi (Business features) trong thời gian phát triển ngắn từ 2-4 tuần. Đội Scrum có hai đặc tính rõ nét:

1. Đa kỹ năng: Các thành viên trong đội có tất cả các kỹ năng cần thiết để hoàn thành công việc.

2. Tự tổ chức: Các thành viên trong đội phải có kỹ năng tự tìm hiểu cũng như tổ chức bản thân để hoàn thành công việc một cách tốt nhất. Sau khi làm việc trong gần hai năm với vai trò là kỹ sư đảm bảo chất lượng (Quality Assurance - QA) trong một nhóm Scrum, tôi nhận ra vai trò của QA trong nhóm Scrum không chỉ dừng lại ở việc viết các trường hợp kiểm thử (test cases) và báo cáo lỗi (bugs reporting).

Đối nghịch với các hoạt động đồng bộ của mô hình Thác nước (Waterfall) truyền thống, các hoạt động phát triển của Scrum diễn ra theo thứ tự không đồng nhất. Việc phá vỡ sự phát triển đồng nhất đặt ra câu hỏi chung cho các khách hàng (Clients), đội ngũ lập trình viên (Developers) và các bên liên quan – những người lần đầu tham gia vào mô hình Agile: “Làm thế nào đội ngũ QA có thể kiểm tra sản phẩm trong suốt một Sprint ngay cả trước khi ứng dụng được dựng lên?”. Bài chia sẻ này tập trung vào việc giải thích vai trò quan trọng của QA trong mô hình Agile và trong một nhóm Scrum, chúng đến từ những gì tôi đã học được trong suốt quá trình làm việc tại vị trí QA trong những năm vừa qua.

Không đơn thuần chỉ là viết Test Cases

Trong mô hình phát triển Waterfall, QA chỉ bắt tay vào công việc tại thời điểm gần cuối của dự án, khi giai đoạn lập trình đã hoàn tất. Thông thường, các QA sẽ nhận được một bộ tài liệu đặc tả yêu cầu (Requirements document) và một ứng dụng gần như hoàn chỉnh, để dựa vào đó, QA sẽ viết và thực thi các Test Cases nhằm đảm bảo ứng dụng hoạt động đúng với những gì được đặc tả. Tuy nhiên, vai trò QA trong mô hình Scrum là một khái niệm hoàn toàn khác.

Trong một nhóm Scrum, QA tham gia và thực hiện một loạt các công việc ngay từ đầu cùng với các kỹ sư phân tích yêu cầu (Business Analyst) và các Developers. Như đã đề cập ở trên, Scrum yêu cầu tất cả các thành viên trong đội phải là những người đa kỹ năng, cho nên các QA đôi khi cũng giúp người nắm giữ sản phẩm (Product Owner) viết các Test Cases cho kiểm thử chấp nhận (Acceptance Test) trên vai trò của chính Product Owner. Việc này sẽ giúp thúc đẩy tiến độ phát triển của cả nhóm ngay cả khi Product Owner không có mặt tại thời điểm đó. Ngoài ra QA cũng có thể đặt ra những câu hỏi và đưa ra các tình huống giả định cho Product Owner để làm rõ các yêu cầu nghiệp vụ (Business requirements).

Ước lượng cho các User Stories

QA rất giỏi trong việc tạo ra các tình huống kiểm thử đứng trên vai trò của người dùng. Họ cũng rất xuất sắc trong việc nhận định và nắm bắt các trường hợp kiểm thử phức tạp có khả năng sinh ra lỗi rất cao. Có QA trong giai đoạn lập kế hoạch (Planning) là một lợi thế khá lớn, vì trong khi các Developers tập trung nhiều hơn vào các luồng happy path của User Stories, các QA sẽ đưa ra các luồng unhappy path để việc ước lượng (Estimation) cho các User Stories trở nên chính xác hơn rất nhiều (do có cả happy lẫn unhappy path), giảm thiểu tình trạng làm thêm giờ (Overtime work) khi Sprint đã được bắt đầu. Ước lượng luôn là một công việc khó nhưng độ chính xác sẽ cao hơn rất nhiều khi cả nhóm Scrum đều tham gia vào công việc này…

(còn tiếp)