Thử nghiệm thâm nhập - Phương pháp

Thử nghiệm thâm nhập là sự kết hợp các kỹ thuật xem xét các vấn đề khác nhau của hệ thống và kiểm thử phần mềm , phân tích và đưa ra các giải pháp. Nó được dựa trên một quy trình có cấu trúc thực hiện kiểm thử phần mềm  thâm nhập từng bước.

Chương này mô tả các bước hoặc giai đoạn thử nghiệm thâm nhập khác nhau.

Các bước của phương pháp kiểm thử phần mềm  thâm nhập

Sau đây là bảy bước thử nghiệm thâm nhập

Học kiểm thử

Lập kế hoạch & chuẩn bị

Lập kế hoạch và chuẩn bị bắt đầu với việc xác định các mục tiêu và mục tiêu của thử nghiệm thâm nhập.

Khách hàng và người kiểm thử phần mềm  cùng nhau xác định các mục tiêu để cả hai bên có cùng mục tiêu và sự hiểu biết. Các mục tiêu chung của thử nghiệm thâm nhập là -

Để xác định tính dễ bị tổn thương và cải thiện tính bảo mật của các hệ thống kỹ thuật.

Có bảo mật CNTT được xác nhận bởi bên thứ ba bên ngoài.

Tăng tính bảo mật của cơ sở hạ tầng tổ chức / nhân sự.

Trinh sát

Trinh sát bao gồm phân tích thông tin sơ bộ. Nhiều lần, người thử nghiệm không có nhiều thông tin ngoài thông tin sơ bộ, tức là địa chỉ IP hoặc khối địa chỉ IP. Người thử nghiệm bắt đầu bằng cách phân tích thông tin có sẵn và, nếu được yêu cầu, yêu cầu thêm thông tin như mô tả hệ thống, gói mạng, v.v. từ khách hàng. Bước này là thử nghiệm thâm nhập thụ động, một loại. Mục tiêu duy nhất là để có được một thông tin đầy đủ và chi tiết của các hệ thống.

Khám phá

Trong bước này, một trình kiểm thử phần mềm  thâm nhập sẽ rất có thể sử dụng các công cụ tự động để quét các tài sản đích để phát hiện các lỗ hổng. Những công cụ này thường có cơ sở dữ liệu riêng của họ cung cấp thông tin chi tiết về các lỗ hổng mới nhất. Tuy nhiên, người khám phá đã khám phá

Khám phá mạng - Chẳng hạn như khám phá các hệ thống, máy chủ và các thiết bị khác.

Host Discovery - Nó xác định các cổng mở trên các thiết bị này.

Dịch vụ thẩm vấn - Nó thẩm vấn cổng để khám phá các dịch vụ thực tế đang chạy trên chúng.

Phân tích thông tin và rủi ro

Trong bước này, người thử nghiệm sẽ phân tích và đánh giá thông tin được thu thập trước các bước kiểm thử phần mềm  để tự động thâm nhập hệ thống. Do số lượng hệ thống và quy mô cơ sở hạ tầng lớn hơn nên việc này tốn rất nhiều thời gian. Trong khi phân tích, người thử nghiệm xem xét các yếu tố sau -

Các mục tiêu xác định của kiểm thử phần mềm  thâm nhập.

Rủi ro tiềm tàng đối với hệ thống.

Thời gian ước tính cần thiết để đánh giá các lỗ hổng bảo mật tiềm ẩn cho phép thử thâm nhập hoạt động tiếp theo.

Tuy nhiên, từ danh sách các hệ thống đã xác định, trình kiểm thử phần mềm  có thể chọn chỉ kiểm thử phần mềm  những hệ thống có chứa các lỗ hổng tiềm ẩn.

Nỗ lực xâm nhập hoạt động

Đây là bước quan trọng nhất phải được thực hiện một cách cẩn trọng. Bước này đòi hỏi mức độ mà các lỗ hổng tiềm năng đã được xác định trong bước khám phá có các rủi ro thực tế. Bước này phải được thực hiện khi cần xác minh các lỗ hổng tiềm ẩn. Đối với những hệ thống có yêu cầu về tính toàn vẹn rất cao, khả năng dễ bị tổn thương và rủi ro cần được xem xét cẩn thận trước khi thực hiện các quy trình làm sạch quan trọng.

Phân tích cuối cùng

Bước này chủ yếu xem xét tất cả các bước được tiến hành (đã thảo luận ở trên) cho đến thời điểm đó và đánh giá các lỗ hổng có trong các rủi ro tiềm tàng. Hơn nữa, người thử nghiệm khuyên bạn nên loại bỏ các lỗ hổng và rủi ro. Trên tất cả, người thử nghiệm phải đảm bảo tính minh bạch của các thử nghiệm và các lỗ hổng mà nó được tiết lộ.

chuẩn bị báo cáo

Việc chuẩn bị báo cáo phải bắt đầu với các thủ tục kiểm thử phần mềm  tổng thể, sau đó là phân tích các lỗ hổng và rủi ro. Các rủi ro cao và các lỗ hổng nghiêm trọng phải có các ưu tiên và sau đó theo thứ tự thấp hơn.

Tuy nhiên, trong khi ghi lại báo cáo cuối cùng, các điểm sau cần được xem xét -

Tóm tắt tổng thể về kiểm thử phần mềm thâm nhập.

Chi tiết của từng bước và thông tin được thu thập trong quá trình thử nghiệm bút.

Chi tiết về tất cả các lỗ hổng và rủi ro được phát hiện.

Chi tiết làm sạch và sửa chữa hệ thống.

Gợi ý cho bảo mật trong tương lai.

Kiểm tra nhanh - Công cụ

kiểm thử phần mềm 

Trong các dự án Agile, Testers chịu trách nhiệm cho các công việc hàng ngày sau đây

Hỗ trợ các nhà phát triển viết mã, với sự giải thích về hành vi mong đợi của hệ thống.

Giúp các nhà phát triển tạo ra các bài kiểm thử phần mềm đơn vị hiệu quả và hiệu quả.

Phát triển các kịch bản tự động hóa.

Tích hợp các công cụ / tập lệnh thử nghiệm tự động hóa với tích hợp liên tục để kiểm thử phần mềm hồi quy.

Để thực hiện hiệu quả và nhanh chóng các tác 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.

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

Lưu ý - Các giải pháp Ghi lại và Phát lại, Thử nghiệm Cuối cùng, Nặng và Kiểm thử phần mềm Tự động hóa không nhanh như

Quy trình thử nghiệm 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ể duy trì được tạo bằng các công cụ như vậy trở thành một trở ngại để thay đổi

Những công cụ chuyên biệt như vậy tạo ra nhu cầu cho các chuyên gia tự động hóa thử nghiệm và do đó các tổ chức bồi dưỡng

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

S.No.	Công cụ & mục đích
1	Hudson CI Framework
2	Selenium Kiểm thử chức năng - Tích hợp với Hudson
3	CruiseControl CI Framework
4	Junit Kiểm thử đơn vị Java
5	Nunit .Net Unit Test
6	Cobertura / JavaCodeCoverage / JFeature / JCover / Phạm vi kiểm thử Java
7	hề Java - Thử nghiệm đột biến / Lỗi hạt giống tự động
số 8	Gretel Công cụ giám sát kiểm thử Java
9	TestCocoon C / C ++ hoặc C # - giảm số lượng kiểm thử bằng cách tìm các kiểm thử dự phòng và tìm mã chết
10	JAZZ Java - Branch, Node, và Defuse Coverage và triển khai GUI, các nhà lập kế hoạch thử nghiệm, thiết bị đo động và một bộ phân tích thử nghiệm
11	Kiến Java - Tự động xây dựng
12	Nant .Net - Tự động xây dựng
13	Lửa trại Agile Testing add-on cho JIRA

Công cụ tự động hóa thử nghiệm Agile

Các công cụ tự động hóa thử nghiệm Agile hiệu quả hỗ trợ

Tự động kiểm thử phần mềm sớm bằng cách sử dụng phương pháp thử nghiệm đầu tiên.

Viết mã tự động hóa thử nghiệm bằng ngôn ngữ thực, ngôn ngữ cụ thể của miền.

Tập trung vào hành vi mong đợi của hệ thống.

Tách bản chất của Bài kiểm thử phần mềm từ các chi tiết triển khai, do đó làm cho nó độc lập với Công nghệ.

Thúc đẩy hợp tác.

Các xét nghiệm đơn vị tự động (sử dụng Junit hoặc NUnit) hỗ trợ phương pháp tiếp cận thử nghiệm đầu tiên để mã hóa. Đây là các thử nghiệm hộp trắng và đảm bảo rằng thiết kế là âm thanh và không có lỗi. Các thử nghiệm như vậy được xây dựng bởi các nhà phát triển với sự hỗ trợ từ những người thử nghiệm 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 phân phối một sản phẩm có thể không đáp ứng các 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 kiểm thử phần mềm chấp nhận được viết với sự hợp tác của khách hàng, các bên liên quan khác, người thử nghiệm và nhà phát triển. Kiểm thử phần mềm 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 thử nghiệm chỉ tập trung vào việc chấp nhận, mã kết quả có thể vẫn không thể mở rộng.

Do đó, các bài kiểm thử phần mềm đơn vị tự động và các bài kiểm thử phần mềm 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à khung công cụ Agile hỗ trợ Kiểm thử phần mềm chấp nhận tự động là

Phù hợp

Fitnesse

Concordion

Ruby

Quả dưa chuột

Phù hợp

Ward Cunningham đã phát triển công cụ Fit có thể được sử dụng cho Tự động kiểm thử phần mềm chấp nhận. Fit cho phép

Khách hàng hoặc Chủ sở hữu sản phẩm cung cấp ví dụ về hành vi sản phẩm bằng cách sử dụng Microsoft Word và Microsoft Excel

Các lập trình viên dễ dàng biến những ví dụ đó thành các bài kiểm thử phần mềm 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 việc 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 văn bản, gạch dưới và in nghiêng, tạo danh sách có dấu đầu dòng và thực hiện các định dạng đơn giản khác.

Trong FitNesse, Tự động kiểm thử phần mềm chấp nhận như sau:

Kiểm thử phần mềm nhanh 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 thử nghiệm trên trang mà bạn có thể chỉnh sửa.

Ngoài ra, hãy đặt bảng thử nghiệm trong Microsoft Excel, sao chép vào khay nhớ tạm và sau đó sử dụng lệnh Bảng tính để FitNesse để có 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ả kiểm thử phần mề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ây đại diện cho các giá trị mong đợi thu được

các tế bào màu đỏ biểu thị rằng một giá trị khác với những gì bạn mong đợi thu được

các tế bào màu vàng biểu thị rằng một ngoại lệ đã được ném

Quả dưa chuột

Dưa chuột là một công cụ dựa trên khung hành vi phát triển 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 thử phần mềm chấp nhận cho các ứng dụng web.

Cho phép tự động hóa xác thực 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 đó mở rộng sang khung công tác 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.

Kiểm thử nhanh - Kanban

Các hoạt động thử nghiệm nhanh có thể được quản lý hiệu quả bằng các khái niệm Kanban. Sau đây đảm bảo thử nghiệm được hoàn thành trong thời gian trong vòng lặp / chạy nước rút và do đó tập trung vào việc phân phối sản phẩm chất lượng.

kiểm thử phần mềm

Câu chuyện của người dùng có thể kiểm thử phần mền và kích thước có hiệu quả dẫn đến phát triển và thử nghiệm trong giới hạn thời gian đã chỉ định.

Giới hạn WIP (Work-In-Progress) cho phép tập trung vào một số lượng giới hạn các câu chuyện của người dùng tại một thời điểm.

Ban 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 kiểm thử 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ị các trường hợp kiểm thử trả trước, duy trì bộ kiểm thử khi tiến trình phát triển và thu được phản hồi của khách hàng giúp loại bỏ các lỗi trong vòng lặp / chạy nước rút.

Định nghĩa của Done (DoD) được cho là Done-Done theo nghĩa là Story chỉ đạt trạng thái hoàn thành sau khi thử nghiệm cũng được hoàn thành.

Các 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 với tính năng ban Kanban. Các tính năng cho một bản phát hành cụ thể được gán cho bảng Tính năng Kanban theo dõi trạng thái phát triển tính năng một cách trực quan.

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.

Các hoạt động kiểm thử Agile sau đảm bảo phân phối 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

Những người kiểm thử tham gia vào Tạo Câu chuyện của 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 đều được ghi lại bằng các Câu chuyện của Người dùng và các Yêu cầu Không phải chức năng là một phần của Câu chuyện của Người dùng.

Câu chuyện của người dùng có thể kiểm thử.

Kích thước của các câu chuyện của người dùng cho phép phát triển và kiểm thử được hoàn thành (DoneDone) trong Iteration.

Visual Task Kanban Board

Mô tả trạng thái và tiến trình của Công việc

Các nút cổ chai được xác định ngay lập tức khi chúng xảy ra

Tạo điều kiện để đo thời gian chu kỳ mà sau đó có thể được tối ưu hóa

Cộng tác nhóm giúp trong

Trách nhiệm của toàn bộ Nhóm sản phẩm Chất lượng

Độ phân giải của tắc nghẽn và khi chúng xảy ra, tiết kiệm thời gian chờ đợi

Đóng góp của mọi chuyên môn trong mọi hoạt động

Tích hợp liên tục tập trung vào thử nghiệm tích hợp liên tục

Tự động hóa các thử nghiệm để tiết kiệm nỗ lực và thời gian thử nghiệm

Phòng ngừa khiếm khuyết với các trường hợp thử nghiệm được viết trước đó để phát triển và tư 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ác câu chuyện của người dùng tại một thời điểm

Kiểm thử liên tục khi quá trình phát triển diễn ra, để đảm bảo Sửa lỗi trong vòng lặp

Đảm bảo phạm vi kiểm thử

Giữ số lỗi mở thấp

Khám phá câu chuyện

Khám phá câu chuyện là thông tin liên lạc 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 để chấp nhận phát triển.

Chủ sở hữu sản phẩm sẽ đư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 sẽ khám phá nhiều hơn về từng câu chuyện trước khi họ đánh dấu nó sẵn sàng để chấp nhận. Những người kiểm thử  cũng tham gia vào việc giao tiếp từ góc nhìn thử nghiệm để làm cho nó trở nên khả thi nhất có thể.

Việc hoàn thiện Câu chuyện dựa trên giao tiếp liên tục 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

Việc ước tính diễn ra trong Kế hoạch phát hành và lập kế hoạch lặp lại.

Trong Kế hoạch phát hành, những người thử nghiệm cung cấp

Thông tin về hoạt động thử nghiệm nào là bắt buộc

Ước tính nỗ lực cho cùng một

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

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

Do đó, Ước tính thử nghiệm đóng vai trò chính 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 Iteration hiện tại.

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

Chuẩn bị dữ liệu thử nghiệm

Mở rộng kiểm thử chấp nhận

Thực hiện kiểm thử thủ công

Tiến hành các phiên kiểm thử Exploratory

Tự động kiểm thử tích hợp liên tục

Ngoài các nhiệm vụ kiểm thử 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 thử năng suất

Kiểm thử hồi quy

Cập nhật các kiểm thử tích hợp liên tục liên quan

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

Story Progression phát hiện các bài kiểm thử bổ sung được yêu cầu do liên lạc liên tục giữa các nhà phát triển và người thử nghiệm. Trong các tình huống mà các 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 kiểm thử thăm dò.

Kiểm thử liên tục được thực hiện trong quá trình tiến triển câu chuyện và bao gồm kiểm thử 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

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

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

Kiểm thử nhanh - Sản phẩm công việc

Kế hoạch kiểm thử phần mềm đượ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 quy hoạch Sprint. Kế hoạch kiểm thử phần mềm hoạt động như một hướng dẫn cho quá trình thử nghiệm để có phạm vi kiểm thử phần mềm hoàn chỉnh.

kiểm thử phần mềm

Nội dung điển hình của một kế hoạch thử nghiệm là

Chiến lược kiểm thử phần mềm 

Môi trường thử nghiệm

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

Phạm vi thử nghiệm

Kiểm thử phần mềm nỗ lực và lịch trình

Công cụ kiểm thử phần mềm 

Trong các dự án Agile, tất cả các Thành viên Nhóm 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 tham gia vào kế hoạch kiểm thử phần mềm là tốt.

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

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

Câu chuyện của người dùng không thử nghiệm sản phẩm công việc theo nguyên tắc. Tuy nhiên, trong các Dự án Agile, những người thử nghiệm tham gia vào Tạo Câu chuyện của Người dùng. Người thử nghiệm viết Câu chuyện của 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ể khác nhau của hệ thống.

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

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

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

Bài kiểm thử phần mềm đơn vị

Kiểm thử phần mềm tích hợp

Kiểm thử phần mềm chức năng

Kiểm thử phần mềm phi chức năng

Kiểm thử phần mềm chấp nhận

Các thử nghiệm sau đó được tự động cho các lần chạy tiếp theo.

Trong Test Driven Development , Unit Test được viết đầu tiên thất bại, Code được phát triển và thử nghiệm để đảm bảo các bài kiểm thử phần mềm vượt qua.

Trong Kiểm thử phần mềm chấp nhận phát triển theo hướng , Kiểm thử phần mềm chấp nhận được viết đầu tiên không thành công, Mã được phát triển và kiểm thử phần mềm để đảm bảo các bài  vượt qua.

Trong các phương pháp Phát triển khác, các Testers cộng  tác với các thành viên khác của Nhóm để đảm bảo Kiểm thử phần mềm Bảo hiểm.

Trong tất cả các loại phương thức, việc tích hợp liên tục diễn ra, bao gồm thử nghiệm tích hợp liên tục.

Nhóm có thể quyết định khi nào và những thử nghiệm nào sẽ được tự động hóa. Ngay cả khi tự động hóa các bài kiểm thử phần mềm đòi hỏi nỗ lực và thời gian, kết quả kiểm thử phần mềm tự động làm giảm đáng kể nỗ lực thử nghiệm lặp đi lặp lại và thời gian trong các lần lặp của dự án Agile. Điều này lần lượt tạo điều kiện cho nhóm chú ý hơn đến các hoạt động cần thiết 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 lại được đóng khung thời gian. Do đó, nếu không thể hoàn thành việc kiểm thử phần mềm Câu chuyện của người dùng trong Sprint cụ thể, người kiểm thử phần mềm có thể báo cáo trong cuộc họp standup hàng ngày mà câu chuyện của người dùng không thể đạt được Trạng thái đã hoàn thành trong Sprint đó và do đó cần được giữ cho Sprint tiếp theo.

Kết quả kiểm thử

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 các bản ghi kết quả kiểm thử phần mềm cần thiết. Người thử nghiệm xem lại Nhật ký kết quả thử nghiệm. Các kết quả kiểm thử phần mềm cần phải được duy trì cho mỗi lần chạy nước rút / giải phóng.

Bản tóm tắt thử nghiệm cũng có thể được chuẩn bị có chứa -

Phạm vi kiểm thử phần mềm (Điều gì đã được kiểm thử phần mềm và những gì không được kiểm thử phần mềm )

Phân tích lỗi cùng với Phân tích nguyên nhân gốc nếu có thể

Trạng thái kiểm thử phần mềm hồi quy sau khi sửa lỗi

Các vấn đề và độ phân giải tương ứng

Các sự cố đ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

Chỉ số kiểm thử phần mềm 

Báo cáo chỉ số thử nghiệm

Trong các dự án Agile, các chỉ số kiểm thử phần mềm a bao gồm những điều sau cho mỗi Sprint -

Nỗ lực thử nghiệm

Kiểm thử phần mềm độ chính xác ước tính

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

Phạm vi kiểm thử phần mềm tự động

Số lỗi

Tỷ lệ lỗi (Số lỗi trên mỗi điểm câu chuyện của người dùng)

Lỗi nghiêm trọng

Thời gian để khắc phục lỗi trong cùng một Sprint (Chi phí càng nhiều càng nhiều để khắc phục lỗi thoát khỏi chạy nước rút hiện tại)

Số lỗi được khắc phục trong cùng Sprint

Hoàn thành kiểm thử phần mềm chấp nhận của khách hàng trong Sprint

Báo cáo đánh giá và hồi tưởng Sprint

Những người kiểm thử phần mềm cũng đóng góp cho Báo cáo đánh giá và hồi tưởng Sprint. Các nội dung điển hình là

Chỉ số kiểm thử

Nhật ký kết quả kiểm thử phần mềm kết quả đánh giá

Điều gì đã đúng và những gì có thể được cải thiện từ Điểm kiểm thử phần mềm xem

Thực hành tốt nhất

Bài học kinh nghiệm

Vấn đề

Phản hồi của khách hàng

Kiểm tra nhanh - Kỹ thuật

Kỹ thuật thử nghiệm từ thử nghiệm truyền thống cũng có thể được sử dụng trong thử nghiệm Agile. Thêm vào đó, các kỹ thuật và thuật ngữ thử nghiệm cụ thể của Agile được sử dụng trong các dự án Agile.

kiểm thử phần mềm

Cơ sở kiểm thử

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 việc tồn đọng sản phẩm thường là những câu chuyện của người dùng. Các yêu cầu phi chức năng cũng được chú ý 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 của người dùng.

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

Trải nghiệm từ các lần lặp lại trước đó của cùng một dự án hoặc các dự án trước đây.

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 của Done

Định nghĩa Hoàn thành (DoD) là các 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 phần tồn đọng của Sprint. 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à một danh sách kiểm thử 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 một câu chuyện của 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 của người dùng. Câu chuyện của người dùng đạt đến giai đoạn Xong sau khi tất cả các mục trong danh sách kiểm thử  DoD được hoàn thành. Một DoD được chia sẻ giữa các nhóm.

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

Tiêu chí chấp nhận kiểm thử chi tiết

Tiêu chí để đảm bảo tính nhất quán của User Story với những người khác trong Iteration

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

Giao diện

Yêu cầu dữ liệu thử nghiệm

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

Tái cấu trúc

Yêu cầu xem xét và phê duyệt

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

ở mọi cấp độ kiểm thử 

cho từng tính năng

cho mỗi lần lặp lại

để phát hành

Thông tin kiểm thử

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

Câu chuyện của người dùng cần được kiểm thử 

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 được mong đợi sẽ hoạt động

Tính khả dụng của công cụ

Kiểm thử 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 thử nghiệm được cho là làm việc trong một chế độ cộng tác, đó là trách nhiệm của người kiểm thử

Có được thông tin kiểm thử  cần thiết trên cơ sở liên tục.

Xác định khoảng trống thông tin ảnh hưởng đến thử nghiệm.

Giải quyết các khoảng trống cộng tác với các thành viên khác trong nhóm.

Quyết định khi nào đạt đến mức thử nghiệm.

Đảm bảo các thử nghiệm thích hợp được thực hiện tại các thời điểm thích hợp.

Thiết kế thử nghiệm chức năng và phi chức năng

Trong các dự án Agile, các kỹ thuật thử nghiệm truyền thống có thể được sử dụng, nhưng trọng tâm là thử nghiệm sớm. Các trường hợp thử nghiệm cần phải được đặt 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 tiếp tiểu bang

Class Tree

Đối với thiết kế thử nghiệm 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 của người dùng, các kỹ thuật thiết kế thử nghiệm hộp đen chỉ có thể được sử dụng để thiết kế các trường hợp kiểm thử có 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 cho 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 kiểm thử thăm dò có thể được kết hợp với các kỹ thuật thử nghiệm truyền thống.

Kiểm thử thăm dò (ET) được định nghĩa là học tập đồng thời, thiết kế thử nghiệm và thực hiện kiểm thử . Trong thử nghiệm Exploratory, người thử nghiệm chủ động kiểm soát thiết kế của các bài kiểm thử 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 bài kiểm thử mới và tốt hơn.

Kiểm thử Exploratory có ích để thích ứng với các thay đổi trong các dự án Agile.

Thử nghiệm 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 nguy cơ 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 chất lượng sản phẩm có thể được xác định là một vấn đề tiềm ẩn với chất lượng sản phẩm. Rủi ro chất lượng sản phẩm bao gồm

Rủi ro chức năng

Rủi ro hiệu suất phi chức năng

Rủi ro khả năng sử dụng phi chức năng

Phân tích rủi ro phải được thực hiện để đánh giá xác suất (khả năng) 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 rộng rãi

Rủi ro thấp chỉ yêu cầu kiểm thử Cursory

Các thử nghiệm được thiết kế bằng cách sử dụng các kỹ thuật kiểm thử phù 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 thử phù hợp

Fit Tests là Kiểm thử 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 kiểm thử. Các bảng HTML được sử dụng để hiển thị các trường hợp Kiểm thử. Lịch thi đấu là một lớp Java phía sau bảng HTML. Lịch thi đấu 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.

tester nhanh trong nhó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.

Học 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.

học tester

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

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 tra, 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 tra để có đúng các trường hợp kiểm tra 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 tra, tiến độ kiểm tra 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 tra.

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 tra, 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 trải nghiệm.

Vai trò của Tester trokiểm thửng 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 .

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

Đị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 tra có liên quan.

Đảm bảo rằng các nhiệm vụ thử nghiệm 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 tra, nhất quán và đầy đủ.

Thực hiện các bài kiểm tra đúng vào đúng thời điểm và ở các cấp độ kiểm tra 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 tra 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 tra 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 tra

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 tra, Lập kế hoạch kiểm tra, Đặc tả kiểm tra, Kiểm tra thực hiện, Đánh giá thử nghiệm và Báo cáo kết quả kiểm tra. Đó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 kiểm tra.

Mở để phản hồi - Tham gia vào các cuộc kiểm tra 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 tra

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

Xác định phạm vi kiểm tra, mức độ kiểm tra, kiểm tra 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 tra, 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 tra và xác định tần suất kiểm tra.

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.

Đặt 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 tra.

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

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 tra 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 hàm và tính năng.

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

Một trình kiểm tra 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 tra, 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 tra

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 tra đơn giản và chuyển sang các bài kiểm tra 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 tra cần thiết, các chiến lược kiểm tra và dữ liệu thử nghiệm có thể được tổ chức.

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

Trong thử nghiệm Agile, các phương pháp thử nghiệm thường được sử dụng là từ các phương pháp truyền thống và được căn chỉnh theo nguyên tắc - Kiểm thử  phần mêm sớm. Các trường hợp thử nghiệm được viết trước khi mã được viết. Sự nhấn mạnh 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à ở mức phù hợp.

kiểm thử phần mềm

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

Kiểm thử phát triển theo hướng (TDD)

Phát triển thử nghiệm chấp nhận thử nghiệm (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 thử nghiệm (TDD), mã được phát triển dựa trên phương pháp Testfirst được chỉ dẫn bởi các trường hợp kiểm thử tự động. Một trường hợp thử nghiệm được viết đầu tiên để thất bại, mã được phát triển dựa trên đó để đảm bảo rằng các thử nghiệm vượt qua. Phương pháp được lặp đi lặp lại, 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ự giúp đỡ của các bước sau:

Bước 1 - Viết một trường hợp Kiểm thử để phản ánh hành vi mong đợi của chức năng của mã cần được viết.

Bước 2 - Chạy thử nghiệm. Kiểm thử không thành công vì mã vẫn chưa được phát triển.

Bước 3 - Phát triển mã dựa trên trường hợp thử nghiệm.

Bước 4 - Chạy lại kiểm thử . Lần này, bài kiểm thử 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 thử trôi qua.

Bước 5 - Refactor mã.

Bước 6 - Chạy lại kiểm thử để đảm bảo nó vượt qua.

Lặp lại bước 1 - Bước 6 thêm các trường hợp thử nghiệm để thêm chức năng. Các bài kiểm thử bổ sung và các bài kiểm thử trước đó được chạy mỗi lần để đảm bảo mã đang chạy như mong đợi. Để thực hiện quá trình này nhanh chóng, các bài kiểm thử được tự động hóa.

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

Chấp nhận thử nghiệm phát triển theo hướng

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

Bước 1 - Viết các trường hợp kiểm thử chấp nhận cùng với các câu chuyện của người dùng phối hợp với khách hàng và người dùng.

Bước 2 - Xác định các tiêu chí chấp nhận được liên kết.

Bước 3 - Xây dựng mã dựa trên các bài kiểm thử chấp nhận và các tiêu chí chấp nhận.

Bước 4 - Chạy thử nghiệm chấp nhận để đảm bảo rằng mã đang chạy như mong đợi.

Bước 5 - Tự động hóa các bài kiểm thử chấp nhận. Lặp lại Bước 3 - Bước 5 cho đến khi tất cả các câu chuyện của người dùng trong lần lặp được thực hiện.

Bước 6 - Tự động hóa các phép thử hồi quy.

Bước 7 - Chạy các kiểm thử hồi quy tự động để đảm bảo Continuous Regression.

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

Phát triển điều khiển hành vi (BDD) tương tự như Phát triển theo hướng thử nghiệm (TDD) và trọng tâm là thử nghiệm 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 với người dùng, người thử nghiệm 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.

Minh bạch về những gì đang được phát triển và thử nghiệm.

Kiểm thử nhanh - Scrum (Tester)

Scrum ủng hộ phương pháp tiếp cận toàn đội , 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 cho các bản phân phối dự án. 

kiểm thử phần mềm

Việc ra quyết định được để lại cho nhóm nhằm đưa ra các hành động thích hợp được thực hiện vào đúng thời điểm mà không bị chậm trễ thời gian. Cách tiếp cận này cũng khuyến khích sử dụng đúng đắn tài năng của đội thay vì hạn chế một hoạt động. Những người kiểm thử phần mềm cũng tham gia vào tất cả các hoạt động dự án và phát triển đóng góp chuyên môn của họ trong thử nghiệm.

Cả nhóm làm việc cùng nhau trên Chiến lược kiểm thử , Lập kế hoạch kiểm thử , Đặc tả kiểm thử , Kiểm thử thực thi, Đánh giá thử nghiệm và Báo cáo kết quả kiểm thử .

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

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

Người thử nghiệm cũng đưa ra Tiêu chí chấp nhận cho mọi trường hợp được khách hàng đồng ý.

Người thử nghiệm đóng góp vào việc tạo ra những câu chuyện của người dùng có thể kiểm chứng.

Kế hoạch phát hành

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

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

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

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

Lập kế hoạch chạy nước rút được thực hiện vào đầu mỗi lần chạy nước rút. Các backlog chạy nước rút được tạo ra với những câu chuyện người dùng được chọn từ việc tồn đọng sản phẩm để thực hiện trong lần chạy nước rút cụ thể đó.

Những người kiểm thử nên 

Xác định khả năng kiểm thử các câu chuyện của người dùng được chọn cho lần chạy nước rút

Tạo kiểm thử chấp nhận

Xác định mức độ kiểm thử 

Xác định tự động hóa thử nghiệm

Người thử nghiệm cập nhật kế hoạch thử nghiệm với các ước tính cho nỗ lực thử nghiệm và thời lượng trong lần chạy nước rút. Điều này đảm bảo cung cấp thời gian cho các thử nghiệm cần thiết trong thời gian chạy nước rút có đóng hộp và cũng chịu trách nhiệm về nỗ lực kiểm thử .

Phân tích thử nghiệm

Khi chạy nước rút bắt đầu, khi các nhà phát triển thực hiện phân tích câu chuyện để thiết kế và thực hiện, người thử nghiệm thực hiện phân tích thử nghiệm cho các câu chuyện trong phần tồn đọng chạy nước rút. Tester tạo các trường hợp kiểm thử bắt buộc - cả kiểm thử 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 thử đơn vị khi họ phát triển mã cho các câu chuyện của người dùng. Kiểm thử đơn vị được tạo ra trong mỗi lần chạy nước rút, trước khi mã được viết. Các trường hợp thử nghiệm đơn vị có nguồn gốc từ các thông số kỹ thuật thiết kế cấp thấp.

Những người thử nghiệm thực hiện các tính năng chức năng và phi chức năng của các câu chuyện của người dùng.

Những người thử nghiệm cố vấn cho các thành viên khác trong nhóm scrum với chuyên môn của họ trong thử nghiệm để toàn bộ nhóm sẽ có trách nhiệm đối với chất lượng của sản phẩm.

Vào cuối của nước rút, khách hàng và / hoặc người dùng cuối thực hiện Kiểm thử chấp nhận của người dùng và cung cấp phản hồi cho nhóm scrum. Điều này tạo thành đầu vào cho lần chạy nước rút tiếp theo.

Kết quả kiểm thử được thu thập và duy trì.

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

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

Kiểm thử thủ công tập trung nhiều hơn vào kiểm thử thăm dò, lỗ hổng sản phẩm, dự đoán lỗi.

Tự động hóa hoạt động thử nghiệm

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

Tạo dữ liệu thử nghiệm

Tải dữ liệu thử nghiệm

Xây dựng triển khai vào môi trường thử nghiệm

Kiểm thử quản lý môi trường

So sánh đầu ra dữ liệu

Kiểm thử hồi quy

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

Quản lý cấu hình

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

Các trường hợp kiểm thử thủ công, thử nghiệm tự động, dữ liệu thử nghiệm, kế hoạch kiểm thử, chiến lược thử nghiệm và các hiện vật thử nghiệm khác cần phải được kiểm soát phiên bản và yêu cầu quyền truy cập có liên quan được đảm bảo. Điều này có thể được thực hiện bằng cách duy trì các hiện vật thử nghiệm trong hệ thống quản lý cấu hình.

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

Những người kiểm thử trong Nhóm Scrum có thể làm theo các Thực tiễn Nhanh nhẹn sau đây -

Ghép nối - Hai Thành viên Nhóm ngồi lại với nhau và làm việc cộng tác. Hai người có thể là hai Testers hoặc một Tester và một Developer.

Thiết kế thử nghiệm gia tăng - Các trường hợp thử nghiệm được phát triển khi tiến trình chạy nước rút tăng dần và Câu chuyện của người dùng được thêm vào.

Chỉ số nhanh

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

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

Tỷ lệ chạy nước rút thành công - (Số lần chạy nước rút thành công / Tổng số lần chạy nước rút) * 100 . Một Sprint thành công là một trong đó Đội có thể đáp ứng cam kết của mình.

Vận tốc - Vận tốc của một đội dựa trên số điểm của Điểm Câu chuyện mà một đội kiếm được trong một lần chạy nước rút. Điểm câu chuyện là thước đo của Câu chuyện của người dùng được tính trong quá trình ước tính.

Yếu tố trọng tâm - (Vận tốc / Năng lực làm việc của đội) / 100 . Yếu tố trọng tâm là tỷ lệ phần trăm nỗ lực của nhóm mà kết quả trong các câu chuyện đã hoàn thành.

Độ chính xác ước tính - (Nỗ lực dự tính / Nỗ lực thực tế) / 100 . Độ chính xác ước tính là khả năng của nhóm trong việc ước tính nỗ lực một cách chính xác.

Sprint Burndown - Công việc (trong Story Points hoặc trong giờ) đó là còn lại Vs. Công việc cần được giữ lại lý tưởng (theo ước tính).

Nếu nó là nhiều hơn, sau đó nó có nghĩa là đội đã thực hiện nhiều công việc hơn là họ có thể làm.

Nếu nó ít hơn, thì điều đó có nghĩa là Đội đã không Ước tính chính xác.

Defect Count - Số lỗi trong Sprint. Số lỗi là số lượng lỗi trong phần mềm chống lại việc tồn đọng.

Mức độ nghiêm trọng của khuyết tật - Khuyết tật có thể được phân loại là nhỏ, lớn và quan trọng theo mức độ nghiêm trọng của chúng. Người thử nghiệm có thể xác định phân loại.

Sprint Retrospectives

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

Những điều đã diễn ra tốt đẹp

Số liệu

Phạm vi cải tiến

Các mục tác vụ cần áp dụng

kiểm thử Góc phần tư

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

Kiểm thử đơn vị
Thử nghiệm hội nhập

Thử nghiệm hệ thống

Kiểm thử chấp nhận người dùng

Kiểm thử đơn vị

Hoàn thành cùng với Mã hóa, bởi Nhà phát triển

Được hỗ trợ bởi Tester, người viết Test Cases, đảm bảo 100% Bảo hiểm 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 thử đơn vị được tự động

Thử nghiệm hội nhập

Thực hiện cùng với tích hợp liên tục khi tiến trình chạy nước rút

Hoàn tất ở cuối sau khi tất cả Sprint được hoàn thành

Tất cả các yêu cầu chức năng được kiểm thử 

Tất cả các giao diện giữa các đơn vị được kiểm thử 

Tất cả các lỗi đã được báo cáo

Các thử nghiệm được tự động hóa nếu có thể

Thử nghiệm hệ thống

Đã hoàn thành khi Tiến trình phát triển

Câu chuyện, tính năng và chức năng của người dùng được kiểm thử 

Thử nghiệm được thực hiện trong môi trường sản xuất

Kiểm thử chất lượng được thực hiện (Hiệu suất, Độ tin cậy, v.v.)

Lỗi được báo cáo

Các thử nghiệm được tự động hóa nếu có thể

Kiểm thử chấp nhận người dùng

Hoàn thành vào cuối mỗi Sprint và ở cuối dự án

Thực hiện bởi khách hàng. 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 thử và được xác định với Tiêu chí chấp nhận

Loại thử nghiệm

Kiểm thử thành phần (Kiểm thử đơn vị)

Kiểm thử chức năng (Kiểm thử câu chuyện của người dùng)

Kiểm thử không hoạt động (Hiệu suất, Tải, Căng thẳng, v.v.)

Kiểm thử chấp nhận

Các bài kiểm thử  có thể hoàn toàn Thủ công, hoàn toàn Tự động, Kết hợp Hướng dẫn sử dụng và Tự động hoặc Thủ công được Công cụ hỗ trợ.

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

Các xét nghiệm có thể cho

Hỗ trợ phát triển (Hỗ trợ lập trình) - Hỗ trợ lập trình thử nghiệm đượ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 một Hệ thống

Những thử nghiệm nào cần được chạy sau khi mã hóa để đảm bảo Mã mới không cản trở phần còn lại của các hành vi của hệ thống

Chỉ xác minh (Sản phẩm phê bình) - Các bài kiểm thử sản phẩm phê bình được sử dụng để phát hiện những bất cập trong Sản phẩm hoàn chỉnh

Đối mặt với kinh doanh và công nghệ Đối mặt với thử nghiệm

Để quyết định thử nghiệm nào sẽ được thực hiện khi nào, bạn cần xác định xem thử nghiệm có phải là

Đối mặt với doanh nghiệp, hoặc

Đối mặt với công nghệ

Kiểm thử đối mặt với doanh nghiệp

Thử nghiệm là một bài kiểm thử đối mặt với doanh nghiệp nếu nó trả lời các câu hỏi được đóng khung với các từ từ tên miền kinh doanh. Đây là những hiểu biết của các chuyên gia kinh doanh và sẽ quan tâm 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.

Công nghệ Đối mặt với thử nghiệm

Thử nghiệm là một thử nghiệm công nghệ nếu nó trả lời các câu hỏi được đóng khung với các từ từ miền 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 các giải thích về công nghệ.

Hai khía cạnh của các loại thử nghiệm có thể được xem bằng cách sử dụng các góc độ thử nghiệm nhanh được xác định bởi Brian Marick.

Thử thách nhanh nhẹn

Kết hợp hai khía cạnh của các loại thử nghiệm, các phần tư thử nghiệm Agile sau đây được bắt nguồn từ Brian Marick

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

Các phần tư thử nghiệm Agile cung cấp một 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 các thử nghiệm cần thiết.

Quadrant Q1 - Unit Level, Technology Facing và hỗ trợ các nhà phát triển. Các bài kiểm thử đơn vị thuộc về Quadrant này. Các bài kiểm thử này có thể là các bài kiểm thử Tự động hóa.

Quadrant Q2 - Mức hệ thống, mặt doanh nghiệp và hành vi sản phẩm phù hợp. Các bài kiểm thử chức năng thuộc về góc phần tư này. Các xét nghiệm này là thủ công hoặc tự động.

Quadrant Q3 - Hệ thống hoặc Cấp độ chấp nhận người dùng, Đối mặt với doanh nghiệp và tập trung vào các tình huống thời gian thực. Kiểm thử chấp nhận của người dùng thuộc về góc phần tư này. Các xét nghiệm này là thủ công.

Quadrant Q4 - Hệ thống hoặc Cấp độ chấp nhận 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, bảo trì, kiểm thử 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, các phần tư thử nghiệm nhanh nhẹn phản ánh những gì-kiểm thử -khi có thể được hình dung như sau

học kiểm thử

Kiểm thử - Các 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ử Agile.

Lợi ích kiểm thử Agile

Những lợi ích của thử nghiệm Agile là

ảnh minh họa

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 thông tin 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 thử nghiệm nhanh chóng 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ử phần mêm của họ để tập trung vào những gì có thể thực hiện được.

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

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 tổng hợp 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 bộ nhóm.

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

Phản hồi nhanh chóng để thay đổi yêu cầu và sớm đáp ứng chúng.

Kiểm thử hồi quy liên tục điều khiển hồi quy.

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

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

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

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

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 ở mọi cấp độ.

Người thử nghiệm tham gia vào định nghĩa 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.

Những 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.

Kiểm thử các 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 trạng thái kiểm thử và tiến độ kiểm thử nhanh chóng 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 kiểm thử 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, hãy tận dụng thử nghiệm tự động hóa như một cách hiệu quả.

Những thách thức trong thử nghiệm nhanh nhẹn

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ó bởi Business and Management có thể dẫn đến những kỳ vọng không thể thực hiện được.

Agile theo phương pháp tiếp cận toàn đội, nhưng không phải ai cũng biết các yếu tố cần thiết của thực hành kiểm thử. Người kiểm thử 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ể thực hiện với Sprints có thời gian đóng (Iterations).

Phương pháp tiếp cận thử nghiệm đầu tiên yêu cầu Nhà phát triển căn cứ mã hóa trên phản hồi Tester, nhưng trong các tình huống thực tế, Nhà phát triển thường quen với việc viết mã dựa trên 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 là với toàn bộ Nhóm Agile, nhưng trong giai đoạn ban đầu, Nhà phát triển không được Tập trung vào Chất lượng khi họ có nhiều hơn vào chế độ triển khai.

Cuộc gọi tích hợp liên tục để 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.

Những người kiểm thử có thể thích ứng với những thay đổi với bộ óc Agile, nhưng có thể thay đổi kết quả thử nghiệm và kiểm thử kết quả có thể không thể thực hiện được để hoàn thành trong Sprint.

Tự động hóa sớm được khuyến cáo để có thể giảm thời gian thử nghiệm thủ công và thời gian. Nhưng, trong kịch bản thực tế, đến các xét nghiệm 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 nguyên tắc sau trong khi thực hiện Kiểm thử nhanh.

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

Tham gia vào phiên ước tính để đạt được nỗ lực và thời gian thử nghiệm để các hoạt động thử nghiệm được cung cấp 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 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 để làm cho việc kiểm thử và mã hóa thành công tốt trong Sprint.

Tham gia các Cuộc họp Thường trực Hàng ngày và chuyển tải Kiểm thử Trì hoãn hoặc Chặn nếu có, để nhận được giải pháp ngay lập tức.

Theo dõi và báo cáo trạng thái 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 để thích ứng với các thay đổi, đáp ứng với các sửa đổi đối với các trường hợp kiểm thử, dữ liệu thử nghiệm.

Tham gia vào các lần xem lại Sprint để hiểu và đóng góp các phương pháp hay nhất và bài học được học.

Cộng tác trong việc thu thập Phản hồi của Khách hàng tại mỗi Sprint.

Hoạt động theo dõi trong kiểm thử phần mềm

ảnh minh họa

Trạng thái kiểm thử phần mêm có thể được truyền đạt

Trong các cuộc họp đứng lên hàng ngày

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

Qua sứ giả

Trạng thái kiểm thử  được xác định bởi trạng thái vượt qua kiểm thử là rất quan trọng trong việc quyết định xem 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.

Tiến độ kiểm tra

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

Hội đồng Scrum (Ban nhiệm vụ nhanh)

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 một Câu chuyện của người dùng có thể được chuyển đến trạng thái Xong chỉ sau khi đạt được Tiêu chí chấp nhận. Điều này, lần lượt, được quyết định bởi Trạng thái kiểm thử khi Tiêu chuẩn chấp nhận được đánh giá bởi một trạng thái kiểm tra.

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 thảo luận và làm việc cộng tác để giải quyết như vậy.

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 tôi 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 thử nghiệm Agile cần phải nhận thông tin đó cho nhóm để các quyết định thích hợp có thể được đưa ra 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 lại.

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 để xử lý 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

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

Kiểm thử Pass / Fail

Đã phát hiện / Sửa lỗi

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

Tỷ lệ chuyển đổi / lỗi kiểm tra

Tỷ lệ phát hiện lỗi

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

Duy trì tính minh bạch.

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

Báo cáo ngay lập tức mà không có sự chậm trễ giao tiếp.

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

Lọc lạm dụng 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 được kỳ vọng của khách hàng hay không. Điều này cần phải được thực hiện vào cuối mỗi lần lặp lại 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.

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

Thử nghiệm nhanh được dựa trên các phương pháp kiểm thử thử nghiệm đầu tiên và liên tục. Do đó, các công cụ thử nghiệm truyền thống, được xây dựng trên phương pháp thử nghiệm cuối cùng, có thể không phù hợp. Do đó, trong khi lựa chọn các công cụ kiểm thử trong các dự án Agile, việc liên kết với kiểm thử Agile cần được xác minh.

Giảm tổng thời gian thử nghiệm bằng cách tự động kiểm thử trước đó trong vòng đời phát triển.

Người thử nghiệm nhanh cần phải duy trì tốc độ của mình để phù hợp với lịch phát hành phát triển. Do đó, lập kế hoạch, theo dõi và lập kế hoạch lại đúng đắn các hoạt động thử nghiệm cần đượ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% thử nghiệm trong các dự án. Do đó, những người kiểm thử có chuyên môn cần phải là thành viên của nhóm Agile.

Sự tham gia của những người kiểm thử  với 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 kỳ vọng 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 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 / nhiệm vụ của người dùng theo mong đợi của khách hàng.

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

Hoạt động kiểm thử quy hoạch.

Liên kết với nhóm phát triển để đảm bảo việc sản xuất mã đáp ứng các yêu cầu với thiết kế thử nghiệm trả trước.

Kiểm thử thử nghiệm đầu tiên và liên tục để đảm bảo rằng trạng thái thực hiện đạt được các tiêu chí chấp nhận tại thời điểm dự kiến.

Đảm bảo kiểm thử ở tất cả các cấp trong vòng chạy nước rút.

Kiểm thử hồi quy vào cuối mỗi lần chạy nước rút.

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 lỗi để xác định cần phải sửa trong Sprint hiện tại và có thể bị trì hoãn cho 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 cho thành công thử nghiệm nhanh -

Phương pháp tiếp cận toàn bộ nhóm - Trong cách tiếp cận này, các nhà phát triển đào tạo những người thử nghiệm và những 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, qua đó hợp tác và đóng góp sẽ có lợi ích tối đa. Sự hợp tác của những 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 thành yêu cầu để vượt qua bài kiểm tra.

Agile Testing Mindset - Người thử nghiệm chủ động liên tục cải thiện chất lượng và cộng tác liên tục với phần còn lại của nhóm.

Tự động kiểm thử hồi quy - Thiết kế cho thử nghiệm và phát triển ổ đĩa với các thử nghiệm. Bắt đầu đơn giản và cho phép nhóm chọn công cụ. Hãy sẵn sàng cung cấp lời khuyên.

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

Xây dựng một nền tảng của thực hành nhanh nhẹn cốt lõi - 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 từng bước, chấp nhận thay đổi, duy trì sức mạnh tổng hợp.

Cộng tác với khách hàng - Khai thác các ví dụ, sự hiểu biết 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, thu thập phản hồi.

Hãy xem Big Picture - Phát triển Drive với các bài kiểm thử và ví dụ về mặt kinh doanh sử dụng dữ liệu thử nghiệm thực tế và suy nghĩ về các tác động trên các lĩnh vực khác.

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

ảnh minh họa

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ử truyền thống. Ngoài ra, Agile tester cần

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 trải 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ử .

Đị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ụ thử nghiệm 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ử đú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ử 

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

Đặt 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ử .

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

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ử đơ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ử và dữ liệu thử nghiệm có thể được tổ chức.