Khách hàng có cần tham gia kiểm thử không?
Câu trả lời là: Có. Dự án càng lớn, khách hàng càng phải tham gia càng sớm càng tốt. Có thể là một người hoặc cả một team, một nhóm end-users (những người sẽ tham gia vận hành sau này) tham gia vào công tác kiểm tra chất lượng, trong phần mềm gọi là Bug Tracking và Quality Assurance (QA), Quality Control (QC). Tuy nhiên khách hàng không phải là các Tester chuyên nghiệp với những kỹ năng và công cụ để có thể "vặt lá tìm sâu" hoặc để tìm ra một vấn đề thực sự. Do đó họ không thể tham gia như một QA. Họ hoàn toàn có thể tham gia tìm lỗi ở bề mặt của chương trình, giống như một người đi kiểm tra bề ngoài một tòa nhà mới xây xem có vết nứt gì không, hệ thống đi ống có hợp lý hay không...
Vây Bug Tracking là gì? Làm thế nào để hiểu được vòng đời của một lỗi (bug - hay còn gọi là bọ phần mềm)? Làm thế nào để hiểu được một Bug Report của Tester để có thể nhận định tổng thể về chất lượng dự án và khả năng đáp ứng tiến độ dự án?
Thuật ngữ:
- Bug: Lỗi do viết code gây ra. Cần phân biệt bug với defect là lỗi do khách quan, hoặc lỗi từ một bên thứ ba (thí dụ yêu cầu đầu vào không đầy đủ, mơ hồ, mập mờ, mâu thuẫn...)
- Debug: Là quá trình khống chế lỗi, hay nói vui là đè lỗi ra để khai quật và tìm kiếm nguyên nhân. Một số giải pháp Debug như: Chia vùng để thử nhanh (còn gọi là trial and error), thả dữ liệu giả (mock data) vào code đang chạy để kiểm tra tình trạng...
- Dev Team: Là nhóm kỹ thuật chịu trách nhiệm viết code và fix bug (sửa lỗi)
- Release: Là mốc để bàn giao (hoặc một phần) sản phẩm.
- Validate data: Một thuật ngữ quen thuộc đối với Dev Team khi nói về việc dữ liệu không được kiểm tra trước khi gửi đi, dẫn đến lỗi xảy ra mà không thể biết nguyên nhân.
- Regession bug, còn gọi là bug hồi quy (tương tự triệu chứng di căn) là một dạng lỗi âm thầm di chuyển vào nhiều ngóc ngách mặc dù các tính năng bên ngoài vẫn chạy bình thường, tuy nhiên hệ thống dường như chạy chậm, hoặc sử dụng CPU nhiều hơn trước.
Bug là gì?
Bug là những lỗi phần mềm trong chương trình hoặc hệ thống máy tính làm cho kết quả không chính xác hoặc không hoạt động như mong muốn. (Theo wikipedia)
Debug là quá trình tìm kiếm và phát hiện lỗi trong phần mềm trước khi launching, đưa sản phẩm đến tay người dùng. Debug diễn ra ngay sau khi những dòng code đầu tiên được viết và tiếp tục được thực hiện cho đến khi kết hợp với những unit khác của lập trình tạo thành một sản phầm phần mềm hoàn chỉnh.
Fixbug (sửa lỗi) là quá trình triển khai ngay sau debug, nhằm duy trì hoặc nâng cao chất lượng sản phẩm.
Quy trình quản lý vòng đời ticket (bug, issue, task...) trong hệ thống quản lý dự án RedMine
Tại sao lại xảy ra bug trong quá trình phát triển phần mềm?
Có rất nhiều lý do gây ra lỗi (bug). Lý do phổ biến nhất là do con người tạo nên – trong quá trình design và coding. Sản phẩm càng có yêu cầu phức tạp thì khả năng tồn tại nhiều bug càng cao. Và không thể tự tin để nói rằng sản phẩm của mình là Bug Free.Vậy câu hỏi đặt ra là: Những yếu tố nào dẫn đến bug trong sản phẩm?
1. Yếu tố con người
Con người góp phần tạo nên sản phẩm, mà đã là con người thì không thể hoàn hảo. Con người sẽ tạo ra sai lầm và không thể khẳng định chắc chắn rằng sản phẩm phần mềm mình làm ra không có bất kì lỗi nào. Và rằng chúng ta chưa tìm ra bất kì công cụ – trí tuệ nhân tạo nào có thể tạo nên sản phẩm phần mềm tốt hơn con người. Đó là lý do vì sao bug xuất hiện.
2. Thất bại trong việc trao đổi thông tin
Một lý do thường gặp khác là về việc thất bại trong quá trình trao đổi thông tin: hiểu sai, thiếu giao tiếp,… Sự thất bại này có thể xảy ra tại nhiều phases trong quá trình phát triển phần mềm: Thu thập yêu cầu, tổng hợp – giải thích yêu cầu, hiểu yêu cầu để thực hiện implement,… Nếu trong trường hợp yêu cầu mơ hồ, không rõ ràng, developer sẽ implement mà không thật sự hiểu rõ yêu cầu, vì vậy dẫn đến bug. Và một trường hợp khác, khi một developer cố gắng sửa một đoạn code của một người khác và thiếu đi sự trao đổi giữa hai bên.
3. Khung thời gian phát triển không thực tế
Sản phẩm thường được phát triển theo lịch trình gấp gáp, dồn dập, với nguồn lực hạn chế. Vì vậy, để đáp ứng kịp thời hạn release, đôi khi sẽ không có đủ thời gian để thiết kế, code và kiểm thử một cách cẩn thận. Một sự thay đổi yêu cầu nhỏ vào thời gian cuối sẽ dẫn đến sự thay đổi của code và có khả năng gây ra bug.
4. Logic design kém
Trong thời đại phát triển phức tạp của hệ thống phần mềm, đôi khi phần mềm phức tạp đến mức nó đòi hỏi rất nhiều sự nghiên cứu, phát triển và động não (brainstorm) để đạt được một giải pháp đáng tin cậy. Sự thiếu kiên nhẫn và mong muốn hoàn thành nó càng nhanh càng tốt có thể dẫn đến sai sót. Áp dụng sai công nghệ (linh kiện, sản phẩm, kỹ thuật), mong muốn hoặc khao khát sử dụng cách dễ nhất để thực hiện giải pháp, thiếu hiểu biết đúng đắn về tính khả thi của kỹ thuật trước khi thiết kế kiến trúc đều có thể gây ra lỗi. Thật không may, không phải là do chúng ta không thông minh; chỉ là chúng ta thường không có thời gian, chúng ta không có đủ kinh nghiệm thực tế...
5. Thực hiện code kém hiệu quả
Bug thường xuất hiện bởi code yếu kém. Code yếu kém thể hiện qua việc quên tạo lớp an toàn cho lỗi (try catch exception) hoặc xử lý không hiệu quả, thiếu validate dữ liệu (kiểu dữ liệu, phạm vi, điều kiện biên,…). Thêm vào đó, developers có thể phải làm việc với những tools, compilers, debuggers,…kém hiệu quả.
6. Thiếu sự kiểm soát các build version
Nếu một function đã được test ở bản build trước và sau một vài lần build, bug hồi quy (tương tự triệu chứng di căn) xảy ra thì rất khó để có thể phát hiện ra chúng. Vì vậy việc kiểm soát các bản build là rất quan trọng
7. Thiếu sót về kĩ năng kiểm thử
Ở một vài công ty, quy trình kiểm thử thường bị xem nhẹ hoặc không xảy ra. Thêm vào đó, tester thiếu hiểu biết và kinh nghiệm về kiểm thử sẽ dẫn đến việc bỏ sót bug trong sản phẩm. Ngoài ra, nếu tester không cẩn thận, không chú ý trong quá trình thực hiện test, kết quả sẽ là sản phẩm với chất lượng yếu kém và tồn tại nhiều bug nghiêm trọng.
8. Tự tin thái quá
Một số người thường thích nói những câu như “ Quá đơn giản”, “Dễ như ăn bánh”, “ Xong ngay trong một nốt nhạc”. Những sự quá tự tin như thế này thường dẫn đến việc bỏ lỡ những điểm quan trọng.
9. Sử dụng tool của bên thứ ba
Trong quá trình phát triển phần mềm, chúng ta thường sử dụng ít nhất một tool của bên thứ ba, và chính trong các tool này có thể chứa lỗi. Các tool này có thể là công cụ hố trợ lập trình (class libraries, shared DLLs, compilers, HTML editors, debuggers etc.) Nhưng lỗi trong tool này sẽ dẫn đến lỗi trong phần mềm đang được phát triển.
10.Thay đổi trong phút chót
Những thay đổi có thể xảy ra với requirement, cơ sở hạ tầng, tools, platform có thể rất nguy hiểm, nhất là khi sản phẩm chuẩn bị được release. Những thao tác như thay đổi cấu trúc cơ sở dữ liệu, làm cho sản phẩm có thể tương thích với nhiều hệ điều hành/trình duyệt khá phức tạp và nếu được làm trong thời gian ngắn sẽ dẫn đến việc xảy ra bug.
Vậy khi nào một bug không phải là bug?
Một bug có thể đúng với 1 hoặc nhiều hơn trong 4 quy tắc trên. Vậy ngược lại khi nó không đúng với bất kỳ nguyên tắc nào trên đó nhưng vẫn chưa xác định được chính xác và rõ ràng là bug hay không? Hãy cùng thử trả lời mỗi câu hỏi dưới đây cho mỗi vấn đề đang gặp, có thể bạn sẽ biết được có nên đưa nó vào danh sách bugs không hay là feedback nó:
- Nó có khó hiểu, khó sử dụng hay cản trở khả năng của người dùng sử dụng ứng dụng không?
- Bạn có thể làm nó xảy ra từ hai lần trở lên không?
- Nếu chỉ xảy ra 1 lần, nó có tạo ra kết quả tiêu cực đáng kể không?
- Nó có làm mất hứng thú của người dùng sử dụng không?
- Nó có gì trái ngược hay mâu thuẫn không?
- Nó có phải là cách tối ưu nhất không?
- Bạn có mong đợi nó xảy ra theo một cách khác?
Chất lượng của Bug Report tốt được kiểm tra như thế nào?
Viết tóm tắt lỗi rõ ràng
Tóm tắt lỗi rõ ràng sẽ giúp dev dễ dàng phân tích lỗi. Một báo cáo chất lượng kém sẽ làm tăng thời gian phân tích, code và test.
Mô tả cụ thể
Đừng viết một bài văn để mô tả vấn đề: Hãy mô tả một cách cụ thể và cố gắng tóm tắt vấn đề với ít từ nhất có thể nhưng vẫn phải diễn tả rõ vấn đề. Không nên gộp nhiều vấn đề lại với nhau ngay cả khi chúng có vẻ tương tự nhau. Với mỗi vấn đề phải có report riêng cho từng vấn đề đó.
Chỉ rõ bug có thể tái hiện được hay không
Nếu bug không thể tái hiện, nó sẽ không bao giờ được fix. Tester nên mô tả các bước tái hiện rõ ràng và chi tiết. Đừng giả sử hoặc skip qua bất kỳ bước tái hiện nào. Một bug khi mà được mô tả rõ ràng từng bước (step by step) sẽ dễ dàng tái hiện và fix bug.
Làm thế nào để report một bug?
Dưới đây là một format report bug đơn giản. Nó có thể khác nhau tùy thuộc vào công cụ mà tester đang sử dụng. Nếu đang report bug theo cách thủ công thì cần lưu ý thông tin của một số trường sau:
- Reporter - Người báo cáo: Tên tester và email.
- Product - Tên sản phẩm: Tên sản phẩm mà tester tìm ra bug.
- Version - Phiên bản: Phiên bản của sản phẩm (Nếu có).
- Component - Thành phần: Là module phụ hay chính của sản phẩm.
- Platform - Nền tảng: Các nền tảng phần cứng mà tester tìm ra lỗi. Ví dụ: PC, MAC,...
- Operating system - Hệ điều hành: Tên các hệ điều hành mà tester tìm ra lỗi. Ví dụ: Windows, Linux, Unix, SunOS, Mac OS...Trong trường hợp bug chỉ xảy ra ở phiên bản cụ thể, tester nên bổ sung thêm phiên bản của hệ điều hành. Ví dụ: Windows NT, Windows 2000, Windows XP,...
- Priority - Độ ưu tiên: Khi nào bug nên được fix? Độ ưu tiên thường quy định từ P1 đến P5 theo thứ tự tăng dần.
- Severity - Mức độ nghiêm trọng: Mô tả tác động của bug đối với sản phẩm, người dùng. Các loại mức độ nghiêm trọng:
- Blocker, showstopper: Không thể thực hiện test thêm nữa.
- Critical: Ứng dụng bị crash, mất dữ liệu.
- Major: Thiếu chức năng chính.
- Minor: Thiếu chức năng phụ.
- Trivial: Cải thiện giao diện người dùng.
- Enhancement: Yêu cầu tính năng mới hoặc nâng cấp tính năng của chức năng hiện có.
- Status - Trạng thái: Khi tester vừa tạo bug -> trạng thái của bug là “New”. Sau đó sẽ có các trạng thái tương ứng như: Resolved - bug đã được fix; Done - bug đã được tester exe test; Reopen - Sau khi dev fix, test re-test vẫn còn lỗi;....
- Assign To - Giao cho: Nếu tester biết ai sẽ là fix bug thì gắn tên của dev vào bug tương ứng.
- URL - Link: Link URL của trang xảy ra lỗi.
- Summary - Tóm tắt: Một đoạn tóm tắt ngắn, dưới 60 từ dùng để mô tả về bug. Và đảm bảo rằng phần tóm tắt này mô tả đầy đủ về bug và vị trí xảy ra.
- Description - Mô tả: Mô tả chi tiết về bug đang xảy ra. Gồm có:
- Reproduce - Cách tái hiện: Mô tả rõ ràng các bước tái hiện bug. Actual result - Kết quả thực tế: Kết quả thực tế của việc chạy các bước tái hiện bug ở trên.
- Expected result -Kết quả mong muốn: Cách ứng dụng hoạt động đúng khi chạy các bước tái hiện bug ở trên.
Đáp án: B
Đây là một câu hỏi thể hiện sự hiểu biết về chẩn đoán chất lượng dự án căn cứ vào các báo cáo hàng tuần. Dự án đi vào giai đoạn ổn định khi đường cong bug ít dao động, nâng lên nẩy xuống với biên độ giảm dần, và mịn dần khi đi về cuối dự án (release). Quy luật này được gọi tên là Zero Bug Bounce. Một quy luật khác là Bug Convergence - là điểm lao dốc của đường cong bug báo hiệu hệ thống đang chuẩn bị đi vào quỹ đạo ổn định.
