Technical Debt là gì

Technical Debt (nợ kĩ thuật) là các issue/defect vẫn còn trong code khi một ứng dụng được phát hành. Nói một cách đơn giản - đó là sự khác biệt (về lỗi) giữa những gì được mong đợi và những gì được bàn giao Ward Cunningham - cha đẻ của wiki đã nghĩ ra ý tưởng "Technical debt" đầu tiên từ những năm 90, tương đồng với tác động của nợ xấu đối với ngành tài chính Ta hiểu như sau: Khi đội dev đang bận rộn phát triển dự án và sửa lỗi thì nhiều lỗi mới xuất hiện. Trong số này, một số được fix và một số khác phải để đến bản release sau. Technical bebt ban đầu rất ít, nhưng theo quá trình code thì càng ngày nó càng nhiều lên, trở thành nợ nần chồng chất. Nợ đến một lúc nào đó mà ta không trả nổi thì sẽ dẫn đến "phá sản". Đây là hậu quả tồi tệ nhất của nợ kỹ thuật nếu nó không được giải quyết kịp thời.

Tại sao QA team chịu ảnh hưởng nhiều nhất do technical debt(nợ kĩ thuật)

Trong một chu kỳ thiết kế và phát triển phần mềm điển hình, có một số điều có thể dẫn đến nợ kỹ thuật như :

• Do khách hàng thay đổi requirement liên tục, kiến trúc dự án không kịp thay đổi cho phù hợp
• Do kiểm tra và sửa lỗi không đầy đủ, thiếu sự phối hợp giữa các đội, mã kế thừa và quá trình tái cấu trúc chậm
• Và các yếu tố khác: dev thiếu nền tảng kĩ thuật, ...

Ví dụ: tái sử dụng code đã viết, dev copy và paste code sửa đôi chút (thay vì phải tách thành module riêng). Cách này nhanh, nhưng nếu có bug sẽ tạo ra cực nhiều nợ kĩ thuật

Tuy nhiên, không nơi nào là những thách thức do nợ kỹ thuật rõ ràng hơn trong kiểm thử chất lượng, nơi các đội kiểm thử phải đáp ứng các thời hạn không mong muốn và mọi thứ có thể bị bỏ đi

Testers/QA thường rơi vào tình trạng lúng túng khi bất ngờ, người quản lý bàn giao đến và nói với họ: " Chúng tôi phải tung ra sản phẩm trong một thời gian, xin lỗi vì không thể liên lạc kịp thời. Hãy kết thúc tất cả các nhiệm vụ kiểm thử để sẵn sàng với bản demo. "

Về cơ bản, bất kỳ vấn đề nào mà "giải quyết nó sau" thì đều dẫn đến những khoản nợ ngất ngưởng. Thiếu kiểm thử, các user story không rõ ràng, sprint ngắn, và các ví dụ khác về áp lực bàn giao đóng một vai trò rất lớn đằng sau sự tích tụ của nợ kỹ thuật cho QA.

Ví dụ về thế giới thực Một nhà bán lẻ trực tuyến có trụ sở tại Mỹ có hiện diện trên nhiều trang web và ứng dụng trên điện thoại di động đã gặp phải thách thức về nợ kĩ thuật thực tế khi sự phức tạp của lưới kiểm thử bắt đầu kết hợp với mỗi lần chạy nước rút mới.

Điều này xảy ra do sự bùng nổ đột ngột về số lượng thiết bị di động được thử nghiệm, nhiều ngôn ngữ được hỗ trợ và hơn nửa tá mạng xã hội được sử dụng.

Thách thức nợ kĩ thuật sẽ xuất hiện theo các cách sau:

• Tiêu thụ thời gian quá nhiều trong thử nghiệm bản phát hành - Với số lượng trình duyệt, thiết bị tăng lên cùng với mỗi lần chạy thử, chu kỳ phát hành sẽ tiếp tục bị chậm trễ dẫn đến mất thời gian để tiếp thị.
• Chi phí tuyển dụng ngày càng tăng - Số lượng người kiểm thử cần thiết để hỗ trợ dự án gần gấp đôi đã được dịch sang chi phí thêm 500.000 đô la
• Tính phức tạp trong dự án - Với sự phức tạp ngày càng tăng của dự án, việc theo dõi các trường hợp thử nghiệm và lỗi đã trở thành một thách thức
• Quá nhiều thời gian lãng phí trong việc theo đuổi các kết quả sai - Một lần nữa, một sự thất bại của sự phức tạp ngày càng tăng của dự án.

QA nên quản lí technical debt như thế nào?

Hầu hết các nhà quản lý bảo đảm chất lượng xem nợ kĩ thuật là lí do cho việc chạy một mình trong sprint hiện tại. Điều này dẫn đến việc chỉ kiểm thử bằng phương pháp thủ công và hoàn toàn bỏ qua kiểm thử tự động

Các nguyên tắc Agile chỉ ra rằng chúng ta cần hình dung vấn đề nợ kĩ thuật là không có khả năng duy trì và đáp ứng các tiêu chí đánh giá chất lượng.

Một cách tiếp cận chủ động sẽ xác định defect sau mỗi lần fix lỗi của dev bằng cách test lại toàn bộ các chức năng của hệt hông. Chúng ta có thể làm tất cả bằng tay nhưng với hàng nghìn kịch bản thử nghiệm cho một dự án trung bình thì kiểm thử tự động là điều cần thiết.

Rõ ràng, kiểm thử hiệu quả có thể giúp chúng ta đạt được chiến thằng trong cuộc chiến tranh về nợ kĩ thuật. Vì vậy, nó có ý nghĩa gì? Nó có nghĩa là hệ thống của chúng ta được trang bị tốt như thế nào để xác định các defect trong ứng dụng tổng thể.

Như phương trình trên cho thấy, hiệu quả của test case thậm chí có thể đạt tới 100% nếu số lượng khách hàng tìm thấy lỗi (sau lỗi sản xuất) đã được ánh xạ chính xác đến số lỗi tìm thấy ở mỗi giai đoạn thử nghiệm.

Kiểm thử tự động giúp chúng ta giảm thiểu số lượng kịch bản được thực hiện bằng cách báo cáo kết quả và so sánh chúng với các lần thử nghiệm trước đó

Trước đây, các tổ chức và các đội phát triển phần mềm thường nghĩ hoạt động QA là hoạt động hỗ trợ cho các sản phẩm, khống có cũng không sao. Trên thực tế, cách tiếp cận không đúng đối với kiểm định chất lượng / thử nghiệm là chính xác những gì đã dẫn đến thách thức liên tục về nợ kỹ thuật ngay từ đầu.

Như vậy kiểm thử tự động là một trong các cách tốt nhất cho QA để giảm tải nợ kĩ thuật.

Tham khảo: http://www.softwaretestinghelp.com/technical-debt-and-qa/#more-8852