Cập nhật vào August 28, 2019
Kiểm thử đã được chấp nhận rộng rãi như một phần của phát triển phần mềm kể từ khi phần mềm được phát triển. Tuy nhiên, Business Intelligence (BI) đã chậm hơn trong việc áp dụng thử nghiệm như một phần tích hợp của quá trình phát triển trong phần mềm BI như IBM Cognos. Hãy cùng khám phá lý do tại sao BI chậm hơn trong việc áp dụng các phương pháp thử nghiệm và hậu quả của KHÔNG thử nghiệm.
Tại sao các tổ chức không kiểm tra BI…
- Hạn chế thời gian. Các dự án BI luôn chịu áp lực phải được chuyển giao nhanh hơn. Điều mà một số tổ chức có thể không nhận ra là giai đoạn dễ dàng nhất để giảm thời gian là thử nghiệm.
- Ràng buộc ngân sách. Suy nghĩ là thử nghiệm quá tốn kém và không thể dành riêng một nhóm thử nghiệm.
- Nhanh hơn là tốt hơn. Đây không nhất thiết là một cách tiếp cận “nhanh nhẹn” và chỉ có thể đưa bạn đến sai nơi nhanh hơn.
- Tâm lý “chỉ làm đúng ngay lần đầu tiên”. Cách tiếp cận ngây thơ này khẳng định rằng sự hiện diện của kiểm soát chất lượng sẽ làm giảm nhu cầu thử nghiệm.
- Thiếu quyền sở hữu. Điều này tương tự với gạch đầu dòng trước đó. Suy nghĩ là "người dùng của chúng tôi sẽ kiểm tra nó." Cách tiếp cận này có thể dẫn đến người dùng không hài lòng và rất nhiều vé hỗ trợ.
- Thiếu công cụ. Quan niệm sai lầm rằng họ không có công nghệ phù hợp để kiểm tra.
- Thiếu hiểu biết về thử nghiệm. Ví dụ,
- Việc kiểm tra phải đánh giá tính chính xác và hợp lệ của dữ liệu, tính nhất quán của dữ liệu, tính kịp thời của dữ liệu, hiệu suất phân phối và tính dễ sử dụng của cơ chế phân phối.
- Thử nghiệm trong một dự án BI có thể bao gồm thử nghiệm hồi quy, thử nghiệm đơn vị, thử nghiệm khói, thử nghiệm tích hợp, thử nghiệm chấp nhận của người dùng, thử nghiệm đặc biệt, thử nghiệm căng thẳng / khả năng mở rộng, thử nghiệm hiệu suất hệ thống.
Chi phí của việc KHÔNG Kiểm tra BI là gì?
- Thiết kế không hiệu quả. Kiến trúc kém có thể không được phát hiện nếu bỏ qua thử nghiệm. Các vấn đề thiết kế có thể góp phần vào khả năng sử dụng, hiệu suất, tái sử dụng cũng như bảo trì và bảo dưỡng.
- Các vấn đề về tính toàn vẹn của dữ liệu. Dữ liệu bị hỏng hoặc những thách thức về dòng dữ liệu có thể dẫn đến sự thiếu tin tưởng vào các con số.
- Vấn đề xác thực dữ liệu. Các quyết định được đưa ra dựa trên dữ liệu xấu có thể tàn phá doanh nghiệp. Không có gì tệ hơn việc cố gắng quản lý bằng các chỉ số dựa trên thông tin không chính xác.
- Giảm sự chấp nhận của người dùng. Nếu các con số không đúng hoặc nếu ứng dụng không thân thiện với người dùng, cộng đồng người dùng của bạn sẽ không sử dụng phần mềm BI doanh nghiệp mới sáng bóng của bạn.
- Tăng chi phí do thiếu tiêu chuẩn hóa.
- Tăng chi phí để sửa chữa các khiếm khuyết trong các giai đoạn sau của vòng đời phát triển BI. Bất kỳ vấn đề nào được phát hiện ngoài giai đoạn yêu cầu sẽ có giá cao hơn theo cấp số nhân so với nếu được phát hiện sớm hơn.
Bây giờ chúng ta đã tìm ra lý do tại sao các tổ chức có thể không kiểm tra và những cạm bẫy xảy ra khi bạn không kiểm tra BI, hãy cùng xem một số nghiên cứu về kiểm thử trong phát triển phần mềm.
Các nghiên cứu cho thấy Thử nghiệm Nền tảng BI của bạn Tiết kiệm tiền!
Một nghiên cứu về 139 công ty Bắc Mỹ có quy mô từ 250 đến 10,000 nhân viên, được báo cáo chi phí gỡ lỗi hàng năm từ 5.2 triệu đô la đến 22 triệu đô la. Phạm vi chi phí này phản ánh các tổ chức không có thử nghiệm đơn vị tự động tại chỗ. Riêng biệt, nghiên cứu của IBM và Microsoft đã phát hiện ra rằng với kiểm tra đơn vị tự động tại chỗ, số lượng lỗi có thể giảm từ 62% đến 91%. Điều này có nghĩa là số đô la chi tiêu cho việc gỡ lỗi có thể giảm từ phạm vi 5 triệu đô la - 22 triệu đô la xuống phạm vi 0.5 triệu đô la đến 8.4 triệu đô la. Đó là một khoản tiết kiệm rất lớn!
Chi phí để sửa lỗi nhanh chóng leo thang.
Một bài báo về các chiến thuật phát triển phần mềm thành công chứng tỏ rằng hầu hết các lỗi được tạo ra sớm trong chu kỳ phát triển và bạn càng đợi lâu để phát hiện và sửa thì chi phí sửa chữa càng cao. Vì vậy, không cần một nhà khoa học tên lửa nào đưa ra kết luận hiển nhiên rằng các lỗi được phát hiện và sửa chữa càng sớm thì càng tốt. Nói về khoa học tên lửa, NASA đã xuất bản một bài báo về vấn đề đó - “Lỗi tính toán chi phí thông qua vòng đời của dự án.”
Trực quan rằng chi phí để sửa lỗi tăng lên khi vòng đời phát triển tiến triển. Nghiên cứu của NASA được thực hiện để xác định chi phí tương đối của việc sửa chữa các lỗi được phát hiện tiến triển nhanh như thế nào. Nghiên cứu này sử dụng ba cách tiếp cận để xác định chi phí tương đối: phương pháp chi phí từ dưới lên, phương pháp phân tích tổng chi phí và phương pháp dự án giả định từ trên xuống. Các phương pháp tiếp cận và kết quả được mô tả trong bài báo này giả định sự phát triển của một hệ thống phần cứng / phần mềm có các đặc điểm của dự án tương tự như các phương pháp được sử dụng trong quá trình phát triển một tàu vũ trụ lớn, phức tạp, một máy bay quân sự hoặc một vệ tinh thông tin liên lạc nhỏ. Kết quả cho thấy mức độ leo thang của chi phí, khi các lỗi được phát hiện và sửa chữa ở các giai đoạn sau và giai đoạn sau của vòng đời dự án. Nghiên cứu này là đại diện cho các nghiên cứu khác đã được thực hiện.
Từ biểu đồ trên, nghiên cứu từ TRW, IBM, GTE, Bell Labs, TDC và những người khác cho thấy chi phí sửa lỗi trong các giai đoạn phát triển khác nhau:
- Chi phí sửa lỗi được phát hiện trong giai đoạn yêu cầu được định nghĩa là 1 đơn vị
- Chi phí để sửa lỗi đó nếu được tìm thấy trong giai đoạn thiết kế là tăng gấp đôi việc này
- Ở giai đoạn mã và gỡ lỗi, chi phí để sửa lỗi là đơn vị 3
- Ở giai đoạn thử nghiệm đơn vị và tích hợp, chi phí để sửa lỗi trở thành 5
- Ở giai đoạn thử nghiệm hệ thống, chi phí để sửa lỗi tăng lên 20
- Và khi hệ thống đang trong giai đoạn hoạt động, chi phí tương đối để sửa lỗi đã tăng lên 98, gần 100 lần chi phí sửa lỗi nếu được tìm thấy trong giai đoạn yêu cầu!
Điểm mấu chốt là việc sửa chữa các khiếm khuyết sẽ tốn kém hơn nhiều nếu chúng không được phát hiện sớm.
Kết luận
Nghiên cứu quan trọng đã được thực hiện để chứng minh giá trị của việc kiểm thử sớm và liên tục trong phát triển phần mềm. Chúng tôi, trong cộng đồng BI, có thể học hỏi từ bạn bè của chúng tôi trong việc phát triển phần mềm. Mặc dù hầu hết các nghiên cứu chính thức đã được thực hiện liên quan đến phát triển phần mềm, các kết luận tương tự có thể được rút ra về phát triển BI. Giá trị của thử nghiệm là không thể chối cãi, nhưng nhiều tổ chức đã chậm hơn trong việc tận dụng thử nghiệm chính thức môi trường BI của họ và tích hợp thử nghiệm vào các quy trình phát triển BI của họ. Chi phí của không thử nghiệm là có thật. Những rủi ro liên quan đến không thử nghiệm là có thật.
Bạn muốn xem một số thử nghiệm Cognos tự động đang hoạt động? Xem các video trên danh sách phát của chúng tôi bằng nhấn vào đây!
