Error, Bugs, Failure
Duy Văn | 23/11/2024
Bài viết này hơi lạc lõng vì đúng ra mình nên viết theo flow là đi vào SDLC, sau đó là Agile, rồi mới đến Error, Bugs, Failure khi đi vào Testing.
Nhưng mà mình thấy nếu viết theo flow đó thì sẽ không hợp lý, vì mình cần phải nói về Error, Bugs, Failure ngay từ đầu, để mọi người hiểu được lý do tại sao hoạt động kiểm thử quan trọng đến thế, hiểm hoạ mà nó mang lại nếu không thực hiện, rủi ro thất bại (Risk of Failure) ra làm sao.
Khái niệm
Errors - hay còn hiểu là sai sót, Bugs/Defects - lỗi và Failure - thất bại liên quan trực tiếp đến nhau.
| Sai sót sẽ dấn đến lỗi trong sản phẩm phần mềm và lỗi nếu không được phát hiện sẽ mang đến một rủi ro thất bại khi nó tiến vào môi trường vận hành. Nếu rủi ro đó là thật và thực sự xảy ra thì cái kết chính là thất bại của sản phẩm phần mềm và nó sẽ đem lại rất nhiều thiệt hại về kinh tế, tệ hơn là thiệt hại về người và kiện cáo. | Errors will lead to Bugs/Defects in the software product and if the defects are not detected, it will bring a risk of failure when it propagate into production environment. If that risk is real and actually happens, the result is the failure of the software product and it will cause economic loses, worse is safety issue and lawsuits |
Typical question: How are errors, bugs/defects and failure are related? - Sai sót, lỗi và thất bại của sản phẩm phần mềm liên hệ với nhau như thế nào?
Errors
Errors - sai sót là sản phẩm của con người. Đúng theo cái tên của nó, nó là những sai sót do những cá nhân tham gia vào quá trình phát triển sản phẩm phần mềm gây ra.
Nói thì hơi mang tính triết học một chút, nhưng một sai sót không có hình thù, nó không hiện hữu ở thế giới vật chất, thay vào đấy là tồn tại ở dạng ý tưởng mang tính trừu tượng.
Ví dụ 1:
Mày viết lỗi cái doc hả em ? Vâng, em paste cái template vào nhưng quên không sửa
Quên cái gì đó - đây là một sai sót của người viết các tài liệu liên quan đến sản phẩm phần mềm, rồi khi mọi người đọc tài liệu, hoặc sẽ chẳng hiểu cái gì được viết trong đấy, hoặc hiểu sai hoàn toàn.
Ví dụ 2:
Mày chưa handle exception cái hàm này à em ? Bỏ mẹ, có vụ đấy nữa nhỉ
Không nhìn ra edge case hay exception - đây là một sai sót của dev khi viết code, đoạn code này khi được chạy sẽ gây ra lỗi, có thể Errors thrown, hay đơn giản là nó hoạt động không như đã được ấn định.
Ví dụ 3:
Mày hình như viết thiếu test case à ? Toang, thế là em áp dụng chưa đúng technique rồi
Không áp dụng đúng kỹ thuật viết test case - đây là một sai sót của tester khi viết test case kiểm thử phần mềm, khi test case đã bị viết sai và chạy, nó sẽ không bắt được lỗi, giảm tính bao quát của bộ test case.
Typical question: What is an error? - Sai sót là gì?
Nguyên nhân dẫn đến sai sót của một con người thì nhiều vô kể, nào thì mệt mỏi, nào thì áp lực thời gian, phải nhanh về đi đón con, tự nhiên cô giáo gọi báo con trượt chân ngã đập mặt vào cạnh bàn, v.v…
Và để giảm khả năng xảy ra sai sót, cũng như khắc phục kịp thời sai sót trước khi nó dẫn đến bug thì cần áp dụng các công đoạn kiểm tra chéo sản phẩm làm việc giữa các thành viên trong team, ví dụ như doc sẽ được review lại bởi lead, code sẽ cần qua unit test và code review, test case sẽ đi qua peer review, v.v…
Một điều quan trọng nữa là, với một người làm IT, phong độ được phản ánh bởi chính việc có thường xuyên gây ra sai sót hay không. Anh sai sót nhiều thì anh phong độ kém, láo nháo là bên trên cho anh ra khỏi dự án. Nên hãy ăn đủ, ngủ đủ, làm việc điều độ.
Typical question: How to reduce the chance of error? - Làm cách nào để giảm khả năng sai sót?
Bugs/Defects
Như đã nêu ở trên, bug/defect là kết quả của một sai sót, sai sót là hành động và sai sót phải tạo ra cái gì đó, và cái gì đó chính là lỗi ở trong sản phẩm làm việc.
Bugs/Defects có thể được hiểu thông qua 2 ý tưởng sau:
- Nó là lỗi hiện hữu trong các sản phẩm công việc trong quá trình phát triển phần mềm, ví dụ như typo, code chạy toàn lỗi, test case không chạy được, v.v…
- Nó là sự hiện hình của sai sót ở dạng vật lý, hiện hữu ở thế giới thật với một hình thù nào đó mà chúng ta có thể nhìn vào, tự đưa ra đánh giá rằng đối tượng đó không nên như thế, hay suy ngược ra rằng đã có sai sót nào đó xảy ra dẫn đến sự hình thành của đối tượng.
Ví dụ 1:
Mày viết lỗi cái doc hả em ? Vâng, em paste cái template vào nhưng quên không sửa
Quên cái gì đó - đây là một sai sót của người viết các tài liệu như đã nêu ở phần Errors, vậy thì lỗi ở đây chính là một document viết sai, đọc khó hiểu, không hiểu hoặc gây hiểu lầm
Ví dụ 2:
Mày chưa handle exception cái hàm này à em ? Bỏ mẹ, có vụ đấy nữa nhỉ
Không nhìn ra edge case hay exception - đây là một sai sót của dev khi viết code, lỗi ở đây chính là một function hay method chạy bị lỗi cho một số đầu vào nhất định
Ví dụ 3:
Mày hình như viết thiếu test case à ? Toang, thế là em áp dụng chưa đúng technique rồi
Không áp dụng đúng kỹ thuật viết test case - đây là một sai sót của tester, vậy lỗi ở đây là một test case không có giá trị do không hoạt động đúng, không bắt được bug, thiếu tính bao quát (coverage)
Typical question: Lỗi trong sản phẩm phần mềm là gì? - What is a bug or defect in software product?
Nhiều người trong ngành sẽ nói Bugs và Defects là hai từ có thể dùng qua lại cho nhau, đúng. Nhưng mình nghĩ mọi người nên có cách hiểu rạch ròi, dù rằng nó được quy về làm một vì nó cũng chẳng quá quan trọng.
Bug là lỗi trong sản phẩm phần mềm, ở các phần code và chính sản phẩm đó.
Defect là lỗi ở trong các tài liệu liên quan như tài liệu yêu cầu, tài liệu thiết kế, v.v…
Lý do chúng ta dùng chung hai khái niệm này là vì, dù sao thì nơi xuất hiện lỗi cũng sẽ được đề cập, lỗi trong tài liệu, lỗi trong code, v.v… vậy nên việc dùng riêng bug và defect là không thật sự cần thiết.
Failure
Failure có thể được hiểu nôm na là thất bại của sản phẩm phần mềm khi đang vận hành (production environment). Bắt nguồn từ việc một hay nhiều bug nghiêm trọng vượt qua giai đoạn kiểm thử, không được phát hiện, không được sửa, chúng tiến vào môi trường vận hành và tuỳ thuộc vào mức độ nghiêm trọng, nó có thể làm hỏng các tính năng quan trọng của sản phẩm, hoặc phá huỷ toàn bộ sản phẩm.
Typical question: What is failure of a software product? Where can it occur? - Thất bại của sản phẩm phần mềm là gì? Nó có thể xảy ra ở đâu?
Nói qua một chút về tính nghiêm trọng của bug - Bug severity. Thông thường, sẽ có 4 mức độ nghiêm trọng của bug:
- Critical/Nghiêm trọng: Bug sẽ khiến sản phẩm phần mềm crash, lỗi hoàn toàn, thoát ra ngoài, mất dữ liệu, không có khả năng vượt qua
- Major-High/Cao: Bug sẽ làm hỏng một hoặc nhiều tính năng chính hoặc quan trọng của sản phẩm phần mềm, khiến flow sử dụng bị dừng, tuy phần mềm không crash nhưng người dùng không thể tiến xa hơn, không có cách vượt qua
- Medium: Bug sẽ làm hỏng một hoặc nhiều tính năng nhỏ hoặc phụ của sản phẩm phần mềm, các tính năng chính không bị ảnh hưởng, flow sử dụng vẫn đi qua, nhưng những tính năng bổ trợ bị ảnh hưởng không thể vận hành, gây ảnh hưởng đến khả năng sử dụng phần mềm
- Low-Cosmetic/Thấp: Bug không gây ảnh hưởng lên bất kỳ tính năng nào, thường là các bug về UI/UX, gây ảnh hưởng đến trải nghiệm của người dùng, hình ảnh của khách hàng,v.v…
Khi một thất bại xảy ra, rõ ràng là sản phẩm phần mềm đã được đưa vào vận hành, nó sẽ ngay lập tức gây ra thiệt hại. Thiệt hại kinh tế là cái luôn luôn xuất hiện, ví dụ một ứng dụng ngân hàng mà lăn ra hẹo thì chắc chắn ngân hàng ăn đủ. Hay một phần mềm điều khiển thiết bị y tế mà hỏng thì chắc chắn sẽ có người gặp rủi ro về sức khoẻ.
Một số failure kinh điển trong lịch sử phần mềm
| Tên sự cố | Mô tả |
|---|---|
| Therac-25 | Therac-25 là một máy xạ trị ung thư được sản xuất bởi AECL (Atomic Energy of Canada Limited) vào những năm 1980. Máy Therac-25 sử dụng electron để xạ trị ung thư, và nó có thể hoạt động ở 2 chế độ: chế độ điều trị nhanh và chế độ điều trị chậm. Trong quá trình vận hành đã xảy ra lỗi đồng bộ trong phần mềm điều khiển máy xạ trị Therac-25, khiến bệnh nhân nhận liều lượng bức xạ quá mức. Ít nhất 6 bệnh nhân tử vong và nhiều người khác bị thương nặng. |
| Lỗi Y2K (năm 2000) | Nhiều hệ thống máy tính cũ chỉ lưu trữ hai chữ số cuối của năm, dẫn đến lo ngại rằng chúng sẽ gặp sự cố khi chuyển sang năm 2000. May mắn thay, nhờ nỗ lực khắc phục trên toàn cầu, hậu quả của lỗi Y2K không nghiêm trọng như dự đoán. |
| Lỗi phần mềm tên lửa Patriot (1991) | Lỗi làm tròn số trong hệ thống tính toán thời gian, khiến hệ thống không thể theo dõi chính xác mục tiêu. Một tên lửa Scud của Iraq đã vượt qua hệ thống phòng thủ Patriot và tấn công một doanh trại quân đội Mỹ, khiến 28 người thiệt mạng và 100 người bị thương. |
| Lỗi giao dịch của Knight Capital Group năm 2012 | Vào ngày 1 tháng 8 năm 2012, Knight Capital Group, một trong những công ty giao dịch tần suất cao lớn nhất tại Mỹ, đã gặp sự cố phần mềm khiến hệ thống tự động gửi hàng loạt lệnh mua bán bất thường trên thị trường. Lỗi này xuất phát từ việc cập nhật phần mềm không đúng cách, khiến hệ thống kích hoạt một thuật toán giao dịch cũ đã bị vô hiệu hóa. Knight Capital Group thiệt hại 440 triệu USD chỉ trong vòng 45 phút và suýt bị phá sản. Sự cố này là một lời cảnh tỉnh về rủi ro của việc sử dụng thuật toán giao dịch tự động và tầm quan trọng của việc kiểm thử phần mềm kỹ lưỡng. |