Bug life cycle là gì

Software bugs are a fact of life. The bad news is that finding and fixing software bugs takes up a significant portion of your software development time. In this article, we’ll show you how to get better at spotting them and how to develop more effective bug-tracking practices.

What is Defect/Bug?

A defect is a deviation from a specified requirement or specification.

In the context of software development, a bug is an error, flaw, failure or fault in a computer program that causes it to behave unexpectedly or not function as intended. A defect may also be called an anomaly, fault, failure or bug depending on context.

The process of fixing a defect is called debugging and consists of testing to find the cause of the bug and correcting it.

What is Defect Life Cycle?

A defect life cycle is the path that a defect follows from its inception to resolution. It starts with the initial discovery of a problem, continues through all levels of investigation and decision-making, and finally ends with closure or abandonment.

‍

Defect States

1. New:

In the Defect Life Cycle, this is the first state of a defect. When a new flaw is discovered, it is classified as 'New,' and validations and testing are done on it later in the Defect Life Cycle.

2. Assigned:

During the development phase, a product defect is collected and assigned to the team responsible. The development manager or project lead assigns each developer as they see fit.

3. Open:

Any time a developer flags an issue in the new application, they must immediately start addressing it. The status of a bug is always evaluated based on the impact on overall functionality of the app. If the defect poses more harm to the user experience than other bugs, the status will be changed accordingly with respect to severity. In case, the defect has no impact on overall performance and could be cleared without much hassle then it may be waived from any further analysis.

4. Fixed:

Once the developer finishes the task of making the required changes to fix a defect, they can mark their progress in the project management system by changing its status from “In Progress” to “Fixed.”

5. Pending Retest

Upon fixing a defect, the developer assigns the defect back to testers who will be responsible for retesting the defect and therefore marking it as fixed once all possible defects have been eliminated.

6. Retest

When testers have successfully validated the fix of a bug, they proceed to retest it to confirm that the solution works as expected.

7. Reopen

If any issue persists in the defect, then it will be assigned to the developer again. And if after fixing the bug it works, and if again found in another testing it is marked as ‘Reopen’.

8. Closed

When a technical issue has been handled, the quality analyst will change the status of the defect in an appropriate system to “Closed”.

Role of Bug Life Cycle

a) For testers:

They will be responsible for the verification of the fix of bugs. When testing a game, testers need to make sure they fire at any bugs they come across. They'll do their best to track those down and won't rest until they're squashed!

Good knowledge of bug status will help them report things clearly and in a timely manner so that people know exactly what's going on, there are no misunderstandings over prioritising tasks, and any bugs should be fixed as quickly as possible.

b)For developers:

If a problem is identified within some aspect of the application, it gets reported by users (or testers) and then forwarded to either developers or product managers concerned. Both parties can work together in order to identify the proper course of action for resolving bugs - whether that means the presence of more information from the part of testers about what steps led up to the bug being discovered, or if it's enough to know that there isn't too much in terms of existing documentation on how this kind of scenario should be handled.

It's important that they are both on board with which path each discovery takes because otherwise time will be wasted through miscommunication.

c)For Product managers

To do a proper job managing and keeping track of product bugs, it’s important to have all the right details at hand. This includes what stage each bug is in, who we need to give feedback on them, as well as their status and other related factors.

Bugs can come up at any time, and so it helps to have this information handy so that we can change direction quickly if necessary and make sure everything goes smoothly while keeping tabs on what's going on behind the scenes.

Wrapping up

Every piece of software needs to be tested before it is released. Even the most well-tested programs have bugs, but it's important to remember that not all bugs are created equal. Some bugs will affect only a small percentage of users, while others can cause significant problems for large numbers of people. Bug life cycle helps us understand when and how we should fix them.

‍

 - Bài 3 : Tìm hiểu Quy trình SDLC , STLC sẽ  giải thích SDLC (Software Development Life-cycle/chu kỳ phát triển phần mềm) , Software Test Life Cycle - STLC ( Quy tắc kiểm thử) và một số mô hình kiểm thử thường áp dụng 

I. Tình huống 

- Gỉa sử Bạn/ Team bạn/ Công ty nhận một dự án phần mềm của một khách hàng . Việc phát triển  - Kiểm thử - Bàn giao sẽ trải qua các giai đoạn sau: 

1) Thu thập càng nhiều thông tin càng tốt về tất cả các yêu cầu cụ thể về kỷ thuật, logic, giao diện, mục đích sử dụng và các mong muốn khác. Càng cụ thể càng tốt . Đó là giai đoạn  THU THẬP YÊU CẦU PHẦN MỀM  (Requirement Analysis). 

2) Từ những yêu cầu có được ở giai đoạn 1, Lập kế hoạch cho các ngôn ngữ lập trình như Java, php, .net ...Cơ Sở dữ liệu như Oracle, My SQL,SQL Server...để đáp ứng đầy đủ  với yêu cầu chức năng và yêu cầu kỷ thuật cho các chức năng hiện tại và những yêu cầu trong tương lai có thể được giải quyết. Đây là giai đoạn THIẾT KẾ (Software Architecture/Design). 

3) Sau khi đã có thiết kế, đội ngũ Developer sẽ thực hiện xây dựng phần mềm dựa trên những đặc tả thiết kế . Đây là giai đoạn CODING ( Development). 

4) Tiếp đến,  thử nghiệm các chức năng được xây dựng ở giai đoạn 3  để xác minh rằng nó đúng với yêu cầu của khách hàng . Đây là giai đoạn KIỂM THỬ PHẦN MỀM (Software Testing) .

5) Một khi sản phẩm phần mềm đã sẵn sàng, Việc bảo trì,nâng cấp để giải quyết các vấn đề nảy sinh hoặc các yêu cầu mới từ khách hàng . Đây sẽ là giai đoạn BẢO TRÌ (Maintenance) . 

Những giai đoạn ở tình huống trên nằm trong chu kỳ phát triển phần mềm . 
Vậy quy trình phát triển phần mềm (SDLC) là gì? Nó là qui trình chung của một tổ chức, trình tự các hoạt động để phát triển 1 ứng dụng. 

Có rất nhiều quy trình phát triền phần mềm khác nhau như : Mô hình thác nước, mô hình chữ V, Mô hình xoắn ốc ...hoặc kết hợp các mô hình.

2-  Qui trình kiểm thử phần mềm (STLC) 

 Là những  hoạt động của QC -Tester Team để kiểm thử một ứng dụng phần mềm. Bao gồm: 

1)  Preparing the test strategy : Phương pháp kiểm thử tiếp cận, xác định chiến lược kiểm thử , tùy theo yêu cầu của khách hàng mà nên ưu tiên những vấn đề nào trước. Thường giai đoạn này ta sẽ tự đặt câu hỏi: Sẽ kiểm thử cái gì và kiểm thử như thế nào 

2) Preparing the test plan: Lập kế hoạch kiểm thử . Xác định và phân chia họp lý thời gian, nhân sự , các tool được sử dụng cho từng chắc năng 

3) Creating the test environment: Chuẩn bị môi trường, nền tảng cho công việc kiểm thử phần mềm, gồm Hệ điều hành(Win 7, win 8, linux , IOS...) , Trình duyệt (IE, Safari, Opera...), thiết bị ( Mobile, tablet, desktop...)

3)Write test cases/Test script: Viết testcase cho các trường họp sẽ test bao gồm cả 3 trường họp : True, Fail và không xác định kết quả ( case nảy sinh, không có trong tài liệu đặc tả (spec) . Viết test script nếu có dùng tool để thực hiện automation test cho test chức năng, giao diện hoặc các kịch bản 

4) Executing the test scripts/ test cases: Thực thi các case trong testcase/test scrips để thực hiện việc kiểm thử, quá trình này có thể có update thêm một số case còn thiếu (nếu có hoặc phát sinh thêm) 

5) Analyzing the results and reporting the bugs: Phân tích kết quả test để tìm hiểu nguyên nhân gây bug định hướng cách khắc phục đồng thời  post bug lên các bug tracking (Jira, mantis...) 

6) Doing regression testing : Test quy hồi sau khi bug đã được fixed. 

7) Test exiting: Kết thúc công việc kiểm thử - báo cáo hoặc ghi lại các kinh nghiệm đã gặp phải trong dự án này. Các vấn đề "can not fix" đồng thời thống kê lại số liệu các bug 

----------------------------------------------------------

http://kiemthuphanmemvvn.blogspot.com/

Face: https://www.facebook.com/KiemThuPhanMemVvn

Group: https://www.facebook.com/groups/1549328495322684/ 

Chọn "Đăng ký nhận bài qua mail" để nhận bài viết mới nhất nhé 

---

Page 2