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