Kiểm tra nhanh - Hướng dẫn nhanh

Agilelà một phương pháp luận phát triển lặp đi lặp lại, trong đó cả hoạt động phát triển và kiểm tra đều đồng thời. Kiểm tra không phải là một giai đoạn riêng biệt; Mã hóa và Kiểm tra được thực hiện tương tác và tăng dần, dẫn đến chất lượng sản phẩm cuối cùng đáp ứng các yêu cầu của khách hàng. Hơn nữa, tích hợp liên tục dẫn đến việc loại bỏ lỗi sớm và do đó tiết kiệm thời gian, công sức và chi phí.

Tuyên ngôn Agile

Tuyên ngôn Agile được xuất bản bởi một nhóm các nhà phát triển phần mềm vào năm 2001, nêu bật tầm quan trọng của nhóm phát triển, đáp ứng các yêu cầu thay đổi và sự tham gia của khách hàng.

The Agile Manifesto is −

Chúng tôi đang khám phá ra những cách tốt hơn để phát triển phần mềm bằng cách thực hiện nó và giúp những người khác làm điều đó. Thông qua công việc này, chúng tôi đã hiểu ra giá trị -

Các cá nhân và tương tác qua các quy trình và công cụ.
Phần mềm làm việc trên tài liệu toàn diện.
Hợp tác với khách hàng trong quá trình đàm phán hợp đồng.
Đáp ứng sự thay đổi so với việc tuân theo một kế hoạch.

Có nghĩa là, trong khi có giá trị trong các mục ở bên phải, chúng ta đánh giá các mục ở bên trái nhiều hơn.

Kiểm thử Agile là gì?

Agile Testing là một thực hành kiểm thử phần mềm tuân theo các nguyên tắc phát triển phần mềm nhanh.

Kiểm thử Agile liên quan đến tất cả các thành viên của nhóm dự án, với chuyên môn đặc biệt do người kiểm thử đóng góp. Kiểm thử không phải là một giai đoạn riêng biệt và được đan xen với tất cả các giai đoạn phát triển như yêu cầu, thiết kế và mã hóa và tạo trường hợp thử nghiệm. Thử nghiệm diễn ra đồng thời thông qua Vòng đời phát triển.

Hơn nữa, với việc người kiểm thử tham gia vào toàn bộ Vòng đời phát triển cùng với các thành viên nhóm chức năng chéo, sự đóng góp của người kiểm thử trong việc xây dựng phần mềm theo yêu cầu của khách hàng, với thiết kế và mã tốt hơn sẽ trở nên khả thi.

Kiểm thử Agile bao gồm tất cả các cấp độ kiểm thử và tất cả các loại kiểm thử.

Thử nghiệm Agile Vs. Thử nghiệm thác nước

Trong phương pháp luận Phát triển thác nước, các hoạt động của Vòng đời phát triển xảy ra theo các giai đoạn tuần tự. Do đó, thử nghiệm là một giai đoạn riêng biệt và chỉ được bắt đầu sau khi hoàn thành giai đoạn phát triển.

Sau đây là những điểm nổi bật về sự khác biệt giữa Thử nghiệm Agile và Thử nghiệm thác nước -

Kiểm tra nhanh	Thử nghiệm thác nước
Kiểm tra không phải là một giai đoạn riêng biệt và diễn ra đồng thời với sự phát triển.	Kiểm tra là một giai đoạn riêng biệt. Tất cả các cấp độ và loại thử nghiệm chỉ có thể bắt đầu sau khi hoàn thành quá trình phát triển.
Người kiểm tra và nhà phát triển làm việc cùng nhau.	Người kiểm tra làm việc riêng biệt với các nhà phát triển.
Người kiểm tra tham gia vào việc đưa ra các yêu cầu. Điều này giúp ánh xạ các yêu cầu đến các hành vi trong kịch bản thế giới thực và cũng tạo khung các tiêu chí chấp nhận. Ngoài ra, các Trường hợp Kiểm tra Chấp nhận hợp lý sẽ sẵn sàng cùng với các yêu cầu.	Người kiểm tra có thể không tham gia vào giai đoạn yêu cầu.
Kiểm tra chấp nhận được thực hiện sau mỗi lần lặp lại và phản hồi của khách hàng được tìm kiếm.	Kiểm tra chấp nhận chỉ được thực hiện khi kết thúc dự án.
Mỗi lần lặp đều hoàn thành thử nghiệm của chính nó, do đó cho phép kiểm thử hồi quy được thực hiện mỗi khi các chức năng hoặc logic mới được phát hành.	Kiểm thử hồi quy chỉ có thể được thực hiện sau khi hoàn thành quá trình phát triển.
Không có thời gian chậm trễ giữa mã hóa và thử nghiệm.	Thời gian chậm trễ thông thường giữa mã hóa và thử nghiệm.
Thử nghiệm liên tục với các mức thử nghiệm chồng chéo.	Kiểm tra là một hoạt động có tính thời gian và các cấp độ kiểm tra không được trùng lặp.
Kiểm tra là một thực hành tốt nhất.	Kiểm tra thường bị bỏ qua.

Nguyên tắc thử nghiệm Agile

Các nguyên tắc của kiểm thử Agile là -

Testing moves the project forward- Kiểm tra liên tục là cách duy nhất để đảm bảo tiến độ liên tục. Thử nghiệm Agile cung cấp phản hồi liên tục và sản phẩm cuối cùng đáp ứng nhu cầu kinh doanh.
Testing is not a phase- Các bài kiểm tra nhóm Agile cùng với nhóm phát triển để đảm bảo rằng các tính năng được triển khai trong một lần lặp nhất định được thực hiện. Thử nghiệm không được giữ cho giai đoạn sau.
Everyone tests- Trong thử nghiệm nhanh, toàn bộ nhóm bao gồm các nhà phân tích, nhà phát triển và người kiểm tra sẽ kiểm tra ứng dụng. Sau mỗi lần lặp lại, ngay cả khách hàng cũng thực hiện Kiểm tra sự chấp nhận của người dùng.
Shortening Feedback Loops- Trong Thử nghiệm Agile, nhóm kinh doanh biết được sự phát triển sản phẩm cho mỗi lần lặp lại. Chúng tham gia vào mọi lần lặp lại. Phản hồi liên tục rút ngắn thời gian phản hồi phản hồi và do đó chi phí liên quan đến việc sửa chữa nó ít hơn.
Keep the Code Clean- Các khuyết tật được sửa chữa khi chúng được nâng lên trong cùng một lần lặp lại. Điều này đảm bảo mã sạch ở bất kỳ mốc phát triển nào.
Lightweight Documentation - Thay vì tài liệu kiểm tra toàn diện, người kiểm tra Agile -
- Sử dụng danh sách kiểm tra có thể tái sử dụng để đề xuất các bài kiểm tra.
- Tập trung vào bản chất của bài kiểm tra hơn là các chi tiết ngẫu nhiên.
- Sử dụng các kiểu / công cụ tài liệu nhẹ.
- Nắm bắt các ý tưởng thử nghiệm trong biểu đồ để thử nghiệm khám phá.
- Tận dụng tài liệu cho nhiều mục đích.
Leveraging one test artifact for manual and automated tests- Có thể sử dụng cùng một cấu phần tập lệnh thử nghiệm để thử nghiệm thủ công và làm đầu vào cho các thử nghiệm tự động. Điều này loại bỏ yêu cầu của Tài liệu kiểm tra thủ công và sau đó là Tập lệnh kiểm tra tự động hóa tương đương.
“Done Done,” not just done - Trong Agile, một tính năng được cho là không phải được thực hiện sau khi phát triển mà là sau khi phát triển và thử nghiệm.
Test-Last vs. Test Driven- Các trường hợp kiểm thử được viết cùng với các yêu cầu. Do đó, sự phát triển có thể được thúc đẩy bởi thử nghiệm. Cách tiếp cận này được gọi là Phát triển theo hướng kiểm tra (TDD) và Phát triển theo hướng kiểm tra chấp nhận (ATDD). Điều này trái ngược với thử nghiệm là giai đoạn cuối cùng trong Thử nghiệm thác nước.

Hoạt động thử nghiệm Agile

Các Hoạt động Kiểm tra Agile ở Cấp độ Dự án là -

Lập kế hoạch phát hành (Kế hoạch thử nghiệm)
- Đối với mỗi Lặp lại,
- Hoạt động kiểm tra nhanh trong quá trình lặp lại
Kiểm tra hồi quy
Hoạt động phát hành (Liên quan đến thử nghiệm)

Các Hoạt động Kiểm tra Agile trong một lần lặp lại bao gồm:

Tham gia lập kế hoạch lặp lại
Ước tính nhiệm vụ từ quan điểm thử nghiệm
Viết các trường hợp thử nghiệm bằng cách sử dụng mô tả tính năng
Kiểm tra đơn vị
Thử nghiệm hội nhập
Kiểm tra tính năng
Sửa lỗi
Thử nghiệm hội nhập
Kiểm tra chấp nhận
Báo cáo Tình trạng về Tiến độ Kiểm tra
Theo dõi khiếm khuyết

Agile là một phương pháp luận phát triển lặp đi lặp lại, trong đó toàn bộ nhóm dự án tham gia vào tất cả các hoạt động. Các yêu cầu phát triển khi quá trình lặp lại tiến triển, thông qua sự hợp tác giữa khách hàng và các nhóm tự tổ chức. Vì Mã hóa và Kiểm tra được thực hiện tương tác và gia tăng, trong quá trình phát triển, sản phẩm cuối cùng sẽ có chất lượng và đảm bảo các yêu cầu của khách hàng.

Mỗi lần lặp lại dẫn đến gia tăng sản phẩm hoạt động được tích hợp và được phân phối để Kiểm tra sự chấp nhận của người dùng. Do đó, phản hồi của khách hàng thu được sẽ là đầu vào cho các Lặp lại tiếp theo / tiếp theo.

Tích hợp liên tục, chất lượng liên tục

Tích hợp liên tục là chìa khóa thành công của Phát triển Agile. Tích hợp thường xuyên, ít nhất là hàng ngày để bạn sẵn sàng cho bản phát hành khi được yêu cầu. Thử nghiệm trong Agile trở thành một thành phần thiết yếu của tất cả các giai đoạn phát triển, đảm bảo chất lượng liên tục của sản phẩm. Phản hồi liên tục từ mọi người tham gia vào dự án sẽ làm tăng thêm chất lượng của sản phẩm.

Trong Agile, giao tiếp được coi trọng hàng đầu và các yêu cầu của khách hàng sẽ được tiếp nhận khi cần thiết. Điều này mang lại sự hài lòng cho khách hàng rằng tất cả các yếu tố đầu vào được xem xét và sản phẩm chất lượng hoạt động có sẵn trong suốt quá trình phát triển.

phương pháp Agile

Có một số Phương pháp Agile hỗ trợ Phát triển Agile. Các phương pháp Agile bao gồm:

Scrum

Scrum là một phương pháp phát triển Agile nhấn mạnh vào cách tiếp cận lấy nhóm làm trung tâm. Nó ủng hộ sự tham gia của toàn bộ nhóm vào tất cả các hoạt động phát triển dự án.

XP

Lập trình eXtreme lấy khách hàng làm trung tâm và tập trung vào các yêu cầu thay đổi liên tục. Với các bản phát hành thường xuyên và phản hồi của khách hàng, sản phẩm cuối cùng sẽ có chất lượng đáp ứng các yêu cầu của khách hàng được làm rõ ràng hơn trong quá trình này.

Pha lê

Crystal dựa trên việc thuê tàu, giao hàng theo chu kỳ và đóng gói.

Thuê tàu bao gồm việc thành lập một nhóm phát triển, thực hiện phân tích tính khả thi sơ bộ, đạt được kế hoạch ban đầu và phương pháp phát triển.
Phân phối theo chu kỳ với hai hoặc nhiều chu kỳ phân phối tập trung vào giai đoạn phát triển và phân phối sản phẩm tích hợp cuối cùng.
Trong quá trình Kết thúc, việc triển khai vào môi trường người dùng, đánh giá và phản ánh sau triển khai được thực hiện.

FDD

Phát triển theo hướng tính năng (FDD) liên quan đến việc thiết kế và xây dựng các tính năng. Sự khác biệt giữa FDD và các Phương pháp phát triển Agile khác là các tính năng được phát triển theo từng giai đoạn ngắn và cụ thể riêng biệt.

DSDM

Phương pháp Phát triển Phần mềm Động (DSDM) dựa trên Phát triển Ứng dụng Nhanh (RAD) và phù hợp với Khung Agile. DSDM tập trung vào việc phân phối sản phẩm thường xuyên, thu hút sự tham gia tích cực của người dùng và trao quyền cho các nhóm để đưa ra quyết định nhanh chóng.

Phát triển phần mềm tinh gọn

Trong Phát triển Phần mềm Tinh gọn, trọng tâm là loại bỏ lãng phí và mang lại giá trị cho khách hàng. Điều này dẫn đến sự phát triển nhanh chóng và sản phẩm có giá trị.

Lãng phí bao gồm công việc đã hoàn thành một phần, công việc không liên quan, các tính năng không được khách hàng sử dụng, lỗi, v.v. làm tăng thêm sự chậm trễ trong giao hàng.

Các Lean Principles là -

Loại bỏ rác thải
Khuếch đại học tập
Cam kết trì hoãn
Trao quyền cho nhóm
Giao hàng nhanh
Xây dựng tính chính trực trong
Xem toàn bộ

Kanban

Kanban tập trung vào việc quản lý công việc với trọng tâm là giao hàng đúng lúc (JIT), đồng thời không gây quá tải cho các thành viên trong nhóm. Các nhiệm vụ được hiển thị cho tất cả những người tham gia xem và cho các Thành viên trong Nhóm thực hiện công việc từ một hàng đợi.

Kanban dựa trên -

Bảng Kanban (Trực quan và Kiên trì trong suốt quá trình phát triển)
Giới hạn công việc đang tiến hành (WIP)
Thời gian dẫn đầu

Các phương pháp kiểm tra Agile

Các thực hành thử nghiệm được xác định rõ ràng cho mọi dự án, dù Agile hay không, để cung cấp các sản phẩm chất lượng. Các nguyên tắc Kiểm thử truyền thống khá thường được sử dụng trong Kiểm thử Agile. Một trong số đó là Thử nghiệm sớm tập trung vào -

Viết các trường hợp kiểm thử để thể hiện hành vi của hệ thống.
Phòng ngừa, phát hiện và loại bỏ các khiếm khuyết sớm.
Đảm bảo rằng các loại thử nghiệm phù hợp được chạy vào đúng thời điểm và là một phần của cấp độ thử nghiệm phù hợp.

Trong tất cả các Phương pháp Agile mà chúng ta đã thảo luận, Thử nghiệm Agile tự nó là một Phương pháp. Trong tất cả các phương pháp, các trường hợp kiểm thử được viết trước khi mã hóa.

Trong hướng dẫn này, chúng tôi sẽ tập trung vào Scrum với tư cách là Phương pháp kiểm tra Agile.

Các phương pháp kiểm tra Agile thường được sử dụng khác là:

Test-Driven Development (TDD) - Phát triển theo hướng kiểm tra (TDD) dựa trên mã hóa được hướng dẫn bởi các bài kiểm tra.
Acceptance Test-Driven Development (ATDD) - Phát triển theo hướng kiểm tra chấp nhận (ATDD) dựa trên giao tiếp giữa khách hàng, nhà phát triển và người kiểm tra và được thúc đẩy bởi Tiêu chí chấp nhận được xác định trước và các trường hợp kiểm tra chấp nhận.
Behavior-Driven Development (BDD) - Trong quá trình phát triển theo hướng hành vi (BDD), thử nghiệm dựa trên hành vi mong đợi của phần mềm đang được phát triển.

Vòng đời thử nghiệm Agile

Trong Scrum, các hoạt động Kiểm tra bao gồm:

Đóng góp vào Câu chuyện của người dùng dựa trên hành vi dự kiến của Hệ thống được mô tả như Trường hợp thử nghiệm
Lập kế hoạch phát hành dựa trên nỗ lực kiểm tra và các khiếm khuyết
Lập kế hoạch Sprint dựa trên Câu chuyện của người dùng và những khiếm khuyết
Thực hiện Sprint với Kiểm tra Liên tục
Kiểm tra hồi quy sau khi hoàn thành Sprint
Báo cáo kết quả kiểm tra
Kiểm tra tự động hóa

Kiểm tra là lặp đi lặp lại và dựa trên chạy nước rút như được mô tả trong sơ đồ dưới đây -

Phát triển Agile lấy nhóm làm trung tâm và các nhà phát triển và người thử nghiệm tham gia vào tất cả các hoạt động phát triển và dự án. Làm việc theo nhóm tối đa hóa thành công của thử nghiệm trong các dự án Agile.

Một Tester trong nhóm Agile phải tham gia và đóng góp vào tất cả các hoạt động của dự án và đồng thời phải tận dụng kiến thức chuyên môn trong kiểm thử.

Một người kiểm thử Agile nên có các kỹ năng kiểm thử truyền thống. Ngoài ra, người thử nghiệm Agile cần -

Kỹ năng giao tiếp tốt.
Khả năng hành động tích cực và định hướng giải pháp với các thành viên trong nhóm và các bên liên quan.
Khả năng thể hiện tư duy phê phán, định hướng về chất lượng, hoài nghi về sản phẩm.
Có năng lực chủ động để chủ động tiếp thu thông tin từ các bên liên quan.
Kỹ năng làm việc hiệu quả với khách hàng và các bên liên quan trong việc xác định Câu chuyện người dùng có thể kiểm tra, Tiêu chí chấp nhận.
Tài năng để trở thành một thành viên tốt trong nhóm làm việc với các nhà phát triển trong việc tạo ra mã chất lượng.
Khả năng sử dụng các kỹ năng kiểm thử để có các trường hợp kiểm thử phù hợp vào đúng thời điểm và ở cấp độ phù hợp và thực thi chúng tốt trong thời gian của sprint.
Khả năng đánh giá và báo cáo kết quả thử nghiệm, tiến độ thử nghiệm và chất lượng sản phẩm.
Tính cởi mở để đáp ứng các thay đổi một cách nhanh chóng, bao gồm việc thay đổi, thêm hoặc cải thiện các trường hợp thử nghiệm.
Có khả năng tự tổ chức công việc.
Niềm đam mê để phát triển kỹ năng liên tục.
Năng lực về Tự động hóa kiểm tra, Phát triển theo hướng kiểm tra (TDD), Phát triển theo hướng kiểm tra chấp nhận (ATDD), Phát triển theo hướng hành vi (BDD) và Kiểm tra dựa trên kinh nghiệm.

Vai trò của Tester trong Nhóm Agile

Tester trong Nhóm Agile tham gia vào tất cả các dự án và hoạt động phát triển để đóng góp tốt nhất kiến thức chuyên môn về kiểm thử.

Các hoạt động của Agile Tester bao gồm -

Đảm bảo sử dụng đúng các công cụ kiểm tra.
Cấu hình, sử dụng và quản lý môi trường thử nghiệm và dữ liệu thử nghiệm.
Cố vấn các thành viên khác trong nhóm trong các khía cạnh liên quan của thử nghiệm.
Đảm bảo rằng các nhiệm vụ thử nghiệm thích hợp được lên lịch trong quá trình phát hành và lập kế hoạch chạy nước rút.
Hiểu, thực hiện và cập nhật chiến lược kiểm tra.
Hợp tác với các nhà phát triển, khách hàng và các bên liên quan để làm rõ các yêu cầu, về khả năng kiểm tra, tính nhất quán và tính hoàn chỉnh.
Thực hiện các bài kiểm tra đúng lúc và đúng mức độ kiểm tra.
Báo cáo các khiếm khuyết và làm việc với nhóm để giải quyết chúng.
Đo lường và báo cáo phạm vi kiểm tra trên tất cả các kích thước phạm vi áp dụng.
Tham gia vào các cuộc truy quét nước rút, chủ động đề xuất và thực hiện các cải tiến.

Trong Vòng đời Agile, người thử nghiệm đóng một vai trò quan trọng trong:

Teamwork
Lập kế hoạch kiểm tra
Sprint Zero
Integration
Thực hành thử nghiệm Agile

Làm việc theo nhóm

Trong Phát triển Agile, làm việc theo nhóm là cơ bản và do đó yêu cầu những điều sau:

Collaborative Approach- Làm việc với các thành viên trong nhóm đa chức năng về Chiến lược Kiểm thử, Lập kế hoạch Kiểm tra, Đặc 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. Đóng góp kiến thức chuyên môn về thử nghiệm kết hợp với các hoạt động khác của nhóm.
Self-organizing - Lập kế hoạch và tổ chức tốt trong các chặng đua để đạt được mục tiêu của bài kiểm tra bằng cách kết hợp chuyên môn từ các thành viên khác trong nhóm.
Empowerment - Đưa ra các quyết định kỹ thuật thích hợp trong việc đạt được các mục tiêu của nhóm.
Commitment - Cam kết hiểu và đánh giá hành vi và đặc tính của sản phẩm theo yêu cầu của khách hàng và các bên liên quan.
Transparent - Cởi mở, giao tiếp và có trách nhiệm.
Credibility- Đảm bảo độ tin cậy của chiến lược kiểm tra, việc triển khai và thực thi. Thông báo cho khách hàng và các bên liên quan về chiến lược thử nghiệm.
Open to Feedback- Tham gia các cuộc hồi tưởng nước rút để học hỏi từ cả thành công và thất bại. Tìm kiếm phản hồi của khách hàng và hành động nhanh chóng và phù hợp để đảm bảo chất lượng cung cấp.
Resilient - Đáp ứng những thay đổi.

Lập kế hoạch kiểm tra

Lập kế hoạch kiểm tra nên bắt đầu trong quá trình lập kế hoạch phát hành và cập nhật trong mỗi sprint. Lập kế hoạch kiểm tra cần bao gồm các nhiệm vụ sau:

Xác định phạm vi kiểm tra, mức độ kiểm tra, mục tiêu kiểm tra và chạy nước rút.
Quyết định về môi trường thử nghiệm, công cụ thử nghiệm, dữ liệu thử nghiệm và cấu hình.
Phân công kiểm tra các tính năng và đặc điểm.
Lập lịch các nhiệm vụ kiểm tra và xác định tần suất kiểm tra.
Xác định phương pháp kiểm tra, kỹ thuật, công cụ và dữ liệu kiểm tra.
Xác định các điều kiện tiên quyết như nhiệm vụ tiền nhiệm, chuyên môn và đào tạo.
Xác định các yếu tố phụ thuộc như chức năng, mã, thành phần hệ thống, nhà cung cấp, công nghệ, công cụ, hoạt động, nhiệm vụ, nhóm, loại thử nghiệm, mức thử nghiệm và các ràng buộc.
Đặt ưu tiên xem xét tầm quan trọng và phụ thuộc của khách hàng / người dùng.
Đến khoảng thời gian và nỗ lực cần thiết để kiểm tra.
Xác định các nhiệm vụ tại mỗi kế hoạch sprint.

Sprint Zero

Sprint Zero liên quan đến các hoạt động chuẩn bị trước khi chạy nước rút đầu tiên. Người kiểm tra cần cộng tác với nhóm về các hoạt động sau:

Xác định phạm vi
Chia các câu chuyện của người dùng thành các lần chạy nước rút
Tạo kiến trúc hệ thống
Lập kế hoạch, mua và cài đặt các công cụ (bao gồm cả các công cụ kiểm tra)
Tạo chiến lược thử nghiệm ban đầu cho tất cả các cấp độ thử nghiệm
Xác định các chỉ số kiểm tra
Chỉ định các tiêu chí chấp nhận, còn được gọi là định nghĩa về “Hoàn thành”
Xác định tiêu chí thoát
Tạo bảng Scrum
Đặt hướng kiểm tra trong suốt chặng nước rút

Hội nhập

Trong Agile, một sản phẩm hoạt động có chất lượng phải sẵn sàng để phát hành vào bất kỳ thời điểm nào trong vòng đời phát triển. Điều này ngụ ý hội nhập liên tục như một phần của sự phát triển. Một người thử nghiệm Agile cần hỗ trợ tích hợp liên tục với thử nghiệm liên tục.

Để thực hiện điều này, người kiểm tra cần phải -

Hiểu chiến lược tích hợp.
Xác định tất cả các phụ thuộc giữa các chức năng và tính năng.

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

Một người kiểm thử Agile cần phải thích ứng với các thực hành Agile để kiểm tra trong một dự án nhanh.

Pairing- Hai thành viên trong nhóm cùng làm việc trên cùng một bàn phím. Khi một trong số họ kiểm tra, phần còn lại đánh giá / phân tích thử nghiệm. Hai thành viên trong nhóm có thể
- Một người thử nghiệm và một nhà phát triển
- Một người thử nghiệm và một nhà phân tích kinh doanh
- Hai người thử nghiệm
Incremental Test Design - Các trường hợp kiểm thử được xây dựng từ các câu chuyện của người dùng, bắt đầu với các bài kiểm tra đơn giản và chuyển sang các bài kiểm tra phức tạp hơn.
Mind Mapping- Sơ đồ tư duy là một sơ đồ để tổ chức thông tin một cách trực quan. Bản đồ tư duy có thể được sử dụng như một công cụ hiệu quả trong thử nghiệm Agile, sử dụng thông tin nào liên quan đến các phiên kiểm tra cần thiết, chiến lược kiểm tra và dữ liệu kiểm tra có thể được tổ chức.

Trạng thái kiểm tra có thể được thông báo -

Trong các cuộc họp đứng hàng ngày
Sử dụng các công cụ quản lý kiểm tra tiêu chuẩn
Qua sứ giả

Trạng thái kiểm tra được xác định bởi trạng thái vượt qua kiểm tra là rất quan trọng trong việc quyết định xem nhiệm vụ có "Hoàn thành" hay không. Hoàn thành có nghĩa là tất cả các bài kiểm tra cho nhiệm vụ vượt qua.

Tiến độ kiểm tra

Tiến trình kiểm tra có thể được theo dõi bằng cách sử dụng -

Scrum Boards (Ban Nhiệm vụ Agile)
Biểu đồ Burndown
Kết quả kiểm tra tự động

Tiến độ kiểm tra cũng có ảnh hưởng trực tiếp đến tiến độ phát triển. Điều này là do một Câu chuyện người dùng có thể được chuyển đếnDonetrạng thái chỉ sau khi đạt được Tiêu chí chấp nhận. Đến lượt nó, điều này được quyết định bởi Trạng thái kiểm tra vì Tiêu chí chấp nhận được đánh giá bởi Trạng thái kiểm tra.

Nếu có bất kỳ sự chậm trễ hoặc tắc nghẽn nào trong quá trình kiểm tra, toàn bộ nhóm sẽ thảo luận và làm việc cộng tác để giải quyết cùng một giải pháp.

Trong các Dự án Agile, các thay đổi diễn ra khá thường xuyên. Khi nhiều thay đổi diễn ra, chúng ta có thể mong đợi rằng Trạng thái thử nghiệm, Tiến độ thử nghiệm và Chất lượng sản phẩm sẽ không ngừng phát triển. Người kiểm tra Agile cần đưa thông tin đó đến nhóm để có thể đưa ra các quyết định thích hợp vào đúng thời điểm nhằm hoàn thành thành công mỗi lần lặp.

Khi các thay đổi xảy ra, chúng có thể ảnh hưởng đến các tính năng hiện có từ các lần lặp trước. Trong những trường hợp như vậy, các thử nghiệm thủ công và tự động phải được cập nhật để đối phó hiệu quả với rủi ro hồi quy. Kiểm tra hồi quy cũng cần thiết.

Chất lượng sản phẩm

Chỉ số Chất lượng Sản phẩm bao gồm -

Kiểm tra Đạt / Không đạt
Đã tìm thấy / sửa lỗi khiếm khuyết
Kiểm tra vùng phủ sóng
Tỷ lệ vượt qua kiểm tra / thất bại
Tỷ lệ phát hiện khiếm khuyết
Mật độ khuyết tật

Tự động hóa việc thu thập và báo cáo các chỉ số chất lượng sản phẩm giúp -

Duy trì sự minh bạch.
Thu thập tất cả các chỉ số phù hợp và cần thiết vào đúng thời điểm.
Báo cáo ngay lập tức mà không có sự chậm trễ liên lạc.
Cho phép người thử nghiệm tập trung vào thử nghiệm.
Lọc việc sử dụng sai số liệu.

Để đảm bảo chất lượng sản phẩm tổng thể, nhóm Agile cần thu thập phản hồi của khách hàng về việc sản phẩm có đáp ứng được kỳ vọng của khách hàng hay không. Điều này cần được thực hiện ở cuối mỗi lần lặp và phản hồi sẽ là đầu vào cho các lần lặp tiếp theo.

Các yếu tố để thành công

Trong các dự án Agile, các sản phẩm chất lượng có thể được chuyển giao nếu thử nghiệm Agile thành công.

Các điểm sau đây cần được xem xét để thành công của thử nghiệm Agile:

Thử nghiệm Agile dựa trên các phương pháp tiếp cận thử nghiệm đầu tiên và thử nghiệm liên tục. Do đó, các công cụ kiểm tra truyền thống, được xây dựng trên phương pháp kiểm tra cuối cùng, có thể không phù hợp. Do đó, trong khi lựa chọn Công cụ kiểm tra trong các dự án Agile, cần phải xác minh sự phù hợp với kiểm thử Agile.
Giảm tổng thời gian thử nghiệm bằng cách tự động hóa các thử nghiệm sớm hơn trong vòng đời phát triển.
Người kiểm thử Agile cần phải duy trì tốc độ của họ để phù hợp với lịch trình phát hành phát triển. Do đó, việc lập kế hoạch, theo dõi và tái lập kế hoạch thích hợp cho các hoạt động thử nghiệm cần phải được thực hiện nhanh chóng với chất lượng sản phẩm là mục tiêu.
Kiểm thử thủ công chiếm tới 80% kiểm thử trong các dự án. Do đó, những người thử nghiệm có chuyên môn cần phải là một phần của nhóm Agile.
Sự tham gia của những người kiểm tra có chuyên môn trong suốt vòng đời phát triển khiến toàn bộ nhóm tập trung vào sản phẩm chất lượng đáp ứng mong đợi của khách hàng.
- Xác định câu chuyện của người dùng nhấn mạnh hành vi của sản phẩm mà người dùng cuối mong đợi.
- Xác định Tiêu chí chấp nhận ở cấp câu chuyện của người dùng / cấp độ nhiệm vụ theo mong đợi của khách hàng.
- Ước tính nỗ lực và thời gian cho các hoạt động thử nghiệm.
- Lập kế hoạch hoạt động thử nghiệm.
- Liên kết với nhóm phát triển để đảm bảo sản xuất mã đáp ứng các yêu cầu với thiết kế thử nghiệm trả trước.
- Thử nghiệm đầu tiên và thử nghiệm liên tục để đảm bảo rằng trạng thái đã hoàn thành đạt được các tiêu chí chấp nhận tại thời điểm dự kiến.
- Đảm bảo thử nghiệm ở tất cả các cấp độ trong sprint.
- Kiểm tra hồi quy vào cuối mỗi sprint.
- Thu thập và phân tích các chỉ số sản phẩm hữu ích cho sự thành công của dự án.
- Phân tích các khiếm khuyết để xác định những khiếm khuyết cần được khắc phục trong Sprint hiện tại và những khiếm khuyết có thể bị trì hoãn trong Sprint tiếp theo.
- Tập trung vào những gì quan trọng theo quan điểm của Khách hàng.

Lisa Crispin đã xác định bảy yếu tố chính để thành công trong thử nghiệm Agile -

Whole Team approach- Trong cách tiếp cận này, các nhà phát triển đào tạo người thử nghiệm và người thử nghiệm đào tạo các thành viên khác trong nhóm. Điều này giúp mọi người hiểu rõ mọi nhiệm vụ trong dự án, từ đó sự hợp tác và đóng góp sẽ mang lại lợi ích tối đa. Sự hợp tác của người kiểm tra với khách hàng cũng là một yếu tố quan trọng để đặt kỳ vọng của họ ngay từ đầu và chuyển các tiêu chí chấp nhận sang yêu cầu để vượt qua kiểm tra.
Agile Testing Mindset - Người kiểm tra chủ động liên tục cải tiến chất lượng và cộng tác liên tục với những người còn lại trong nhóm.
Automate Regression Testing- Thiết kế cho khả năng kiểm tra và phát triển ổ đĩa với các bài kiểm tra. Bắt đầu đơn giản và cho phép nhóm lựa chọn các công cụ. Sẵn sàng cung cấp lời khuyên.
Provide and Obtain Feedback- Vì đây là giá trị Agile cốt lõi, nên toàn bộ nhóm phải cởi mở để nhận phản hồi. Vì những người kiểm tra là những người cung cấp phản hồi từ chuyên gia, cần tập trung vào những thông tin cần thiết và có liên quan. Đổi lại, việc thu thập thông tin phản hồi phải phù hợp với các thay đổi và thử nghiệm trường hợp thử nghiệm.
Build a Foundation of Core Agile Practices - Tập trung vào thử nghiệm cùng với mã hóa, tích hợp liên tục, môi trường thử nghiệm cộng tác, làm việc gia tăng, chấp nhận các thay đổi, duy trì sức mạnh tổng hợp.
Collaborate with Customers - Lấy ví dụ, sự hiểu biết và kiểm tra các yêu cầu ánh xạ đến hành vi của sản phẩm, thiết lập Tiêu chí chấp nhận, thu thập phản hồi.
Look at the Big Picture - Thúc đẩy sự phát triển với các thử nghiệm và ví dụ đối mặt với doanh nghiệp bằng cách sử dụng dữ liệu thử nghiệm trong thế giới thực và suy nghĩ về tác động đối với các lĩnh vực khác.

Trong chương này, chúng ta sẽ thấy một số thuộc tính quan trọng của Kiểm thử Agile.

Lợi ích của Thử nghiệm Agile

Các lợi ích của thử nghiệm Agile là -

Làm hài lòng khách hàng bởi sản phẩm được thử nghiệm hoàn toàn nhanh chóng, liên tục và tìm kiếm phản hồi của khách hàng
Khách hàng, nhà phát triển và người thử nghiệm liên tục tương tác với nhau, do đó giảm thời gian chu kỳ.
Người kiểm thử Agile tham gia vào việc xác định các yêu cầu đóng góp kiến thức chuyên môn về kiểm thử của họ để tập trung vào những gì có thể làm được.
Người kiểm thử nhanh nhẹn tham gia vào việc ước tính đánh giá nỗ lực và thời gian kiểm tra.
Thiết kế thử nghiệm ban đầu phản ánh Tiêu chí chấp nhận.
Yêu cầu kiểm tra được cả nhóm hợp nhất, tránh những mặt hạn chế.
Toàn bộ đội luôn tập trung vào chất lượng sản phẩm.
Định nghĩa của Done kiểm tra phản ánh trạng thái vượt qua đảm bảo rằng yêu cầu được đáp ứng.
Phản hồi liên tục về sự chậm trễ hoặc tắc nghẽn để có thể đưa ra giải pháp ngay lập tức với nỗ lực của cả nhóm.
Đáp ứng nhanh chóng các yêu cầu thay đổi và sớm đáp ứng.
Kiểm tra hồi quy theo hướng tích hợp liên tục.
Không có thời gian chậm trễ giữa phát triển và thử nghiệm. thử nghiệm đầu tiên, các phương pháp tiếp cận thử nghiệm liên tục được tuân theo.
Kiểm thử tự động được triển khai sớm trong vòng đời phát triển, do đó giảm tổng thời gian và công sức kiểm tra.

Các phương pháp hay nhất trong thử nghiệm Agile

Thực hiện theo các phương pháp hay nhất được cung cấp bên dưới -

Bao gồm các kiểm tra viên có chuyên môn trong tất cả các loại kiểm tra ở tất cả các cấp.
Người thử nghiệm tham gia vào việc xác định các yêu cầu, cộng tác với khách hàng về hành vi mong đợi của sản phẩm.
Người kiểm tra chia sẻ phản hồi liên tục với nhà phát triển và khách hàng.
Thử nghiệm các phương pháp tiếp cận thử nghiệm đầu tiên và liên tục để phù hợp với công việc phát triển.
Theo dõi tình trạng kiểm tra và tiến độ kiểm tra nhanh chóng và liên tục, tập trung vào việc cung cấp sản phẩm chất lượng.
Kiểm tra tự động hóa sớm trong vòng đời phát triển để giảm thời gian chu kỳ.
Để thực hiện Kiểm tra hồi quy, hãy sử dụng Kiểm tra tự động hóa như một cách hiệu quả.

Những thách thức trong thử nghiệm Agile

Những thách thức sau đây tồn tại trong thử nghiệm Agile:

Việc không hiểu cách tiếp cận Agile và những hạn chế của nó bởi Doanh nghiệp và Ban quản lý có thể dẫn đến những kỳ vọng không thể đạt được.
Agile tuân theo cách tiếp cận toàn nhóm, nhưng không phải ai cũng biết những điều cơ bản của Thực hành kiểm tra. Người kiểm tra được khuyên nên huấn luyện những người khác, nhưng trong kịch bản thực tế có thể không khả thi với Chạy nước rút trong hộp thời gian (Lặp lại).
Phương pháp tiếp cận thử nghiệm đầu tiên yêu cầu Nhà phát triển dựa trên việc viết mã dựa trên Phản hồi của người kiểm tra, nhưng trong các tình huống thực tế, Nhà phát triển quen với việc viết mã dựa trên Yêu cầu từ Khách hàng hoặc Doanh nghiệp.
Trách nhiệm giải trình đối với Sản phẩm chất lượng là với toàn bộ Nhóm Agile, nhưng trong giai đoạn đầu, các Nhà phát triển có thể không tập trung vào Chất lượng vì họ đang chú trọng hơn vào chế độ triển khai.
Tích hợp liên tục yêu cầu Kiểm tra hồi quy đòi hỏi nỗ lực đáng kể, ngay cả khi nó phải được tự động hóa.
Người kiểm tra có thể thích nghi với những thay đổi với tư duy Agile, nhưng việc đáp ứng các Thay đổi và Kiểm tra kết quả có thể không khả thi để đạt được mục tiêu hoàn thành trong Sprint.
Nên tự động hóa sớm để có thể giảm Nỗ lực và Thời gian Kiểm tra Thủ công. Tuy nhiên, trong kịch bản thực tế, việc đạt được các Bài kiểm tra có thể tự động hóa và tự động hóa chúng đòi hỏi thời gian và nỗ lực.

Nguyên tắc Kiểm tra Agile

Sử dụng các nguyên tắc sau khi thực hiện Kiểm tra Agile.

Tham gia vào Lập kế hoạch phát hành để xác định các hoạt động Thử nghiệm được yêu cầu và đưa ra phiên bản ban đầu của kế hoạch thử nghiệm.
Tham gia vào phiên ước tính để đạt được nỗ lực và thời lượng thử nghiệm để các hoạt động thử nghiệm được điều chỉnh trong các lần lặp lại.
Tham gia vào Định nghĩa Câu chuyện Người dùng để đến các Trường hợp Kiểm tra Chấp nhận.
Tham gia mọi Cuộc họp Lập kế hoạch Sprint để hiểu phạm vi và cập nhật Kế hoạch Kiểm tra.
Liên tục cộng tác với Nhóm phát triển trong Sprint để giúp cho việc Kiểm tra và Mã hóa thành công tốt đẹp trong Sprint.
Tham gia vào các cuộc họp độc lập hàng ngày và truyền đạt sự chậm trễ hoặc tắc nghẽn của thử nghiệm nếu có, để nhận được giải pháp ngay lập tức.
Theo dõi và báo cáo tình trạng kiểm tra, tiến độ kiểm tra và chất lượng sản phẩm thường xuyên.
Sẵn sàng thích ứng với các thay đổi, đáp ứng với các sửa đổi đối với Trường hợp thử nghiệm, Dữ liệu thử nghiệm.
Tham gia vào Sprint Retrospectives để hiểu và đóng góp các phương pháp hay nhất và bài học kinh nghiệm.
Cộng tác để lấy Phản hồi của Khách hàng tại mỗi Sprint.

Như trong trường hợp Kiểm thử truyền thống, Kiểm thử Agile cũng cần bao gồm tất cả các Cấp độ Kiểm thử.

Kiểm tra đơn vị
Thử nghiệm hội nhập
Thử nghiệm hệ thống
Kiểm tra sự chấp nhận của người dùng

Kiểm tra đơn vị

Được thực hiện cùng với Mã hóa, bởi Nhà phát triển
Được hỗ trợ bởi Tester, người viết các trường hợp kiểm thử đảm bảo 100% phạm vi thiết kế
Các trường hợp kiểm thử đơn vị và kết quả kiểm thử đơn vị cần được xem xét
Các khuyết tật lớn chưa được giải quyết (theo mức độ ưu tiên và mức độ nghiêm trọng) không được để lại
Tất cả các bài kiểm tra đơn vị đều được tự động hóa

Thử nghiệm hội nhập

Được thực hiện cùng với Tích hợp liên tục khi Sprint tiến triển
Hoàn thành ở cuối sau khi tất cả các Sprint đã hoàn thành
Tất cả các yêu cầu chức năng đều được kiểm tra
Tất cả các Giao diện giữa các Đơn vị đều được kiểm tra
Tất cả các khiếm khuyết được báo cáo
Kiểm tra được tự động nếu có thể

Thử nghiệm hệ thống

Hoàn thành khi Quá trình phát triển tiến triển
Câu chuyện, Tính năng và Chức năng của Người dùng đã được Kiểm tra
Thử nghiệm được thực hiện trong Môi trường Sản xuất
Kiểm tra chất lượng được thực hiện (Hiệu suất, Độ tin cậy, v.v.)
Các khiếm khuyết được báo cáo
Kiểm tra được tự động nếu có thể

Kiểm tra sự chấp nhận của người dùng

Được thực hiện vào cuối mỗi Sprint và khi kết thúc dự án
Do Khách hàng thực hiện. Phản hồi được thực hiện bởi Nhóm
Phản hồi sẽ là đầu vào cho Sprint tiếp theo
Câu chuyện của người dùng trong Sprint được xác minh trước để có thể kiểm tra và tuân theo Tiêu chí chấp nhận đã xác định

Các loại kiểm tra

Kiểm tra thành phần (Kiểm tra đơn vị)
Kiểm tra chức năng (Kiểm tra câu chuyện của người dùng)
Kiểm tra phi chức năng (Hiệu suất, Tải, Căng thẳng, v.v.)
Kiểm tra chấp nhận

Các bài kiểm tra có thể hoàn toàn bằng tay, hoàn toàn tự động, kết hợp giữa thủ công và tự động hoặc được hỗ trợ bởi các công cụ.

Hỗ trợ lập trình và thử nghiệm sản phẩm phê bình

Các bài kiểm tra có thể dành cho -

Supporting Development (Support Programming) - Hỗ trợ các bài kiểm tra lập trình được sử dụng bởi các lập trình viên.
- Để quyết định mã nào họ cần viết để thực hiện một hành vi nhất định của Hệ thống
- Những Kiểm tra nào cần được chạy sau khi Mã hóa để đảm bảo Mã mới không cản trở các hoạt động còn lại của Hệ thống
Verification only (Critique Product) - Thử nghiệm Sản phẩm Phê bình được sử dụng để phát hiện ra những điểm không phù hợp trong Thành phẩm

Thử nghiệm đối mặt với doanh nghiệp và đối mặt với công nghệ

Để quyết định những bài kiểm tra sẽ được thực hiện khi nào, bạn cần xác định liệu một bài kiểm tra có -

Đối mặt với Doanh nghiệp, hoặc
Đối mặt với công nghệ

Thử nghiệm đối mặt với kinh doanh

Bài kiểm tra là bài kiểm tra đối mặt với doanh nghiệp nếu nó trả lời các câu hỏi được đóng khung bằng các từ trong lĩnh vực kinh doanh. Những điều này được các chuyên gia kinh doanh hiểu và sẽ quan tâm đến họ để hành vi của hệ thống có thể được giải thích trong kịch bản thời gian thực.

Thử nghiệm đối mặt với công nghệ

Bài kiểm tra là bài kiểm tra đối mặt với công nghệ nếu nó trả lời các câu hỏi được đóng khung bằng các từ thuộc lĩnh vực công nghệ. Các lập trình viên hiểu những gì cần phải được thực hiện dựa trên những giải thích về công nghệ.

Hai khía cạnh này của các loại thử nghiệm có thể được xem bằng cách sử dụng Phần tư Thử nghiệm Agile do Brian Marick xác định.

Phần tư thử nghiệm Agile

Kết hợp hai khía cạnh của Các loại thử nghiệm, Phần tư Thử nghiệm Agile sau đây được đúc kết bởi Brian Marick:

Bộ tư thử nghiệm Agile cung cấp phân loại hữu ích để giúp các nhóm xác định, lập kế hoạch và thực hiện thử nghiệm cần thiết.

Quadrant Q1- Cấp độ Đơn vị, Đối mặt với Công nghệ và hỗ trợ các nhà phát triển. Các bài kiểm tra đơn vị thuộc về Góc phần tư này. Các bài kiểm tra này có thể là các bài kiểm tra Tự động.
Quadrant Q2- Cấp độ hệ thống, đối mặt kinh doanh và hành vi sản phẩm phù hợp. Kiểm tra chức năng thuộc về góc phần tư này. Các bài kiểm tra này là thủ công hoặc tự động.
Quadrant Q3- Mức độ chấp nhận của hệ thống hoặc người dùng, Đối mặt kinh doanh và tập trung vào các tình huống thời gian thực. Kiểm tra sự chấp nhận của người dùng thuộc về góc phần tư này. Các bài kiểm tra này là thủ công.
Quadrant Q4- Mức độ chấp nhận hệ thống hoặc hoạt động, đối mặt với công nghệ và tập trung vào hiệu suất, tải, căng thẳng, khả năng bảo trì, kiểm tra khả năng mở rộng. Các công cụ đặc biệt có thể được sử dụng cho các thử nghiệm này cùng với thử nghiệm tự động hóa.

Kết hợp những điều này, Phần tư Thử nghiệm Agile phản ánh What-Testing-When có thể hình dung như sau:

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 được giao của dự án. 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 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 được hệ thống trong môi trường thực và do đó hiểu rõ về kết quả thực sự họ muốn là gì. Đ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 các 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à mang lại giá trị kinh doanh cho khách hàng. Nhóm quyết định về độ dài sprint với việc 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 cách 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 người dùng chọn 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 chung 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 kỳ 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 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 vào 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 tiễn 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 là 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ác 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 (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 nhiều hơn, điều đó có nghĩa là Nhóm đã thực hiện nhiều Công việc hơn những gì họ có thể làm.
- Nếu nó nhỏ hơn, thì có nghĩa là Nhóm nghiên cứu đã không ước tính chính xác.
Defect Count- Số lượng khuyết tật 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.
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

Trong Kiểm thử Agile, các phương pháp Kiểm thử thường được sử dụng là từ các phương pháp truyền thống và phù hợp với nguyên tắc - Kiểm tra sớm. Các Trường hợp Kiểm tra được viết trước khi viết mã. Trọng tâm là phòng ngừa, phát hiện và loại bỏ khiếm khuyết chạy đúng loại thử nghiệm vào đúng thời điểm và ở cấp độ phù hợp.

Trong chương này, bạn sẽ hiểu về các phương pháp -

Phát triển theo hướng kiểm tra (TDD)
Phát triển theo hướng kiểm tra chấp nhận (ATDD)
Phát triển theo hướng hành vi (BDD)

Hướng phát triển thử nghiệm

Trong phương pháp Phát triển theo hướng kiểm tra (TDD), mã được phát triển dựa trên cách tiếp cận Testfirst do các Trường hợp kiểm thử tự động hướng dẫn. Một trường hợp thử nghiệm được viết trước để thất bại, mã được phát triển dựa trên đó để đảm bảo rằng thử nghiệm vượt qua. Phương pháp được lặp lại, việc tái cấu trúc được thực hiện thông qua sự phát triển của mã.

TDD có thể được hiểu với sự trợ giúp của các bước sau:

Step 1 - Viết một trường hợp thử nghiệm để phản ánh hành vi mong đợi của chức năng của mã cần được viết.
Step 2- Chạy thử nghiệm. Kiểm tra không thành công vì mã vẫn chưa được phát triển.
Step 3 - Phát triển mã dựa trên trường hợp thử nghiệm.
Step 4- Chạy thử lại. Lần này, bài kiểm tra phải vượt qua khi chức năng được mã hóa. Lặp lại Bước (3) và Bước (4) cho đến khi kiểm tra vượt qua.
Step 5 - Cấu trúc lại mã.
Step 6 - Chạy kiểm tra lại để đảm bảo nó vượt qua.

Nói lại Step 1 – Step 6thêm các trường hợp thử nghiệm để thêm chức năng. Các bài kiểm tra đã thêm và các bài kiểm tra trước đó được chạy mọi lúc để đảm bảo mã đang chạy như mong đợi. Để làm cho quá trình này diễn ra nhanh chóng, các bài kiểm tra được tự động hóa.

Các bài kiểm tra có thể ở cấp độ đơn vị, tích hợp hoặc hệ thống. Cần đảm bảo giao tiếp liên tục giữa người thử nghiệm và nhà phát triển.

Kiểm tra chấp nhận Phát triển theo hướng

Trong phương pháp Phát triển theo hướng kiểm tra chấp nhận (ATDD), mã được phát triển dựa trên cách tiếp cận thử nghiệm đầu tiên do các Trường hợp kiểm tra chấp nhận chỉ đạo. Trọng tâm là tiêu chí chấp nhận và các Trường hợp kiểm tra chấp nhận được viết bởi người kiểm tra trong quá trình Tạo câu chuyện người dùng với sự cộng tác của khách hàng, người dùng cuối và các bên liên quan có liên quan.

Step 1 - Viết các trường hợp kiểm tra chấp nhận cùng với các câu chuyện của người dùng với sự cộng tác của khách hàng và người dùng.
Step 2 - Xác định các tiêu chí chấp nhận liên quan.
Step 3 - Phát triển mã dựa trên các kiểm tra chấp nhận và tiêu chí chấp nhận.
Step 4 - Chạy các bài kiểm tra chấp nhận để đảm bảo rằng mã đang chạy như mong đợi.
Step 5- Tự động hóa các bài kiểm tra nghiệm thu. Nói lạiStep 3 – Step 5 cho đến khi tất cả các câu chuyện người dùng trong lần lặp được triển khai.
Step 6 - Tự động hóa các bài kiểm tra hồi quy.
Step 7 - Chạy Kiểm tra hồi quy tự động để đảm bảo Hồi quy liên tục.

Phát triển theo hướng hành vi (BDD)

Phát triển theo hướng hành vi (BDD) tương tự như Phát triển theo hướng kiểm tra (TDD), và trọng tâm là kiểm tra mã để đảm bảo hành vi mong đợi của hệ thống.

Trong BDD, ngôn ngữ như tiếng Anh được sử dụng để có ý nghĩa đối với người dùng, người kiểm tra và nhà phát triển. Nó đảm bảo -

Liên lạc liên tục giữa người dùng, người thử nghiệm và nhà phát triển.
Tính minh bạch về những gì đang được phát triển và thử nghiệm.

Các Kỹ thuật Kiểm tra từ kiểm thử truyền thống cũng có thể được sử dụng trong kiểm thử Agile. Ngoài những điều này, các thuật ngữ và kỹ thuật thử nghiệm cụ thể của Agile được sử dụng trong các dự án Agile.

Cơ sở thử nghiệm

Trong các dự án nhanh, sản phẩm tồn đọng thay thế các tài liệu đặc tả yêu cầu. Nội dung của sản phẩm tồn đọng thường là câu chuyện của người dùng. Các yêu cầu phi chức năng cũng được quan tâm trong các câu chuyện của người dùng. Do đó, cơ sở thử nghiệm trong các dự án Agile là câu chuyện người dùng.

Để đảm bảo thử nghiệm chất lượng, những điều sau đây cũng có thể được coi là cơ sở thử nghiệm bổ sung:

Kinh nghiệm từ các lần lặp trước của cùng một dự án hoặc các dự án trong quá khứ.
Các chức năng, kiến trúc, thiết kế, mã và đặc điểm chất lượng hiện có của hệ thống.
Lỗi dữ liệu từ các dự án hiện tại và quá khứ.
Phản hồi của khách hàng.
Tài liệu người dùng.

Định nghĩa về Hoàn thành

Định nghĩa Hoàn thành (DoD) là tiêu chí được sử dụng trong các dự án Agile để đảm bảo hoàn thành một hoạt động trong Sprint tồn đọng. DoD có thể thay đổi từ nhóm Scrum này sang nhóm Scrum khác, nhưng nó phải nhất quán trong một nhóm.

DoD là danh sách kiểm tra các hoạt động cần thiết đảm bảo thực hiện các chức năng và tính năng trong câu chuyện người dùng cùng với các yêu cầu phi chức năng là một phần của câu chuyện người dùng. Câu chuyện của người dùng đạt đến giai đoạn Hoàn tất sau khi tất cả các mục trong danh sách kiểm tra DoD được hoàn thành. Một DoD được chia sẻ trong nhóm.

Một DoD điển hình cho một câu chuyện người dùng có thể chứa:

Tiêu chí chấp nhận chi tiết có thể kiểm tra
Các tiêu chí để đảm bảo tính nhất quán của Câu chuyện người dùng với những người khác trong Lặp lại
Tiêu chí cụ thể liên quan đến sản phẩm
Các khía cạnh hành vi chức năng
Đặc điểm phi chức năng
Interfaces
Yêu cầu dữ liệu thử nghiệm
Kiểm tra vùng phủ sóng
Refactoring
Yêu cầu xem xét và phê duyệt

Ngoài DoD cho Câu chuyện người dùng, DoD cũng được yêu cầu -

ở mọi cấp độ kiểm tra
cho mỗi Tính năng
cho mỗi Lặp lại
để phát hành

Thông tin kiểm tra

Người kiểm tra cần có thông tin Kiểm tra sau:

Câu chuyện của người dùng cần được kiểm tra
Tiêu chí chấp nhận được liên kết
Giao diện hệ thống
Môi trường nơi Hệ thống dự kiến sẽ hoạt động
Tính khả dụng của công cụ
Kiểm tra vùng phủ sóng
DoD

Trong các dự án Agile, vì thử nghiệm không phải là một hoạt động tuần tự và người kiểm thử phải làm việc trong chế độ cộng tác, nên người kiểm thử có trách nhiệm -

Thu thập thông tin thử nghiệm cần thiết trên cơ sở liên tục.
Xác định các lỗ hổng thông tin ảnh hưởng đến việc kiểm tra.
Hợp tác giải quyết các khoảng cách với các thành viên khác trong nhóm.
Quyết định khi nào đạt đến cấp độ kiểm tra.
Đảm bảo các thử nghiệm thích hợp được thực hiện vào các thời điểm thích hợp.

Thiết kế kiểm tra chức năng và phi chức năng

Trong các dự án Agile, các kỹ thuật kiểm thử truyền thống có thể được sử dụng, nhưng trọng tâm là kiểm thử sớm. Các trường hợp kiểm thử cần phải có trước khi bắt đầu triển khai.

Đối với thiết kế thử nghiệm chức năng, người thử nghiệm và nhà phát triển có thể sử dụng các kỹ thuật thiết kế thử nghiệm Hộp đen truyền thống như:

Phân vùng tương đương
Phân tích giá trị ranh giới
Bảng Quyết định
Chuyển đổi trạng thái
Cây lớp

Đối với thiết kế kiểm thử phi chức năng, vì các yêu cầu phi chức năng cũng là một phần của mỗi câu chuyện người dùng, các kỹ thuật thiết kế kiểm thử hộp đen chỉ có thể được sử dụng để thiết kế các trường hợp kiểm thử liên quan.

Thử nghiệm thăm dò

Trong các dự án Agile, thời gian thường là yếu tố giới hạn đối với Phân tích thử nghiệm và Thiết kế thử nghiệm. Trong những trường hợp như vậy, các kỹ thuật thử nghiệm Khám phá có thể được kết hợp với các kỹ thuật thử nghiệm truyền thống.

Thử nghiệm khám phá (ET) được định nghĩa là học đồng thời, thiết kế thử nghiệm và thực hiện thử nghiệm. Trong Thử nghiệm khám phá, người thử nghiệm chủ động kiểm soát thiết kế của các thử nghiệm khi chúng được thực hiện và sử dụng thông tin thu được trong khi thử nghiệm để thiết kế các thử nghiệm mới và tốt hơn.

Thử nghiệm Khám phá rất hữu ích để đáp ứng các thay đổi trong các dự án Agile.

Kiểm tra dựa trên rủi ro

Thử nghiệm dựa trên rủi ro là thử nghiệm dựa trên rủi ro thất bại và giảm thiểu rủi ro bằng cách sử dụng các kỹ thuật thiết kế thử nghiệm.

Rủi ro về chất lượng sản phẩm có thể được định nghĩa là một vấn đề tiềm ẩn đối với chất lượng sản phẩm. Rủi ro về chất lượng sản phẩm bao gồm -

Rủi ro chức năng
Rủi ro hoạt động phi chức năng
Rủi ro về khả năng sử dụng phi chức năng

Phân tích rủi ro được thực hiện để đánh giá xác suất (khả năng xảy ra) và tác động của từng rủi ro. Sau đó, các rủi ro được ưu tiên -

Rủi ro cao yêu cầu thử nghiệm mở rộng
Rủi ro thấp chỉ yêu cầu Kiểm tra Cursory

Các thử nghiệm được thiết kế bằng các Kỹ thuật Kiểm tra thích hợp dựa trên Mức độ rủi ro và Đặc điểm rủi ro của từng Rủi ro. Các thử nghiệm sau đó được thực hiện để giảm thiểu Rủi ro.

Kiểm tra phù hợp

Kiểm tra phù hợp là Kiểm tra chấp nhận tự động. Công cụ Fit và FitNesse có thể được sử dụng để tự động hóa các thử nghiệm chấp nhận.

FIT sử dụng JUnit, nhưng mở rộng chức năng thử nghiệm. Các bảng HTML được sử dụng để hiển thị các trường hợp Kiểm thử. Fixture là một lớp Java phía sau bảng HTML. Vật cố định lấy nội dung của bảng HTML và chạy các trường hợp thử nghiệm trên dự án đang được thử nghiệm.

Kế hoạch Kiểm tra được chuẩn bị tại thời điểm Lập kế hoạch Phát hành và được sửa đổi tại mỗi Kế hoạch Sprint. Kế hoạch kiểm tra hoạt động như một hướng dẫn cho quá trình kiểm tra để có phạm vi kiểm tra hoàn chỉnh.

Nội dung điển hình của Kế hoạch Kiểm tra là -

Chiến lược thử nghiệm
Môi trường thử nghiệm
Kiểm tra vùng phủ sóng
Phạm vi kiểm tra
Kiểm tra nỗ lực và lịch trình
Công cụ kiểm tra

Trong các Dự án Agile, tất cả các Thành viên trong Nhóm phải chịu trách nhiệm về chất lượng của sản phẩm. Do đó, tất cả mọi người đều tham gia vào việc lập kế hoạch kiểm tra.

Trách nhiệm của người kiểm tra là cung cấp hướng dẫn cần thiết và cố vấn cho phần còn lại của nhóm về chuyên môn kiểm tra của họ.

Câu chuyện của người dùng

Về nguyên tắc, User Story không phải là thử nghiệm các sản phẩm công việc. Tuy nhiên, trong các Dự án Agile, người thử nghiệm tham gia vào Việc tạo Câu chuyện Người dùng. Người kiểm tra viết Câu chuyện người dùng mang lại giá trị cho khách hàng và bao gồm các hành vi có thể có khác nhau của hệ thống.

Người kiểm tra cũng đảm bảo rằng tất cả Câu chuyện của người dùng đều có thể kiểm tra được và đảm bảo Tiêu chí chấp nhận.

Kiểm tra thủ công và tự động

Trong lần chạy Thử nghiệm đầu tiên, Thử nghiệm Thủ công được sử dụng. Chúng bao gồm -

Kiểm tra đơn vị
Kiểm tra tích hợp
Kiểm tra chức năng
Kiểm tra phi chức năng
Kiểm tra chấp nhận

Các bài kiểm tra sau đó được tự động hóa cho các lần chạy tiếp theo.

Trong Test Driven Development, Bài kiểm tra đơn vị được viết đầu tiên để không đạt, Mã được phát triển và kiểm tra để đảm bảo Bài kiểm tra vượt qua.

Trong Acceptance Test Driven Development, Các bài kiểm tra chấp nhận được viết trước khi không đạt, Mã được phát triển và thử nghiệm để đảm bảo các Bài kiểm tra đạt.

Trong các phương pháp Phát triển khác, Người kiểm tra cộng tác với phần còn lại của Nhóm để đảm bảo Độ bao phủ của Kiểm tra.

Trong tất cả các loại phương pháp, Tích hợp liên tục diễn ra, bao gồm kiểm tra tích hợp liên tục.

Nhóm có thể quyết định khi nào và thử nghiệm nào sẽ được tự động hóa. Ngay cả khi việc tự động hóa các bài kiểm tra đòi hỏi nỗ lực và thời gian, kết quả các bài kiểm tra tự động làm giảm đáng kể nỗ lực và thời gian kiểm tra lặp đi lặp lại trong quá trình lặp lại của Dự án Agile. Điều này lại tạo điều kiện cho nhóm chú ý nhiều hơn đến các hoạt động bắt buộc khác, chẳng hạn như Câu chuyện người dùng mới, Thay đổi, v.v.

Trong Scrum, các lần lặp được đóng hộp thời gian. Do đó, nếu không thể hoàn thành thử nghiệm Câu chuyện người dùng trong một Sprint cụ thể, người kiểm tra có thể báo cáo trong cuộc họp dự phòng hàng ngày rằng câu chuyện người dùng không thể đạt đến Trạng thái hoàn thành trong Sprint đó và do đó cần được giữ lại để chờ Sprint tiếp theo.

Kết quả kiểm tra

Vì hầu hết các Thử nghiệm trong các Dự án Agile được tự động hóa, các Công cụ tạo ra Nhật ký Kết quả Kiểm tra cần thiết. Người kiểm tra xem lại Nhật ký kết quả kiểm tra. Kết quả kiểm tra cần được duy trì cho mỗi sprint / release.

Tóm tắt Kiểm tra cũng có thể được chuẩn bị bao gồm:

Phạm vi thử nghiệm (Cái gì đã được kiểm tra và cái gì chưa được kiểm tra)
Phân tích khiếm khuyết cùng với Phân tích nguyên nhân gốc rễ nếu có thể
Trạng thái kiểm tra hồi quy sau khi sửa lỗi
Các vấn đề và giải pháp tương ứng
Các vấn đề đang chờ xử lý, nếu có
Bất kỳ sửa đổi nào được yêu cầu trong Chiến lược thử nghiệm
Số liệu kiểm tra

Báo cáo Chỉ số Kiểm tra

Trong các Dự án Agile, các Chỉ số Kiểm tra bao gồm những điều sau cho mỗi Sprint:

Kiểm tra nỗ lực
Kiểm tra độ chính xác của ước tính
Kiểm tra vùng phủ sóng
Phạm vi kiểm tra tự động
Số khiếm khuyết
Tỷ lệ sai sót (Số lượng khiếm khuyết trên mỗi điểm câu chuyện của người dùng)
Mức độ nghiêm trọng của khiếm khuyết
Thời gian để sửa lỗi trong cùng một Sprint (Chi phí sửa lỗi thoát khỏi sprint hiện tại cao gấp 24 lần)
Số lỗi được sửa trong cùng một Sprint
Hoàn thành Kiểm tra sự chấp nhận của Khách hàng trong Sprint

Báo cáo đánh giá và hồi cứu Sprint

Người kiểm tra cũng đóng góp vào Báo cáo Sơ kết Sprint và Báo cáo Hồi cứu. Các nội dung tiêu biểu là -

Số liệu kiểm tra
Kết quả kiểm tra Nhật ký kết quả xem xét kết quả
Điều gì đã đúng và những gì có thể được cải thiện từ Quan điểm kiểm tra
Thực hành tốt nhất
Bài học kinh nghiệm
Issues
Phản hồi của khách hàng

Hoạt động Agile Testing có thể được quản lý một cách hiệu quả bằng cách sử dụng các khái niệm Kanban. Những điều sau đây đảm bảo việc kiểm tra được hoàn thành kịp thời trong vòng lặp lại / chạy nước rút và do đó tập trung vào việc cung cấp sản phẩm chất lượng.

Câu chuyện của người dùng có thể kiểm tra và có kích thước hiệu quả dẫn đến việc phát triển và thử nghiệm trong các giới hạn thời gian được chỉ định.
Giới hạn WIP (Work-In-Progress) cho phép tập trung vào một số câu chuyện giới hạn của người dùng tại một thời điểm.
Bảng Kanban đại diện cho quy trình làm việc một cách trực quan, giúp theo dõi các hoạt động thử nghiệm và tắc nghẽn, nếu có.
Khái niệm hợp tác nhóm Kanban cho phép giải quyết các tắc nghẽn khi chúng được xác định, mà không cần thời gian chờ đợi.
Chuẩn bị trước các Trường hợp thử nghiệm, duy trì bộ thử nghiệm khi quá trình phát triển tiến triển và nhận được Phản hồi của Khách hàng giúp loại bỏ các Sai sót trong quá trình lặp lại / chạy nước rút.
Định nghĩa Hoàn thành (DoD) được cho là Hoàn thành-Hoàn thành theo nghĩa là một Câu chuyện chỉ đạt đến trạng thái hoàn thành sau khi quá trình kiểm tra cũng hoàn tất.

Hoạt động thử nghiệm trong phát triển sản phẩm

Trong Phát triển sản phẩm, các bản phát hành có thể được theo dõi bằng bảng Kanban tính năng. Các tính năng cho một bản phát hành cụ thể được gán cho bảng Kanban Tính năng theo dõi trực quan trạng thái phát triển tính năng.

Các Tính năng trong bản phát hành được chia thành các câu chuyện và được phát triển trong bản phát hành bằng cách sử dụng cách tiếp cận nhanh nhẹn.

Các hoạt động Thử nghiệm Agile sau đây đảm bảo cung cấp chất lượng trong mọi bản phát hành và ở cuối tất cả các bản phát hành -

Người kiểm tra tham gia vào việc Tạo câu chuyện người dùng và do đó đảm bảo -
- Tất cả các Hành vi có thể có của Hệ thống được ghi lại bằng Câu chuyện của người dùng và các Yêu cầu phi chức năng nằm trong Câu chuyện của người dùng.
- Câu chuyện của người dùng có thể kiểm tra được.
- Kích thước của Câu chuyện người dùng cho phép Hoàn thành việc phát triển và kiểm tra (DoneDone) trong Lặp lại.
Bảng Kanban Nhiệm vụ Trực quan -
- Mô tả trạng thái và tiến trình của Nhiệm vụ
- Các tắc nghẽn được xác định ngay lập tức khi chúng xảy ra
- Tạo điều kiện để đo lường thời gian chu kỳ mà sau đó có thể được tối ưu hóa
Hợp tác nhóm giúp trong -
- Trách nhiệm giải trình của toàn bộ Nhóm về chất lượng sản phẩm
- Giải quyết tắc nghẽn khi và khi chúng xảy ra, tiết kiệm thời gian chờ đợi
- Sự đóng góp của mọi chuyên gia trong tất cả các hoạt động
Tích hợp liên tục tập trung vào Kiểm tra tích hợp liên tục
Tự động hóa các bài kiểm tra để tiết kiệm thời gian và nỗ lực kiểm tra
Phòng chống sai sót với các Trường hợp kiểm tra được viết trước đó cho Phát triển và cố vấn cho các Nhà phát triển về những gì được dự đoán bởi các hành vi khác nhau của Hệ thống -
- Giới hạn WIP để tập trung vào một số lượng giới hạn Câu chuyện của người dùng tại một thời điểm
Kiểm tra liên tục khi quá trình Phát triển tiến triển, để đảm bảo các bản sửa lỗi trong vòng lặp lại -
- Đảm bảo phạm vi kiểm tra
- Giữ cho số lỗi mở ở mức thấp

Khám phá câu chuyện

Khám phá câu chuyện là giao tiếp trong một nhóm Agile để khám phá sự hiểu biết Câu chuyện khi chủ sở hữu sản phẩm chuyển một câu chuyện để được chấp nhận để phát triển.

Chủ sở hữu sản phẩm đưa ra câu chuyện dựa trên chức năng mà hệ thống mong đợi. Các nhà phát triển khám phá nhiều hơn trên mỗi câu chuyện trước khi họ đánh dấu nó đã sẵn sàng để chấp nhận. Người kiểm tra cũng tham gia vào giao tiếp từ góc độ kiểm thử để làm cho nó có thể kiểm tra được nhiều nhất có thể.

Việc hoàn thiện Câu chuyện dựa trên sự trao đổi thường xuyên và liên tục giữa Chủ sở hữu sản phẩm, Nhà phát triển và Người thử nghiệm.

Ước lượng

Ước tính xảy ra trong Lập kế hoạch phát hành và từng Lập kế hoạch lặp lại.

Trong Lập kế hoạch phát hành, người kiểm tra cung cấp -

Thông tin về những hoạt động thử nghiệm được yêu cầu
Ước tính nỗ lực cho cùng một

Trong lập kế hoạch Lặp lại, người kiểm tra góp phần quyết định xem có thể đưa vào bao nhiêu câu chuyện trong một lần lặp. Quyết định phụ thuộc vào Nỗ lực Kiểm tra và Ước tính Lịch trình Kiểm tra. Ước tính câu chuyện cũng phản ánh ước tính thử nghiệm.

Trong Kanban, Done-Done chỉ được hoàn thành khi một câu chuyện được phát triển và kiểm tra và được đánh dấu là hoàn chỉnh không có khiếm khuyết.

Do đó, Ước tính thử nghiệm đóng một vai trò quan trọng trong ước tính câu chuyện.

Lập kế hoạch câu chuyện

Lập kế hoạch Câu chuyện bắt đầu sau khi một Câu chuyện đã được ước tính và gán cho phần Lặp lại hiện tại.

Lập kế hoạch Câu chuyện bao gồm các nhiệm vụ kiểm tra sau:

Chuẩn bị dữ liệu thử nghiệm
Mở rộng kiểm tra chấp nhận
Thực hiện kiểm tra thủ công
Tiến hành các phiên Thử nghiệm Khám phá
Tự động hóa các bài kiểm tra tích hợp liên tục

Ngoài các Nhiệm vụ kiểm tra này, các nhiệm vụ khác cũng có thể được yêu cầu, chẳng hạn như -

Kiểm tra năng suất
Kiểm tra hồi quy
Cập nhật các bài kiểm tra tích hợp liên tục có liên quan

Tiến trình câu chuyện

Story Progression phát hiện ra các bài kiểm tra bổ sung được yêu cầu do liên lạc liên tục giữa nhà phát triển và người kiểm tra. Trong các tình huống mà nhà phát triển cần rõ ràng hơn về việc triển khai, người thử nghiệm thực hiện thử nghiệm khám phá.

Kiểm tra liên tục được thực hiện trong Tiến trình câu chuyện và bao gồm Kiểm tra tích hợp liên tục. Toàn bộ nhóm tham gia vào các hoạt động thử nghiệm.

Chấp nhận câu chuyện

Chấp nhận câu chuyện xảy ra khi câu chuyện đạt đến trạng thái Đã hoàn thành. tức là, câu chuyện được phát triển và thử nghiệm và được báo hiệu là hoàn chỉnh.

Kiểm tra câu chuyện được cho là hoàn thành khi tất cả các thử nghiệm liên quan đến câu chuyện vượt qua hoặc mức độ tự động hóa thử nghiệm được đáp ứng.

Trong các Dự án Agile, Người kiểm tra chịu trách nhiệm cho các công việc hàng ngày sau:

Hỗ trợ các nhà phát triển trong việc viết mã, với những giải thích rõ ràng về hành vi mong đợi của hệ thống.
Giúp các nhà phát triển trong việc tạo các bài kiểm tra đơn vị hiệu quả và hiệu quả.
Phát triển các tập lệnh tự động hóa.
Tích hợp các công cụ / tập lệnh kiểm tra tự động hóa với tích hợp liên tục để kiểm tra hồi quy.

Để triển khai hiệu quả và nhanh chóng các nhiệm vụ này, một hệ thống Tích hợp Liên tục (CI) hỗ trợ CI của Mã và các thành phần thử nghiệm được sử dụng trong hầu hết các dự án Agile.

Người kiểm tra và nhà phát triển trong các dự án nhanh có thể được hưởng lợi từ các công cụ khác nhau để quản lý các phiên kiểm tra và tạo và gửi báo cáo Lỗi. Ngoài các công cụ chuyên dụng để kiểm tra nhanh, các nhóm nhanh cũng có thể hưởng lợi từ các công cụ quản lý kiểm tra và tự động hóa kiểm thử.

Note - Các giải pháp Tự động hóa Ghi và Phát lại, Kiểm tra Lần cuối, Hạng nặng và Tự động hóa Kiểm tra không nhanh nhẹn như -

Quy trình kiểm tra cuối cùng được khuyến khích bởi các công cụ như vậy không hoạt động cho các nhóm Agile.
Các tập lệnh không thể hiểu được được tạo bằng các công cụ như vậy trở thành một trở ngại để thay đổi
Các công cụ chuyên dụng như vậy tạo ra nhu cầu về các chuyên gia Tự động hóa thử nghiệm và do đó thúc đẩy các silo

Các công cụ được sử dụng rộng rãi là -

Không.	Công cụ & Mục đích
1	Hudson Khung CI
2	Selenium Kiểm tra chức năng - Tích hợp với Hudson
3	CruiseControl Khung CI
4	Junit Kiểm tra đơn vị Java
5	Nunit Kiểm tra đơn vị .Net
6	Cobertura / JavaCodeCoverage / JFeature / JCover / Phạm vi kiểm tra Java
7	Jester Java - Kiểm tra đột biến / Tạo lỗi tự động
số 8	Gretel Công cụ giám sát phạm vi kiểm tra Java
9	TestCocoon C / C ++ hoặc C # - giảm số lượng Kiểm tra bằng cách tìm Kiểm tra dư thừa và tìm Mã chết
10	JAZZ Java - Bảo hiểm Nhánh, Nút và Khử lỗi và triển khai GUI, Bộ lập kế hoạch kiểm tra, Công cụ động và Bộ phân tích kiểm tra
11	Ant Java - Bản dựng tự động hóa
12	Nant .Net - Bản dựng tự động hóa
13	Bonfire Tiện ích bổ sung Kiểm tra Agile cho JIRA

Các công cụ tự động hóa kiểm tra Agile

Hỗ trợ các công cụ tự động hóa kiểm tra Agile hiệu quả -

Tự động hóa thử nghiệm sớm bằng cách tiếp cận thử nghiệm đầu tiên.
Viết mã tự động kiểm tra bằng ngôn ngữ thực, ngôn ngữ miền cụ thể.
Tập trung vào hành vi mong đợi của hệ thống.
Tách bản chất của Kiểm tra khỏi các chi tiết triển khai, do đó làm cho nó trở nên độc lập với Công nghệ.
Thúc đẩy sự hợp tác.

Kiểm thử đơn vị tự động (sử dụng Junit hoặc NUnit) hỗ trợ phương pháp thử nghiệm đầu tiên để mã hóa. Đây là các bài kiểm tra hộp trắng và đảm bảo rằng thiết kế là tốt và không có khuyết tật. Các bài kiểm tra như vậy được xây dựng bởi các nhà phát triển với sự hỗ trợ từ người kiểm tra và có thể độc lập với chức năng được yêu cầu. Điều này dẫn đến việc cung cấp một sản phẩm có thể không đáp ứng yêu cầu của khách hàng và do đó không có giá trị kinh doanh.

Mối quan tâm này được giải quyết bằng cách tự động hóa Kiểm tra chấp nhận được viết với sự cộng tác của khách hàng, các bên liên quan khác, người kiểm tra và nhà phát triển. Các bài kiểm tra chấp nhận tự động được viết bởi khách hàng hoặc chủ sở hữu sản phẩm / nhà phân tích kinh doanh phản ánh hành vi mong đợi của sản phẩm. Sự tham gia của các nhà phát triển đảm bảo việc sản xuất mã theo yêu cầu. Tuy nhiên, nếu việc kiểm tra chỉ tập trung vào việc chấp nhận, thì mã kết quả có thể vẫn không thể mở rộng.

Do đó, Kiểm tra Đơn vị Tự động và Kiểm tra Chấp nhận Tự động là miễn phí và cả hai đều cần thiết trong Phát triển Agile.

Các công cụ và khuôn khổ Agile hỗ trợ Kiểm tra chấp nhận tự động là -

Fit
Fitnesse
Concordion
Ruby
Cucumber

Phù hợp

Ward Cunningham đã phát triển công cụ Fit có thể được sử dụng để Tự động hóa Kiểm tra Chấp nhận. Fit cho phép -

Khách hàng hoặc Chủ sở hữu sản phẩm để đưa ra ví dụ về hành vi của sản phẩm bằng Microsoft Word và Microsoft Excel
Lập trình viên để dễ dàng biến các ví dụ đó thành các bài kiểm tra tự động.

Fit 1.1 hỗ trợ cả Java và .NET.

FitNesse

FitNesse là một wiki, là một kiểu máy chủ web cho phép bất kỳ khách truy cập nào thực hiện bất kỳ chỉnh sửa nào, bao gồm thay đổi các trang hiện có và tạo các trang mới. Một ngôn ngữ đánh dấu đơn giản cho phép bạn dễ dàng tạo tiêu đề, in đậm, gạch chân và nghiêng văn bản, tạo danh sách có dấu đầu dòng và thực hiện các loại định dạng đơn giản khác.

Trong FitNesse, Tự động hóa kiểm tra chấp nhận như sau:

Thể hiện các bài kiểm tra dưới dạng bảng dữ liệu đầu vào và dữ liệu đầu ra dự kiến.
Sử dụng FitNesse để đặt bảng kiểm tra trên trang mà bạn có thể chỉnh sửa.
- Ngoài ra, hãy đặt bảng kiểm tra trong Microsoft Excel, sao chép vào khay nhớ tạm và sau đó sử dụng Spreadsheet to FitNesse lệnh để FitNesse định dạng bảng của bạn đúng cách
Chạy thử nghiệm
Bạn nhận được kết quả thử nghiệm bằng cách mã hóa màu của các ô trong bảng thử nghiệm
- các ô màu xanh lục biểu thị rằng các giá trị mong đợi thu được
- ô màu đỏ thể hiện rằng một giá trị khác với những gì bạn mong đợi nhận được
- các ô màu vàng biểu thị rằng một ngoại lệ đã được ném ra

Quả dưa chuột

Cucumber là một công cụ dựa trên khung Phát triển Theo hướng Hành vi (BDD). Các tính năng chính là -

Được sử dụng để viết các bài kiểm tra chấp nhận cho các ứng dụng web.
Cho phép tự động xác nhận chức năng ở định dạng dễ đọc và dễ hiểu như tiếng Anh đơn giản.
Đã được triển khai trong Ruby và sau đó được mở rộng sang khuôn khổ Java. Cả hai đều hỗ trợ Junit.
Hỗ trợ các ngôn ngữ khác như Perl, PHP, Python, .Net, v.v.
Có thể được sử dụng cùng với Selenium, Watir, Capybara, v.v.