Kiểm thử phần mềm thâm nhập Vs. Dễ bị tổn thương

Nói chung, hai thuật ngữ này, ví dụ, Kiểm thử phần mềm thâm nhập và đánh giá tính dễ bị tổn thương được sử dụng thay thế cho nhau bởi nhiều người, vì hiểu lầm hoặc quảng cáo tiếp thị.

Nhưng, cả hai điều khoản này khác nhau về mục tiêu và các phương tiện khác. Tuy nhiên, trước khi mô tả sự khác biệt, trước tiên chúng ta hãy hiểu cả hai thuật ngữ một.

Kiểm thử phần mềm

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

Kiểm thử phần mềm thâm nhập sao chép các hành động của kẻ tấn công mạng bên ngoài hoặc / và bên trong nhằm phá vỡ bảo mật thông tin và hack dữ liệu có giá trị hoặc phá vỡ hoạt động bình thường của tổ chức.

Vì vậy, với sự trợ giúp của các công cụ và kỹ thuật tiên tiến, một người Kiểm thử phần mềm thâm nhập (còn được gọi là hacker đạo đức ) đã nỗ lực kiểm soát các hệ thống quan trọng và có được quyền truy cập vào dữ liệu nhạy cảm.

Đánh giá tính dễ bị tổn thương

Mặt khác, đánh giá lỗ hổng là kỹ thuật xác định (khám phá) và đo lường các lỗ hổng bảo mật (quét) trong một môi trường nhất định.

Đó là một đánh giá toàn diện về vị trí bảo mật thông tin (phân tích kết quả). Hơn nữa, nó xác định các điểm yếu tiềm ẩn và cung cấp các biện pháp giảm thiểu thích hợp (khắc phục) để loại bỏ các điểm yếu đó hoặc giảm dưới mức rủi ro.

Sơ đồ sau đây tóm tắt đánh giá lỗ hổng

Bảng dưới đây minh họa sự khác biệt cơ bản giữa Kiểm thử phần mềm thâm nhập và đánh giá lỗ hổng

Kiểm thử thâm nhập	Đánh giá tính dễ bị tổn thương
Xác định phạm vi của một cuộc tấn công.	Tạo một thư mục tài sản và tài nguyên trong một hệ thống nhất định.
Kiểm thử thu thập dữ liệu nhạy cảm.	Khám phá các mối đe dọa tiềm năng cho từng tài nguyên.
Tập hợp thông tin mục tiêu và / hoặc kiểm thử hệ thống.	Phân bổ giá trị định lượng và ý nghĩa cho các tài nguyên có sẵn.
Dọn dẹp hệ thống và đưa ra báo cáo cuối cùng.	Nỗ lực giảm thiểu hoặc loại bỏ các lỗ hổng tiềm năng của các tài nguyên có giá trị.
Nó không xâm phạm, tài liệu và đánh giá và phân tích môi trường.	Phân tích toàn diện và thông qua việc xem xét hệ thống mục tiêu và môi trường của nó.
Đó là lý tưởng cho môi trường vật lý và kiến ​​trúc mạng.	Đó là lý tưởng cho môi trường phòng thí nghiệm.
Nó có nghĩa là cho các hệ thống thời gian thực quan trọng.	Nó có nghĩa là cho các hệ thống không quan trọng.

Lựa chọn nào là lý tưởng để thực hành?

Cả hai phương pháp đều có chức năng và cách tiếp cận khác nhau, vì vậy nó phụ thuộc vào vị trí bảo mật của hệ thống tương ứng. Tuy nhiên, vì sự khác biệt cơ bản giữa Kiểm thử phần mềm thâm nhập và đánh giá lỗ hổng, kỹ thuật thứ hai có lợi hơn so với kỹ thuật thứ nhất.

Đánh giá lỗ hổng xác định các điểm yếu và đưa ra giải pháp để khắc phục chúng. Mặt khác, Kiểm thử phần mềm thâm nhập chỉ trả lời câu hỏi rằng "bất kỳ ai cũng có thể đột nhập vào bảo mật hệ thống và nếu vậy, thì anh ta có thể làm hại gì?"

Hơn nữa, một đánh giá lỗ hổng cố gắng cải thiện hệ thống bảo mật và phát triển một chương trình bảo mật tích hợp, trưởng thành hơn. Mặt khác, Kiểm thử phần mềm thâm nhập chỉ đưa ra một bức tranh về hiệu quả của chương trình bảo mật của bạn.

Như chúng ta đã thấy ở đây, đánh giá lỗ hổng có lợi hơn và cho kết quả tốt hơn so với thử nghiệm thâm nhập. Nhưng, các chuyên gia khuyên rằng, là một phần của hệ thống quản lý bảo mật, cả hai kỹ thuật nên được thực hiện thường xuyên để đảm bảo một môi trường bảo mật hoàn hảo.

Kiểm thử phần mềm - Phương pháp

Kiểm thử phần mềm thâm nhập là sự kết hợp của 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 tích và đưa ra giải pháp. Nó dựa trên một quy trình có cấu trúc để thực hiện kiểm thử thâm nhập từng bước.

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

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

Kiểm thử phần mềm 

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

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ử cùng 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. Mục tiêu chung của kiểm thử thâm nhập là

Để xác định lỗ hổ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 một 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 kiểm thử 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 kiểm thử 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, kế hoạch 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 người kiểm thử thâm nhập rất có thể sẽ sử dụng các công cụ tự động để quét các tài sản mục tiêu để phát hiện ra các lỗ hổng. Các công cụ này thường có cơ sở dữ liệu riêng cung cấp các chi tiết về các lỗ hổng mới nhất. Tuy nhiên, người kiểm thử phát hiện ra

Khám phá mạng - Chẳng hạn như khám phá thêm 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.

Thẩm vấn dịch vụ - Nó thẩm vấn các 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 kiểm thử phân tích và đánh giá thông tin thu thập được trước các bước kiểm thử để tự động xâ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 cực kỳ tốn thời gian. Trong khi phân tích, người kiểm thử xem xét các yếu tố sau

Các mục tiêu được xác định của bài kiểm thử thâm nhập.

Những rủi ro tiềm ẩn cho 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ăng cho thử nghiệm thâm nhập hoạt động tiếp theo.

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

Nỗ lực xâm nhập tích cực

Đây là bước quan trọng nhất phải được thực hiện với sự quan tâm đúng mức. 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ó 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ăng. 

Đối với những hệ thống có yêu cầu toàn vẹn rất cao, lỗ hổng tiềm ẩn và rủi ro cần được xem xét cẩn thận trước khi tiến hành 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 thực hiện (đã thảo luận ở trên) cho đến thời điểm đó và đánh giá các lỗ hổng hiện diện dưới dạng rủi ro tiềm ẩn. Hơn nữa, người kiểm thử đề nghị loại bỏ các lỗ hổng và rủi ro. Trên hết, người kiểm thử phải đảm bảo tính minh bạch của các bài kiểm thử và các lỗ hổng mà nó tiết lộ.

Chuan bi bao cao

Chuẩn bị báo cáo phải bắt đầu với các quy trình kiểm thử phần mềm tổng thể, tiếp theo 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 đây cần được xem xét -

Tóm tắt tổng thể về thử nghiệm thâm nhập.

Chi tiết từng bước và thông tin thu thập được trong quá trình thử 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 về làm sạch và sửa chữa các hệ thống.

Gợi ý cho an ninh trong tương lai.

Kiểm thử phần mềm thâm nhập - Giới thiệu

Kiểm thử phần mềm thâm nhập là một loại kiểm thử bảo mật được sử dụng để kiểm thử tính không an toàn của ứng dụng. Nó được tiến hành để tìm ra rủi ro bảo mật có thể có trong hệ thống.

Nếu một hệ thống không được bảo mật, thì bất kỳ kẻ tấn công nào cũng có thể phá vỡ hoặc chiếm quyền truy cập vào hệ thống đó. 

Rủi ro bảo mật thường là một lỗi vô ý xảy ra trong khi phát triển và triển khai phần mềm. Ví dụ: lỗi cấu hình, lỗi thiết kế và lỗi phần mềm, v.v.

kiểm thử phần mềm

Tại sao cần kiểm thử phần mềm thâm nhập?

Kiểm thử thâm nhập thường đánh giá khả năng của hệ thống để bảo vệ các mạng, ứng dụng, thiết bị đầu cuối và người dùng khỏi các mối đe dọa bên ngoài hoặc bên trong. Nó cũng cố gắng bảo vệ các kiểm soát bảo mật và đảm bảo chỉ có quyền truy cập được ủy quyền.

Kiểm thử phần mềm thâm nhập là cần thiết bởi vì

Nó xác định một môi trường mô phỏng tức là, làm thế nào kẻ xâm nhập có thể tấn công hệ thống thông qua tấn công mũ trắng .

Nó giúp tìm các khu vực yếu nơi kẻ xâm nhập có thể tấn công để có quyền truy cập vào các tính năng và dữ liệu của máy tính.

Nó hỗ trợ để tránh tấn công mũ đen và bảo vệ dữ liệu gốc.

Nó ước tính mức độ của cuộc tấn công vào doanh nghiệp tiềm năng.

Nó cung cấp bằng chứng để đề xuất, tại sao điều quan trọng là tăng đầu tư vào khía cạnh bảo mật của công nghệ

Khi nào thực hiện kiểm thử phần mềm thâm nhập?

Kiểm thử phần mềm thâm nhập là một tính năng thiết yếu cần được thực hiện thường xuyên để đảm bảo chức năng của một hệ thống. Ngoài ra, nó nên được thực hiện bất cứ khi nào -

Hệ thống an ninh phát hiện ra các mối đe dọa mới của những kẻ tấn công.

Bạn thêm một cơ sở hạ tầng mạng mới.

Bạn cập nhật hệ thống của bạn hoặc cài đặt phần mềm mới.

Bạn di dời văn phòng của bạn.

Bạn thiết lập chương trình / chính sách người dùng cuối mới.

Làm thế nào là thử nghiệm thâm nhập có lợi?

Kiểm thử phần mềm thâm nhập cung cấp các lợi ích sau

Cải tiến hệ thống quản lý - Nó cung cấp thông tin chi tiết về các mối đe dọa bảo mật. Ngoài ra, nó cũng phân loại mức độ của các lỗ hổng và gợi ý cho bạn, cái nào dễ bị tổn thương hơn và cái nào ít hơn. Vì vậy, bạn có thể dễ dàng và chính xác quản lý hệ thống bảo mật của mình bằng cách phân bổ các tài nguyên bảo mật phù hợp.

Tránh bị phạt - Kiểm thử thâm nhập giúp các hoạt động chính của tổ chức của bạn được cập nhật và tuân thủ hệ thống kiểm toán. Vì vậy, kiểm thử thâm nhập bảo vệ bạn khỏi đưa ra tiền phạt.

Bảo vệ khỏi thiệt hại tài chính - Một vi phạm đơn giản của hệ thống an ninh có thể gây ra thiệt hại hàng triệu đô la. Kiểm thử phần mềm thâm nhập có thể bảo vệ tổ chức của bạn khỏi những thiệt hại như vậy.

Bảo vệ khách hàng - Vi phạm ngay cả dữ liệu của một khách hàng có thể gây thiệt hại lớn về tài chính cũng như tổn hại danh tiếng. Nó bảo vệ các tổ chức giao dịch với khách hàng và giữ nguyên dữ liệu của họ.

Kiểm thử phần mềm Agile - Công cụ

Trong các dự án Agile, Người kiểm thử chịu trách nhiệm cho các nhiệm vụ hàng ngày sau -

Hỗ trợ các nhà phát triển trong mã hóa, với sự làm rõ về hành vi dự kiến ​​của hệ thống.

Giúp các nhà phát triển trong việc 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 kiểm thử tự động với tích hợp liên tục để kiểm thử hồi quy.

Để triển khai nhanh chóng và hiệu quả các tác vụ này, 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.

Kiểm thử phần mềm 

Người kiểm thử và nhà phát triển trong các dự án nhanh có thể được hưởng lợi từ các công cụ khác nhau để quản lý các phiên kiểm thử và để tạo và gửi báo cáo Khiếm khuyết. 

Ngoài các công cụ chuyên dụng để kiểm thử nhanh, các nhóm nhanh cũng có thể được hưởng lợi từ các công cụ quản lý kiểm thử và tự động hóa kiểm thử .

Lưu ý - Các giải pháp tự động hóa ghi và phát lại, kiểm thử lần cuối, nặng và kiểm thử không linh hoạt như

Quy trình làm việc 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 đối với các nhóm Agile.

Các tập lệnh không thể nhầm lẫn được tạo bằng các công cụ như vậy trở thành một trở ngại để thay đổi

Các công cụ chuyên dụng như vậy tạo ra nhu cầu về các chuyên gia tự động hóa Thử nghiệm và do đó thúc đẩy các silo

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

S.No.	Công cụ & Mục đích
1	Hudson Khung CI
2	Selen Kiểm thử chức năng - Tích hợp với Hudson
3	CruiseControl Khung CI
4	Tháng sáu Kiểm thử đơn vị Java
5	Nữ tu Kiểm thử đơn vị .Net
6	Cobertura / JavaCodeCoverage / JFeature / JCover / Bảo hiểm kiểm thử Java
7	hề Java - Kiểm thử đột biến / Tạo lỗi tự động
số 8	Gretel Công cụ giám sát vùng phủ sóng thử nghiệm Java
9	TestCocoon C / C ++ hoặc C # - giảm số lượng Bài kiểm thử bằng cách tìm các Bài kiểm thử dự phòng và tìm Mã chết
10	JAZZ Java - Chi nhánh, Nút, và Bảo hiểm Defuse và triển khai GUI, Trình lập kế hoạch kiểm thử ra, Thiết bị động và Trình phân tích kiểm thử
11	Kiến Java - Tự động hóa xây dựng
12	Nam Kinh .Net - Xây dựng tự động hóa
13	Ngọn lửa Bổ trợ kiểm thử Agile cho JIRA

Công cụ tự động kiểm thử Agile

Hỗ trợ các công cụ tự động kiểm thử phần mềm Agile hiệu quả

Tự động hóa thử nghiệ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 kiểm thử bằng ngôn ngữ thực, ngôn ngữ cụ thể của miền.

Tập trung vào hành vi dự kiến ​​của hệ thống.

Tách biệt bản chất của Thử nghiệm khỏi các chi tiết triển khai, do đó làm cho Công nghệ trở nên độc lập.

Bồi dưỡng hợp tác.

Các thử nghiệm đơn vị tự động (sử dụng Junit hoặc NUnit) hỗ trợ phương pháp thử nghiệm đầu tiên cho 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ó khiếm khuyết. 

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ừ 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 cung cấp một sản phẩm có thể không đáp ứng yêu cầu của khách hàng và do đó không có giá trị kinh doanh.

Mối quan tâm này được giải quyết bằng cách tự động hóa các Bài kiểm thử chấp nhận được viết với sự cộng tác của khách hàng, các bên liên quan khác, người kiểm thử và nhà phát triển. 

Các thử nghiệ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 dự kiến ​​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 sự chấp nhận, mã kết quả có thể vẫn không thể mở rộng.

Do đó, Kiểm thử đơn vị tự động và Kiểm thử 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ụ linh hoạt hỗ trợ Kiểm thử chấp nhận tự động là

Phù hợp

Fitnesse

Sự kết hợp

Hồng ngọc

Quả dưa chuột

Phù hợp

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

Khách hàng hoặc Chủ sở hữu sản phẩm để đưa ra ví dụ về hành vi sản phẩm bằng Microsoft Word và Microsoft Excel

Lập trình viên để dễ dàng biến những ví dụ đó thành các bài kiểm thử tự động.

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

FitNlie

FitNesse là một wiki, là một kiểu máy chủ web cho phép bất kỳ khách truy cập nào thực hiện bất kỳ chỉnh sửa nào, bao gồm thay đổi các trang hiện có và tạo các trang mới. 

Một ngôn ngữ đánh dấu đơn giản cho phép bạn dễ dàng tạo các tiêu đề, làm đậm văn bản, gạch chân và in nghiêng, tạo danh sách dấu đầu dòng và thực hiện các loại định dạng đơn giản khác.

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

Express kiểm thử 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.

Hoặc, đặt bảng kiểm thử vào Microsoft Excel, sao chép vào bảng tạm và sau đó sử dụng lệnh Bảng tính sang FitNesseđể định dạng FitNlie đúng bảng của bạn

Chạy thử

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 kiểm thử

các ô màu xanh biểu thị rằng các giá trị dự kiến ​​thu được

các ô màu đỏ biểu thị rằng giá trị khác với giá trị bạn mong đợi

các tế bào màu vàng thể hiện 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 phát triển hướng hành vi (BDD). Các tính năng chính là -

Được sử dụng để viết bài kiểm thử chấp nhận cho các ứng dụng web.

Cho phép tự động hóa xác nhận chức năng ở định dạng dễ đọc và dễ hiểu như tiếng Anh đơn giản.

Đã được triển khai trong Ruby và sau đó được mở rộng sang khung Java. Cả hai đều ủng hộ Junit.

Hỗ trợ các ngôn ngữ khác như Perl, PHP, Python, .Net

Có thể được sử dụng cùng với Selenium, Watir, Capybara

Kiểm thử phần mềm - Kanban

Các hoạt động kiểm thử phần mềm Agile có thể được quản lý hiệu quả bằng cách sử dụng các khái niệm Kanban. Sau đây đảm bảo kiểm thử được hoàn thành kịp thời 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.

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

Giới hạn WIP (Công việc đang tiến hành) cho phép tập trung vào một số lượng hạn chế các câu chuyện của người dùng tại một thời điểm.

Kiểm thử phần mềm

Bảng Kanban đại diện cho quy trình làm việc một cách trực quan, giúp theo dõi các hoạt động 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, không có thời gian chờ đợi.

Chuẩn bị các trường hợp thử nghiệm trả trước, duy trì bộ thử nghiệm khi quá trình phát triển tiến triển và có được Phản hồi của khách hàng giúp loại bỏ các khiếm khuyết trong vòng lặp / chạy nước rút.

Định nghĩa Xong (DoD) được cho là Xong - Xong theo nghĩa là Câu chuyện đạt đến trạng thái hoàn thành chỉ sau khi thử nghiệm cũng hoàn tất.

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

Trong phát triển sản phẩm, các bản phát hành có thể được theo dõi với tính năng bảng 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 một 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 phương pháp nhanh.

Các hoạt động Kiểm thử Agile sau đây đảm bảo phân phối chất lượng trong mỗi bản phát hành và vào cuối tất cả các bản phát hành

Người kiểm thử phần mềm tham gia vào Tạo câu chuyện người dùng và do đó đảm bảo

Tất cả các Hành vi có thể có của Hệ thống được ghi lại bằng các Câu chuyện của Người dùng và Yêu cầu Không có chức năng là một phần của Câu chuyện Người dùng.

Câu chuyện của người dùng là Testable.

Kích thước của Câu chuyện người dùng cho phép Phát triển và Kiểm thử hoàn tất (DoneDone) trong Lặp lại.

Nhiệm vụ trực quan Ban Kanban

Mô tả trạng thái và tiến độ của Nhiệm vụ

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ỳ có thể được tối ưu hóa

Hợp tác nhóm giúp trong

Trách nhiệm của toàn đội cho chất lượng sản phẩm

Giải quyết các tắc nghẽn khi 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 tất cả các hoạt động

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

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

Phòng ngừa khiếm khuyết với các trường hợp thử nghiệm được viết trước đó cho 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 hạn chế Câu chuyện 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 tiến triển, để đảm bảo Sửa lỗi trong vòng lặp

Đảm bảo phạm vi kiểm thử phần mềm.

Giữ số lượng khuyết tật mở thấp

Khám phá câu chuyện

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

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

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 kiểm thử .

Ước lượng

Ước tính xảy ra trong Kế hoạch phát hành và mỗi Kế hoạch lặp.

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

Thông tin về những hoạt động kiểm thử được yêu cầu

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

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

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

Do đó, Ước tính kiểm thử đóng vai trò chính trong ước tính câu chuyện.

Kế hoạch câu chuyện

Story Planning bắt đầu sau khi Story được ước tính và được gán cho Lặp lại hiện tại.

Story Planning bao gồm các nhiệm vụ kiểm thử sau

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

Mở rộng các bài kiểm thử chấp nhận

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

Tiến hành các buổi kiểm thử thăm dò

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ử phần mềm năng suất

Kiểm thử hồi quy

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

Câu chuyện tiến triển

Story Progression khám phá các thử nghiệm bổ sung được yêu cầu do kết nối liên tục giữa 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 khi thực hiện, người kiểm thử thực hiện kiểm thử thăm dò.

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

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

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

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

Kiểm thử phần mềm Agile - Sản phẩm làm 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 Kế hoạch Sprint. 

Kế hoạch kiểm thử hoạt động như một hướng dẫn cho quá trình thử nghiệm để có phạm vi kiểm thử hoàn chỉnh.

Nội dung tiêu biểu của Kế hoạch kiểm thử là

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

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

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

Phạm vi kiểm thử

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

Công cụ kiểm thử

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ử  là tốt.

kiểm thử phần mềm

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

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

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

Người kiểm thử 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ử được 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ử đầu tiên, Kiểm thử thủ công được sử dụng. Chúng bao gồm -

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

Kiểm thử tích hợp

Kiểm thử chức năng

Các xét nghiệm phi chức năng

Xét nghiệm nghiệm thu

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

Trong Phát triển hướng thử nghiệm, các thử nghiệm đơn vị được viết trước tiên để thất bại, Mã được phát triển và thử nghiệm để đảm bảo các Thử nghiệm vượt qua.

Trong thử nghiệm chấp nhận hướng phát triển , các thử nghiệm chấp nhận được viết trước tiên để thất bại, Code được phát triển và thử nghiệm để đảm bảo các thử nghiệm vượt qua.

Trong các phương pháp Phát triển khác, Người kiểm thử cộng tác với các thành viên còn lại trong Nhóm để đảm bảo Phạm vi kiểm thử .

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

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

Kết quả kiểm thử phần mềm.

Vì hầu hết các Thử nghiệm trong Dự án Agile đều được tự động, Công cụ tạo Nhật ký kết quả kiểm thử cần thiết. Người kiểm thử xem lại Nhật ký kết quả kiểm thử . Các kết quả kiểm thử cần được duy trì cho mỗi lần chạy nước rút / phát hành.

Tóm tắt kiểm thử cũng có thể được chuẩn bị có chứa

Phạm vi thử nghiệm (Những gì đã được thử nghiệm và những gì chưa được thử nghiệ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ử hồi quy sau khi sửa lỗi

Các vấn đề và Nghị quyết tương ứng

Vấn đề đang chờ xử lý, nếu có

Bất kỳ sửa đổi nào được yêu cầu trong Chiến lược thử nghiệm

Kiểm thử số liệu

Kiểm thử phần mềm số liệu báo cáo

Trong các dự án Agile, Số liệu kiểm thử bao gồm các số liệu sau cho mỗi Sprint

Nỗ lực kiểm thử

Kiểm thử độ chính xác dự toán

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

Bảo hiểm kiểm thử tự động

Số khuyết tật

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

Khiếm khuyết nghiêm trọng

Thời gian để khắc phục một lỗi trong cùng một Sprint (Chi phí phải trả là 24x để sửa một lỗi thoát khỏi nước rút hiện tại)

Số lỗi được sửa trong cùng một Sprint

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

Báo cáo hồi cứu và hồi cứu của Sprint

Những người thử nghiệm cũng đóng góp vào Báo cáo Hồi cứu và Hồi cứu của Sprint. Các nội dung tiêu biểu là

Kiểm thử phần mềm số liệu

Kết quả kiểm thử Nhật ký kết quả xem xét

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

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

Bài học kinh nghiệm

Các vấn đề

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

Kiểm tra Agile - Kỹ thuật

Kỹ thuật kiểm thử phần mềm từ thử nghiệm truyền thống cũng có thể được sử dụng trong thử nghiệm Agile.

Ngoài ra, các kỹ thuật và thuật ngữ kiểm thử cụ thể của Agile được sử dụng trong các dự án Agile.

Cơ sở kiểm thử

Trong các dự án nhanh, tồn đọng sản phẩm thay thế các tài liệu đặc tả yêu cầu. Nội dung của tồn đọng sản phẩm là câu chuyện người dùng thông thường. 

Các yêu cầu phi chức năng cũng được quan tâm trong các câu chuyện của người dùng. Do đó, cơ sở thử nghiệm trong các dự án Agile là câu chuyện của người dùng.

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

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

Kinh 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 trong quá khứ.

Các chức năng, kiến ​​trúc, thiết kế, mã và các đặc tính chất lượng hiện có của hệ thống.

Khiếm khuyết 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 Xong

Định nghĩa Hoàn thành (DoD) là tiêu chí được sử dụng trong các dự án Agile để đảm bảo hoàn thành một hoạt động trong hồ sơ tồn đọng của Sprint. DoD có thể thay đổi từ nhóm Scrum này sang nhóm 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 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 người dùng. Câu chuyện 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ẻ trên toàn đội.

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

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

Tiêu chí để đảm bảo tính nhất quán của Câu chuyện người dùng với những người khác trong Lặp lại

Tiêu chí cụ thể liên quan đến sản phẩm

Các khía cạnh hành vi chức năng

Đặc điểm phi chức năng

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 mỗi tính năng

cho mỗi lần lặp

để 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 người dùng cần được kiểm thử

Tiêu chí chấp nhận liên kết

Giao diện hệ thống

Môi trường nơi Hệ thống dự kiến ​​sẽ hoạt động

Công cụ có sẵn

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 phải làm việc trong chế độ hợp tác, nên trách nhiệm của người thử nghiệm là

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

Xác định các lỗ hổng thông tin ảnh hưởng đến thử nghiệm.

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

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

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

Thiết kế kiểm thử 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 được đưa ra trước khi bắt đầu thực hiện.

Đố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ị biên

Bàn quyết định

Chuyển nhà nước

Cây lớp

Đố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 thử nghiệm 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 kiểm thử truyền thống.

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

kiểm thử thăm dò có ích để phù hợp với những 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 rủi ro thất bại và giảm thiểu rủi ro bằ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 định nghĩa 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 đượ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 đòi hỏi phải thử nghiệm rộng rãi

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

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ử sự phù hợp

kiểm thử phần mềm  Fit 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 bài kiểm thử chấp nhận.

FIT sử dụng JUnit, nhưng mở rộng chức năng thử nghiệm. Bảng HTML được sử dụng để hiển thị các trường hợp thử nghiệm. Lịch thi đấu là một lớp Java đằng 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.

Kiểm thử phần mềm Agile - Phương pháp

Trong Kiểm thử phần mềm Agile, các phương pháp Kiểm thử thường được sử dụng là từ các thực tiễn truyền thống và được căn chỉnh theo nguyên tắc - Kiểm thử sớm. 

Các trường hợp thử nghiệm được viết trước khi mã được viết. Trọng tâm là phòng ngừa khiếm khuyết, phát hiện và loại bỏ chạy các loại thử nghiệm đúng lúc và đúng cấp độ.

Kiểm thử phần mềm

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

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

Kiểm thử chấp nhận phát triển hướng (ATDD)

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

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

Trong phương pháp Phát triển hướng thử nghiệm (TDD), mã được phát triển dựa trên phương pháp tiếp cận thử nghiệm được chỉ đạo bởi các trường hợp thử nghiệm tự động. 

Một trường hợp thử nghiệm được viết trước tiên để thất bại, mã được phát triển dựa trên đó để đảm bảo rằng thử nghiệm vượt qua. 

Phương thức được lặp lại, tái cấu trúc được thực hiện thông qua việc phát triển mã.

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

Bước 1 - Viết một trường hợp thử nghiệm để phản ánh hành vi dự kiến ​​về chức năng của mã cần được viết.

Bước 2 - Chạy thử nghiệm. Thử nghiệm thất bại 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 thử lại. Lần này, bài Kiểm thử phần mềm 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 thử nghiệm vượt qua.

Bước 5 - Tái cấu trúc mã.

Bước 6 - Chạy thử nghiệm một lần nữa để đả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 thử nghiệm được thêm vào và các thử nghiệm trước đó được chạy mỗi lần để đảm bảo mã được chạy như mong đợi. Để làm cho quá trình này nhanh chóng, các bài Kiểm thử được tự động.

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

Kiểm thử chấp nhận phát triển

Trong phương pháp Phát triển dựa trên thử nghiệm 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ỉ đạo bởi các trường hợp thử nghiệm chấp nhận. 

Trọng tâm là các 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 những người thử nghiệm 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.

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 liên quan.

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

Bước 4 - Chạy thử nghiệm chấp nhận để đảm bảo 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ặp lại được thực hiện.

Bước 6 - Tự động hóa các bài Kiểm thử hồi quy.

Bước 7 - Chạy thử nghiệm hồi quy tự động để đảm bảo hồi quy liên tục.

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

Phát triển hướng hành vi (BDD) tương tự như Phát triển hướng thử nghiệm (TDD), và trọng tâm là Kiểm thử mã để đảm bảo hành vi dự kiến ​​của hệ thống.

Trong BDD, ngôn ngữ như tiếng Anh được sử dụng sao cho hợp lý với người dùng, người Kiểm thử phần mềm và nhà phát triển. Nó đảm bảo

Giao tiếp 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

Scrum ủng hộ Cách 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 với các sản phẩm dự án. Ra quyết định được để lại cho nhóm dẫn đến các hành động thích hợp được thực hiện vào đúng thời điểm mà không có bất kỳ sự chậm trễ nào. 

Cách tiếp cận này cũng khuyến khích sử dụng hợp lý tài năng của đội thay vì giới hạn trong một hoạt động. Người thử nghiệm cũng tham gia vào tất cả các dự án và các hoạt động phát triển đóng góp chuyên môn của họ trong thử nghiệm.

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

Toàn bộ nhóm làm việc cùng nhau về Chiến lược thử nghiệm, Lập kế hoạch kiểm thử phần mềm, Đặc tả thử nghiệm, Thực hiện thử nghiệm, Đánh giá thử nghiệm và Báo cáo kết quả thử nghiệm.

Hợp tác tạo câu chuyện người dùng

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

Người kiểm thử cũng đưa ra Tiêu chí chấp nhận cho mọi kịch bản được khách hàng đồng ý.

Người kiểm thử góp phần tạo ra những câu chuyện người dùng có thể kiểm chứng.

Kế hoạch phát hành

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

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

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

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

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

Người kiểm thử nên

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

Tạo các bài kiểm tra chấp nhận

Xác định cấp độ kiểm tra

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

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

Phân tích kiểm thử 

Khi chạy nước rút bắt đầu, khi các nhà phát triển tiến hành phân tích câu chuyện để thiết kế và thực hiện, người kiểm thử thực hiện phân tích thử nghiệm cho các câu chuyện trong hồ sơ tồn đọng nước rút. Tester tạo ra các trường hợp kiểm thử cần thiết - cả kiểm tra thủ công và tự động.

Kiểm thử

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 tra đơn vị được tạo trong mỗi lần chạy nước rút, trước khi mã được viết. Các trường hợp thử nghiệm đơn vị được lấy từ thông số kỹ thuật thiết kế cấp thấp.

Người kiểm thử phần mềm thực hiện các tính năng chức năng và phi chức năng của câu chuyện người dùng.

Những người kiểm tra cố vấn cho các thành viên khác trong nhóm scrum có chuyên môn về kiểm tra để toàn bộ nhóm sẽ có trách nhiệm tập thể về chất lượng sản phẩm.

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

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

Kiểm thử  tự động hóa

kiểm thử tự động hóa được coi trọng trong các nhóm Scrum. Người kiểm tra dành thời gian trong việc tạo, thực hiện, giám sát và duy trì các kiểm tra và kết quả tự động. 

Vì các thay đổi có thể xảy ra bất cứ lúc nào trong các dự án scrum, người kiểm tra cần điều chỉnh việc kiểm tra các tính năng đã thay đổi và cả kiểm tra hồi quy liên quan. Kiểm thử tự động hóa tạo điều kiện quản lý nỗ lực kiểm tra liên quan đến các thay đổi. 

Kiểm tra tự động ở tất cả các cấp tạo điều kiện đạt được tích hợp liên tục. Kiểm tra tự động chạy nhanh hơn nhiều so với kiểm tra thủ công mà không cần nỗ lực thêm.

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

Tự động hóa các hoạt động kiểm tra

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

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

Đang tải dữ liệu thử nghiệm

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

Quản lý môi trường thử nghiệm

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

kiểm thử hồi quy

Trong một lần chạy nước rút, người kiểm thử mã mới / được sửa đổi trong lần chạy nước rút đó. Tuy nhiên, người kiểm thử cũng cần đảm bảo rằng mã được phát triển và thử nghiệm trong các lần chạy nước rút trước đó cũng đang hoạt động cùng với mã mới. 

Do đó kiểm tra hồi quy được coi trọng trong scrum. Kiểm tra hồi quy tự động được chạy trong tích hợp liên tục.

Quản lý cấu hình

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

Nó cũng quản lý tích hợp liên tục mã mới với hệ thống. kiểm thử hồi quy tự động được thực hiện trong quá trình tích hợp liên tục.

Các trường hợp kiểm thử thủ công, kiểm tra tự động, dữ liệu kiểm tra, kế hoạch kiểm tra, chiến lược kiểm tra và các tạo phẩm kiểm tra 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 Tạo phẩm thử nghiệm trong Hệ thống quản lý cấu hình.

Thực hành kiểm thử Agile

Những người thử nghiệm trong Nhóm Scrum có thể tuân theo các Thực tiễn Agile sau

Ghép nối - Hai thành viên trong nhóm ngồi lại với nhau và làm việc cùng nhau. Hai người có thể là hai Người thử nghiệm hoặc một Người thử nghiệm và một Nhà phát triển.

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

Số liệu Agile

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

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

Tỷ lệ Sprint thành công - (Số Sprint thành công / Tổng số Sprint) * 100 . Một Sprint thành công là một trong đó Nhóm có thể đáp ứng cam kết của mình.

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

Yếu tố tập trung - (Vận tốc / Năng lực làm việc của nhóm) / 100 . Yếu tố tập trung là tỷ lệ phần trăm nỗ lực của nhóm dẫn đến kết thúc câu chuyện.

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

Sprint Burndown - Công việc (tính theo Story Story hoặc theo giờ) còn lại Vs. Công việc cần được duy trì lý tưởng (theo Dự toán).

Nếu nhiều hơn, điều đó có nghĩa là Nhóm đã đảm nhận nhiều Công việc hơn họ có thể làm.

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

Số lượng khuyết tật - Số lượng lỗi trong một Sprint. Số lượng lỗi là số lượng lỗi trong phần mềm so với tồn đọng.

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

Hồi tưởng nước rút

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

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

Số liệu

Phạm vi cải tiến

Các mục hành động để áp dụng

Kiểm tra Agile - Quadrant

Như trong trường hợp Thử nghiệm truyền thống, Thử nghiệm Agile cũng cần bao gồm tất cả các Cấp độ thử nghiệ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ị

kiểm thử phần mềm

Thực hiện cùng với Mã hóa, bởi Nhà phát triển

Được hỗ trợ bởi Tester, người viết Test Case đảm bảo 100% 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 điểm 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ử phần mềm đơ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 của Sprints

Hoàn thành vào cuối sau khi tất cả cá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 khiếm khuyết được báo cáo

Các xét nghiệm được tự động nếu có thể

Thử nghiệm hệ thống

Thực hiện khi quá 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.)

Khiếm khuyết được báo cáo

Các xét nghiệm được tự động nếu có thể

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

Thực hiện vào cuối mỗi Sprint và khi kết thúc 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 các Sprint tiếp theo

Câu chuyện của người dùng trong Sprint được xác minh trước là có thể Kiểm thử phần mềm được và với Tiêu chí chấp nhận được xác định

Các loại kiểm thử

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 người dùng)

Các thử nghiệm phi chức năng (Hiệu suất, Tải, Căng thẳng, v.v.)

Xét nghiệm nghiệm thu

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

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 (Lập trình hỗ trợ) - Các lập trình viên hỗ trợ được các lập trình viên sử dụng.

Để quyết định mã nào họ cần viết để thực hiện một hành vi nhất định của Hệ thống

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

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

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

Để 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ó -

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

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

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

Một bài Kiểm thử 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 bằng các từ trong lĩnh vực kinh doanh. Những điều này được các chuyên gia kinh doanh hiểu và sẽ quan tâm đến họ để hành vi của hệ thống có thể được giải thích trong kịch bản thời gian thực.

Kiểm thử công nghệ

Một bài Kiểm thử là một bài Kiểm thử đối mặt với 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 được thực hiện dựa trên sự làm rõ 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 Bộ tứ Kiểm thử Agile được xác định bởi Brian Marick.

Phần tư kiểm thử Agile

Kết hợp hai khía cạnh của các loại thử nghiệm, Quadrant thử nghiệm Agile sau đây được dẫn xuất bởi Brian Marick

Quadrant 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 thử nghiệm cần thiết.

Quadrant Q1 - Cấp độ đơn vị, Đối mặt với công nghệ và hỗ trợ các nhà phát triển. Các bài Kiểm thử đơn vị thuộc về Quadrant này. Những bài Kiểm thử này có thể là bài Kiểm thử tự động.

Quadrant Q2 - Cấp độ hệ thống, kinh doanh phải đối mặt và hành vi sản phẩm phù hợp. Các xét nghiệm 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 - Mức chấp nhận của hệ thống hoặc người dùng, đối mặt với doanh nghiệp và tập trung vào các kịch bản thời gian thực. Kiểm thử chấp nhận 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 - Mức chấp nhận hệ thống hoặc hoạt động, đối mặt với công nghệ và tập trung vào hiệu suất, tải, ứng suất, khả năng duy trì, Kiểm thử phần mềm 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, Quadrant thử nghiệm Agile phản ánh What-tests-Khi nào có thể được hình dung như sau.

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