Vòng đời bug trong kiểm thử phần mềm là gì?
Trong kiểm thử phần mềm, Vòng đời bug là tập hợp chính xác các giai đoạn mà bug trải qua trong suốt vòng đời của nó. Mục tiêu của vòng đời bug là làm cho quá trình sửa chữa bug hiệu quả hơn thông qua việc phối hợp và thông báo tình trạng hiện tại của các bug khi chúng được xử lý bởi nhiều người.
Vòng đời của bug trong quy trình kiểm thử phần mềm là gì?
Vòng đời bug được chia thành chín giai đoạn như dưới đây:
1. Mới xuất hiện
Ở giai đoạn đầu của vòng đời, vấn đề được phát hiện. Khi một bug mới được phát hiện, nó sẽ được gán trạng thái, sau khi quá trình kiểm tra và xác nhận bắt đầu, nó sẽ lại có trạng thái mới.
2. Được ủy quyền
Bug mới xuất hiện sẽ được giao cho bộ phận thích hợp giải quyết. Thông thường, quản lý nhóm kiểm thử sẽ là người chỉ định các bug cho nhóm sản xuất.
3. Mở
Khi một nhà sản xuất bắt đầu giải quyết vấn đề, bug ở trạng thái mở. Các nhà sản xuất sẽ bắt đầu khắc phục bug dựa trên các thông số kỹ thuật. Cũng có khả năng vấn đề sẽ không xuất hiện một cách thích hợp; trong trường hợp này, nhà sản xuất có thể chuyển vấn đề sang một trong bốn trạng thái này vì những lý do cụ thể.
- Trùng lặp
- Bị hoãn
- Bị từ chối
- Không phải là bug
4. Sửa
Khi nhà sản xuất thực hiện các biện pháp thích hợp và các vấn đề được giải quyết, trạng thái được đánh dấu là đã khắc phục.
5. Chờ kiểm tra lại
Sau khi nhà sản xuất đã giải quyết vấn đề và thực hiện các điều chỉnh cần thiết, nó sẽ được giao lại cho tester để kiểm tra lại. Thời gian chờ đợi kiểm thử lặp lại và sự cố vẫn ở trong tình trạng “Đang chờ kiểm tra lại”.
6. Lặp lại kiểm thử
Trường hợp bước vào giai đoạn kiểm thử lại khi tester tiếp tục kiểm tra sự cố. Tester sẽ kiểm tra lại xem nhà sản xuất có sửa chữa các vấn đề đúng theo yêu cầu hay không.
7. Mở lại
Nếu các yêu cầu không được hoàn thành một cách chính xác và sự cố vẫn còn trong các chức năng, tester sẽ mở lại trạng thái bug.
8. Xác nhận
Nếu sự cố không có vấn đề gì và đã được nhà sản xuất sửa chữa một cách thích hợp, trạng thái của bug sẽ được thay đổi và nó được ghi lại là đã xác nhận.
9. Hoàn thành
Khi một lỗ hổng không tồn tại và được đánh giá và xác nhận đầy đủ, dẫn đến tình trạng đóng. Tester sửa đổi trạng thái của bug.
Sau đây là một số ví dụ về vòng đời bug:
- Mới. Một tester đảm bảo chất lượng (hãy gọi anh ta là Tom) truy cập trang web của một cửa hàng sách trực tuyến mà anh ta đang đánh giá và thêm một cuốn sách vào giỏ hàng. Vật phẩm được thêm vào giỏ hàng của Tom, nhưng anh ấy không thể đặt hai cuốn sách giống nhau. Một cú nhấp chuột vào “+” để điều chỉnh số lượng không có tác dụng. Tom nêu chi tiết vấn đề và tạo một báo cáo bug dưới dạng “Mới”.
- Được giao. Một PM (giả sử Susan, người quản lý dự án) nhận thấy một lỗ hổng trong danh sách. Vấn đề có vẻ là thực tế và quan trọng. Susan đã giao công việc cho Brian, một nhà sản xuất phụ, người phát triển tính năng giỏ hàng.
- Mở. Brian nhận được nhiệm vụ mới và cố gắng sao chép nó bằng cách làm theo các hướng dẫn trong báo cáo. Biểu tượng “+” không hoạt động như dự định. Brian cập nhật trạng thái bug thành Mở và bắt đầu điều tra nguyên nhân. Tuy nhiên, không phải trường hợp nào cũng diễn ra như vậy. Brian hiểu rằng bug có thể không hợp lệ. Trong khi cố gắng giải quyết nó ngay lập tức, anh ta có thể sử dụng một trạng thái thay thế, chẳng hạn như:
- Nhân bản. Trong khi đọc báo cáo, Brian nhận thấy rằng Peter, một tester phần mềm khác, đã báo cáo bug này một ngày trước đó. Brian phân loại vấn đề là trùng lặp.
- Bị từ chối. Brian thêm sách vào giỏ và nhấp vào “+” bằng cách sử dụng hướng dẫn từ báo cáo sự cố. Số giảm còn hai. Có lẽ sự cố là do kết nối internet không đáng tin cậy. Hoặc bug xảy ra trên một thiết bị nào đó, nhưng Tom không đề cập đến thông tin này trong phần mô tả.
- Hoãn lại. Lỗ hổng này chỉ ảnh hưởng đến trình duyệt Firefox, trình duyệt có lượng người dùng hạn chế. Brian chọn sửa nó sau khi xác định được nguồn gốc của các bug thanh toán. thành viên của khả năng của nhóm thử nghiệm
- Không phải là bug. Brian được thông báo nhưng nhanh chóng phát hiện ra Tom đã cố gắng mua thêm một cuốn sách điện tử. Điều này là không thể do logic của trang web: người dùng có thể truy cập ebook từ bất kỳ thiết bị nào, loại bỏ nhu cầu lấy nó hai lần.
- Cần thêm thông tin. Brian không chắc chắn về hoàn cảnh xuất hiện của con bọ. Người dùng có đang đăng nhập vào tài khoản của mình lúc này không? Tom đang cố thêm một mặt hàng trên trang sản phẩm hay ở giai đoạn xác nhận đơn hàng?
- Không thể sửa chữa được. Brian nhận thức được tình hình và đã cố gắng khắc phục nó nhiều lần. Đó là một bug khó xác định và anh ấy sẽ phải qua một cơ sở mã lớn để sửa chữa nó. Hiện tại, một người có thể đặt hai cuốn sách bằng cách nhập “2” vào ô hiển thị số lượng hàng hóa.
- Đã sửa. Brian phát hiện và sửa bug mã hóa. Sau đó, anh ta thay đổi tiến trình thành “Đã sửa”.
- Chờ kiểm tra lại. Khi bug đã được sửa, kiểm thử sẽ được giao cho Tom và chờ quá trình kiểm tra lại.
- Kiểm thử lại. Tom được thông báo rằng trạng thái lỗi của anh ấy đã thay đổi. Anh ấy phải kiểm tra lại chức năng và đảm bảo rằng người dùng hiện có thể điều chỉnh số lượng sách. Anh ấy kích hoạt trạng thái thử lại và bắt đầu làm việc.
- Đã mở lại. Không may rằng Tom thấy vấn đề vẫn tồn tại trong suốt quá trình kiểm thử lại. Số lượng mục không thay đổi khi bạn nhấp vào “+”. Lỗi được mở lại và đưa cho Brian. Brian cần kiểm tra lại vấn đề. Sự cố sẽ được kiểm thử lại lần nữa khi nó đã được khắc phục.
- Đã xác minh. Trong quá trình kiểm thử, Tom đảm bảo rằng nút hoạt động như dự định. Người dùng hiện có thể điều chỉnh số lượng hàng hóa trong giỏ bằng cách nhấn “+”. Tom cập nhật trạng thái của bug thành. Đã xác minh.
- Đã đóng. Susan kết thúc công việc sau khi xác nhận rằng vấn đề đã được giải quyết.
.png)
Kết luận
Vòng đời của bug kết thúc khi bug đã được khắc phục và vấn đề được giải quyết. Tuy nhiên, giai đoạn tiếp theo của chu kỳ phát triển mở ra: kiểm thử hồi quy. Sau khi mọi thứ đã được khắc phục, QA tester kiểm thử hệ thống (hoặc ít nhất là các chức năng quan trọng trong) để đảm bảo rằng các sửa đổi gần đây không ảnh hưởng đến các chức năng. Nói cách khác, điều quan trọng là phải đảm bảo rằng việc sửa chữa không làm sai lệch những gì trước đó đã hoạt động bình thường. Và nếu có, một vòng đời bug sẽ lại bắt đầu.
Nếu bạn đang tìm kiếm một nhà cung cấp IT giàu kinh nghiệm, GCT Solution là sự lựa chọn lý tưởng. Chúng tôi có hơn 3 năm kinh nghiệm trong việc cung cấp các giải pháp số hóa cho doanh nghiệp như phát triển ứng dụng di động, phát triển ứng dụng web, phát triển hệ thống, phát triển blockchain và dịch vụ kiểm thử. Cùng đội ngũ gồm hơn 100 chuyên gia và lập trình viên, chúng tôi có thể xử lý các dự án ở mọi quy mô cũng như độ phức tạp. Chúng tôi đã hợp tác thành công với các khách hàng từ nhiều ngành nghề và khu vực khác nhau, mang lại hơn 50+ giải pháp chất lượng cao. Tại GCT Solution, chúng tôi cam kết hỗ trợ bạn trong việc đạt được mục tiêu của bạn. Nếu bạn quan tâm, xin vui lòng liên hệ với chúng tôi để có một cuộc thảo luận chi tiết. Chúng tôi tự tin rằng GCT Solution có thể đáp ứng mọi nhu cầu IT của bạn với những giải pháp linh hoạt và hiệu quả.
Author: Chi Vo – Content Marketing Executive
