Kiểm thử 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ử phần mềm .
Kiểm thử đơn vị

Thử nghiệm hội nhập

Thử nghiệm hệ thống

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

Kiểm thử đơn vị

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

Được hỗ trợ bởi Tester, người viết Test Cases, đảm bảo 100% Bảo hiểm thiết kế

Các trường hợp kiểm thử đơn vị và kết quả kiểm thử đơn vị cần được xem xét

Các khuyết tật lớn chưa được giải quyết (theo mức độ ưu tiên và mức độ nghiêm trọng) không được để lại

Tất cả các bài kiểm thử đơn vị được tự động

Thử nghiệm hội nhập

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

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

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

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

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

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

Thử nghiệm hệ thống

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

Câu chuyện, tính năng và chức năng của người dùng được kiểm thử
Thử nghiệm được thực hiện trong môi trường sản xuất

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

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

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

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

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

Thực hiện bởi khách hàng. Phản hồi được thực hiện bởi Nhóm

Phản hồi sẽ là đầu vào cho Sprint tiếp theo

Câu chuyện của người dùng trong Sprint được xác minh trước để có thể kiểm thử và 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.)

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

ảnh minh họa

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 

ảnh minh họa

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

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

ảnh minh họa

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ử đượ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 thử nhanh - Hoạt động theo dõi

ảnh minh họa học kiểm thử

trạng thái kiểm thử 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ử phần mềm đượ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 - kiểm thử trong nhóm

ảnh minh họa

Phát triển nhanh là nhóm làm trung tâm và các nhà phát triển và kiểm thử phần mềm  tham gia vào tất cả các hoạt động dự án và phát triển. Teamwork tối đa hóa thành công của thử nghiệm trong các dự án Agile.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Vai trò của Tester 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 tra.

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

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

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

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

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

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

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

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

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

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

Làm việc theo nhóm

Kế hoạch kiểm tra

Sprint Zero

Hội nhập

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

Làm việc theo nhóm

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

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

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

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

Cam kết - Cam kết hiểu và đánh giá hành vi và đặc điểm của sản phẩm theo yêu cầu của khách hàng và các bên liên quan.

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

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

Mở để phản hồi - Tham gia vào các cuộc kiểm tra chạy nước rút để học hỏi từ cả thành công lẫn thất bại. Tìm kiếm phản hồi của khách hàng và hành động nhanh chóng và phù hợp để đảm bảo chất lượng phân phôi.

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

Kế hoạch kiểm tra

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

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

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

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

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

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

Xác định các điều kiện tiên quyết như nhiệm vụ tiền nhiệm, chuyên môn và đào tạo.

Xác định các phụ thuộc như chức năng, mã, thành phần hệ thống, nhà cung cấp, công nghệ, công cụ, hoạt động, nhiệm vụ, nhóm, loại thử nghiệm, mức thử nghiệm và các ràng buộc.

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

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

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

Sprint Zero

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

Phạm vi xác định

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

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

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

Tạo chiến lược thử nghiệm ban đầu cho tất cả các cấp thử nghiệm

Xác định số liệu kiểm tra

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

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

Tạo bảng Scrum

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

Hội nhập

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

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

Hiểu chiến lược tích hợp.

Xác định tất cả các phụ thuộc giữa các hàm và tính năng.

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

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

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

Một người thử nghiệm và một nhà phát triển

Một nhà phân tích và một nhà phân tích nghiệp vụ

Hai người kiểm tra

Thiết kế thử nghiệm gia tăng - Các trường hợp kiểm thử được xây dựng từ các câu chuyện của người dùng, bắt đầu với các bài kiểm tra đơn giản và chuyển sang các bài kiểm tra phức tạp hơn.

Mind Mapping - Bản đồ tư duy là một sơ đồ tổ chức thông tin một cách trực quan. Lập bản đồ tư duy có thể được sử dụng như một công cụ hiệu quả trong thử nghiệm Agile, sử dụng thông tin nào liên quan đến các phiên kiểm tra cần thiết, chiến lược kiểm tra và dữ liệu thử nghiệm có thể được tổ chức.

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

Trong kiểm thử phần mềm Agile, các phương pháp thử nghiệm thường được sử dụng là từ các phương pháp truyền thống và được căn chỉnh theo nguyên tắc - Kiểm thử 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.

ảnh kiểm thử phần mềm

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

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

Phát triển thử nghiệm chấp nhận thử nghiệm (ATDD)

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

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

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

TDD có thể được hiểu với sự 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. Kiểm thử không thành công vì mã vẫn chưa được phát triển.

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

Bước 4 - Chạy lại kiểm thử . Lần này, bài kiểm thử phải vượt qua khi chức năng được mã hóa. Lặp lại

Bước (3) và Bước (4) cho đến khi kiểm thử  trôi qua.

Bước 5 - Refactor mã.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Liên lạc liên tục giữa người dùng, người thử nghiệm và nhà phát triển.

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

Kiểm thử nhanh - Scrum

ảnh minh họa

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

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

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

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

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

Kế hoạch phát hành

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

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

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

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

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

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

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

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

Xác định mức độ kiểm tra

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

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

Phân tích thử nghiệm

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

Thử nghiệm

Tất cả các thành viên của nhóm Scrum nên tham gia thử nghiệm.

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

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

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

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

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

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

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

Kiểm tra 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 hoạt động thử nghiệm

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

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

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

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

Kiểm tra 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 kiểm tra mã mới / sửa đổi trong lần chạy nước rút đó. Tuy nhiên, người thử nghiệm cũng cần đảm bảo rằng mã được phát triển và thử nghiệm trong các lần chạy nước rút trước đó cũng đang hoạt động cùng với mã mới. Do đó kiểm tra hồi quy được đưa ra tầm quan trọng trong scrum. Các bài 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 công tác xây dựng và kiểm thử tự động được sử dụng trong các dự án Scrum. Điều này cho phép chạy phân tích tĩnh và kiểm 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 của mã mới với hệ thống. Kiểm tra hồi quy tự động được chạy trong khi tích hợp liên tục.

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

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

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

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

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

Chỉ số nhanh

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

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

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

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

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

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

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

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

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

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

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

Sprint Retrospectives

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

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

Số liệu

Phạm vi cải tiến

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

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

Kiểm thử đơn vị

Thử nghiệm hội nhập

Thử nghiệm hệ thống

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

Kiểm thử đơn vị

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

Được hỗ trợ bởi Tester, người viết Test Cases, đảm bảo 100% Bảo hiểm thiết kế

Các trường hợp kiểm thử đơn vị và kết quả kiểm thử đơn vị cần được xem xét

Các khuyết tật lớn chưa được giải quyết (theo mức độ ưu tiên và mức độ nghiêm trọng) không được để lại

Tất cả các bài kiểm thử đơn vị được tự động

Thử nghiệm hội nhập

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

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

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

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

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

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

Thử nghiệm hệ thống

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

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

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

Kiểm thử chất lượng được thực 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.)

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 

ảnh minh họa

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 

ảnh minh họa

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

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

ảnh minh họa

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ử đượ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 thử nhanh - Hoạt động theo dõi

ảnh minh họa

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

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

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

Qua sứ giả

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

Tiến độ kiểm tra

Quá trình kiểm thử phần mềm 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 - Các thuộc tính quan trọng

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

ảnh minh họa

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ử đượ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 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 để làm cho việc kiểm thử và mã hóa thành công tốt trong Sprint.

Tham gia vào 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 - Thử nghiệm trong nhóm

ảnh minh họa

Phát triển nhanh là nhóm làm trung tâm và các nhà phát triển và kiểm thử phần mềm tham gia vào tất cả các hoạt động dự án và phát triển. Teamwork tối đa hóa thành công của thử nghiệm trong các dự án Agile.

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

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

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

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

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

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

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

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

Khả năng sử dụng các kỹ năng kiểm tra để 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 tra và chất lượng sản phẩm.

Tính mở để phản hồi nhanh chóng các thay đổi, bao gồm thay đổi, thêm hoặc cải thiện các trường hợp kiểm 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 tra có liên quan.

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

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

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

Thực hiện các bài kiểm 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 tra chạy nước rút, chủ động đề xuất và triển khai các cải tiến.

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

Làm việc theo nhóm

Kế hoạch kiểm 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 tra, Lập kế hoạch kiểm thử, Đặc tả kiểm tra, Kiểm thử  thực hiện, Đánh giá thử nghiệm và Báo cáo kết quả kiểm tra. Đóng góp chuyên môn kiểm thử cùng với các hoạt động nhóm khác.

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

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

Cam kết - Cam kết hiểu và đánh giá hành vi và đặc điểm của sản phẩm theo yêu cầu của khách hàng và các bên liên quan.

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

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

Mở để phản hồi - Tham gia vào các cuộc kiểm thử chạy nước rút để học hỏi từ cả thành công lẫn thất bại. Tìm kiếm phản hồi của khách hàng và hành động nhanh chóng và phù hợp để đảm bảo chất lượng phân phôi.

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

Kế hoạch kiểm tra

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

Xác định phạm vi kiểm tra, mức độ kiểm tra, kiểm 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 tra, dữ liệu thử nghiệm và cấu hình.

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

Lập kế hoạch nhiệm vụ kiểm tra và xác định tần suất kiểm 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 tra)

Tạo chiến lược thử nghiệm ban đầu cho tất cả các cấp thử nghiệm

Xác định số liệu kiểm 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 tra Agile cần hỗ trợ tích hợp liên tục với thử nghiệm liên tục.

Để thực hiện điều này, người kiểm 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 tra Agile cần phải thích ứng với các thực hành Agile để thử nghiệm trong một dự án nhanh.

Ghép nối - Hai thành viên trong nhóm làm việc cùng nhau trên cùng một bàn phím. Là một trong số họ kiểm 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 tra

Thiết kế thử nghiệm gia tăng - Các trường hợp kiểm thử được xây dựng từ các câu chuyện của người dùng, bắt đầu với các bài kiểm tra đơn giản và chuyển sang các bài kiểm 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 tra cần thiết, chiến lược kiểm tra và dữ liệu thử nghiệm có thể được tổ chức.

Kiểm tra nhanh - Tổng quan trong tester

Agile là một phương pháp phát triển lặp đi lặp lại, trong đó cả hai hoạt động phát triển và kiểm thử đều đồng thời. Thử nghiệm không phải là một pha riêng biệt; Mã hóa và thử nghiệm được thực hiện tương tác và từng bước, 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, kết quả tích hợp liên tục trong việc loại bỏ lỗi sớm và do đó tiết kiệm thời gian, công sức và chi phí.

ảnh minh họa

Tuyên ngôn nhanh nhẹ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 thực hiện nó và giúp những người khác làm điều đó. Thông qua công việc này, chúng ta đã đạt đến giá trị -

Cá nhân và tương tác trên 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.

Khách hàng hợp tác về thương lượng hợp đồng.

Trả lời thay đổi theo 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.

Thử nghiệm Agile là gì

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

Kiểm tra nhanh bao gồm 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 kiểm thử. 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 ra trường hợp thử nghiệm. Thử nghiệm diễn ra đồng thời thông qua Chu kỳ phát triển cuộc sống.

Hơn nữa, với những người thử nghiệm tham gia toàn bộ Vòng đời phát triển cùng với các thành viên nhóm chức năng, sự đóng góp của người thử nghiệm để 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ở thành có thể.

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

Kiểm tra Agile 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 của Chu kỳ phát triển cuộc sống diễn ra theo từng giai đoạn. Vì vậy, thử nghiệm là một giai đoạn riêng biệt và được bắt đầu chỉ 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à Kiểm thử Thá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 pha riêng biệt. Tất cả các cấp và các 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 thử nghiệm làm việc riêng biệt với 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 cá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 thử chấp nhận hợp lý sẽ sẵn sàng cùng với các yêu cầu. Người thử nghiệm có thể không tham gia vào giai đoạn yêu cầu.

Kiểm thử 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 thử chấp nhận chỉ được thực hiện ở cuối dự án.

Mỗi lần lặp lại hoàn thành thử nghiệm riêng của nó, do đó cho phép thử nghiệm hồi quy được thực hiện mỗi khi các hàm hoặc logic mới được giải phóng. Kiểm thử hồi quy có thể được thực hiện chỉ sau khi hoàn thành phát triển.

Không có thời gian trễ giữa mã hóa và kiểm thử . Thời gian chậm trễ thông thường giữa mã hóa và kiểm thử.

Thử nghiệm liên tục với các cấp độ kiểm thử trùng lặp. Kiểm thử là một hoạt động theo thời gian và các cấp kiểm thử không thể trùng lặp.

Thử nghiệm là phương pháp hay nhất. Kiểm thử thường bị bỏ qua.

Nguyên tắc kiểm thử nhanh

Các nguyên tắc của thử nghiệm Agile là

Thử nghiệm di chuyển dự án về phía trước - Kiểm thử liên tục là cách duy nhất để đảm bảo tiến trình liên tục. Kiểm thử nhanh chóng cung cấp 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.

Thử nghiệm không phải là một giai đoạn - Các thử nghiệm nhóm Agile cùng với nhóm phát triển để đảm bảo rằng các tính năng được triển khai trong một lần lặp được thực hiện. Thử nghiệm không được lưu giữ trong giai đoạn sau.

Tất cả mọi người 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 lại, ngay cả khách hàng thực hiện Kiểm thử chấp nhận người dùng.

Rút ngắn vòng lặp phản hồi - Trong thử nghiệm nhanh nhẹn, nhóm kinh doanh có thể biết được sự phát triển sản phẩm cho mỗi lần lặp lại. Chúng liên quan đến mọi lần lặp lại. Phản hồi liên tục rút ngắn thời gian phản hồi phản hồi và do đó chi phí liên quan đến việc sửa lỗi sẽ í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 sẽ ở 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 thử nghiệm Agile

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

Tập trung vào bản chất của bài kiểm thử chứ không phải là chi tiết ngẫu nhiên.

Sử dụng các công cụ / kiểu tài liệu có trọng lượng nhẹ.

Nắm bắt các ý tưởng thử nghiệm trong điều lệ để kiểm thử khám phá.

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 kịch bản lệnh thử nghiệm để kiểm thử 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à một kịch bản kiểm thử tự động hóa tương đương.

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

Test-Last vs. Test Driven - Các trường hợp kiểm thử được viết cùng với các yêu cầu. Do đó, phát triển có thể được thúc đẩy bởi thử nghiệm. Cách tiếp cận này được gọi là Phát triển theo hướng kiểm thử(Test Driven Development - TDD) và Phát triển thử nghiệm chấp nhận (ATDD). Điều này trái ngược với thử nghiệm như một giai đoạn cuối trong Thử nghiệm thác nước.

Hoạt động kiểm tra nhanh

Các hoạt động thử nghiệm nhanh ở cấp dự án là

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

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

Các hoạt động thử nghiệm nhanh nhẹn trong quá trình lặp lại

Kiểm thử hồi quy

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

Các hoạt động thử nghiệm nhanh trong một lần lặp bao gồm -

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

Ước tính công việc từ chế độ xem thử nghiệm

Viết các trường hợp thử nghiệm 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

Thử nghiệm 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 trạng thái về tiến độ thử nghiệm

Theo dõi lỗi

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

ảnh minh họa

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

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

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

Xử lý là một hành động cung cấp một sự cải tiến để thay thế một sai lầm và thiết lập nó đúng. Thường thì sự hiện diện của tính dễ bị tổn thương trong một khu vực có thể cho thấy sự yếu kém trong quá trình hoặc thực tiễn phát triển có thể nhân rộng hoặc kích hoạt tính dễ bị tổn thương tương tự ở các địa điểm khác.

Do đó, trong khi khắc phục, điều quan trọng là người thử phải điều tra cẩn thận thực thể hoặc ứng dụng được thử nghiệm với các biện pháp kiểm thử bảo mật không hiệu quả trong tâm trí.

Vì những lý do này, công ty tương ứng nên thực hiện các bước để khắc phục mọi lỗ hổng có thể khai thác trong một khoảng thời gian hợp lý sau khi thử nghiệm thâm nhập ban đầu.

Trong thực tế, ngay sau khi công ty đã hoàn thành các bước này, người kiểm thử bút phải thực hiện kiểm thử lại để xác thực các điều khiển mới được thực hiện có khả năng giảm thiểu rủi ro ban đầu.

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

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

Tất cả các thay đổi cần được kiểm thử lại; tuy nhiên, việc kiểm thử lại toàn bộ hệ thống là cần thiết hay không sẽ được xác định bởi đánh giá rủi ro của các thay đổi.