 |
| ảnh minh họa |
Việc ra quyết định được để lại cho nhóm nhằm đưa ra 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ễ thời gian. Cách tiếp cận này cũng khuyến khích sử dụng đúng đắn tài năng của đội thay vì hạn chế một hoạt động. Những người kiểm tra cũng tham gia vào tất cả các hoạt động dự án và phát triển đóng góp chuyên môn của họ trong thử nghiệm.
Cả nhóm làm việc cùng nhau trên Chiến lược kiểm tra, Lập kế hoạch kiểm tra, Đặc tả kiểm tra, Kiểm tra thực thi, Đánh giá thử nghiệm và Báo cáo kết quả kiểm tra.
Người thử nghiệm cũng đưa ra Tiêu chí chấp nhận cho mọi trường hợp được khách hàng đồng ý.
Người thử nghiệm đóng góp vào việc tạo ra những câu chuyện của người dùng có thể kiểm chứng.
Mỗi lần chạy nước rút không cần phải có bản phát hành. Bản phát hành có thể sau một nhóm chạy nước rút. Tiêu chí chính của 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 chạy nước rút với quy hoạch phát hành làm đầu vào.
Kế hoạch phát hành là cơ sở của phương pháp thử nghiệm và kế hoạch kiểm tra để phát hành. Kiểm tra ước tính nỗ lực thử nghiệm và kế hoạch thử nghiệm cho việc phát hành. Khi các kế hoạch phát hành thay đổi, người kiểm thử phải xử lý các thay đổi, có được một cơ sở kiểm tra thích hợp xem xét bối cảnh phát hành lớn hơn. Học Tester cũng cung cấp các nỗ lực thử nghiệm được yêu cầu ở phần cuối của tất cả các chạy nước rút.
Những người kiểm thử nên
Xác định khả năng kiểm tra các câu chuyện của người dùng được chọn cho lần chạy nước rút
Tạo kiểm tra chấp nhận
Xác định mức độ kiểm tra
Xác định tự động hóa thử nghiệm
Người thử nghiệm cập nhật kế hoạch thử nghiệm với các ước tính cho nỗ lực thử nghiệm và thời lượng trong lần chạy nước rút. Điều này đảm bảo cung cấp thời gian cho các thử nghiệm cần thiết trong thời gian chạy nước rút có đóng hộp và cũng chịu trách nhiệm về nỗ lực kiểm tra.
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. Kiểm tra đơn vị được tạo ra trong mỗi lần chạy nước rút, trước khi mã được viết. Các trường hợp thử nghiệm đơn vị có nguồn gốc từ các thông số kỹ thuật thiết kế cấp thấp.
Những người thử nghiệm thực hiện các tính năng chức năng và phi chức năng của các câu chuyện của người dùng.
Những người thử nghiệm 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 thử nghiệm để toàn bộ nhóm sẽ có trách nhiệm đối với chất lượng của sản phẩm.
Vào cuối của nước rút, khách hàng và / hoặc người dùng cuối thực hiện Kiểm tra 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 tạo thành đầu vào cho lần chạy nước rút tiếp theo.
Kết quả kiểm tra được thu thập và duy trì.
Kiểm tra thủ công tập trung nhiều hơn vào kiểm tra thăm dò, lỗ hổng sản phẩm, dự đoán lỗi.
Tạo dữ liệu thử nghiệm
Tải dữ liệu thử nghiệm
Xây dựng triển khai vào môi trường thử nghiệm
Kiểm tra quản lý môi trường
So sánh đầu ra dữ liệu
Kiểm tra hồi quy
Trong một lần chạy nước rút, người thử nghiệm kiểm tra mã mới / sửa đổi trong lần chạy 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 tra hồi quy được đưa ra tầm quan trọng trong scrum. Các bài kiểm tra hồi quy tự động được chạy trong tích hợp liên tục.
Các trường hợp kiểm tra thủ công, thử nghiệm tự động, dữ liệu thử nghiệm, kế hoạch kiểm tra, chiến lược thử nghiệm và các hiện vật thử nghiệm khác cần phải được kiểm soát phiên bản và yêu cầu quyền truy cập có liên quan được đảm bảo. Điều này có thể được thực hiện bằng cách duy trì các hiện vật thử nghiệm trong hệ thống quản lý cấu hình.
Ghép nối - Hai Thành viên Nhóm ngồi lại với nhau và làm việc cộng tác. Hai người có thể là hai Testers hoặc một Tester và một Developer.
Thiết kế thử nghiệm gia tăng - Các trường hợp thử nghiệm được phát triển khi tiến trình chạy nước rút tăng dần và Câu chuyện của người dùng được thêm vào.
Một số chỉ số được đề xuất cho phát triển Scrum. Các số liệu quan trọng là
Tỷ lệ chạy nước rút thành công - (Số lần chạy nước rút thành công / Tổng số lần chạy nước rút) * 100 . Một Sprint thành công là một trong đó Đội có thể đáp ứng cam kết của mình.
Vận tốc - Vận tốc của một đội dựa trên số điểm của Điểm Câu chuyện mà một đội kiếm được trong một lần chạy nước rút. Điểm câu chuyện là thước đo của Câu chuyện của người dùng được tính trong quá trình ước tính.
Yếu tố trọng tâm - (Vận tốc / Năng lực làm việc của đội) / 100 . Yếu tố trọng tâm là tỷ lệ phần trăm nỗ lực của nhóm mà kết quả trong các câu chuyện đã hoàn thành.
Độ chính xác ước tính - (Nỗ lực dự tính / Nỗ lực thực tế) / 100 . Độ chính xác ước tính là khả năng của nhóm trong việc ước tính nỗ lực một cách chính xác.
Sprint Burndown - Công việc (trong Story Points hoặc trong giờ) đó là còn lại Vs. Công việc cần được giữ lại lý tưởng (theo ước tính).
Nếu nó là nhiều hơn, sau đó nó có nghĩa là đội đã thực hiện nhiều công việc hơn là họ có thể làm.
Nếu nó ít hơn, thì điều đó có nghĩa là Đội đã không Ước tính chính xác.
Defect Count - Số lỗi trong Sprint. Số lỗi là số lượng lỗi trong phần mềm chống lại việc tồn đọng.
Mức độ nghiêm trọng của khuyết tật - Khuyết tật có thể được phân loại là nhỏ, lớn và quan trọng theo mức độ nghiêm trọng của chúng. Người thử nghiệm có thể xác định phân loại.
Những điều đã diễn ra tốt đẹp
Số liệu
Phạm vi cải tiến
Các mục tác vụ cần áp dụng
Cả nhóm làm việc cùng nhau trên Chiến lược kiểm tra, Lập kế hoạch kiểm tra, Đặc tả kiểm tra, Kiểm tra thực thi, Đánh giá thử nghiệm và Báo cáo kết quả kiểm tra.
Tạo cộng tác câu chuyện của người dùng
Người thử nghiệm tham gia vào Tạo câu chuyện của người dùng. Người thử nghiệm đó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 cho khách hàng và / hoặc người dùng cuối hiểu được hệ thống trong môi trường thực tế và do đó nhận được sự rõ ràng về 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 nhanh hơn các yêu cầu và cũng làm giảm xác suất thay đổi trong các yêu cầu sau này.Người thử nghiệm cũng đưa ra Tiêu chí chấp nhận cho mọi trường hợp được khách hàng đồng ý.
Người thử nghiệm đóng góp vào việc tạo ra những câu chuyện của người dùng có thể kiểm chứng.
Kế hoạch phát hành
Kế hoạch phát hành được thực hiện cho toàn bộ dự án. Tuy nhiên, khung công tác Scrum liên quan đến việc ra quyết định lặp lại khi có thêm thông tin trong quá trình thực hiện chạy nước rút. Do đó, phiên kế hoạch phát hành vào đầ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, vì thông tin liên quan có sẵn.Mỗi lần chạy nước rút không cần phải có bản phát hành. Bản phát hành có thể sau một nhóm chạy nước rút. Tiêu chí chính của 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 chạy nước rút với quy hoạch phát hành làm đầu vào.
Kế hoạch phát hành là cơ sở của phương pháp thử nghiệm và kế hoạch kiểm tra để phát hành. Kiểm tra ước tính nỗ lực thử nghiệm và kế hoạch thử nghiệm cho việc phát hành. Khi các kế hoạch phát hành thay đổi, người kiểm thử phải xử lý các thay đổi, có được một cơ sở kiểm tra thích hợp xem xét bối cảnh phát hành lớn hơn. Học Tester cũng cung cấp các nỗ lực thử nghiệm được yêu cầu ở phần cuối của tất cả các 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 vào đầu mỗi lần chạy nước rút. Các backlog chạy nước rút được tạo ra với những câu chuyện người dùng được chọn từ việc tồn đọng sản phẩm để thực hiện trong lần chạy nước rút cụ thể đó.Những người kiểm thử nên
Xác định khả năng kiểm tra các câu chuyện của người dùng được chọn cho lần chạy nước rút
Tạo kiểm tra chấp nhận
Xác định mức độ kiểm tra
Xác định tự động hóa thử nghiệm
Người thử nghiệm cập nhật kế hoạch thử nghiệm với các ước tính cho nỗ lực thử nghiệm và thời lượng trong lần chạy nước rút. Điều này đảm bảo cung cấp thời gian cho các thử nghiệm cần thiết trong thời gian chạy nước rút có đóng hộp và cũng chịu trách nhiệm về nỗ lực kiểm tra.
Phân tích thử nghiệm
Khi chạy nước rút bắt đầu, khi các nhà phát triển thực hiện phân tích câu chuyện để thiết kế và thực hiện, người thử nghiệm thực hiện phân tích thử nghiệm cho các câu chuyện trong phần tồn đọng chạy nước rút. Tester tạo các trường hợp kiểm tra bắt buộc - cả kiểm tra 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. Kiểm tra đơn vị được tạo ra trong mỗi lần chạy nước rút, trước khi mã được viết. Các trường hợp thử nghiệm đơn vị có nguồn gốc từ các thông số kỹ thuật thiết kế cấp thấp.
Những người thử nghiệm thực hiện các tính năng chức năng và phi chức năng của các câu chuyện của người dùng.
Những người thử nghiệm 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 thử nghiệm để toàn bộ nhóm sẽ có trách nhiệm đối với chất lượng của sản phẩm.
Vào cuối của nước rút, khách hàng và / hoặc người dùng cuối thực hiện Kiểm tra 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 tạo thành đầu vào cho lần chạy nước rút tiếp theo.
Kết quả kiểm tra được thu thập và duy trì.
Thử nghiệm tự động hóa
Thử nghiệm tự động hóa được đánh giá cao trong các nhóm Scrum. Những người thử nghiệm dành thời gian trong việc tạo, thực hiện, giám sát và duy trì các thử nghiệm và kết quả tự động. Khi các thay đổi có thể xảy ra bất kỳ lúc nào trong các dự án scrum, người kiểm thử cần phải kiểm tra các tính năng đã thay đổi và cũng có thể thử nghiệm hồi quy liên quan. Thử nghiệm tự động hóa tạo điều kiện cho việc quản lý nỗ lực thử nghiệm liên quan đến các thay đổi. Các bài kiểm tra tự động ở tất cả các cấp tạo thuận lợi cho việc tích hợp liên tục. Các thử nghiệm tự động chạy nhanh hơn nhiều so với các thử nghiệm thủ công mà không cần nỗ lực thêm.Kiểm tra thủ công tập trung nhiều hơn vào kiểm tra thăm dò, lỗ hổng sản phẩm, dự đoán lỗi.
Tự động hóa hoạt động thử nghiệm
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à dẫn đến tiết kiệm chi phí. Tự động hóaTạo dữ liệu thử nghiệm
Tải dữ liệu thử nghiệm
Xây dựng triển khai vào môi trường thử nghiệm
Kiểm tra quản lý môi trường
So sánh đầu ra dữ liệu
Kiểm tra hồi quy
Trong một lần chạy nước rút, người thử nghiệm kiểm tra mã mới / sửa đổi trong lần chạy 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 tra hồi quy được đưa ra tầm quan trọng trong scrum. Các bài 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
Một hệ thống quản lý cấu hình sử dụng các khung công tác xây dựng và kiểm thử 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ị nhiều lần khi mã mới được kiểm tra vào Hệ thống quản lý cấu hình. Nó cũng quản lý 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 khi tích hợp liên tục.Các trường hợp kiểm tra thủ công, thử nghiệm tự động, dữ liệu thử nghiệm, kế hoạch kiểm tra, chiến lược thử nghiệm và các hiện vật thử nghiệm khác cần phải được kiểm soát phiên bản và yêu cầu quyền truy cập có liên quan được đảm bảo. Điều này có thể được thực hiện bằng cách duy trì các hiện vật thử nghiệm trong hệ thống quản lý cấu hình.
Thực hành thử nghiệm nhanh nhẹn
Những người kiểm thử trong Nhóm Scrum có thể làm theo các Thực tiễn Nhanh nhẹn sau đây -Ghép nối - Hai Thành viên Nhóm ngồi lại với nhau và làm việc cộng tác. Hai người có thể là hai Testers hoặc một Tester và một Developer.
Thiết kế thử nghiệm gia tăng - Các trường hợp thử nghiệm được phát triển khi tiến trình chạy nước rút tăng dần và Câu chuyện của người dùng được thêm vào.
Chỉ số nhanh
Trong quá trình phát triển phần mềm, việc thu thập và phân tích các chỉ số giúp cải thiện quy trình và do đó đạt được năng suất tốt hơn, phân phối chất lượng 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 là có thể và những người thử nghiệm phải chú ý đến các số liệu mà họ cần.Một số chỉ số được đề xuất cho phát triển Scrum. Các số liệu quan trọng là
Tỷ lệ chạy nước rút thành công - (Số lần chạy nước rút thành công / Tổng số lần chạy nước rút) * 100 . Một Sprint thành công là một trong đó Đội có thể đáp ứng cam kết của mình.
Vận tốc - Vận tốc của một đội dựa trên số điểm của Điểm Câu chuyện mà một đội kiếm được trong một lần chạy nước rút. Điểm câu chuyện là thước đo của Câu chuyện của người dùng được tính trong quá trình ước tính.
Yếu tố trọng tâm - (Vận tốc / Năng lực làm việc của đội) / 100 . Yếu tố trọng tâm là tỷ lệ phần trăm nỗ lực của nhóm mà kết quả trong các câu chuyện đã hoàn thành.
Độ chính xác ước tính - (Nỗ lực dự tính / Nỗ lực thực tế) / 100 . Độ chính xác ước tính là khả năng của nhóm trong việc ước tính nỗ lực một cách chính xác.
Sprint Burndown - Công việc (trong Story Points hoặc trong giờ) đó là còn lại Vs. Công việc cần được giữ lại lý tưởng (theo ước tính).
Nếu nó là nhiều hơn, sau đó nó có nghĩa là đội đã thực hiện nhiều công việc hơn là họ có thể làm.
Nếu nó ít hơn, thì điều đó có nghĩa là Đội đã không Ước tính chính xác.
Defect Count - Số lỗi trong Sprint. Số lỗi là số lượng lỗi trong phần mềm chống lại việc tồn đọng.
Mức độ nghiêm trọng của khuyết tật - Khuyết tật có thể được phân loại là nhỏ, lớn và quan trọng theo mức độ nghiêm trọng của chúng. Người thử nghiệm 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ẻ -Những điều đã diễn ra tốt đẹp
Số liệu
Phạm vi cải tiến
Các mục tác vụ cần áp dụng
Không có nhận xét nào:
Đăng nhận xét