Sự cần thiết của Kiểm thử phần mềm 

Trong bài viết này, chúng ta sẽ tìm hiểu lý do vì sao phần mềm hiện nay lại hay bị lỗi hơn bao giờ hết. Xem xét các bài học thực tiễn về kiểm thử phần mềm trước khi phát hành (kiểm thử beta). Tìm ra cách để tác động lên nền công nghiệp phần mềm.
Trong bài viết này, chúng ta sẽ tìm hiểu lý do vì sao phần mềm hiện nay lại hay bị lỗi hơn bao giờ hết. Xem xét các bài học thực tiễn về kiểm thử phần mềm trước khi phát hành (kiểm thử beta). Tìm ra cách để tác động lên nền công nghiệp phần mềm.
Phần mềm hiện tại không giống như những gì chúng đang được sử dụng. Theo báo cáo của Chủ tịch ủy ban cố vấn CNTT, phần mềm ngày nay thường bị hỏng theo những cách khó lường. Nó hay bị lỗi và không còn đáng tin cậy.
Những thông tin từ này thường không được các cơ quan chức năng công bố. Tuy nhiên, mọi người đều biết về chất lượng ngày càng tệ đi của phần mềm. Các nhật báo cũng thường thông tin về vấn đề này.
Kiểm thử đã từng được sử dụng
Randy Covill, một nhà phân tích cấp cao tại viện nghiên cứu AMR về các ứng dụng và chiến lược về thương mại điện tử, thuộc 1 công ty chuyên phân tích về CNTT tại Boston nói rằng “Tiến trình phát triển phần mềm đã từng là một điều mang tính phức tạp và lâu dài”. Theo Roger Sherman, cựu giám đốc kiểm thử của Microsoft đã giải thích trong báo cáo của ông vào năm 1995 có tựa đề “Hãy mang đến những sản phẩm thích hợp vào đúng thời điểm”, là chất lượng phần mềm được xác định theo ba tiêu chí chính: độ tin cậy, tính năng và quy trình. Nếu các điều kiện của thị trường thay đổi và khiến cho các nhà phát triển hướng trọng tâm không cân đối vào bất cứ chân nào của chiếc kiềng, thì hai chân kia sẽ phải chịu hậu quả. Nếu thứ đầu tiên tung ra thị trường là quy trình hay bộ tính năng thì Sherman cảnh báo rằng tính tin cậy sẽ phải chịu hậu quả. Trong nhiều năm trước, khi thị trường còn ít biến động, các nhà phát triển đã tạo ra những phần mềm đáng tin cậy bởi họ bị mắc kẹt vào một quy trình an toàn.
Theo Covill, các bài học thực tiễn được chấp nhận khi phát triển phần mềm đã được nghiên cứu từ 3 đến 6 tháng trước khi bắt đầu quá trình thử nghiệm sản phẩm 12 tháng. Sau đó, các nhà phát triển thực hiện tới 16 loại kiểm thử về chức năng, tính ổn định, sự dễ dàng tích hợp và khả năng mở rộng. Tiếp theo, sau khi họ thấy rằng phần mềm đã đạt đủ độ ổn định để đem sử dụng, kiểm soát, các cài đặt trong thực tế, họ chuyển chúng đến các nhân viên kiểm thử beta và đợi nhận thông báo lại từ nhóm này.
Quá trình beta này mang lại lợi ích cho cả hai bên. Các nhà cung cấp có một sản phẩm tốt hơn vì nếu các CIO bắt được lỗi thì sẽ là do các nhà phát triển, Theo trung tâm nghiên cứu hiệu năng phần mềm, kiểm thử beta mang lại một vài kết quả cao nhất trong việc sửa lỗi do sự thiếu sót, mơ hồ, tốc độ và khả năng của phần mềm khi đem so sánh với 16 các hình thức kiểm thử khác. Và các CIO thì được lợi bởi việc có được công nghệ đầu tiên, hiểu được trạng thái của nó và có được động lực với các nhà cung cấp cho phép các CIO có thể yêu cầu các tính năng cụ thể hơn. Thêm vào đó, hầu hết các CIO đều nhận thêm một khoản phí ứng dụng được chiết khấu cho phần mềm.
Nhưng cũng có những thời điểm kiểm thử bị bỏ quên
Nhưng ý kiến của ông Neil Goldman, giám đốc về chiến lược mạng máy tính tại tổ chức nghiên cứu công nghệ Boston thuộc tập đoàn Yankee lại cho rằng quá trình kiểm thử beta lý tưởng xưa kia chưa bao giờ đi theo kế hoạch. Một vài CIO đã thực hiện quá trình kiểm thử này đơn giản là để nhận được phần mềm trước với mức giá thấp và chưa bao giờ thực sự thực hiện nó hay thông báo cho các nhà cung cấp về hiệu suất của phần mềm. Và rất nhiều người chỉ có mỗi ý định là gửi lại các phản hồi đã trở nên lạc hướng trong suốt thập kỷ qua với các ưu tiên như việc chuẩn bị cho sự cố Y2K. Các phản hồi của Kiểm thử Beta đã bị bỏ đi nhiều đến mức mà rất nhiều các cửa hàng phần mềm bắt đầu giữ mức giá thấp cho đến khi họ nhận được thông tin phản hồi báo lỗi từ chính nhà cung cấp.
Một vài CIO đơn giản xem kiểm thử chỉ như phần phụ trợ của họ. Ông Ron Furmaniuk, quản lý hành chính tại Công ty phát triển Lotus tại Cambridge nói rằng khoảng hơn 4000 nhân viên kiểm thử mà ông quản lý, hầu hết lại là các quản lý của nhóm IS, trưởng nhóm dự án, các kĩ sư hệ thống các nhà phân tích và chuyên gia tư vấn. Ông ta không tìm thấy nổi một CIO hay giám đốc về IT nào trong nhóm mà ông quản lý.
Và trong khi các CIO trở nên quá bận rộn với chương trình kiểm thử beta thì thị trường đã thay đổi và các nhà phát triển cũng đã bận rộn hơn nhiều.
Ông Jean-Luc Alarcon, phó chủ tịch cấp cao về tài nguyên truyền thông tương tác và các báo cáo nghiên cứu chi nhánh tại Stamford thuộc tập đoàn tư vấn Beta, nhắc lại những năm về trước, các nhà cung cấp nói với khách hàng về thời gian chờ đợi là 18 tháng cho một sản phẩm mới được tung ra. “Họ nói rằng, với Internet chúng tôi sẽ cung cấp cho bạn các chức năng một cách thường xuyên. Nhưng trong nỗ lực xây dựng ứng dụng với nhiều tính năng hơn so với các đối thủ cạnh tranh, có thời gian để được thị trường chấp nhận nên động lực làm việc của họ trong môi trường Internet tốc độ cao, các nhà cung cấp bắt đầu cắt giảm những phần không cần thiết và chu kì 12 tháng cùng với các bài kiểm thử beta không còn trong danh sách. (Chad Robinson, một nhà nghiên cứu cấp cao tại nhóm Robert Frances chú thích thêm rằng một số nhà cung cấp lớn cũng dừng việc chạy các bài kiểm thử beta bởi họ không muốn chi tiết của sản phẩm mà họ chuẩn bị tung ra bị rò rỉ ra cho các đối thủ cạnh tranh của họ)
Như ông Sherman dự đoán, trở thành nhà tiên phong tung ra thị trường và đưa ra các tính năng trước một bước thì độ tin cậy chắn chắn sẽ ở vị trí phụ.
Rất ít các nhà phát triển vẫn dùng kiểm thử beta, ông Covill tại viện ngiên cứu AMR cho hay, họ đang gửi đi các nguyên mẫu mà họ chỉ bỏ ra có vài tháng để phát triển nó và họ biết rằng nó sẽ có lỗi. Nếu phẩn hồi của kiểm thử viên không tốt thì các nhà cung cấp sẽ bỏ các nguyên mẫu đó đi không thương tiếc và bắt đầu một cái khác. Nếu phản hồi là tốt thì ứng dụng sẽ được tung ra thị trường. Các CIO đang có khả năng mua những sản phẩm mới được tung ra hơn là lấy các phiên bản còn kém xa bản nguyên mẫu.
Các phần mềm chủ được cung cấp bởi các nhà cung cấp dịch vụ ứng dụng (gọi tắt là ASPs) không khá hơn đươc mấy, theo ông Goldman, các ứng dụng do ASP cung cấp chỉ chạy được tại server ASP, có thể hiệu chỉnh liên tục nên ASP không phải lo lắng về tính mạnh mẽ của ứng dụng khi họ tung ra chúng. Để đạt đến 99.999% thời gian thao tác sẽ tốn rất nhiều tiền và họ không chi trả nhiều tiền đến thế, tiền cũng như năng lượng (trong công tác kiểm thử). Họ chỉ muốn tung ra được luôn.
Theo ông Capers Jones, nhà nghiên cứu thuộc hệ thống quản lý Artemis, chỉ 30% các công ty phần mềm ở Mỹ thực hiện kiểm thử beta tính tại thời điểm năm 1998, một con số mà có người cho rằng đã giảm đi cho đến thời điểm hiện tại. Cũng trong khoảng thời gian đó, các thất bại của phần mềm khó lường lại không được tìm thấy bởi các kiểm thử viên đầu tiên mà là từ những người sử dụng đầu tiên.
Lí do các CIO không sử dụng kiểm thử Beta
Brian Berlin, CIO của Washington Group International không sử dụng kiểm thử beta. Ông không tìm được một ứng dụng nào có thể xử lý các chức năng cốt lõi của CNTT đủ mạnh để cung cấp lợi thế kinh doanh cho công ty Boise, một tổ chức kĩ sư xây dựng ở bang Idaho. Ông cũng nói thêm chỉ có duy nhất một loại ứng dụng đáng được xem xét trước và chi trả cho quá trình kiểm thử, “chúng tôi không phải là một công ty mạng, chúng tôi không cần phải đứng trên bờ vực của những chuyện như này”.
Jeff Scott thì nói rằng ông ấy không thể biện hộ cho các nhu cầu về nguồn lực mà kiểm thử yêu cầu. Với tư cách là giám đốc quản lý công nghệ tiên tiến tại ngân hàng Charlotte trụ sở tại N.C. Scott muốn tìm kiếm các công nghệ để cải thiện việc liên lạc nội bộ và các yêu cầu xử lý từ bên ngoài ngân hàng được số hóa. Trong một lần, ông đã tổ chức một nhóm với mục đích kiểm thử trước khi tung ra các phần mềm của Sun Microsystems. Mặc dù nhóm của ông đã nghiên cứu những đặc tính và sự phức tạp của công nghệ này, nhưng sau cùng ngân hàng quyết định là không đáng để thực hiện. Nên nhóm của Scott đã lãng phí thời gian của họ. Ông ấy nói “chiến lược của chúng tôi bây giờ là có sự tiếp cận công nghệ sớm, còn chúng tôi sẽ để người khác chứng minh điều đó”.
Trong khi Bertlin và Scott thuộc số đông thì thiểu số đang nổ ra cuộc chiến chống lại những phần mềm xuống cấp. Các CIO, những người luôn biết rằng chỉ có làm việc và đặt áp lực lên vai nhà cung cấp thì họ mới tìm được những phần mềm có giá trị.
Home Depot thực hiện kiểm thử Beta như thế nào
Ron Griffin, CIO của công ty Home Depot có trụ sở tại Atlanta không chỉ nhận xét các ứng dụng mà ông ấy mua trước khi đưa vào sản suất hàng loạt, ông ấy còn thực hiện kiểm thử chúng. Nhà cung cấp hạ tầng IT khổng lồ cho các mặt hàng gia đình đã kết nối hơn 700 cửa hàng. Ông Griffin nói rằng ông ấy luôn tìm kiếm những cách thức mới tổ chức bộ máy tốt hơn. 30% các hạ tầng này đều từ các nhà cung cấp.
Griffin tin tưởng rằng ông ấy có thể sử dụng rất nhiều mã nguồn nước ngoài, có khả năng thay đổi tiềm tàng, một cách chính xác vào mạng lưới của ông vì ông ấy sử dụng phần mềm kiểm thử beta. Ông luôn gửi các mã mới cho nhóm của mình và các kiểm thử viên. Tuy nhiên nếu ông ấy thực hiện các bước trong quá trình kiểm thử, nhà cung cấp dường như kết hợp chặt chẽ hơn những thay đổi về chức năng cũng như việc sửa mã nguồn. “Năm ngoái chúng tôi đã làm việc với hơn một tỉ khách hàng thông qua các điểm hệ thống kinh doanh, và có khoảng 50 tỉ giao dịch đã được thực hiện. Hầu hết các ứng dụng đều không được thiết kế nằm trong phạm vi kinh doanh của chúng tôi, nên chúng tôi thường liên tục tái kết cấu và cải tiến nó”.
Griffin nói rằng ông ấy hiểu tại sao nhiều CIOs sử dụng trực giác hơn là quá trình kiểm thử để đưa ra quyết định liệu phần mềm mới này có phục vụ cho việc kinh doanh của họ không (Thường thì kiểm thử mất nhiều thời gian). Nhưng ông nghĩ rằng nếu không có kiểm thử thì sau cùng lại tốn nhiều thời gian và tiền của hơn. “Các tổ chức mà không qua quá trình kiểm thử thấy rằng họ có khoảng thời gian khó khăn khi đưa phần mềm đi vào sản xuất và kinh doanh”. Một khi mà các nhân viên CNTT đã kiểm thử sản phẩm của nhà cung cấp, thì họ có thể ngay lập tức tập huấn cho những thành viên khác trong tổ chức. “Họ sẽ có được cảm nhận về quyền sở hữu thông qua việc kiểm thử và nó dẫn đến việc phần mềm sẽ nhận được sự chấp thuận ở mức cao hơn trong cộng đồng người dùng”
Compaq đã thực hiện kiểm thử Beta
Joe Batista, giám đốc kiêm trưởng bộ phận sáng tạo về Internet doanh nghiệp tại trụ sở Compaq ở Houston, cũng tin rằng ông ta tránh được mã xấu bằng việc có quan hệ tốt với các nhà cung cấp. Nhưng Batista lại đi trước Griffin một bước và hoàn toàn nhấn chìm bản thân vào các quá trình sản xuất của các nhà cung cấp.
Batista đã tạo ra một buổi hội thảo mà ở đó ông và 5 kĩ sư, kiểm thử, thiết kế và phát triển kinh doanh của công ty Compaq, những người đã có kinh nghiệm gặp gỡ với những nhóm quản lý các công ty phần mềm trẻ. Họ lắng nghe những câu chuyện và thúc đẩy các mô hình, các tiến trình và công nghệ nền tảng của họ. Điều này vừa mang tính hợp tác vừa mang tính tách rời.
Vào 02/1999, Batista và nhóm của ông ấy đã thực hiện một phiên làm việc với Conjoin, một công ty đang phát triển các công cụ mạng nội bộ. Khi Batista nghe đến việc CEO của Conjoin là Nick d’Arbeloff nói về công cụ xuất bản mang tính nội bộ “Field First” của công ty ông, Batista nhận ra rằng điều này có thể giúp ông có một dự án. Ông đã phải vật lộn với một mô hình mạng nội bộ mà ông xây dựng cho nhân viên kinh doanh tại chi nhánh phía Đông của Compaq. Quản lý và cập nhật thông tin trên trang chủ - các thông tin quảng cáo, các đầu mục đầu cơ và các phản ứng của khách hàng đang dần trở nên tẻ nhạt. Công cụ “Field First” cho phép bất cứ ai công khai trên mạng nội bộ với các dữ liệu xử lý văn bản thông thường, điều này sẽ làm giảm bớt áp lực. Nhưng Batista không thể mua ngay Field First bởi vì Conjoin vẫn chưa phát triển xong nó. Nên Batista yêu cầu được giúp d’Arbeloff hoàn thiện việc xây dựng bản nguyên mẫu.
Batista nói về loại hình hợp tác công việc này vì nó cho phép Compaq và nhà cung cấp của công ty này có nhiều cơ hội hơn. “Chúng tôi phải theo sát ranh giới hợp tác truyền thống của CNTT, cái mà một ai đó có thể là một nhà cung cấp được thiết lập với 3 sự chứng nhận và hàng triệu đô”. Nếu chất lượng về mã nguồn hay kinh nghiệm của nhà cung cấp là một dấu hỏi, Batista biết ông ấy sẽ mất thời gian nhảy vào vòng xoay của sự phát triển này và lấp đi những chỗ trống.
Sử dụng biện pháp tài chính
Sandy Philips, CIO tại Eso, một trung tâm tư vấn về thương mại điện tử ở Berwyn, không có được sự linh hoạt của Griffin và Batista tại Home Depot và Compaq khi tham gia vào chu trình sản phẩm của các nhà cung cấp (hoặc có ảnh hưởng để thuyết phục các nhà cung cấp bỏ đi việc kiểm soát các nỗ lực phát triển của họ). Với chỉ 4 kĩ sư CNTT làm toàn thời gian, ông ấy rất bận rộn để giữ được 35 triệu đô và hơn 300 nhân công đang làm việc mượt mà tại công ty của ông ây. Tuy nhiên ông ấy vẫn kiểm soát một ngân quỹ lên đến 7 con số và các khoản lỗ lãi kèm theo nó.
Giờ đây, Phillip đang vật lộn để tích hợp hệ thống kế toán hỗ trợ của Eso, một hệ thống quản lý thực tiễn mà công ty đã mua năm ngoái từ một nhà cung cấp (ông ấy không muốn tiết lộ tên). Không chỉ là sản phẩm (cái mà Eso đã mua trước khi Phillip trở thành CIO) bị khiếm khuyết mà còn là việc nhà cung cấp rất chậm chạp trong việc sửa nó.
“Một trong số hệ thống quản lý các hóa đơn được tích hợp đã không chạy được khi làm việc quá nhiều, chúng tôi đã tìm ra lỗi và phải nhập dữ liệu bằng tay vào hóa đơn. Nếu chúng tôi không làm thế sẽ thiệt hại hàng nghìn đô trong vòng một tháng chỉ vì các hóa đơn bị lỗi”
Sau khi phát hiện ra vấn đề, Phillip đã ngay lập tức báo cho nhà cung cấp nhưng không hề nhận được phản hồi. Nên ông ấy đã tự giải quyết vấn đề theo cách của mình. Ông nói “Tôi đã giữ tất cả các hóa đơn mà họ đã gửi” và nói rằng “Tôi sẽ không trả tiền cho đến khi họ sửa được sản phẩm này và cho tôi thấy được hiệu suất thực sự”. “Bỗng nhiên chúng tôi có rất nhiều voice mails, emails và cả sự quan tâm”. Nhà cung cấp đã cử một quản lý kế toán chuyên làm việc với Phillip.
Vì vấn đề của Phillip xuất hiện với nhà cung cấp này nên ông nói với những người khác là ông sẽ không trả tiền cho đến khi ông thấy được kết quả. “Họ đến gặp tôi và thỏa thuận số tiền họ muốn nhận vào mỗi tháng. Tôi quay lại kế hoạch dự án, chỉ ra các công việc đầu ra và nói chúng tôi sẽ có những mốc gia hạn tiền trả dựa theo các mốc công việc đầu ra được hoàn thành tốt”. Bây giờ Phillip có thể từ chối trả tiền nếu nhà cung cấp này có vấn đề về sản phẩm và cần phải sửa chúng.
Phillip cũng thấy rằng các nhà cung cấp có vẻ dễ chịu khi ông mời họ được quảng cáo miễn phí tại các hội nghị và các cuộc gặp nhóm người dùng. “Tôi có sức mạnh để họ có thể tự do quảng cáo, kể cả khi nó có mang tính tiêu cực hay tích cực” và ông ấy tin rằng có thể nắm bắt được họ.
Sức mạnh của số đông
Phillip không phải đơn độc khi sử dụng các nhóm người dùng như một tác động đến các nhà cung cấp. Mike Reilly, trưởng bộ phận kĩ thuật của J.P.Morgan, một công ty tài chính đặt trụ sở tại New York, đã tham gia một nhóm người dùng có liên hệ mật thiết với các nhà cung cấp. Reilly là một phần của một nhóm mở, tại Anh, một trong số ít các nhóm không bị kiểm soát bởi các nhà cung cấp. Nhóm bao gồm hơn 200 người dùng và nhà cung cấp là doanh nghiệp về CNTT và khuyến khích việc điều hành CNTT từ Charles Schwab, Visa hay Bộ quốc phòng Mỹ nhằm nâng cao nhận thức các vấn đề về phần mềm. Ở phương diện này, Allen Brown, Chủ tịch, CEO của nhóm mở đã nhìn thấy các CIO mang tới sự thay đổi. “Thường là khi người mua yêu cầu các giải pháp, nhà cung cấp phản hồi rằng các sự thay đổi sẽ diễn ra trong lần tung ra tiếp theo hoặc họ sẽ coi như chưa nghe phàn nàn gì từ các khách hàng khác”. “Nhưng nếu họ nghe thấy đúng là từ một nhóm bao gồm Boeing, J.P.Morgan và Shell thì việc họ bác bỏ như chưa nghe là rất khó”.
Các nhóm khác, như hội đồng nghiên cứu ở thành phố New York, tụ họp khoảng 100 CIO giàu có nhất tập trung vào các ứng dụng thực tiễn về kinh doanh và nghiên cứu kĩ thuật, ngoại trừ các nhà cung cấp. Các nhà nghiên cứu của hội đồng này đã thăm và phỏng vấn với các nhà cung cấp, mời một số chính trong họ nói chuyện và gửi cho các nhà cung cấp về kết quả các cuộc điều tra CIO.
Các đại diện cho tổ chức được chứng nhận về tiêu chuẩn, như Viện kĩ sư phần mềm và Viện điện và điện tử máy tính cộng đồng tại Washington D.C, một cơ quan chứng nhận về quy tình tại trường đại học Carnegie Mellon ở Pittsburgh nói rằng họ muốn các CIO tham gia và giúp đỡ định hình tiêu chuẩn đánh giá phần mềm mà họ tạo ra. Ông Mike Konrad, một thành viên cấp cao của đội ngũ kĩ thuật tại SEI đã nói “CIO là một nhà quan sát thông thái nhất và chúng tôi muốn được chạm đến sự hiểu biết đó của họ”.
Xem xét việc liệu họ có cùng làm hay tự làm theo cách của họ, ông David Reid, giám đốc bộ phận quản lý IT tại Fazoli, một công ty chuyên về thức ăn nhanh của Ý đóng tại Lexington cho hay đó sẽ là sự bắt buộc khi các CIO bắt đầu nói chuyện về tiền của họ và nếu họ không có thời gian hay cho nhân viên của họ xem lại và kiểm tra. “Chúng tôi vừa thực hiện xong quá trình viết yêu cầu, các bài diễn thuyết kinh doanh, thử nghiệm kịch bản, kiểm tra tài liệu tham khảo và kiểm thử trong phòng thí nghiệm” “chỉ để phát hiện ra có bất cứ sai sót nào trong quá trình thực hiện các sản phẩm ở tất cả các bước”. “Câu trả lời là bạn phải siêng năng trong suốt quá trình chọn lựa và nhớ rằng ai là người phải trả hóa đơn”. “Hơn thế nữa, tất cả những gì chúng ta có thể làm là chờ đợi một sự phát triển và sống sót của sự phù hợp nhất để có thể tiến về phía trước trong ngành công nghiệp phần mềm này”.
343 Go top

Ý kiến về Website HĐGĐCNTT?
1. Đạt yêu cầu, 7 phiếu (44 %)
2. Chưa đạt yêu cầu, 4 phiếu (25 %)
3. Cần thêm chủ đề, 5 phiếu (31 %)
Tổng số phiếu: 16
Thống kê truy cập
  • Người trực tuyến Người trực tuyến
    • Khách Khách 39
    • Thành viên Thành viên 0
    • Tổng Tổng 39