Kiểm tra Agile - Thuộc tính quan trọng

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ử phần mềm Agile.

Lợi ích kiểm thử Agile

Lợi ích của kiểm thử Agile là

Sự hài lòng của khách hàng bằng cách nhanh chóng, liên tục hoàn toàn thử nghiệm sản phẩm 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 kiểm thử liên tục tương tác với nhau, do đó giảm thời gian chu kỳ.

kiểm thử phần mềm

Người kiểm thử nhanh nhẹn tham gia vào việc xác định các yêu cầu đóng góp chuyên môn kiểm thử của họ để tập trung vào những gì khả thi.

Người kiểm thử nhanh nhẹn tham gia ước tính đánh giá nỗ lực và thời gian kiểm thử.

Thiết kế thử nghiệm sớm phản ánh Tiêu chí chấp nhận.

Yêu cầu kiểm thử được củng cố bởi toàn đội, tránh những hạn chế.

Tập trung liên tục vào chất lượng sản phẩm của toàn đội.

Định nghĩa về các bài kiểm thử phản ánh trạng thái Xong đả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 để giải quyết có thể được thực hiện ngay lập tức với nỗ lực từ toàn đội.

Đáp ứng nhanh chóng với các yêu cầu thay đổi và cung cấp chúng sớm.

Tích hợp liên tục kiểm thử hồi quy.

Không có thời gian trì hoãn giữa phát triển và thử nghiệm. thử nghiệm đầu tiên, phương pháp thử nghiệm liên tục được theo sau.

Thử nghiệm tự động hóa được thực hiện sớm trong vòng đời phát triển, do đó giảm tổng thời gian và nỗ lực thử nghiệm.

Thực hành tốt nhất trong kiểm thử Agile

Thực hiện theo các thực tiễn tốt nhất được đưa ra dưới đây

Bao gồm những người thử nghiệm có chuyên môn trong tất cả các loại thử nghiệm ở tất cả các cấp.

Người kiểm thử tham gia định nghĩa các yêu cầu, hợp tác với khách hàng về hành vi dự kiến ​​của sản phẩm.

Người kiểm thử chia sẻ phản hồi liên tục với các nhà phát triển và khách hàng.

Thử nghiệm phương pháp 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 thử và tiến độ kiểm thử kịp thời và liên tục với trọng tâm là cung cấp sản phẩm chất lượng.

Tự động hóa thử nghiệm sớm trong vòng đời phát triển để giảm thời gian chu kỳ.

Để thực hiện kiểm thử hồi quy tận dụng Kiểm thử tự động như một cách hiệu quả.

Những thách thức trong kiểm thử Agile

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

Việc không hiểu được cách tiếp cận Agile và những hạn chế của nó đối với Doanh nghiệp và Quản lý có thể dẫn đến những kỳ vọng không thể thực hiện đượ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 các yếu tố cần thiết của Thực tiễn kiểm thử. Người thử nghiệm đượ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 thực hiện được với Sprints (Iterations) có thời gian.

Phương pháp thử nghiệm đầu tiên yêu cầu Nhà phát triển dựa trên mã hóa trên Phản hồi của người kiểm thử, nhưng trong các tình huống thực tế, Nhà phát triển đã quen với việc mã hóa dựa trên các Yêu cầu đến từ Khách hàng hoặc Doanh nghiệp.

Trách nhiệm đối với Sản phẩm chất lượng thuộc về toàn bộ Nhóm Agile, nhưng trong giai đoạn ban đầu, Nhà phát triển có thể không tập trung vào Chất lượng vì họ tập trung hơn vào chế độ triển khai.

Tích hợp liên tục yêu cầu kiểm thử 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 thử có thể thích ứng với các thay đổi với tập hợp Agile, nhưng việc điều chỉnh các Thay đổi và kiểm thử kết quả có thể không thể thực hiện được để nhắm mục tiêu hoàn thành trong Sprint.

Tự động hóa sớm được khuyến nghị để có thể giảm thời gian và nỗ lực kiểm thử  thủ công. Nhưng, trong kịch bản thực tế, đến các Bài kiểm thử có thể được tự động hóa và tự động hóa chúng đòi hỏi Thời gian và Nỗ lực.

Hướng dẫn kiểm thử nhanh

Sử dụng các hướng dẫn sau trong khi thực hiện kiểm thử phần mềm  Agile.

Tham gia vào Kế hoạch phát hành để xác định các hoạt động Thử nghiệm cần thiết và đưa ra phiên bản ban đầu của kế hoạch kiểm thử.

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 kiểm thử được cung cấp trong các lần lặp.

Tham gia vào Định nghĩa câu chuyện của người dùng để đến các trường hợp kiểm thử chấp nhận.

Tham gia vào 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 thử.

Liên tục cộng tác với Nhóm phát triển trong Sprint để giúp Thử nghiệm và Mã hóa thành công tốt trong Sprint.

Tham gia vào các cuộc họp độc lập hàng ngày và truyền đạt độ trễ hoặc chặn 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 thử, tiến độ kiểm thử và chất lượng sản phẩm thường xuyên.

Hãy sẵn sàng để điều chỉnh các thay đổi, đáp ứng với các sửa đổi đối với các Trường hợp thử nghiệm, Dữ liệu thử nghiệm.

Tham gia vào Hồi cứu Sprint để hiểu và đóng góp các Thực tiễn và Bài học tốt nhất đã học.

Hợp tác trong việc lấy Phản hồi của Khách hàng tại mỗi Sprint.

Kiểm tra nhanh - Hoạt động theo dõi

Tình trạng kiểm thử phần mềm có thể được truyền đạt

Trong các cuộc họp độc lập hàng ngày

Sử dụng các công cụ quản lý kiểm thử tiêu chuẩn

Qua tin nhắn

Trạng thái thử nghiệm được xác định bằng trạng thái vượt qua thử nghiệm là rất quan trọng trong việc quyết định liệu tác vụ có được thực hiện hay không. Xong có nghĩa là tất cả các bài kiểm thử cho nhiệm vụ vượt qua.

kiểm thử phần mềm 

Tiến độ kiểm thử

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

Bảng Scrum (Bảng nhiệm vụ nhanh nhẹn)

Biểu đồ Burndown

Kết quả kiểm thử tự động

Tiến độ thử nghiệm cũng có tác động trực tiếp đến tiến độ phát triển. Điều này là do Câu chuyện người dùng có thể được chuyển sang trạng thái Xong 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 thử nghiệm vì Tiêu chí chấp nhận được đánh giá theo Trạng thái thử nghiệm.

Nếu có bất kỳ sự chậm trễ hoặc tắc nghẽn trong tiến trình thử nghiệm, toàn bộ nhóm sẽ thảo luận và hợp tác để giải quyết tương tự.

Trong các dự án Agile, các thay đổi diễn ra khá thường xuyên. Khi có 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ẽ phát triển liên tục. Người kiểm thử phần mềm Agile cần lấy thông tin đó cho nhóm để có thể đưa ra các quyết định phù hợp vào đúng thời điểm để đi đúng hướng để hoàn thành thành công mỗi lần lặp.

Khi 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 thử hồi quy cũng là cần thiết.

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

Số liệu chất lượng sản phẩm bao gồm

Kiểm thử đạt / không đạt

Khiếm khuyết Tìm thấy / Đã sửa

Kiểm thử vùng phủ sóng

Kiểm thử vượt qua / tỷ lệ thất bại

Khiếm khuyết giá khám phá

Mật độ khuyết tật

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

Duy trì tính minh bạch.

Thu thập tất cả các số liệu có liên quan và cần thiết vào đúng thời điểm.

Báo cáo ngay lập tức mà không bị chậm trễ truyền thông.

Cho phép người kiểm thử tập trung vào kiểm thử.

Lọ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 có được phản hồi của khách hàng về việc sản phẩm có đáp ứng mong đợi của khách hàng hay không. Điều này cần được thực hiện vào 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 phân phối nếu thử nghiệm Agile thành công.

Những điểm sau đây cần được xem xét cho sự thành công của thử nghiệm Agile -

kiểm thử phần mềm Agile dựa trên các phương pháp kiểm tra đầu tiên và liên tục. Do đó, các công cụ kiểm tra truyền thống, được xây dựng theo phương pháp kiểm tra cuối cùng, có thể không phù hợp. Do đó, trong khi chọn Công cụ kiểm tra trong các dự án Agile, việc căn chỉnh để kiểm tra Agile cần phải được xác minh.

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ử nhanh nhẹn cần duy trì tốc độ của mình để phù hợp với lịch phát hành phát triển. Do đó, việc lập kế hoạch, theo dõi và lập kế hoạch lại các hoạt động thử nghiệm thích hợp cần được thực hiện một cách nhanh chóng với chất lượng sản phẩm là mục tiêu.

Thử nghiệm thủ công chiếm tới 80% thử nghiệm 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 thử nghiệm có chuyên môn trong suốt vòng đời phát triển làm cho toàn bộ nhóm tập trung vào chất lượng sản phẩm đá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 sản phẩm được 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ấp độ người dùng theo mong muốn của khách hàng.

Nỗ lực và thời gian ước tính cho các hoạt động thử nghiệm.

Lập kế hoạch thử nghiệm hoạt động.

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 đạt được trạng thái thực hiện đáp ứng 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 nước rút.

kiểm thử phần mềm hồi quy ở cuối mỗi lần chạy nước rút.

Thu thập và phân tích các số liệu sản phẩm hữu ích cho sự thành công của dự án.

Phân tích lỗi để xác định cái nào cần sửa trong Sprint hiện tại và cái nào có thể bị trì hoãn cho các Sprint tiếp theo.

Tập trung vào những gì quan trọng từ quan điểm của Khách hàng.

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

Phương pháp tiếp cận toàn đội - 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 mọi nhiệm vụ trong dự án, từ đó cộng tác và đóng góp sẽ có lợi ích tối đa. Sự hợp tác của người thử nghiệm 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 thử nghiệm.

Tư duy kiểm thử nhanh nhẹn - Những người thử nghiệm chủ động trong việc liên tục cải thiện chất lượng và cộng tác liên tục với các thành viên còn lại trong nhóm.

Tự động kiểm thử hồi quy - Thiết kế để 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 chọn các công cụ. Hãy sẵn sàng để cung cấp lời khuyên.

Cung cấp và lấy phản hồi - Vì đây là giá trị Agile cốt lõi, toàn bộ nhóm nên được mở để nhận phản hồi. Vì người kiểm thử là nhà cung cấp phản hồi chuyên gia, cần tập trung vào thông tin liên quan và cần thiết. Đổi lại, về việc có được thông tin phản hồi nên phù hợp với thay đổi và thử nghiệm trường hợp thử nghiệm.

Xây dựng một nền tảng thực hành Agile cốt lõi - Tập trung vào kiểm tra bên cạnh mã hóa, tích hợp liên tục, môi trường kiểm thử hợp tác, làm việc tăng dần, chấp nhận thay đổi, duy trì sức mạnh tổng hợp.

Phối hợp với khách hàng - Lấy ví dụ, hiểu và kiểm thử ánh xạ yêu cầu đối với hành vi sản phẩm, thiết lập Tiêu chí chấp nhận, nhận phản hồi.

Nhìn vào Bức tranh lớn - Phát triển ổ đĩa 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ề các tác động trên các lĩnh vực khác.

Kiểm tra Agile - Tổng quan

Agile là một phương pháp phát triển lặp Kiểm thử phần mềm, trong đó cả hoạt động phát triển và thử nghiệm đều đồng thời.

Thử nghiệm không phải là một giai đoạn riêng biệt; Mã hóa và thử nghiệm đượ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 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 loại bỏ khiếm khuyết sớm và do đó tiết kiệm thời gian, công sức và chi phí.

Học kiểm thử phần mềm 

Tuyên ngôn nhanh nhẹn

Bản 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, nhấn mạnh 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.

Tuyên ngôn Agile là

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

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 khách hàng qua đàm phán hợp đồng.

Đáp ứng để thay đổi theo một kế hoạch.

Đó là, trong khi có giá trị trong các mục bên phải, chúng tôi đánh giá các mục bên trái nhiều hơn.

Kiểm thử Agile là gì?

Kiểm thử Agile 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ử phần mềm 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 được đóng góp bởi những người thử nghiệm. Thử nghiệm 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 những người thử nghiệm tham gia vào toàn bộ Vòng đời phát triển kết hợp với các thành viên nhóm chức năng chéo, sự đóng góp của người thử nghiệm 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.

Thử nghiệm Agile bao gồm tất cả các cấp độ thử nghiệm và tất cả các loại thử nghiệm.

Thử nghiệm nhanh nhẹn Vs. Thử nghiệm thác nước

Trong phương pháp Phát triển Thác nước, các hoạt động Vòng đời Phát triển diễn ra theo từng giai đoạn. 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
Thử nghiệm không phải là một giai đoạn riêng biệt và xảy ra đồng thời với sự phát triển.	Thử nghiệm 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 phát triển.
Người thử nghiệm và nhà phát triển làm việc cùng nhau.	Người kiểm thử làm việc riêng biệt với các nhà phát triển.
Người thử nghiệm có liên quan đến việc đưa ra các yêu cầu. Điều này giúp trong việc yêu cầu ánh xạ tới các hành vi trong kịch bản thế giới thực và cũng đóng 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 logic sẽ sẵn sàng cùng với các yêu cầu.	Người thử có thể không được 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 hoàn thành kiểm tra riêng của nó, do đó cho phép kiểm tra 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 tra hồi quy chỉ có thể được thực hiện sau khi hoàn thành phát triển.
Không có thời gian trễ giữa mã hóa và thử nghiệm.	Thời gian trễ thông thường giữa mã hóa và thử nghiệm.
Kiểm tra liên tục với các mức kiểm tra chồng chéo.	Kiểm tra là một hoạt động đúng thời gian và mức độ kiểm tra không thể chồ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 kiểm thử Agile

Các nguyên tắc của Kiểm thử phần mềm Agile là

Kiểm thử di chuyển dự án về phía trước - Thử nghiệm liên tục là cách duy nhất để đảm bảo tiến độ liên tục. Kiểm thử Agile cung cấp thông tin phản hồi trên cơ sở liên tục và sản phẩm cuối cùng đáp ứng nhu cầu kinh doanh.

Kiểm thử không phải là một giai đoạn - Nhóm thử nghiệ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 đã cho thực sự được thực hiện. Kiểm thử không được giữ cho giai đoạn sau.

Mọi người đều Kiểm thử - 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 thử nghiệm Kiểm thử ứng dụng. Sau mỗi lần lặp, ngay cả khách hàng cũng thực hiện Kiểm thử chấp nhận người dùng.

Rút ngắn các vòng phản hồi - Trong thử nghiệm Agile, nhóm kinh doanh làm quen với việc phát triển sản phẩm cho mỗi lần lặp. Họ được tham gia vào mỗi lần lặp. 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 nó là ít hơn.

Giữ mã sạch - Các lỗi được sửa khi chúng được nâng lên trong cùng một lần lặp. Điều này đảm bảo mã sạch tại bất kỳ cột mốc phát triển nào.

Tài liệu nhẹ - Thay vì tài liệu Kiểm thử toàn diện, người Kiểm thử Agile

Sử dụng danh sách Kiểm thử có thể tái sử dụng để đề xuất Kiểm thử.

Tập trung vào bản chất của bài Kiểm thử hơn là các chi tiết ngẫu nhiên.

Sử dụng các phong cách / công cụ tài liệu nhẹ.

Nắm bắt ý tưởng thử nghiệm trong điều lệ cho thử nghiệm thăm dò.

Tận dụng tài liệu cho nhiều mục đích.

Tận dụng một tạo phẩm thử nghiệm cho các thử nghiệm thủ công và tự động - Có thể sử dụng cùng một tạo tác kịch bản 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 thử thủ công và sau đó là Tập lệnh Kiểm thử tự động hóa tương đương.

Hoàn thành xong, không chỉ thực hiện - Trong Agile, một tính năng được cho là không được thực hiện sau khi phát triển mà sau khi phát triển và thử nghiệm.

Test-Last so với Test Driven - Test Case đượ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 hướng thử nghiệm (TDD) và Phát triển hướng thử nghiệm chấp nhận (ATDD). Điều này trái ngược với thử nghiệm như là giai đoạn cuối trong Thử nghiệm thác nước.

Hoạt động kiểm thử Agile

Các hoạt động Kiểm thử Agile ở cấp dự án là

Kế hoạch phát hành (Kế hoạch Kiểm thử)

Đối với mỗi lần lặp,

Các hoạt động Kiểm thử nhanh nhẹn trong một lần lặp

Kiểm thử phần mềm hồi quy

Hoạt động phát hành (Kiểm thử liên quan)

Các hoạt động Kiểm thử Agile trong một lần lặp bao gồm

Tham gia lập kế hoạch lặp

Ước tính nhiệm vụ từ quan điểm Kiểm thử

Viết trường hợp Kiểm thử bằng cách sử dụng các mô tả tính năng

Kiểm thử đơn vị

Thử nghiệm hội nhập

Kiểm thử tính năng

Sửa lỗi

Thử nghiệm hội nhập

Kiểm thử chấp nhận

Báo cáo tình trạng về tiến độ kiểm thử

Theo dõi lỗi

Kiểm tra nhanh - Thử nghiệm trong nhóm

kiểm thử phần mềm Phát triển nhanh là nhóm làm trung tâm và các nhà phát triển và kiểm thử tham gia vào tất cả các hoạt động dự án và phát triển. Teamwork 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 cho tất cả các hoạt động của dự án và đồng thời phải tận dụng chuyên môn trong thử nghiệm.

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

Kiểm thử phần mềm

Kỹ năng giao tiếp tốt.

Khả năng hành động tích cực và giải quyết theo định hướng với các thành viên trong nhóm và các bên liên quan.

Khả năng hiển thị suy nghĩ quan trọng, chất lượng theo định hướng, hoài nghi về sản phẩm.

Năng lực chủ động tích cực thu thập 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 của người dùng có thể kiểm thử, Tiêu chí chấp nhận.

Tài năng trở thành một thành viên nhóm tốt làm việc với các nhà phát triển trong việc sản xuất mã chất lượng.

Khả năng sử dụng các kỹ năng kiểm thử để có đúng các trường hợp kiểm thử vào đúng thời điểm và ở cấp độ phù hợp và thực hiện tốt trong thời gian chạy nước rút.

Khả năng đánh giá và báo cáo kết quả kiểm thử, tiến độ kiểm thử và chất lượng sản phẩm.

Tính mở để phản hồi nhanh chóng các thay đổi, bao gồm thay đổi, thêm hoặc cải thiện các trường hợp kiểm thử.

Tiềm năng để tự tổ chức công việc.

Nhiệt tình để tăng trưởng kỹ năng liên tục.

Năng lực trong Tự động hóa kiểm thử, Phát triển theo hướng thử nghiệm (TDD), Phát triển theo hướng thử nghiệm chấp nhận (ATDD), Phát triển dựa trên hành vi (BDD) và Thử nghiệm dựa trên kinh nghiệm.

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

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

Các hoạt động thử nghiệm Agile bao gồm

Đảm bảo sử dụng đúng các công cụ kiểm thử phần mềm.

Định cấu hình, sử dụng và quản lý các môi trường thử nghiệm và dữ liệu thử nghiệm.

Cố vấn cho các thành viên khác trong các lĩnh vực kiểm thử có liên quan.

Đảm bảo rằng các nhiệm vụ kiểm thử thích hợp được lên kế hoạch trong quá trình phát hành và lập kế hoạch chạy nước rút.

Hiểu, triển khai và cập nhật chiến lược kiểm thử.

Cộng tác với các nhà phát triển, khách hàng và các bên liên quan trong việc làm rõ các yêu cầu, về khả năng kiểm thử, nhất quán và đầy đủ.

Thực hiện các bài kiểm thử phần mềm đúng vào đúng thời điểm và ở các cấp độ kiểm thử phù hợp.

Báo cáo lỗi và làm việc với nhóm trong việc giải quyết chúng.

Đo lường và báo cáo phạm vi kiểm thử trên tất cả các thứ nguyên phạm vi áp dụng.

Tham gia vào các cuộc kiểm thử chạy nước rút, chủ động đề xuất và triển khai các cải tiến.

Trong Agile Lifecycle, một người kiểm thử đóng vai trò quan trọng trong

Làm việc theo nhóm

Kế hoạch kiểm thử phần mềm

Sprint Zero

Hội nhập

Thực hành thử nghiệm nhanh nhẹn

Làm việc theo nhóm

Trong phát triển Agile, tinh thần đồng đội là nền tảng và do đó yêu cầu những điều sau đây

Phương pháp tiếp cận hợp tác - Làm việc với các thành viên nhóm chức năng chéo về Chiến lược kiểm thử, Lập kế hoạch kiểm thử, Đặc tả kiểm thử, kiểm thử thực hiện, Đánh giá thử nghiệm và Báo cáo kết quả kiểm thử. Đóng góp chuyên môn kiểm thử cùng với các hoạt động nhóm khác.

Tự tổ chức - Lập kế hoạch và tổ chức tốt trong các cuộc chạy nước rút để đạt được các mục tiêu thử nghiệm bằng cách hợp nhất chuyên môn từ các thành viên khác trong nhóm.

Trao quyền - Đưa ra các quyết định kỹ thuật thích hợp để đạt được các mục tiêu của nhóm.

Cam kết - Cam kết hiểu và đánh giá hành vi và đặc điểm 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.

Minh bạch - Mở, Giao tiếp và có trách nhiệm.

Độ tin cậy - Đảm bảo độ tin cậy của chiến lược thử nghiệm, việc triển khai và thực thi chiến lược. Giữ khách hàng và các bên liên quan được thông báo về chiến lược thử nghiệm.

Mở để phản hồi - Tham gia vào các cuộc kiểm thử phần mềm chạy nước rút để học hỏi từ cả thành công lẫn 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 phân phôi.

Khả năng phục hồi - Phản hồi thay đổi.

Kế hoạch kiểm thử

Kế hoạch kiểm thử 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 lần chạy nước rút. Kế hoạch kiểm thử phải bao gồm các nhiệm vụ sau

Xác định phạm vi kiểm thử, mức độ kiểm thử, kiểm thử và mục tiêu chạy nước rút.

Quyết định môi trường thử nghiệm, công cụ kiểm thử, dữ liệu thử nghiệm và cấu hình.

Chỉ định thử nghiệm các tính năng và đặc điểm.

Lập kế hoạch nhiệm vụ kiểm thử và xác định tần suất kiểm thử.

Xác định các phương pháp thử nghiệm, kỹ thuật, công cụ và dữ liệu thử nghiệm.

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 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.

Thiết lập các ưu tiên xem xét tầm quan trọng của khách hàng / người dùng và phụ thuộc.

Đến thời gian và nỗ lực cần thiết để kiểm thử phần mềm.

Xác định các nhiệm vụ tại mỗi quy hoạch chạy nước rút.

Sprint Zero

Sprint Zero bao gồm các hoạt động chuẩn bị trước khi chạy nước rút đầu tiên. Người kiểm thử cần cộng tác với nhóm về các hoạt động sau -

Phạm vi xác định

Chia câu chuyện của người dùng thành chạy nước rút

Tạo kiến ​​trúc hệ thống

Công cụ lập kế hoạch, mua và cài đặt (bao gồm các công cụ kiểm thử)

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 số liệu kiểm thử

Chỉ định tiêu chí chấp nhận, còn được gọi là định nghĩa “Xong”

Xác định tiêu chí thoát

Tạo bảng Scrum

Đặt hướng thử nghiệm trong suốt các lần chạy nước rút

Hội nhập

Trong Agile, một sản phẩm làm việc có chất lượng sẽ sẵn sàng để phát hành tại bất kỳ thời điểm nào trong vòng đời phát triển. Điều này ngụ ý sự tích hợp liên tục như là một phần của sự phát triển. Trình kiểm thử 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 thử phần mềm 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 hàm và tính năng.

Thực hành thử nghiệm nhanh nhẹn

Một trình kiểm thử phần mềm Agile cần phải thích ứng với các thực hành Agile để thử nghiệm trong một dự án nhanh.

Ghép nối - Hai thành viên trong nhóm làm việc cùng nhau trên cùng một bàn phím. Là một trong số họ kiểm thử, các bài đánh giá / phân tích thử nghiệm khác. 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 nhà phân tích và một nhà phân tích nghiệp vụ

Hai người kiểm thử phần mềm

Thiết kế thử nghiệm gia tăng - 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 thử phần mềm đơn giản và chuyển sang các bài kiểm thử phức tạp hơn.

Mind Mapping - Bản đồ tư duy là một sơ đồ tổ chức thông tin một cách trực quan. Lập 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 thử cần thiết, các chiến lược kiểm thử phần mềm và dữ liệu thử nghiệm có thể được tổ chức.

Kiểm tra nhanh - Phương pháp

kiểm thử phần mềm Agile là một phương pháp phát triển 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 như tiến trình lặp lại, thông qua sự hợp tác giữa khách hàng và các nhóm tự tổ chức. Khi Mã hóa và Kiểm thử được thực hiện tương tác và từng bước, 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 tăng sản phẩm tích hợp và được phân phối cho Thử nghiệm chấp nhận của người dùng. Phản hồi của khách hàng do đó thu được sẽ là đầu vào cho các lần lặp tiếp theo / tiếp 

theo.

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

kiểm thử phần mềm Tích hợp liên tục là chìa khóa cho sự thành công của Agile Development. Tích hợp thường xuyên, ít nhất là hàng ngày như vậy mà bạn đã sẵn sàng cho một bản phát hành và 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ừ tất cả mọi người tham gia dự án sẽ bổ sung thêm chất lượng của sản phẩm.

Trong Agile, thông tin liên lạc được đưa ra vô cùng quan trọng và các yêu cầu của khách hàng được nhận và 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 làm việc 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 tập trung vào nhóm. Nó ủng hộ sự tham gia của toàn bộ nhóm trong tất cả các hoạt động phát triển dự án.

XP

Lập trình eXtreme là trung tâm khách hàng 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ẽ đáp ứng được yêu cầu của khách hàng chất lượng được làm rõ hơn trong suốt quá trình.

Pha lê

Tinh thể được dựa trên điều lệ, giao hàng tuần hoàn và gói gọn.

Điều lệ liên quan đến việc hình thành một nhóm phát triển, thực hiện một phân tích khả thi sơ bộ, đến một kế hoạch ban đầu và phương pháp phát triển.

Giao hàng tuần hoàn 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, triển khai vào môi trường người dùng, các đánh giá và phản ánh sau khi triển khai được thực hiện.

FDD

Tính năng phát triển Driven (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 cụ thể và ngắn.

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à được liên kết với Khung công tác Agile. DSDM tập trung vào việc phân phối thường xuyên sản phẩm, liên quan đến người dùng tích cực 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 Lean

Trong Phát triển phần mềm Lean, tập trung vào loại bỏ chất thải và đưa ra 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ị.

Chất thải bao gồm công việc được thực hiện 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, khuyết tật, vv sử dụng để thêm vào sự chậm trễ khi giao hàng.

Các nguyên tắc nạc là

Loại bỏ rác thải

Amplify Learning

Cam kết chậm trễ

Trao quyền cho nhóm

Cung cấp nhanh

Xây dựng tính toàn vẹn trong

Xem toàn bộ

Kanban

Kanban tập trung vào việc quản lý công việc với sự nhấn mạnh vào việc giao hàng đúng lúc (JIT), trong khi không quá tải 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 Nhóm để kéo công việc từ hàng đợi.

Kanban dựa trên

Ban Kanban (Trực quan và kiên trì trong suốt quá trình phát triển)

Giới hạn làm việc trong tiến trình (WIP)

Thời gian dẫn

Phương pháp kiểm thử phần mềm nhanh nhẹn

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

Viết Test Cases để thể hiện hành vi của hệ thống.

Phòng ngừa khiếm khuyết sớm, phát hiện và loại bỏ.

Đả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 độ kiểm thử phần mềm phù hợp.

Trong tất cả các phương pháp Agile mà chúng ta đã thảo luận, kiểm thử Agile trong chính nó là một phương pháp luận. Trong tất cả các phương pháp tiếp cận, 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 như là phương pháp thử nghiệm nhanh.

Các phương pháp kiểm thử phần mềm Agile thường được sử dụng khác là -

Phát triển theo hướng thử nghiệm (TDD) - Phát triển dựa trên thử nghiệm (TDD) dựa trên mã hóa được hướng dẫn bởi các bài kiểm thử phần mềm.

Phát triển dựa trên thử nghiệm chấp nhận (ATDD) - Phát triển dựa trên sự kiểm thử phần mềm 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 thử nghiệm và được thúc đẩy bởi các tiêu chí chấp nhận được chấp thuận trước và các trường hợp kiểm thử phần mềm chấp nhận.

Phát triển theo hướng hành vi (BDD) - Trong thử nghiệm phát triển theo hành vi (BDD) dựa trên hành vi dự kiến ​​của phần mềm đang được phát triển.

Vòng đời kiểm tra Agile

Trong Scrum, các hoạt động Thử nghiệm 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 mong đợi của Hệ thống được mô tả là Trường hợp kiểm thử phần mềm

Lập kế hoạch phát hành dựa trên nỗ lực kiểm thử phần mềm và lỗi

Lập kế hoạch Sprint dựa trên câu chuyện và lỗi của người dùng

Thực thi chạy nước rút với thử nghiệm liên tục

kiểm thử phần mềm hồi quy sau khi hoàn thành Sprint

Báo cáo kết quả kiểm thử phần mềm

Thử nghiệm tự động hóa

Thử nghiệm là lặp đi lặp lại và chạy nước rút dựa theo mô tả trong sơ đồ dưới đây -

Thử nghiệm thâm nhập - Vấn đề pháp lý

Trước khi cho phép ai đó Kiểm thử phần mềm dữ liệu nhạy cảm, các công ty thường thực hiện các biện pháp liên quan đến tính khả dụng, tính bảo mật và tính toàn vẹn của dữ liệu. 

Để thỏa thuận này được đưa ra, tuân thủ pháp lý là một hoạt động cần thiết cho một tổ chức.

Các quy định pháp lý quan trọng nhất phải được tuân thủ khi thiết lập và duy trì các hệ thống bảo mật và ủy quyền được trình bày dưới đây trong ngữ cảnh sử dụng trong việc thực hiện các thử nghiệm thâm nhập.

Kiểm thử phần mềm

Các vấn đề pháp lý là gì?

Sau đây là một số vấn đề có thể nảy sinh giữa người thử nghiệm và khách hàng của anh ấy

Người Kiểm thử phần mềm không biết khách hàng của anh ta - vì vậy, trên nền tảng nào, anh ta nên được cấp quyền truy cập dữ liệu nhạy cảm

Ai sẽ đảm bảo an toàn cho dữ liệu bị mất?

Khách hàng có thể đổ lỗi cho việc mất dữ liệu hoặc tính bảo mật đối với người Kiểm thử phần mềm

Thử nghiệm thâm nhập có thể ảnh hưởng đến hiệu suất của hệ thống, và có thể tăng cường các vấn đề bảo mật và toàn vẹn; do đó, điều này là rất quan trọng, ngay cả trong một thử nghiệm thâm nhập nội bộ, được thực hiện bởi một nhân viên nội bộ để có được sự cho phép bằng văn bản. Nên có một thỏa thuận bằng văn bản giữa người Kiểm thử phần mềm và công ty / tổ chức / cá nhân để làm rõ tất cả các điểm liên quan đến bảo mật dữ liệu, tiết lộ, vv trước khi bắt đầu thử nghiệm.

Một tuyên bố về ý định nên được lập và ký hợp lệ bởi cả hai bên trước bất kỳ công việc Kiểm thử phần mềm nào. Cần nêu rõ rằng phạm vi công việc và điều đó, bạn có thể và có thể không thực hiện được trong khi thực hiện các bài Kiểm thử phần mềm tính dễ bị tổn thương.

Đối với người Kiểm thử phần mềm, điều quan trọng là phải biết ai sở hữu doanh nghiệp hoặc hệ thống đang được yêu cầu làm việc và cơ sở hạ tầng giữa các hệ thống thử nghiệm và mục tiêu của họ có thể bị ảnh hưởng bởi thử nghiệm bút. Ý tưởng là để đảm bảo;

người Kiểm thử phần mềm có sự cho phép bằng văn bản, với các thông số được xác định rõ ràng.

công ty có các chi tiết của máy Kiểm thử phần mềm bút và đảm bảo rằng anh ta sẽ không rò rỉ bất kỳ dữ liệu bí mật nào.

Thỏa thuận pháp lý có lợi cho cả hai bên. Hãy nhớ rằng, các quy định thay đổi từ quốc gia này sang quốc gia khác, vì vậy hãy giữ cho bản thân tuân thủ luật pháp của quốc gia tương ứng. Ký một thỏa thuận chỉ sau khi xem xét các luật tương ứng.

Thử nghiệm thâm nhập - Xử lý

Các nỗ lực kiểm thử phần mềm thâm nhập - tuy nhiên, có thể không phải lúc nào cũng đảm bảo phát hiện đầy đủ mọi trường hợp mà hiệu quả của kiểm soát an ninh không đủ. 

Xác định một lỗ hổng tập lệnh cross-site hoặc rủi ro trong một khu vực của một ứng dụng có thể không chắc chắn phơi bày tất cả các trường hợp của lỗ hổng này trong ứng dụng. 

Học kiểm thử phần mềm

Chương này minh họa khái niệm và tiện ích của việc khắc phục.

Biện pháp khắc phục là gì?

Xử lý là một hành động cung cấp một sự cải tiến để thay thế một sai lầm và đặt nó đúng. Thường thì sự hiện diện của tính dễ bị tổn thương trong một khu vực có thể cho thấy sự yếu kém trong quá trình hoặc thực tiễn phát triển có thể nhân rộng hoặc kích hoạt tính dễ bị tổn thương tương tự ở các địa điểm khác. Do đó, trong khi khắc phục, điều quan trọng là người thử phải điều tra cẩn thận thực thể hoặc ứng dụng được thử nghiệm với các biện pháp kiểm soát bảo mật không hiệu quả trong tâm trí.

Vì những lý do này, công ty tương ứng nên thực hiện các bước để khắc phục mọi lỗ hổng có thể khai thác trong một khoảng thời gian hợp lý sau khi thử nghiệm thâm nhập ban đầu. Trong thực tế, ngay sau khi công ty đã hoàn thành các bước này, người kiểm thử phần mềm bút nên thực hiện kiểm thử phần mềm lại để xác nhận các điều khiển mới được thực hiện có khả năng giảm thiểu rủi ro ban đầu.

Các nỗ lực khắc phục kéo dài trong một thời gian dài hơn sau khi kiểm thử phần mềm bút ban đầu có thể yêu cầu thực hiện một thử nghiệm mới để đảm bảo kết quả chính xác của môi trường mới nhất. Quyết định này nên được thực hiện sau khi phân tích rủi ro về sự thay đổi đã xảy ra kể từ khi thử nghiệm ban đầu được hoàn thành.

Hơn nữa, trong điều kiện cụ thể, vấn đề an ninh được gắn cờ có thể minh họa một lỗ hổng cơ bản trong môi trường hoặc ứng dụng tương ứng. Do đó, phạm vi kiểm thử phần mềm lại nên xem xét liệu bất kỳ thay đổi nào gây ra bởi việc khắc phục được xác định từ thử nghiệm được phân loại là đáng kể. Tất cả các thay đổi cần được kiểm thử phần mềm lại; tuy nhiên, việc kiểm thử phần mềm lại toàn bộ hệ thống là cần thiết hay không sẽ được xác định bởi đánh giá rủi ro của các thay đổi.