Kiểm tra Agile - Scrum

Những người ủng hộ Scrum Whole Team Approach, theo nghĩa là mọi thành viên trong nhóm phải tham gia vào mọi hoạt động của dự án. Nhóm Scrum tự tổ chức với trách nhiệm giải trình với các sản phẩm dự án được giao. Việc ra quyết định được giao cho nhóm dẫn đến các hành động thích hợp được thực hiện vào đúng thời điểm mà không bị chậm trễ về thời gian. Cách tiếp cận này cũng khuyến khích sử dụng hợp lý tài năng của nhóm thay vì chỉ giới hạn trong một hoạt động. Người kiểm thử cũng tham gia vào tất cả các hoạt động phát triển và dự án đóng góp kiến thức chuyên môn của họ trong việc kiểm thử.

Cả nhóm làm việc cùng nhau về Chiến lược kiểm tra, Lập kế hoạch kiểm tra, Đặc điểm kỹ thuật kiểm tra, Thực hiện kiểm tra, Đánh giá kiểm tra và Báo cáo kết quả kiểm tra.

Tạo câu chuyện người dùng cộng tác

Người thử nghiệm tham gia Sáng tạo câu chuyện người dùng. Người kiểm thử đóng góp ý kiến của họ về hành vi có thể có của hệ thống. Điều này giúp khách hàng và / hoặc người dùng cuối hiểu hệ thống trong môi trường thực và do đó hiểu rõ những gì họ thực sự muốn là kết quả. Điều này dẫn đến việc đóng băng các yêu cầu nhanh hơn và cũng làm giảm xác suất thay đổi các yêu cầu sau này.

Người kiểm thử cũng đưa ra Tiêu chí chấp nhận cho mọi tình huống được khách hàng đồng ý.

Người kiểm tra đóng góp vào việc tạo ra các câu chuyện người dùng có thể kiểm tra.

Lập kế hoạch phát hành

Lập kế hoạch phát hành được thực hiện cho toàn bộ dự án. Tuy nhiên, khung Scrum liên quan đến việc đưa ra quyết định lặp đi lặp lại vì thu được nhiều thông tin hơn trong quá trình thực hiện chạy nước rút. Do đó, phiên Lập kế hoạch phát hành khi bắt đầu dự án không cần đưa ra kế hoạch phát hành chi tiết cho toàn bộ dự án. Nó có thể được cập nhật liên tục, khi có thông tin liên quan.

Mỗi sprint-end không cần phải có bản phát hành. Có thể phát hành sau một nhóm chạy nước rút. Tiêu chí chính của một bản phát hành là cung cấp giá trị kinh doanh cho khách hàng. Nhóm quyết định về độ dài sprint với lập kế hoạch phát hành như một đầu vào.

Lập kế hoạch phát hành là cơ sở của phương pháp tiếp cận thử nghiệm và kế hoạch thử nghiệm để phát hành. Người kiểm tra ước tính Nỗ lực Kiểm tra và lập kế hoạch Kiểm tra cho bản phát hành. Khi kế hoạch phát hành thay đổi, người kiểm tra phải xử lý các thay đổi, có được cơ sở kiểm tra thích hợp xem xét bối cảnh phát hành lớn hơn. Người kiểm tra cũng cung cấp nỗ lực kiểm tra cần thiết khi kết thúc tất cả các lần chạy nước rút.

Kế hoạch nước rút

Lập kế hoạch chạy nước rút được thực hiện khi bắt đầu mỗi nước rút. Sprint backlog được tạo bằng các câu chuyện của người dùng có được từ product backlog để triển khai trong sprint cụ thể đó.

Người kiểm tra nên -

Xác định khả năng kiểm tra của các câu chuyện người dùng đã chọn cho sprint
Tạo các bài kiểm tra chấp nhận
Xác định mức độ kiểm tra
Xác định tự động hóa kiểm tra

Người kiểm tra cập nhật kế hoạch kiểm tra với các ước tính cho nỗ lực và thời lượng kiểm tra trong sprint. Điều này đảm bảo cung cấp thời gian cho việc kiểm tra bắt buộc trong thời gian chạy nước rút trong hộp thời gian và cũng như trách nhiệm giải trình của nỗ lực kiểm tra.

Phân tích thử nghiệm

Khi một sprint bắt đầu, khi các nhà phát triển tiến hành phân tích câu chuyện để thiết kế và triển khai, những người kiểm tra thực hiện phân tích thử nghiệm cho các câu chuyện trong sprint tồn đọng. Tester tạo các trường hợp thử nghiệm được yêu cầu - cả thử nghiệm thủ công và tự động.

Thử nghiệm

Tất cả các thành viên của nhóm Scrum nên tham gia thử nghiệm.

Các nhà phát triển thực hiện các bài kiểm tra đơn vị khi họ phát triển mã cho các câu chuyện của người dùng. Bài kiểm tra đơn vị được tạo trong mỗi sprint, trước khi mã được viết. Các trường hợp kiểm thử đơn vị bắt nguồn từ các thông số kỹ thuật thiết kế cấp thấp.
Người kiểm tra thực hiện các tính năng chức năng và phi chức năng của câu chuyện người dùng.
Người kiểm tra cố vấn cho các thành viên khác trong nhóm scrum với chuyên môn của họ trong việc kiểm tra để toàn bộ nhóm sẽ có trách nhiệm tập thể về chất lượng của sản phẩm.
Vào cuối sprint, khách hàng và / hoặc người dùng cuối thực hiện Kiểm tra sự chấp nhận của người dùng và cung cấp phản hồi cho nhóm scrum. Điều này hình thành như một đầu vào cho nước rút tiếp theo.
Kết quả kiểm tra được thu thập và duy trì.

Kiểm tra tự động hóa

Kiểm thử tự động hóa được coi trọng trong các nhóm Scrum. Người kiểm tra dành thời gian trong việc tạo, thực hiện, giám sát và duy trì các kết quả và kiểm tra tự động. Vì các thay đổi có thể xảy ra bất cứ lúc nào trong các dự án scrum, người kiểm thử cần phải thích ứng với việc kiểm tra các tính năng đã thay đổi và cả kiểm tra hồi quy liên quan. Kiểm thử tự động tạo điều kiện thuận lợi cho việc quản lý nỗ lực kiểm tra liên quan đến các thay đổi. Kiểm tra tự động ở tất cả các cấp tạo điều kiện tích hợp liên tục. Kiểm tra tự động chạy nhanh hơn nhiều so với kiểm tra thủ công mà không cần nỗ lực thêm.

Kiểm thử thủ công tập trung nhiều hơn vào kiểm tra khám phá, tính dễ bị tổn thương của sản phẩm, dự đoán lỗi.

Tự động hóa các hoạt động kiểm tra

Tự động hóa các hoạt động thử nghiệm làm giảm gánh nặng của công việc lặp đi lặp lại và tiết kiệm chi phí. Tự động hóa

Kiểm tra tạo dữ liệu
Tải dữ liệu thử nghiệm
Xây dựng triển khai thành môi trường thử nghiệm
Quản lý môi trường thử nghiệm
So sánh đầu ra dữ liệu

Kiểm tra hồi quy

Trong một nước rút, người kiểm tra kiểm tra mã mới / sửa đổi trong nước rút đó. Tuy nhiên, người thử nghiệm cũng cần đảm bảo rằng mã được phát triển và thử nghiệm trong các lần chạy nước rút trước đó cũng đang hoạt động cùng với mã mới. Do đó, kiểm thử hồi quy được coi trọng trong scrum. Kiểm tra hồi quy tự động được chạy trong tích hợp liên tục.

Quản lý cấu hình

Hệ thống quản lý cấu hình sử dụng các khuôn khổ xây dựng và kiểm tra tự động được sử dụng trong các dự án Scrum. Điều này cho phép chạy phân tích tĩnh và kiểm tra đơn vị lặp đi lặp lại khi mã mới được kiểm tra trong Hệ thống quản lý cấu hình. Nó cũng quản lý sự tích hợp liên tục của mã mới với hệ thống. Kiểm tra hồi quy tự động được chạy trong quá trình tích hợp liên tục.

Các Trường hợp Kiểm tra Thủ công, Kiểm tra Tự động, Dữ liệu Kiểm tra, Kế hoạch Kiểm tra, Chiến lược Kiểm tra và các Phần mềm Kiểm tra khác cần được Kiểm soát Phiên bản và yêu cầu đảm bảo Quyền truy cập liên quan. Điều này có thể được thực hiện bằng cách duy trì Phần mềm thử nghiệm trong Hệ thống quản lý cấu hình.

Thực hành thử nghiệm Agile

Người kiểm tra trong Nhóm Scrum có thể tuân theo các Thực hành Agile sau:

Pairing- Hai Thành viên trong Nhóm ngồi lại với nhau và làm việc hợp tác. Hai người có thể là hai Người kiểm tra hoặc một Người kiểm tra và một Nhà phát triển.
Incremental Test Design - Các trường hợp thử nghiệm được phát triển khi Sprint tiến triển dần dần và các Câu chuyện của người dùng được thêm vào.

Các chỉ số Agile

Trong quá trình phát triển phần mềm, việc thu thập và phân tích các số liệu giúp cải thiện quy trình và do đó đạt được năng suất, chất lượng tốt hơn và sự hài lòng của khách hàng. Trong phát triển dựa trên Scrum, điều này hoàn toàn có thể xảy ra và người kiểm tra phải chú ý đến các chỉ số mà họ cần.

Một số thước đo được đề xuất để phát triển Scrum. Các số liệu quan trọng là -

Ratio of Successful Sprints - (Number of successful Sprints / Total number of Sprints) * 100. Một Sprint thành công là một trong đó Nhóm có thể đáp ứng cam kết của mình.
Velocity- Vận tốc của một đội dựa trên số Điểm câu chuyện mà một đội kiếm được trong một cuộc chạy nước rút. Điểm câu chuyện là thước đo của Câu chuyện người dùng được tính trong quá trình ước tính.
Focus Factor - (Velocity / Team’s Work Capacity) / 100. Yếu tố tập trung là tỷ lệ phần trăm nỗ lực của nhóm dẫn đến câu chuyện đã hoàn thành.
Estimation Accuracy - (Estimated effort / Actual effort) / 100. Độ chính xác của ước tính là khả năng của Nhóm trong việc ước tính chính xác nỗ lực.
Sprint Burndown- Làm việc (tính theo Điểm câu chuyện hoặc theo giờ) còn lại Vs. Công việc cần được Duy trì lý tưởng (theo Ước tính).
- Nếu nó nhiều hơn, thì có nghĩa là Nhóm đã thực hiện nhiều Công việc hơn họ có thể làm.
- Nếu nó ít hơn, thì có nghĩa là Nhóm đã không Ước tính chính xác.
Defect Count- Số lượng khuyết tật trong một Sprint. Số lỗi là số lượng lỗi trong phần mềm so với tồn đọng.
Severity of Defects- Các khiếm khuyết có thể được phân loại là nhỏ, nặng và nghiêm trọng tùy theo mức độ nghiêm trọng của chúng. Người kiểm tra có thể xác định phân loại.

Sprint Retrospectives

Trong Sprint Retrospectives, tất cả các thành viên trong nhóm sẽ tham gia. Họ chia sẻ -

Mọi thứ diễn ra tốt đẹp
Metrics
Phạm vi cải tiến
Các mục hành động cần áp dụng