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

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

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

Trong các dự án Agile, tất cả các Thành viên 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 tra là tốt.

Trách nhiệm của người kiểm tra 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 tra 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 tra và đảm bảo Tiêu chí chấp nhận.
Kiểm tra thủ công và tự động

Trong lần chạy thử nghiệm đầu tiên, các xét nghiệm thủ công được sử dụng. Chúng bao gồm -
Bài kiểm tra đơn vị
Kiểm tra tích hợp
Kiểm tra chức năng
Kiểm tra phi chức năng
Kiểm tra chấp nhận

Các 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 tra vượt qua.

Trong Kiểm tra chấp nhận phát triển theo hướng , Kiểm tra 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 tra để đảm bảo các bài kiểm tra 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 tra 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 tra đòi hỏi nỗ lực và thời gian, kết quả kiểm tra 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 tra Câu chuyện của người dùng trong Sprint cụ thể, người kiểm tra 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 tra

Vì hầu hết các thử nghiệm trong các dự án Agile được tự động hóa, các công cụ tạo ra các bản ghi kết quả kiểm tra 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 tra 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 tra (Điều gì đã được kiểm tra và những gì không được kiểm tra)
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 tra 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 tra
Báo cáo chỉ số thử nghiệm

Trong các dự án Agile, các chỉ số kiểm tra bao gồm những điều sau cho mỗi Sprint -
Nỗ lực thử nghiệm
Kiểm tra độ chính xác ước tính
Kiểm tra vùng phủ sóng
Phạm vi kiểm tra 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 tra 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 tra 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 tra
Nhật ký kết quả kiểm tra 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 tra 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 thử nhanh - Kỹ thuật

Tài liệu học tester tiếng việ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.

Cơ sở Tester

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

Tester 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 độ Tester

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ử

Link đăng ký khóa học : Tài liệu học tester tiếng việt.

Người Tester cần có thông tin Tester sau

Câu chuyện của người dùng cần được Tester

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ụ

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

Có được thông tin Tester 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 Tester 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 Tester thăm dò có thể được kết hợp với các kỹ thuật thử nghiệm truyền thống.

Tester 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 Tester. 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 Tester 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 Tester mới và tốt hơn.

Tester 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 Tester Cursory

Các thử nghiệm được thiết kế bằng cách sử dụng các kỹ thuật Tester 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à Tester 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 Tester. 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.

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

Tài liệu học Tester tiếng việt 

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

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

Tester  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ự trợ 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. Tester  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 Tester . Lần này, bài Tester  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 Tester  trôi qua.

Bước 5 - Refactor mã.

Bước 6 - Chạy lại Tester  để đả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 Tester  bổ sung và các bài Tester  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 Tester  được tự động hóa.

Các bài Tester  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 Tester  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 Tester  chấp nhận. Trọng tâm là về tiêu chí chấp nhận và Các trường hợp Tester  chấp nhận được viết bởi người Tester  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 Tester  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 Tester  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 Tester  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 Tester  hồi quy tự động để đảm bảo Continuous Regression.

Link đăng ký học Tester : Tài liệu học Tester tiếng việt

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 tra nhanh - Scrum

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. 

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

Tester tiếng việ

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 Tài liệu Tester tiếng việt để phát hành. Tester  ướ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ở Tester  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 Tester  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 Tester  chấp nhận

Xác định mức độ Tester 

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

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 Tester  bắt buộc - cả Tester  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 Tester  đơn vị khi họ phát triển mã cho các câu chuyện của người dùng. Tester  đơ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 Tester  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ả Tester  đượ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 Tester  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 Tester  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.

Tester  thủ công tập trung nhiều hơn vào Tester  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

Tester  quản lý môi trường

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

Kiểm tra hồi quy

Trong một lần chạy nước rút, người thử nghiệm Tester  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 đó Tester  hồi quy được đưa ra tầm quan trọng trong scrum. Các bài Tester  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à Tester  đơn vị nhiều lần khi mã mới được Tester  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. Tester  hồi quy tự động được chạy trong khi tích hợp liên tục.

Các trường hợp Tester  thủ công, thử nghiệm tự động, dữ liệu thử nghiệm, kế hoạch Tester , chiến lược Tester 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 Tester 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 tra nhanh - 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ử.

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 thi (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à tuân theo Tiêu chí chấp nhận được xác định

Loại thử nghiệm

Kiểm thử thành phần (Bài 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.)

Tài liệu học tester tiếng việt

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 để hoàn thành 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

Tài liệu học tester tiếng việt 

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

Tài liệu học tester tiếng việt 

Kiểm tra nhanh - Các thuộc tính quan trọng

Kiểm thử phần mềm 

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

Những lợi ích của thử nghiệm 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 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ử 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ử phần mềm đượ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.

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

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

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

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

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

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

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.

Kiểm thử nhanh - Thử nghiệm 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.

Một 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.

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

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

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

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

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

Năng lực chủ động tích cực thu thập thông tin từ các bên liên quan.

Kỹ năng làm việc hiệu quả với khách hàng và các bên liên quan trong việc xác định Câu chuyện của người dùng có thể kiểm thử, Tiêu chí chấp nhận.

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

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

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

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

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

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

Năng lực trong Tự động hóa kiểm thử, Phát triển theo hướng thử nghiệm (TDD), Phát triển theo hướng thử nghiệm chấp nhận (ATDD), Phát triển dựa trên hành vi (BDD) và Thử nghiệm dựa trên 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 vòng đời Agile, 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 kiểm thử.

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

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

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

Trước khi cho phép ai đó kiểm thử phần mềm dữ liệu nhạy cảm, các công ty thường thực hiện các biện pháp liên quan đến tính khả dụng, tính bảo mật và tính toàn vẹn của dữ liệu. Để thỏa thuận này được đưa ra, tuân thủ pháp lý là một hoạt động cần thiết cho một tổ chức.

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

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

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

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

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

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

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

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

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

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

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

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