Trong phần này, chúng ta sẽ tìm hiểu hoạt động của quy trình quản lý Defect. Ngoài ra, hãy xem các Defect trong kiểm thử phần mềm, mục tiêu của quá trình quản lý lỗi, quá trình quản lý lỗi, ưu điểm và nhược điểm của quá trình quản lý lỗi. Tuy nhiên, trước tiên, chúng ta sẽ hiểu quá trình quản lý lỗi và chúng ta sẽ hiểu lỗi trong kiểm thử phần mềm. Các bài viết liên quan:
Defect trong kiểm thử phần mềm
- Bug được thông báo bởi chương trình và bên trong mã được gọi là defect
- Nói cách khác, chúng ta có thể nói rằng khi ứng dụng không hoạt động theo yêu cầu được coi là Defect.
- Nó được chỉ định là sự bất thường so với kết quả thực tế và dự kiến của ứng dụng hoặc phần mềm.
- Defectis sự khác biệt giữa kết quả thực tế và kết quả mong đợi.
- Phần mềm kiểm tra xác định lỗi và nó đã được nhà phát triển sửa trong giai đoạn phát triển của vòng đời phát triển phần mềm.
- Khi một kỹ sư kiểm thử kiểm tra một đoạn mã, anh ta / cô ta bắt gặp sự khác biệt về kết quả đầu ra dự kiến so với đầu ra hiện có, được gọi là một Defect. Và lỗi thay thế có thể được gọi là các vấn đề, lỗi và sự cố trong kiểm thử phần mềm.
Xem thêm Vòng đời phát triển phần mềm (SDLC)
Quy trình quản lý Defect là gì?
Quá trình quản lý defect là cốt lõi của kiểm thử phần mềm. Khi các Defect đã được xác định, hoạt động quan trọng nhất đối với bất kỳ tổ chức nào là quản lý các sai sót, không chỉ cho nhóm kiểm thử mà còn cho tất cả mọi người tham gia vào quá trình phát triển phần mềm hoặc quản lý dự án.
Như chúng ta đã biết, phòng ngừa lỗi là một cách hiệu quả và hiệu quả để giảm số lượng Defect. Ngăn ngừa lỗi là một quá trình rất hiệu quả về mặt chi phí để sửa chữa những Defect được phát hiện trong các giai đoạn trước của quy trình phần mềm.
Quy trình quản lý Defect là quy trình trong đó hầu hết các tổ chức quản lý việc phát hiện Defect, loại bỏ Defect và sau đó là cải tiến quy trình.
Như tên đề xuất, Quy trình Quản lý Lỗi (DMP) quản lý các lỗi bằng cách phát hiện và giải quyết hoặc sửa chữa các lỗi một cách thuần túy.
Không thể tạo ra một phần mềm 100% lỗi hoặc không có lỗi, nhưng một số lỗi có thể được loại bỏ bằng cách sửa chữa hoặc giải quyết chúng.
Quá trình quản lý Defect chủ yếu tập trung vào việc ngăn chặn các Defect, tìm ra các Defect trong các giai đoạn trước đó và điều chỉnh ảnh hưởng của các Defect.
Xem thêm Kiểm tra lỗ hổng bảo mật Improper Error Handling
Mục tiêu của Defect Management Process (DMP)
Mục tiêu chính của quá trình quản lý Defect như được thảo luận dưới đây:
- Mục tiêu chính của DMP là phơi bày những Defect ở giai đoạn đầu của quá trình phát triển phần mềm.
- Việc thực hiện quy trình quản lý lỗi sẽ giúp chúng tôi nâng cao quy trình và việc triển khai phần mềm.
- Quá trình quản lý Defect làm giảm tác động hoặc ảnh hưởng của các Defect đối với phần mềm.
- Quy trình quản lý Defect (DMP) giúp chúng tôi tránh được các Defect.
- Mục tiêu chính của quy trình quản lý Defect là giải quyết hoặc sửa chữa các Defect.
Và đối với các tổ chức hoặc dự án khác nhau, các mục tiêu quan trọng của quá trình quản lý Defect như sau:
- Quy trình quản lý lỗi cho phép chúng tôi cung cấp đầu vào cho các báo cáo trạng thái và tiến độ về lỗi.
- Để tìm nguyên nhân chính dẫn đến lỗi đã xảy ra như thế nào và cách xử lý.
- Để cung cấp thông tin đầu vào, thông tin liên quan đến việc giải phóng Defect.
Các giai đoạn khác nhau của quy trình quản lý Defect
Quá trình quản lý Defect bao gồm một số giai đoạn như sau:
- Defect Prevention
- Deliverable Baseline
- Defect Discovery
- Defect Resolution
- Process Improvement
- Management Reporting
Hãy thảo luận về chúng từng cái một:
Defect Prevention
Giai đoạn đầu tiên của quá trình quản lý Defect là phòng ngừa lỗi. Trong giai đoạn này, việc thực hiện các thủ tục, phương pháp luận và các phương pháp tiếp cận tiêu chuẩn làm giảm nguy cơ sai sót. Loại bỏ Defect ở giai đoạn đầu là cách tiếp cận tốt nhất để giảm tác động của nó.
Bởi vì trong giai đoạn ban đầu, việc sửa chữa hoặc giải quyết các Defect sẽ ít tốn kém hơn, và tác động cũng có thể được giảm bớt.
Nhưng đối với các giai đoạn trong tương lai, việc xác định lỗi và sau đó sửa chữa nó là một quá trình tốn kém và ảnh hưởng của lỗi cũng có thể được khuếch đại.
Giai đoạn ngăn ngừa lỗi bao gồm các bước quan trọng sau:
- Ước tính tác động có thể dự đoán
- Giảm thiểu tác động dự kiến
- Xác định rủi ro quan trọng
Bước 1: Ước tính tác động có thể dự đoán được
Trong bước này, nếu rủi ro gặp phải, chúng ta có thể tính toán tác động tài chính ước tính cho mỗi dịp quan trọng.
Bước 2: Giảm thiểu tác động dự kiến
Khi tất cả các rủi ro trọng yếu đã được phát hiện, chúng tôi có thể chấp nhận những rủi ro cao nhất có thể gây nguy hiểm cho hệ thống nếu gặp phải và cố gắng giảm thiểu hoặc loại bỏ nó.
Những rủi ro không thể loại bỏ được sẽ làm giảm khả năng tồn tại và tác động tài chính của nó.
Bước 3: Xác định rủi ro quan trọng
Trong phòng ngừa lỗi, chúng tôi có thể nhanh chóng xác định các rủi ro quan trọng của hệ thống sẽ ảnh hưởng nhiều hơn nếu chúng xảy ra trong suốt quá trình thử nghiệm hoặc trong giai đoạn tương lai.
Deliverable Baseline
Giai đoạn thứ hai của quá trình quản lý Defect là D
đường cơ sở có thể tồn tại được. Ở đây, tệp có thể phân phối xác định hệ thống, tài liệu hoặc sản phẩm.
Chúng ta có thể nói rằng sản phẩm có thể phân phối là đường cơ sở ngay khi có thể phân phối đạt đến mốc được xác định trước.
Lưu ý: Mốc quan trọng được xác định trước mô tả những gì phần mềm phải đạt được.
Trong giai đoạn này, vật có thể chuyển giao được chuyển từ bước này sang bước khác; các Defect hiện có của hệ thống cũng chuyển sang bước tiếp theo hoặc một cột mốc quan trọng.
Nói cách khác, chúng ta có thể nói rằng sau khi một sản phẩm có thể phân phối được xác định cơ sở, mọi thay đổi bổ sung sẽ được kiểm soát.
Defect Discovery
Giai đoạn tiếp theo của quá trình quản lý Defect là phát hiện ra Defect. Ở giai đoạn đầu của quá trình quản lý Defect, việc phát hiện ra Defect là rất quan trọng. Và sau này, nó có thể gây ra thiệt hại lớn hơn.
Nếu các nhà phát triển đã phê duyệt hoặc ghi nhận lỗi là một lỗi hợp lệ, thì chỉ một lỗi được coi là được phát hiện.
Như chúng ta đã hiểu, trên thực tế không thể loại bỏ từng Defect khỏi hệ thống và làm cho hệ thống không có Defect. Nhưng chúng ta có thể phát hiện sớm các Defect trước khi chúng trở nên đắt đỏ đối với dự án.
Các giai đoạn sau đã bao gồm trong giai đoạn phát hiện Defect; chúng ta hãy hiểu chúng một cách chi tiết:
- Xác định một Defect
- Báo cáo lỗi
- Thừa nhận Defect
Giai đoạn 1: Xác định một Defect
Trong giai đoạn đầu tiên của việc phát hiện Defect, nơi chúng ta cần tìm ra những Defect trước khi trở thành một vấn đề quan trọng.
Giai đoạn 2: Báo cáo một Defect
Thời điểm nhóm kiểm tra xác định được lỗi, họ cần chỉ định các vấn đề đã biết cho nhóm phát triển để đánh giá thêm và quy trình sửa chữa.
Giai đoạn 3: Thừa nhận Defect
Sau khi các kỹ sư thử nghiệm bàn giao lỗi cho các nhà phát triển được chỉ định, bây giờ các nhóm phát triển có trách nhiệm thừa nhận lỗi và tiếp tục khắc phục nếu lỗi đó là lỗi hợp lệ.
Defect Resolution
Khi giai đoạn phát hiện lỗi đã được hoàn thành thành công, chúng tôi chuyển sang bước tiếp theo của quy trình quản lý lỗi, Giải quyết Defect.
Giải pháp Defect là một quy trình từng bước để sửa chữa các Defect, hoặc chúng ta có thể nói rằng quá trình này có lợi để xác định và theo dõi các Defect.
Quá trình này bắt đầu bằng việc bàn giao các Defect cho nhóm phát triển. Các nhà phát triển cần phải tiến hành giải quyết các Defect và sửa chúng dựa trên mức độ ưu tiên.
Khi lỗi đã được chọn, nhà phát triển sẽ gửi báo cáo giải quyết lỗi cho nhóm kiểm tra của người quản lý kiểm tra.
Quá trình giải quyết lỗi cũng liên quan đến việc thông báo lại cho kỹ sư kiểm tra để xác nhận rằng giải pháp đã được xác minh.
Chúng tôi cần làm theo các bước dưới đây để hoàn thành giai đoạn giải quyết lỗi.
- Ưu tiên rủi ro
- Sửa lỗi
- Báo cáo Nghị quyết
Bước 1: Ưu tiên rủi ro
Trong bước đầu tiên của quá trình giải quyết Defect, nhóm phát triển đánh giá các Defect
và sắp xếp việc sửa chữa lỗi. Nếu một Defect nào đó ảnh hưởng nhiều hơn đến hệ thống, thì các nhà phát triển cần phải ưu tiên sửa chữa những Defect đó.
Bước 2: Sửa lỗi
Trong bước thứ hai, nhà phát triển sẽ sửa chữa các lỗi theo mức độ ưu tiên, có nghĩa là các lỗi có mức độ ưu tiên cao hơn sẽ được giải quyết trước. Sau đó, nhà phát triển sẽ sửa các lỗi có mức ưu tiên thấp hơn.
Bước 3: Báo cáo Nghị quyết
Trong bước cuối cùng của quá trình giải quyết lỗi, nhà phát triển cần gửi báo cáo lỗi đã sửa. Vì các nhóm phát triển có trách nhiệm đảm bảo rằng nhóm kiểm thử nhận thức rõ khi nào các lỗi sẽ được sửa và cách nào để sửa lỗi.
Bước này sẽ có lợi cho quan điểm của nhóm kiểm thử để hiểu được gốc rễ của lỗi.
Process Improvement
Trong giai đoạn trên (giải quyết Defect), các Defect đã được sắp xếp và sửa chữa.
Bây giờ, trong giai đoạn cải tiến quy trình, chúng ta sẽ xem xét các Defect có mức độ ưu tiên thấp hơn vì những Defect này cũng rất cần thiết cũng như tác động đến hệ thống.
Tất cả các Defect được thừa nhận đều tương đương với một Defect nghiêm trọng theo quan điểm của giai đoạn cải tiến quy trình và cần được sửa chữa.
Những người có liên quan trong giai đoạn cụ thể này cần phải nhớ lại và kiểm tra xem lỗi được bắt đầu từ đâu.
Tùy thuộc vào điều đó, chúng tôi có thể thực hiện các sửa đổi trong quy trình xác nhận, tài liệu nền tảng, quy trình xem xét có thể tìm ra các sai sót sớm trong quy trình và làm cho quy trình này ít tốn kém hơn.
Những Defect nhỏ này cho phép chúng tôi tìm hiểu cách chúng tôi có thể cải tiến quy trình và tránh sự tồn tại của bất kỳ loại Defect nào có thể ảnh hưởng đến hệ thống hoặc sự cố của sản phẩm trong tương lai.
Management Reporting
Báo cáo quản lý là giai đoạn cuối cùng của quá trình quản lý Defect. Đây là một phần quan trọng và thiết yếu của quá trình quản lý Defect. Báo cáo quản lý là bắt buộc để đảm bảo rằng các báo cáo được tạo ra có mục tiêu và tăng cường quá trình quản lý sai sót.
Nói một cách dễ hiểu, chúng ta có thể nói rằng việc đánh giá và báo cáo của tổ chức hỗ trợ thông tin Defect và quản lý rủi ro, cải tiến quy trình và quản lý dự án.
Bộ thu thập thông tin
Kiểm tra các Defect cụ thể của các nhóm dự án là cơ sở của báo cáo quản lý. Do đó, mọi tổ chức cần xem xét thông tin thu thập được trong suốt quá trình quản lý Defect và nhóm các Defect riêng lẻ.
Quy trình và trạng thái công việc Defect
Nhiều tổ chức khác nhau đạt được kiểm thử phần mềm với sự trợ giúp của một công cụ theo dõi các lỗi trong vòng đời của lỗi / lỗi và cũng chứa các báo cáo lỗi.
Nói chung, một chủ sở hữu của các lỗi báo cáo ở mỗi trạng thái của vòng đời lỗi, chịu trách nhiệm hoàn thành một nhiệm vụ sẽ chuyển báo cáo lỗi sang trạng thái kế tiếp.
Đôi khi, báo cáo lỗi có thể không có chủ sở hữu trong giai đoạn cuối của vòng đời lỗi nếu chúng ta có thể gặp phải tình huống sau:
- Nếu lỗi không hợp lệ, thì báo cáo Lỗi sẽ bị hủy.
- Báo cáo lỗi được coi là hoãn lại nếu lỗi không được sửa như một phần của dự án.
- Nếu lỗi không thể được phát hiện nữa, do đó báo cáo lỗi được coi là không thể lặp lại.
- Báo cáo Defect được coi là kết thúc nếu Defect đã được khắc phục và kiểm tra.
Defect States
Nếu các Defect được xác định trong suốt quá trình thử nghiệm, nhóm thử nghiệm phải quản lý chúng ở ba trạng thái sau:
- Initial state
- Returned state
- Confirmation state
- Initial state
Đây là trạng thái đầu tiên của Defect, còn được gọi là trạng thái mở.
Một hoặc một số kỹ sư kiểm tra chịu trách nhiệm thu thập tất cả dữ liệu cần thiết để sửa chữa các Defect trong trạng thái này.
- Returned state
Trạng thái Defect thứ hai là trạng thái trả về. Trong trường hợp này, người nhận báo cáo thử nghiệm từ chối và yêu cầu người tạo báo cáo cung cấp thêm thông tin.
Ở trạng thái trả về, các kỹ sư kiểm tra có thể cung cấp thêm thông tin hoặc chấp nhận việc từ chối báo cáo.
Nếu các báo cáo khác nhau bị từ chối, người quản lý kiểm tra nên tìm ra các lỗi trong chính quá trình thu thập thông tin ban đầu.
Trạng thái trả về còn được gọi là trạng thái làm rõ hoặc trạng thái bị từ chối.
- Confirmation state
Trạng thái cuối cùng của lỗi là trạng thái xác nhận, trong đó kỹ sư kiểm tra thực hiện kiểm tra xác nhận để đảm bảo rằng lỗi đã được khắc phục.
Nó đạt được bằng cách lặp lại các bước, đã tìm thấy Defect tại thời điểm thử nghiệm.
Nếu lỗi được giải quyết, thì báo cáo sẽ được đóng lại.
Và nếu lỗi không được giải quyết, thì báo cáo được coi là được mở lại và báo cáo lại cho chủ sở hữu trước đây đã bảo quản báo cáo lỗi đó để sửa chữa.
Trạng thái xác nhận còn được gọi là trạng thái đã xác minh hoặc đã giải quyết.
Ưu điểm của quy trình quản lý Defect
Sau đây là những lợi ích quan trọng nhất của quy trình quản lý Defect:
- Quá trình quản lý lỗi cũng sẽ giúp chúng tôi đảm bảo việc giải quyết các lỗi đang được theo dõi.
- Khả năng tiếp cận của các công cụ tự động hóa
- Một trong những thủ tục quan trọng nhất của quy trình quản lý lỗi là quy trình theo dõi lỗi hoặc lỗi.
- Để theo dõi lỗi, chúng tôi có nhiều công cụ tự động hóa khác nhau có sẵn trên thị trường, có thể giúp chúng tôi theo dõi lỗi trong giai đoạn đầu.
Ngày nay, nhiều công cụ khác nhau có sẵn để theo dõi các loại Defect khác nhau. Ví dụ,
Công cụ phần mềm: Các loại công cụ này được sử dụng để xác định hoặc theo dõi các vấn đề không liên quan đến kỹ thuật.
Công cụ hướng tới người dùng: Những loại công cụ này sẽ giúp chúng tôi phát hiện ra những Defect liên quan đến sản xuất.
Cung cấp các chỉ số có giá trị
Quy trình quản lý lỗi cũng cung cấp cho chúng tôi các thước đo lỗi có giá trị cùng với các công cụ tự động hóa.
Và những chỉ số lỗi có giá trị này giúp chúng tôi báo cáo và cải tiến liên tục.
Nhược điểm của quy trình quản lý Defect
Những hạn chế của quy trình quản lý Defect như sau:
- Nếu quy trình quản lý sai sót không được thực hiện một cách thích hợp, thì chúng tôi có thể mất khách hàng, mất doanh thu và uy tín thương hiệu bị tổn hại.
- Nếu quy trình quản lý sai sót không được xử lý đúng cách, thì sẽ có một khoản chi phí tăng lên rất lớn, đó là sự tăng giá của sản phẩm.
- Nếu các Defect không được hoàn thành một cách thích hợp ở giai đoạn đầu, thì về sau, Defect có thể gây ra thiệt hại lớn hơn và chi phí để sửa chữa các Defect cũng sẽ tăng lên.
Kết luận
Trong bài viết này, chúng ta đã xem xét các Defect trong kiểm thử phần mềm, Quy trình quản lý Defect, lợi ích và hạn chế.
Trong kiểm thử phần mềm, Quy trình quản lý lỗi rất quan trọng vì chúng tôi nhận thức được bất kỳ phần mềm nào được viết mã, các lỗi cần được kiểm tra.
Quá trình quản lý lỗi bao gồm việc phát hiện ra các lỗi trong phần mềm và sửa chữa chúng. Quá trình quản lý lỗi hoàn chỉnh sẽ giúp chúng tôi tìm ra lỗi trong giai đoạn đầu và cũng đảm bảo cung cấp một sản phẩm chất lượng cao.
Việc thực hiện quy trình quản lý lỗi đảm bảo rằng không có thêm Defect nào trong ứng dụng khi chuyển nó sang sản xuất. Và kết quả của việc đó sẽ giúp tiết kiệm rất nhiều tiền.
Trong phương pháp luận nhanh nhẹn, quy trình quản lý Defect có ý nghĩa đặc biệt vì các bước chạy nước rút của sự phát triển cũng phải có sự tham gia, cụ thể
pation và hành động từ các kỹ sư thử nghiệm.
Trong bất kỳ tổ chức nào, quản lý cấp cao cũng nên hiểu và hỗ trợ quá trình quản lý Defect trên quan điểm cải thiện công ty.
Xem thêm Đệ quy là gì? Đệ quy trong Dart