Scrum testing cho người mới bắt đầu
Bài viết được dịch từ nguồn: http://www.guru99.com/scrum-testing-a-beginner-s-guide.html Scrum là gì Xây dựng một ứng dụng phần mềm phức tạp là một công việc đầy khó khăn. Phương thức Scrum ra đời như là một giải pháp cho những công việc khó khăn như vậy. Phương pháp này giúp đội phát triển có ...
Bài viết được dịch từ nguồn: http://www.guru99.com/scrum-testing-a-beginner-s-guide.html
Scrum là gì
Xây dựng một ứng dụng phần mềm phức tạp là một công việc đầy khó khăn. Phương thức Scrum ra đời như là một giải pháp cho những công việc khó khăn như vậy. Phương pháp này giúp đội phát triển có thể tập chung vào tất cả các khía cạnh của chất lượng sản phẩm, hiệu năng, khả năng sử dụng...
Dưới đây là một số đặc điểm của Scrum
Scrum có chu kì release cố định ngắn với phạm vi có thể điều chỉnh được gọi là Sprint để giải quyết nhanh chóng những thay đổi cần thiết trong việc phát triển. Mỗi đợt release có thể bao gồm nhiều Sprint. Mỗi Scrum Project có thể có nhiều Release Cycles. Scrum dựa trên 3 Pillar dưới đây:
1. Role in scrum
Có 3 vai trò quan trọng trong Scrum Testing đó là: Product Owner, Scrum Master và Development Team. Dưới đây là cụ thể từng vai trò:
Product Owner:
- Là người định nghĩa các yêu cầu của sản phẩm
- Quyết đinh ngày release cũng như các tính năng tương ứng cần phải hoàn thành
- Ưu tiên các freature dựa trên giá cả và lợi nhuận
- Chịu trách nhiệm cho sự thành công của dự án
- Có thể chập nhận hay hủy bỏ kết quả của đầu việc
Scrum Master:
- Quản lý cả team và năng suất của team
- Duy trì block list và loại bỏ những rào cản trong việc phát triển
- Phối hợp các vai trò và chức năng trong dự án
- Đảm bảo team không gặp những trợ ngại, đụng chạm bên ngoài
- Được mời đến các cuộc họp Dayly scrum, Sprint review và Planning meeting
Team phát triển:
- Team thường gồm từ 5-9 người
- Bao gồm developer, designer và tester…
- Team tự tổ chức và lên kế hoạch cho công việc của mình
- Có quyền làm mọi thứ trong phạm vi project đê đạt được mục tiêu của sprint
- Tích cực tham gia các hoạt động hằng ngày của dự án
2. Scrum Artifacts
Một quy trình scrum bao gồm:
- User story: Một danh sách ngắn gọn giải thích các chức năng của hệ thống.
- Product Backlog: Là một nhóm các user story được capture lại để thực hiện. Product Owner sẽ chuẩn bị và duy trì produck backlog. Nó được ưu tiên bởi product owner, nếu một thành viên nào đso muốn thêm chức năng nào vào đó thì phải được sự cho phép của product owner
- Realse Backlog: Một release là một khung thời gian mà trong đó một số lượng vòng lặp sẽ được hoàn thành. Product ownder sẽ phối hợp với Scrum master để quyết định những story nào sẽ phải release.
- Sprint: là một khoảng thời gian được quy định sẵn để thực hiện một nhóm các story, được quyết định bởi Product owner, team phát triển. Thông thường khoảng thời gian cho một sprint là từ 2-4 tuần.
- Sprint backlog: Là một nhóm các user story sẽ phải hoàn thành trong 1 sprint. Trong suốt Sprint backlog, công việc không bao giờ được assign, và team sẽ tự lựa chọn công việc cho họ. Việc estimate công việc sẽ được cập nhật hằng ngày
- Block list: Nó là một danh sách các block và unmade decision thuộc quyển sở hữu của Scrum master và được update hằng ngày.
- Burndown chart: trình bày toàn bộ tiến trình của công việc bao gồm những việc đang trong tiến trình và những việc đã hoàn thành
3. Cermonies (Processes) Scrum
- Sprint planning: Một sprint bắt đầu với việc team sẽ đưa các story từ realse backlog sang sprint backlog, nó được thực hiện bởi Scrum master. Tester sẽ phải tự estimate effort để thực hiện kiểm thử các story trong Sprint Backlog
- Daily Scrum: Được chủ trì bởi Scrum master, diễn ra trong khoảng 15 phút. Trong suốt Daily Scrum, các thành viên sẽ thảo luận về những việc đã hoàn thành vào ngày hôm trước, kế hoạch cho ngày tiếp theo và những vấn đề gặp phải trong sprint.
- Sprint Review/ Retrospective: Được chủ trì bởi Scrum master, diễn tra trong khoảng từ 2-4 tiếng và thảo luận những việc mà team đã đạt được ở sprint trước, và những bài học rút ra cho sprint sau
VAI TRÒ CỦA TESTER TRONG SCRUM
Không có vai trò thực sự của tester trong tiến trình Scrum. Thông thường việc kiểm thử sẽ được tiến hành bởi lập trình viên với Unit test. Trong khi product owner còn thường xuyên than gia vào kiểm thử trong mỗi sprint. Một vài Scrum project có một test team độc lập phụ thuộc vào tính chất và độ phức tạp của dự án.
Vậy câu hỏi đặt ra là, tester sẽ làm gì trong dự án scrum?
Hoạt động kiểm thử trong Scrum
Trong suốt các giai đoạn khác nhau trong Scrum, tester sẽ làm các công việc dưới đây:
Sprint Planning
- Trong Sprint planning, tester sẽ lựa chọn ra các user-story từ product backlog để test
- Tester sẽ quyết định bao nhiêu giờ (Effort Estimation) cần để hoàn thành việc kiểm thử cho các user-story đã chọn
- Tester cần xác định được mục tiêu của các sprint
- Tester cần tham gia đóng góp vào những quá trình được ưu tiên
Sprint
- Hỗ trợ developer thực hiện unit testing
- Kiểm thử user-story khi đã hoàn thành. Execute test khi đã hoàn thành trong môi trường mà tester và developer làm việc cùng nhau. Lỗi được log lên hệ thống quản lý lỗi và đươc theo dõi hằng ngày. Lỗi có thể được đưa vào và phân tích trong suốt Scrum meeting. Lỗi được retest ngày khi nó được giải quyết và deploy để test
- Tham gia vào cuộc họp Stand meeting
- Có thể mang bất kì item nào trong backlog nếu như thấy nó không thể hoàn thành sang sprint tiếp theo
- Tester có trách nhiệm phát triển automation script. Họ lên kế hoạch để thực hiện automation testing với hệ thống Continous Integration (CI)
- Review kết quả test CI automation và báo cáo cho Stackholder
- Thực hiện test non-function
- Làm việc cùng khách hàng và pỏduct owner để xác định các tiêu chí chấp nhận cho Acceptance testing
- Kết thúc sprint, tester còn thực hiện acceptance testing (UAT) trong một vài trường hợp và xác nhận việc hoàn thành kiểm thử cho sprint hiện tại
Sprint Retrospective
Báo cáo bao gồm các chỉ số rõ ràng và minh bạch của Scrum test cho stackholder về dự án. Các số liệu được báo cáo có thể cho phép team phân tích được tiến trình và những chiến lược trong tương lai cần phải triển khai để nâng cao chất lượng sản phẩm. Có hai số liệu thường xuyên phải report là:
Burn down chart:
-
Mỗi ngày Scrum master ghi lại số lượng công việc ược lượng của sprint. Đó chình là Burn Down Chart và được cập nhật hằng ngày.
-
Burn Down Chart: Nhanh chóng đưa ra một cái nhìn tổng thể về tiến trình của dự án, bao gồm thông tin như tổng số lượng công việc trong dự án cần phải hoàn thành, số lượng công việc đã hoàn thành trong mỗi sprint...
-
Velocity history graph: Đồ thị dự đoán tiến độ làm việc của các team đã đạt được trong mỗi sprint. Nó là một bar graph và trình bày sự thay đổi tiến độ cảu các team qua thời gian. Số liệu được đưa vào có thể rất hữu ích để thay đổi thời gian và ngân quỹ cho dự án, tỉ lệ hoàn thành, story hoàn thành, story còn lại ...