Luận văn thạc sĩ Hệ thống thông tin quản lý: Cải tiến quy trình kiểm thử phần mềm tại nhóm control manager-công ty TMA Solutions

Việc đề xuất cải tiến nhằm giải quyết các hạn chế cũng như nhược điểm của quy trình hiện tại, sau đó đánh giá tác động của quy trình cải tiến lên các tiêu chí về chất lượng sản phẩm, chi

GIỚI THIỆU ĐỀ TÀI

GIỚI THIỆU ĐỀ TÀI

Ngày nay với nhu cầu ứng dụng các sản phẩm công nghệ thông tin ngày càng phổ biến trong nhiều lĩnh vực như truyền thông, liên lạc, quản lý doanh nghiệp, cũng như các ứng dụng hỗ trợ đời sống con người như ứng dụng để điều khiển các thiết bị dùng trong gia đình như các thiết bị nghe nhìn - camera, điện thoại, đến các ứng dụng lớn hơn như trợ giúp điều khiển các phương tiện và hệ thống giao thông, trả tiền cho các hoá đơn, quản lý và thanh toán về tài chính, Với nhu cầu đó thì yêu cầu về chất lượng phần mềm cần được đảm bảo nhằm cung cấp đầy đủ các tính năng cần thiết cũng như hoạt động hiệu quả và thân thiện để đáp ứng các yêu cầu của người sử dụng Để đạt được mục tiêu đó, bên cạnh việc nâng cao khả năng lập trình phát triển phần mềm tốt hơn thì còn đòi hỏi phải có một quy trình kiểm thử phần mềm tốt được thực hiện trước khi ứng dụng đến tay người sử dụng nhằm hạn chế tối đa những lỗ hỏng phần mềm, những sai sót về mặt chức năng, giao diện, bảo mật, Chính vì vậy, chúng ta cần xem xét lại các quy trình kiểm thử phần mềm ứng dụng và cải tiến cho thích hợp để ngày càng nâng cao chất lượng phần mềm phục vụ hoạt động ổn định và đạt được hiệu suất cao trong lĩnh vực ứng dụng, cũng như giảm một phần chi phí cho việc sữa chữa sai sót và giảm các nguy cơ lỗ hỏng trong phần mềm có thể gây tổn thất trong quá trình sử dụng ứng dụng

TMA Solutions là một công ty chuyên về gia công phần mềm tại Việt Nam, công ty có nguồn khách hàng từ các quốc gia như Canada, Úc, Mỹ, Phần Lan, tập trung vào mô hình gia công outsource và kiểm thử các sản phẩm công nghệ về Voice over IP, Contact Center, các ứng dụng xã hội HealthCare và Mobile… Để ngày càng củng cố sự tin tưởng từ khách hàng, TMA đã và đang ngày càng hoàn thiện các quy trình làm việc và đặc biệt chú trọng vào các quy trình kiểm thử cốt lõi nhằm mang lại kết quả tin tưởng nhất, đảm bảo chất lượng sản phẩm hoạt động một cách hiệu quả khi được triển khai thực tế sử dụng Tùy thuộc vào mỗi khách hàng và bản chất của mỗi sản phẩm mà mỗi đội nhóm sẽ có chiến lược lựa chọn một quy trình kiểm thử thích hợp nhằm hướng đến các mục tiêu như: tìm kiểm lỗi, đạt được sự tin tưởng về chất lượng, cung cấp thông tin cho việc ra quyết định và giảm thiểu lỗi thông qua quá trình trao đổi thông tin và thực hiện kiểm tra đầy đủ tính năng, chất lượng sản phẩm, đảm bảo đầu ra đúng theo yêu cầu và hạn chế tối đa rủi ro xảy ra trong quá trình vận hành của sản phẩm trong môi trường thực tế

7 Đối với đội nhóm kiểm thử chuyên về hệ thống Control Manager – một sản phẩm phần mềm dựa trên nền tảng Web, cung cấp việc quản lý tập trung các tác vụ về cấu hình, quản lý và phân bổ tài nguyên cho người dùng đối với các hệ thống Contact Center và hệ thống quản lý cuộc gọi qua Voice over IP, được đầu tư phát triển và nâng cấp bởi các lập trình viên tại Israel trong khoảng thời gian 4 năm qua và là một dạng sản phẩm lâu đời đang được sử dụng rộng rãi bởi các ngân hàng lớn như Deustbank tại Đức và các khách hàng tiềm năng tại khu vực Bắc Mỹ như TBANK, BELL CANADA Vì là một sản phẩm được phát triển lâu dài và có quy mô rộng nên quy trình kiểm thử được áp dụng cho dạng sản phẩm này được nhóm Tester TMA khởi đầu với mô hình kiểm thử đề xuất bởi tổ chức ISTQB

Tuy nhiên, qua thời gian áp dụng quy trình kiểm thử ISTQB tại nhóm Control Manager, các kết quả kiểm thử vẫn còn tồn tại một số thiếu sót về mặt kỹ thuật, chức năng và bảo mật sau khi sản phẩm được triển khai thực tế tại doanh nghiệp

Và quy trình kiểm thử là một yếu tố quyết định, kiểm soát các lỗ hỏng trong quá trình kiểm thử Sau đây là các số liệu thống kê về các lỗ hỏng theo tháng của nhóm kiểm thử Control Manager trong tháng 8 và tháng 10 năm 2016

Hình 1-1: Thống kê lỗ hỏng về kiểm thử vào tháng 8/2016 của nhóm

Hình 1-2: Thống kê lỗ hỏng về kiểm thử vào tháng 10/2016 của nhóm Control

Với hai thống kê ở Hình 1-1 và Hình 1-2, nhận thấy số lượng lỗ hỏng do nguyên nhân về việc thiếu sót trong quá trình kiểm thử là 40% và 9% vào các tháng 8 và tháng 10/2016 Chính vì vậy, đề tài hướng đến việc nghiên cứu, phân tích quy trình kiểm thử tại nhóm Control Manager để có thể đề xuất cải tiến quy trình hiện tại nhằm nâng cao chất lượng kiểm thử thông qua việc giải quyết các mặt còn thiếu sót trong kết quả kiểm thử.

MỤC TIÊU NGHIÊN CỨU

Nghiên cứu này nhằm mục tiêu cải tiến quy trình kiểm thử phần mềm đang được thực hiện tại nhóm Control Manager, công ty TMA Cụ thể như sau:

 Đề xuất cải tiến quy trình kiểm thử này cho nhóm Control Manager

 Đánh giá tác động của quy trình kiểm thử cải tiến đến các tiêu chí về chất lượng phần mềm, chi phí, phân bổ quản lý nhân lực và chiến lược quản lý trong một quy trình kiểm thử.

NỘI DUNG NGHIÊN CỨU

Đề tài sẽ bao gồm các bước phân tích quy trình kiểm thử phần mềm hiện đang được áp dụng tại nhóm Control Manager, thông qua việc mô tả các hoạt động của quy trình kiểm thử phần mềm hiện tại, đút kết những vấn đề còn tồn tại và các kết quả thường thấy về mặt chức năng, bảo mật, hiệu suất cho mỗi ứng dụng sau khi được triển khai ứng dụng trong môi trường thực tế Qua đó đề xuất cải tiến một số hoạt động trong quy trình nhằm giải quyết các vấn đề tồn tại được nêu ra

Và đánh giá tác động của quy trình cải tiến mới đến các tiêu chí về chất lượng

9 phần mềm, chi phí, phân bổ quản lý nhân lực và chiến lược quản lý trong quy trình kiểm thử.

PHẠM VI NGHIÊN CỨU

 Quy trình kiểm thử phần mềm đang được áp dụng cho nhóm ứng dụng Control Manager tại công ty TMA Solutions

 Phân tích và đánh giá ưu và nhược điểm của quy trình kiểm thử hiện tại

 Đề xuất cải tiến một số hoạt động trong quy trình

 Đánh giá các tác động của quy trình mới đến các tiêu chí về chất lượng phần mềm, chi phí, phân bổ quản lý nhân lực và chiến lược quản lý trong quy trình kiểm thử.

BỐ CỤC LUẬN VĂN

Luận văn bao gồm 5 chương:

Chương 1: Tổng quan về đề tài – giới thiệu tổng quan về TMA và dự án Control Manager cùng các báo cáo về tình hình kiểm thử tại nhóm Control Manager, mục tiêu nghiên cứu, nội dung và phạm vi nghiên cứu được trình bày trong chương này

Chương 2: Cơ sở lý thuyết – chương này trình bày cơ sở lý thuyết về thực trạng của quy trình phát triển và kiểm thử phần mềm hiện tại đang được sử dụng phổ biến trong lĩnh vực công nghệ phần mềm cùng các nghiên cứu liên quan đến việc nâng cao chất lượng phần mềm nói chung và kiểm thử nói riêng Và sơ lược về quy trình đánh giá sử dụng trong bài luận văn sẽ được đề cập ở cuối chương Chương 3: Đề xuất cải tiến và đánh giá quy trình cải tiến – trình bày chi tiết quy trình quản lý dự án của tổ chức PMI và mô hình nghiệp vụ BPMN Chương này cũng sẽ đề cập về quy trình kiểm thử hiện tại đang được ứng dụng tại nhóm Control Manager cùng các ưu điểm và nhược điểm được tìm thấy Tiếp theo, sẽ trình bày về quy trình kiểm thử đề xuất và phương pháp đánh giá quy trình mới Chương 4: Kết quả đánh giá quy trình cải tiến: trình bày các kết quả nghiên cứu về định tính và định lượng, phân tích các kết quả thu được

Chương 5: Kết luận và kiến nghị - tóm tắt nội dung nghiên cứu và kết quả đạt được, đưa ra kết luận và kiến nghị dựa trên các kết quả nghiên cứu Các hạn chế và hướng nghiên cứu tiếp theo cũng được đề cập trong chương này

CƠ SỞ LÝ THUYẾT VÀ CÁC NGHIÊN CỨU LIÊN QUAN

THỰC TRẠNG VỀ CÁC QUY TRÌNH PHÁT TRIỂN PHẦN MỀM VÀ KIỂM THỬ HIỆN TẠI

MỀM VÀ KIỂM THỬ HIỆN TẠI

Hiện nay, trong nền công nghiệp phần mềm đã tồn tại những mô hình phát triển phần mềm khá phổ biến như:

 Mô hình phát triển Extreme

 Mô hình kiểm thử ISTQB

Trong đó, mô hình CMMI và Waterfall là việc kiểm thử được thực hiện bởi một nhóm Tester độc lập sau khi các chức năng được phát triển, trước khi được chuyển giao cho khách hàng Hoạt động này thường đưa đến kết quả là giai đoạn kiểm thử được sử dụng như một dự án đệm để bù đắp khi trễ dự án, do đó ảnh hưởng đến thời gian dành cho việc kiểm thử

Mô hình phát triển Agile và Extreme dựa theo mô hình "phát triển phần mềm test-driven" Trong qui trình này, unit test được viết đầu tiên bởi DEV (thường là lập trình song song trong phương pháp lập trình extreme – cực biên) Ban đầu dĩ nhiên là các test này sẽ thất bại như là mong muốn của họ Sau khi code được viết xong thì phần lớn test suite sẽ từng bước tăng lên Test suite là các bản cập nhật liên tục các điều kiện thất bại mới và các trường hợp tiềm ẩn vừa được phát hiện thêm, và chúng được tích hợp vào test hồi qui Unit test thường được duy trì với công cụ chứa source code phần mềm (ví dụ như Eclipse, Jdeveloper, VS net v.v… Code của unit test được lưu trữ chung với code của chương trình) và được tích hợp chung với qui trình build phần mềm (với các phần test tương tác sẽ được bỏ riêng ra khỏi qui trình chấp nhận build thủ công từng phần) Mục đích cuối cùng của qui trình test này là đạt được việc triển khai liên tục, phần mềm được cập nhật có thể công bố ra công chúng thường xuyên

11 Đối với quy trình kiểm thử ISTQB là bao gồm các best practices từ các chuyên gia phần mềm nêu ra, cung cấp các hiểu biết từ căn bản nhất của kiểm thử phần mềm cho đến chuyên sâu, định nghĩa các hoạt động cần thiết cho việc kiểm thử nhằm đảm bảo chất lượng của sản phẩm phần mềm

Mỗi quy trình phát triển phần mềm đều có những đặc tính và yêu cầu khác nhau, và phải được sử dụng cho mỗi sản phẩm phần mềm tương ứng với từng thời kỳ phát triển Trong đó, kiểm thử phần mềm được xem như là một phần của quy trình phát triển phần mềm, có ảnh hưởng đến thời gian hoàn thành sản phẩm như làm dừng, làm chậm quá trình chuyển giao phần mềm cho khách hàng trong trường hợp các tiêu chí chất lượng chưa được đảm bảo Như vậy, với mỗi quy trình phát triển phần mềm cần đảm bảo một quy trình kiểm thử tương ứng nhằm giảm thiểu rủi ro về các vấn đề gặp phải trong suốt quá trình hoạt động và đóng góp vào việc đảm bảo chất lượng của sản phẩm khi đến tay người sử dụng.

CÁC NGHIÊN CỨU LIÊN QUAN

Theo Joachim Wegener [17], việc nâng cao hiệu quả và chất lượng kiểm thử trong lĩnh vực phát triển hệ thống nhúng được bắt nguồn từ yêu cầu an toàn của các thành phần điện tử được sử dụng trong các hệ thống nhúng, ví dụ như Công nghệ vũ trụ, Công nghệ đường sắt và xe máy, Quy trình và công nghệ tự động hóa, Công nghệ truyền thông, cũng như trong điện tử quốc phòng Khi có sự xuất hiện của sự cố/lỗi trong các hệ thống này sẽ gây thiệt hại lớn đến con người hoặc gây nên tổn thất lớn về chi phí Chính vì vậy, việc phát triển các hệ thống nhúng này cần phải tuân theo các yêu cầu và tiêu chuẩn chất lượng cao nhất Và sự đảm bảo chất lượng phân tích là điều quan trọng hàng đầu để đạt được sự phát triển chất lượng cao của các hệ thống nhúng Theo bài nghiên cứu, trong thực tế, biện pháp kiểm tra chất lượng phân tích quan trọng nhất là kiểm thử động và việc kiểm tra kỹ lưỡng các hệ thống đã phát triển là cần thiết cho chất lượng sản phẩm Mục đích của việc kiểm tra là phát hiện các lỗi trong hệ thống đang được thử nghiệm và mang lại sự tin cậy đối với các hoạt động của hệ thống và không có sai sót trong quá trình kiểm thử Và để nâng cao sự hiệu quả của kiểm thử và để giảm chi phí tổng thể cho các hệ thống nhúng, một chiến lược kiểm thử cần mang tính hệ thống và có khả năng tự động hoá Và kiểm thử cải tiến được ứng dụng để kiểm tra hành vi tạm thời của các hệ thống, có thể được dùng để tạo các trường hợp kiểm thử cho kiểm thử cấu trúc và cho phép tự động hoá kiểm thử an toàn Để thực hiện kiểm thử cải tiến, việc thiết kế trường hợp thử nghiệm phải được chuyển thành một vấn đề tối ưu hóa mà lần lượt được giải quyết bằng các kỹ thuật tìm kiếm meta-heuristic Kiểm thử cải tiến dựa trên ý tưởng tìm kiếm

12 các trường hợp thử nghiệm có liên quan trong vùng giá trị đầu vào của hệ thống được thử nghiệm với sự trợ giúp của thuật toán tiến hóa Kiểm thử cải tiến cho phép hoàn chỉnh thiết kế trường hợp thử nghiệm một cách tự động Nhờ sự tự động hoá đầy đủ của kiểm thử cải tiến, mức độ hiệu quả của quá trình kiểm tra có thể được cải thiện rõ ràng hơn trong tất cả các lĩnh vực ứng dụng Hệ thống có thể được kiểm tra với một số lượng lớn các tình huống đầu vào khác nhau để kiểm tra hành vi tạm thời và các kiểm tra an toàn Trong hầu hết các trường hợp, hơn một vài nghìn dữ liệu thử nghiệm được tạo ra và thực thi trong vòng vài phút Các kiểm thử cải tiến sẽ góp phần cải thiện chất lượng cũng như giảm chi phí phát triển cho các hệ thống nhúng Bài nghiên cứu nêu ra các thuật toán cải tiến trong kiểm thử, đó là các kỹ thuật tìm kiếm thích nghi Và kết quả đạt được khẳng định kiểm thử cải tiến là một cách tiếp cận đầy hứa hẹn để tự động hoá thiết kế các trường hợp kiểm thử cho các phương pháp và mục tiêu kiểm thử khác nhau Và để nâng cao tính hiệu quả của kiểm thử và cũng để giảm tổng chi phí phát triển của một hệ thống, thì đòi hỏi phải có tính hệ thống và khả năng tự động hoá

Theo Maria Khalid [18], chất lượng của một sản phẩm phụ thuộc vào mức độ hài lòng của khách hàng và chất lượng đó được đánh giá thông qua các tiêu chuẩn đã được quy định sẵn Và bài nghiên cứu này là một tổng hợp về các tiêu chuẩn được tuân theo trong lĩnh vực công nghệ thông tin để đảm bảo chất lượng sản phẩm phần mềm tương ứng Các chuẩn chất lượng cụ thể như ISO – International Organization for Standardization, CMMI – Capability Maturity Model Integration, PMI – Project Management Institute, ASME – American Society Mechanical Engineers, ANSI – American National Standard Institue, Một số tham khảo về các tiêu chuẩn chất lượng trong lĩnh vực công nghệ thông tin bao gồm các nghiên cứu về:

- Đánh giá chất lượng cho các phương thức mô hình hoá Web (Model-Driven Web Engineering), F.J Dominguez-Mayo 2012

- Đánh giá các nhân tố đảm bảo chất lượng trong Agile (Evaluation of Quality Assurance Factors in Agile Methodologies, M.Sirshar 2012

- Làm thế nào để cải thiện việc đảm bảo chất lượng phần mềm tại các nước đang phát triển (How to improve software Quality Assurance in developing countries), A.Javed 2012

- Các tiêu chuẩn chất lượng và đặc tính cho việc xây dựng Soft-Scape tại Malaysia (Quality standards and specification for Soft-Scape construction in Malaysia), J.A.Sani 2012)

- Đảm bảo chất lượng phần mềm, một nghiên cứu dựa trên nền công nghiệp phần mềm tại Pakistan (Software Quality Assurance A Study based on Pakistan’s Software Industry), A.Iftikhar 2011

- Thực thi và cấu hình mô hình quản lý cho việc nâng cao chất lượng trong giáo dục bậc cao (Implementation and Configuration Management Model for Quality Enhancement in Higher Education), M.N.Malik 2010

- Các phương thức đảm bảo chất lượng cho phát triển dựa trên mô hình: một khảo sát và đánh giá (Quality Assurance Methods for Model-based development: A Survey and Assessment), I.Fey 2007

- Cải tiến chất lượng phần mềm – một định hướng đánh giá (Improving Software Quality – a benchmarking approach), A.Imam 2007

- Kiểm thử phần mềm và đảm bảo chất lượng dự phòng trong Đo Lường (Software testing and preventive Quality Assurance for Metrology), N.Greif

Maria Khalid tập trung phân tích các tham số tiêu chuẩn trong đảm bảo chất lượng đối với các nghiên cứu nêu trên Các tham số tiêu chuẩn được dùng để đánh giá bao gồm: độ tin cậy (Reliability), độ toàn vẹn (Integrity), khả năng tái sử dụng (Reusability), khả năng bảo trì (Maintainability), tính dễ dùng (Ease of Use) và tính hiệu quả (Efficiency), tính di động (Portability), chức năng (Functionality), xác minh (Verification), xác nhận (Validation), hiệu suất (Performance), tính mở rộng (Extendibility) và tính hiệu dụng (Effectiveness) Kết quả đánh giá cho thấy các tiêu chuẩn Chất Lượng trong ngành công nghiệp thông tin đóng vai trò quan trọng trong việc đảm bảo mức độ hài lòng của khách hàng và để đạt được các chứng nhận chất lượng trong ngành công nghiệp thông tin

Theo Robert Baggent [19], với nhu cầu thực tiễn xuất phát từ các dự án bị thất bại do thiếu các khung đánh giá chất lượng mã code, dẫn đến chất lượng của sản phẩm không được xác định cho đến kiểm thử, bài nghiên cứu đã ứng dụng một mô hình đo lường chuẩn hoá dựa trên định nghĩa của khả năng duy trì và các chỉ số mã nguồn trong ISO/IEC 9126 để đo lường chất lượng chuẩn hóa mã code trong việc cải thiện khả năng duy trì phần mềm Theo đó, các đánh giá cá nhân sẽ được lưu trữ tại một kho lưu trữ và dựa trên kho lưu trữ này, bất kỳ hệ thống nào có thể được so sánh với các đo lường chuẩn hóa của ngành công nghiệp rộng lớn đó dựa trên các tiêu chí về chất lượng mã nguồn và khả năng bảo trì Các quy trình tiêu chuẩn trong các dự án đánh giá vẫn tiếp tục so sánh các kết quả, cho đến khi đạt được mức bảo trì phần mềm tối thiểu thì một chứng chỉ xác nhận mức

14 độ tin cậy về khả năng bảo trì sẽ được phát ra cho sản phẩm phần mềm Tóm lại, bài nghiên cứu cung cấp các quy trình và mô hình chuẩn hóa được sử dụng bởi SIG – Software Improvement Group để đánh giá, đo lường, và chứng thực về khả năng duy trì của các sản phẩm phần mềm

Theo Sahil và Rahul [20], việc cải tiến chất lượng phần mềm là cần sử dụng các chiến lược kiểm thử thích hợp cho mỗi giai đoạn phát triển phần mềm Xuất phát từ nhận định kiểm thử phần mềm là kỹ thuật quan trọng cho việc đánh giá chất lượng của một sản phẩm phần mềm để xác định rằng sản phẩm đáp ứng đầy đủ các yêu cầu chất lượng, Sahil và Rahul đã giải thích cụ thể các loại kỹ thuật kiểm thử khác nhau cùng các thuộc tính của chất lượng phần mềm, từ đó nhận dạng loại kỹ thuật kiểm thử nào sẽ thích hợp cho việc đánh giá một thuộc tính chất lượng tương ứng Trong đó, các thuộc tính chất lượng được nêu ra như: tính dễ hiểu (Understandability), tính hoàn thiện (Completeness), tính kết hợp (Conciseness), tính di động (Portability), tính đồng bộ (Consistency), khả năng duy trì (Maintainability), khả năng kiểm tra (Testability), khả năng sử dụng (Usability), tính tin cậy (Reliability), tính cấu trúc (Structure), hiệu quả (Efficiency), bảo mật (Security) Tương ứng với các thuộc tính chất lượng nêu trên, các kỹ thuật kiểm thử tương ứng như sau:

Completeness Boundary/Statement/Loop/Conditi on/Path Coverage Testing

Reliability Stress/Robust/Load Testing

Bảng 2-1: Các thuộc tính chất lượng và kỹ thuật kiểm thử tương ứng [20]

Dựa trên cách phân loại các kỹ thuật kiểm thử ứng với mỗi thuộc tính chất lượng ở bảng trên, Sahil và Rahul đưa ra kết luận rằng các phương thức đo lường của chất lượng phần mềm chính là các kỹ thuật kiểm thử phần mềm Mỗi dự án hoặc mỗi giai đoạn của dự án phát triển phầm mềm phải được ứng dụng một kỹ thuật kiểm thử tương ứng ứng với các điều kiện và yêu cầu khác nhau.

QUY TRÌNH ĐÁNH GIÁ QUY TRÌNH KIỂM THỬ

Với mục tiêu cải tiến quy trình kiểm thử hiện tại của nhóm Control Manager, bài luận văn đề xuất quy trình đánh giá quy trình kiểm thử bao gồm các hoạt động như trong hình 2-1:

Hình 2-1: Quy trình đánh giá quy trình kiểm thử phần mềm tại nhóm Control

Cụ thể các hoat động của quy trình đánh giá trên được mô tả như sau:

- Xác định mục tiêu nghiên cứu: là hoạt động định hướng mục tiêu nghiên cứu của luận văn – đó là Cải tiến và Đánh giá quy trình kiểm thử tại nhóm Control Manager – công ty TMA Solutions

- Cơ sở lý thuyết: tìm hiểu các nghiên cứu liên quan về lĩnh vực công nghệ phần mềm và kiểm thử, cũng như các phương pháp đã được nghiên cứu để nâng cao chất lượng sản phẩm phần mềm

- Nhận dạng phạm vi nghiên cứu: xác định phạm vi nghiên cứu và đối tượng nghiên cứu của luận văn

- Đề xuất cải tiến quy trình: tìm hiểu các mô hình quản lý và kiểm thử hiện tại, đề xuất một quy trình kiểm thử mới dựa trên các mô hình quản lý phổ biến để giải quyết các nhược điểm của quy trình cũ

- Thiết kế mô hình đánh giá: xây dựng một quy trình đánh giá cho mô hình kiểm thử cải tiến mới

- Lập bảng câu hỏi để thảo luận: thiết kế bảng câu hỏi khảo sát dựa trên các biến độc lập và biến phụ thuộc

- Tham vấn PM về bảng câu hỏi: tham vấn các quản lý dự án về mức độ thích hợp của bảng câu hỏi đối với các biến đánh giá

- Tổ chức các cuộc họp mặt/thảo luận theo nhóm: lập lịch và tổ chức các cuộc gặp mặt cho các nhóm cần khảo sát

- Thu thập ý kiến thảo luận: ghi chú các ý kiến thảo luận về quy trình cải tiến và phản hổi về bảng câu hỏi khảo sát

- Hoàn thành bảng câu hỏi: chỉnh sửa bảng câu hỏi phù hợp với ngữ nghĩa và dễ hiểu

- Gởi bảng khảo sát: gởi bảng khảo sát cho đối tượng khảo sát thông qua các đường dẫn liên kết và qua e-mail

- Thu thập kết quả khảo sát: nhận các kết quả đánh giá và lưu trữ

- Chạy phân tích kết quả khảo sát: sử dụng ứng dụng SPSS và AMOS để chạy phân tích dữ liệu đánh giá

- Đánh giá và kết luận: rút ra kết luận từ kết quả thu được sau phân tích SPSS và AMOS

PHƯƠNG PHÁP NGHIÊN CỨU

Nghiên cứu định tính là một hướng tiếp cận nhằm thăm dò để mô tả và giải thích các hành vi dựa vào các phương tiện khảo sát sự nhận thức hoặc động cơ thúc

17 đẩy hoặc các dự định để xây dựng các giả thuyết Trong nghiên cứu định tính, dữ liệu cần thu thập chủ yếu ở dạng định tính, không đo lường bằng số lượng

Thông thường bộ câu hỏi để thu thập dữ liệu định tính là các câu hỏi: thế nào, cái gì và tại sao? Và trong nghiên cứu định tính vẫn sử dụng các dữ liệu dạng số tuy nhiên không phục vụ cho việc chạy mô hình mà để hỗ trợ cho các phân tích và lập luận Dữ liệu trong nghiên cứu định tính thường có độ phân tán lớn

Phương pháp thu thập dữ liệu trong nghiên cứu định tính:

Mặc dù nghiên cứu định tính cũng dùng các phương pháp thu thập dữ liệu như: nghiên cứu tình huống, phỏng vấn, quan sát, ghi hình, ghi âm, gửi thư, nhật ký và các tài liệu khác nhưng linh hoạt và tùy biến (khác với phương pháp nghiên cứu định lượng, mẫu thu thập số liệu được xây dựng trước)

Thu thập dữ liệu thứ cấp:

 Dữ liệu thứ cấp là dữ liệu đã có sẵn

 Các nguồn thu thập: các báo cáo, nghiên cứu, số liệu thống kê, các tài liệu đã được công bố

 Phân loại nguồn dữ liệu và tiến hành thu thập theo yêu cầu

Thu thập dữ liệu sơ cấp:

 Dữ liệu sơ cấp là dữ liệu chưa được công bố do người nghiên cứu trực tiếp thu thập

 Các nguồn thu thập: từ thực tiễn nhờ các phương pháp quan sát, khảo sát

Những đặc trưng của nghiên cứu định tính:

 Tiếp cận quy nạp – Inductive Approach

 Tương tác và phản hồi - Interactive and Reflective

Việc chọn mẫu trong nghiên cứu định tính:

 Nghiên cứu toàn bộ: nghiên cứu tất cả các phần tử có trong tập hợp cần nghiên cứu

 Nghiên cứu đại diện: chỉ nghiên cứu một lượng nhỏ các phần tử thuộc tập hợp Một lượng nhỏ các phần tử được gọi là mẫu

 Vấn đề khi chọn mẫu phải đảm bảo tính đại diện cho tập hợp nghiên cứu Chọn lượng mẫu càng lớn thì mức độ đại diện càng lớn nhưng chi phí và tổ chức nghiên cứu cũng sẽ cao và phức tạp hơn nhiều

Ba công cụ phổ biến thu thập dữ liệu định tính:

 Phỏng vấn sâu: áp dụng khi cần biết về quan điểm, kinh nghiệm của từng cá nhân, linh hoạt và năng động Các loại phỏng vấn: Phỏng vấn không cấu trúc, phỏng vấn bán cấu trúc và phỏng vấn cấu trúc hoặc hệ thống

 Thảo luận nhóm: khám phá vấn đề, tìm hiểu ý tưởng Thường áp dụng khi thiết kế sản phẩm mới, xây dựng căn cứ thiết kế nghiên cứu định lượng

 Quan sát: quá trình ghi lại một cách trực quan và có hệ thống các đồ vật, sự vật, hiện tượng, tình huống và hành vi và không sử dụng phương tiện giao tiếp, đòi hỏi người quan sát phải có sự nhạy bén, chính xác, khách quan và khả năng suy luận từ những gì quan sát được

Xử lý dữ liệu định tính:

Hình 2-2: Quy trình xử lý dữ liệu định tính [ 2 ]

Phương pháp định tính thường được ứng dụng cho các chủ đề nghiên cứu mới, chưa được xác định rõ, hoặc cho các nghiên cứu thăm dò, chưa nắm được các khái niệm và biến số; hoặc khi muốn tìm hiểu mối quan hệ giữa những khía cạnh

19 đặc biệt của đối tượng; hoặc khi cần có sự linh hoạt trong hướng nghiên cứu để phát triển những vấn đề mới và khám phá sâu vào một chủ đề nào đó

Một số thuận lợi từ phương pháp định tính như: đòi hỏi kỹ năng xử lý và phân tích dữ liệu thống kê thấp hơn so với nghiên cứu định lượng, thời gian thực hiện có thể ngắn hơn do không cần dùng mẫu lớn

Tiếp cận định lượng xem xét hiện tượng theo cách có thể đo lường được trên các đối tượng nghiên cứu Nghiên cứu định lượng thường được áp dụng đối với các hiện tượng có thể được diễn tả bằng số lượng Nói cách khác, nghiên cứu định lượng là nghiên cứu sử dụng các phương pháp khác nhau để lượng hóa, đo lường và phản ánh, diễn giải các mối quan hệ giữa các nhân tố (các biến) với nhau

Việc thu thập dữ liệu trong tiếp cận định lượng:

 Các phương pháp thu thập dữ liệu có thể là cân, đo, bản câu hỏi có cấu trúc, phỏng vấn, quan sát bằng những công cụ khác

 Các dạng như phỏng vấn chuyên sâu, câu hỏi không cấu trúc là dạng kết hợp với nghiên cứu định tính Đặc điểm của nghiên cứu định lượng:

 Nghiên cứu định lượng liên quan đến lượng và số trong khi định tính liên quan đến chất và mô tả

 Mục đích của nghiên cứu định lượng là đo các biến số theo các mục tiêu và xem xét sự liên quan giữa chúng dưới dạng các số đo và thống kê

Các dạng dữ liệu định lượng:

 Ví dụ: các con số, số lượng, tỉ lệ, mức độ,

 Biến số được phân loại thành các dạng: kinh tế (tăng trưởng kinh tế, các chỉ số kinh tế, chỉ sô tài chính, ) , tâm lý (thái độ, sự lo lắng) hoặc xã hội Đặc trưng có bản của nghiên cứu định lượng:

 Nghiên cứu định lượng nghiên cứu mối quan hệ giữa các khái niệm và biến số Ví dụ: mối quan hệ giữa sự hỗ trợ của xã hội và chất lượng cuộc sống

 Nghiên cứu định lượng được dùng để tổng quát hóa kết quả nghiên cứu thông qua phân phối ngẫu nhiên và lấy mẫu đại diện

Nghiên cứu định lượng có thể cung cấp dữ liệu để mô tả sự phân bố của các đăc điểm, tính chất của tổng thể nghiên cứu, khảo sát mối quan hệ giữa chúng và xác định mối quan hệ nhân quả

Các kỹ thuật lập bảng câu hỏi:

ĐỀ XUẤT CẢI TIẾN VÀ ĐÁNH GIÁ QUY TRÌNH CẢI TIẾN

QUY TRÌNH THAM KHẢO VỀ QUẢN LÝ DỰ ÁN CỦA TỔ CHỨC PMI 22

3.1 QUY TRÌNH THAM KHẢO VỀ QUẢN LÝ DỰ ÁN CỦA TỔ CHỨC PMI

Quy trình quản lý dự án của tổ chức PMI – Project Management Institue (hình 3- 1) là một quy trình tổng quát về quản lý được tích lũy từ kinh nghiệm của các nhà quản lý, có thể được ứng dụng trong nhiều ngành nghề, công nghiệp Các kinh nghiêm đút rút trong quá trình quản lý dự án đã qua là các bài học vô giá nhằm đảm bảo sản phẩm đầu ra đảm bảo chất lượng và đạt được sự hài lòng cao nhất từ phía khách hàng Với đề tài này, việc cải tiến quy trình kiểm thử hiện tại dựa trên mô hình tham khảo về quản lý dự án của tổ chức PMI nhằm giải quyết các nhược điểm nhận dạng tại mục 3.4 Việc tham chiếu, bổ sung các hoạt động từ quy trình quản lý dự án PMI là bước đệm cho quá trình cải thiện toàn bộ quy trình quản lý kiểm thử cho ứng dụng phần mềm trong nhóm Control Manager mà không làm mất đi các đặc trưng của quy trình ISTQB trong lĩnh vực công nghệ phần mềm

Với quy trình quản lý dự án PMI, cũng bao gồm 5 quy trình riêng biệt (Initiating -> Planning -> Executing -> Monitoring -> Closing), các quy trình này đều có sự tương tác với nhau tương tự mô hình ISTBQ, tuy nhiên chúng ta có thể nhận thấy được tại mỗi quy trình đều có sự hỗ trợ tương tác từ phía khách hàng Đối với giai đoạn “Initiating”, giai đoạn này cần có bước liệt kê tất cả các bên liên quan đến dự án – “Stakeholders Management Strategy”, các bên liên quan là các tập thể hoặc cá nhân chịu ảnh hưởng từ kết quả của dự án như: nhà đầu tư, người dùng cuối, nhân viên lập trình, nhân viên kiểm thử, nhân viên hỗ trợ kỹ thuật, bộ phận quản lý Chính sự xác định rõ các bên liên quan này sẽ đảm bảo thông tin/ yêu cầu của dự án/ sản phẩm được rõ ràng, và thông suốt trong từng giai đoạn Các yêu cầu về chức năng có thể được phân tích kỹ càng, kịp thời xử lý đảm bảo việc ứng dụng mang lại tính thực tế cao nhất

23 Đối với giai đoạn “Monitoring and Controlling”, trong giai đoạn giám sát và điều khiển này, hoạt động đánh giá kết quả đầu ra được tuân theo các quy định chất lượng thông qua hoạt động đánh giá phạm vi chức năng - “Validate Scope”, bao gồm sự đánh giá từ phía khách hàng và nhận sự chấp thuận về chức năng của các bên liên quan trước khi tiếp tục thực thi chức năng tiếp theo

Hình 3-1: Quy trình quản lý dự án PMI [ 3 ]

MÔ HÌNH NGHIỆP VỤ BPMN

BPMN – “Business Process Model and Notation”; Mô hình hóa quy trình nghiệp vụ là phương pháp mô tả bằng hình vẽ, ký hiệu các chuỗi hoạt động trong quy trình nghiệp vụ Qua đó cung cấp một cách nhìn tổng quát về toàn bộ quy trình xử lý một nghiệp vụ và sự tương tác giữa các quy trình này để hoàn thành một nghiệp vụ doanh nghiệp

Mô hình BPMN nhằm làm rõ các câu hỏi như:

- Ai làm công việc này?

- Ai sẽ liên hệ với ai

- Luồng thông tin sẽ đi như thế nào?, …

Mục đích chính của mô hình BPMN là để cung cấp chuỗi các ký hiệu thể hiện cho một quy trình nhằm đơn giản hóa việc đọc hiểu bởi tất cả cá nhân có liên quan trong quy trình từ các nhà phân tích quy trình nghiệp vụ, cho đến các lập trình viên ứng dụng công nghệ cho việc thực hiện các quy trình đó và các cá nhân quản lý và giám sát quy trình Vì vậy, BPMN nhằm tạo một cầu nối cho khoảng cách hiểu về hệ thống/quy trình giữa quá trình thiết kế và thực thi nghiệp vụ [4] Một mục tiêu khác của BPNM và cũng không kém phần quan trọng, đó là đảm bảo ngôn ngữ XML được thiết kế cho việc thực thi quy trình nghiệp vụ như là WSBPEL (Web Service Business Process Execution Language), có thể được hình tượng hóa bằng các ký hiệu hướng nghiệp vụ

Việc mô hình hóa quy trình với BPMN có thể giúp phân tích chi tiết hơn về một quy trình nghiệp vụ doanh nghiệp, qua đó có thể hỗ trợ việc nhận dạng các yếu điểm, những vấn đề còn tồn tại trong quy trình doanh nghiệp từ đó đề ra giải pháp khắc phục hoặc cải tiến tốt hơn

Một số ký hiệu hoặc phương pháp mô tả như: UML Activity Diagram, UML EDOC Business Process, IDEF, ebXML BPSS, Activity-Decision Flow (ADF) Diagram, RosettaNet, LOVeM và Event-Process Chains (EPCs)

Các thành phần cơ bản trong BPMN:

 Flow objects: bao gồm các thành phần hình ảnh chính/chủ yếu để định nghĩa hành vi của quy trình nghiệp vụ như Event, Activities, Gateway

 Connecting object: là các đối tượng thể hiện mối quan hệ liên kết giữa các Flow Objects hoặc các thông tin khác như Sequence Flow, Message Flow, Data Assciation

 Swimlanes: tạo nhóm các thành phần mô hình cơ bản bằng 2 cách: Pool, Lanes

 Artifacts: được sử dụng để cung cấp thêm các thông tin chi tiết về quá trình như Text Annotation, Group

 Data Object: bao gồm Data Object, Data Input, Data Output, Data Stores

Chi tiết các thành phần trong BPMN được mô tả bởi bảng sau:

Thành phần Mô tả Ký hiệu

Event Là một sự kiện được xảy ra trong quy trình Sự kiện này thường tác động đến dòng quy trình và thông thường có một nguyên nhân/yêu cầu hoặc một sự ảnh hưởng Có 3 loại sự kiện: Start, Intermediate và End

Activitiy Là một hoạt động cho công việc mà công ty thực hiện trong một quy trình Các loại hoạt động: Sub-Process và Task

Gateway Được sử dụng để điều khiển sự phân bổ và hội tụ của một chuỗi tuần tự trong một quy trình Bao gồm: chia nhánh, kết hợp, hợp nhất

Sequence Flow Dòng tuần tự được sử dụng để thể hiện trật tự của các hoạt động sẽ được thực thi trong quy trình

Message Flow Thể hiện dòng thông tin truyền giữa hai Participants Association Dùng để liên kết thông tin và các Artifacts với các thành phần hình ảnh BPMN

Pool Là một thể hiện hình ảnh của một Participant Cũng có thể được xem là một “swimlane” và là một nhóm các hoạt

26 động được phân chia từ các Pool khác Một Pool có thể có thông tin chi tiết cho việc thực thi hoặc không có thông tin chi tiết

Lanes Là một phân vùng con trong một quy trình Lanes được dùng để tổ chức và phân loại các hoạt động

Data Object Cung cấp thông tin về các hoạt động cần để thực hiện hoặc được tạo ra Các Data object có thể được thể hiện bởi một đối tượng duy nhất hoặc một tập hợp các đối tượng

Message Được dùng để mô tả nội dung sự giao tiếp giữa hai Participants

Group Được dùng để nhóm các thành phần có chung đặc tính

Hoặc nhóm các thành phần cùng loại

Text Annotation Mô tả thêm thông tin trong lược đồ BPMN

Bảng 3-1: Bảng ký hiệu chung của mô hình BPMN [4]

Trong BPMN, một quy trình được miêu tả như một biểu đồ các yếu tố dòng sự kiện, là một tập các hoạt động, sự kiện, cổng (Gateway) và các chuỗi tuần tự được định nghĩa thực hiện theo một ý nghĩa nhất định BPMN sử dụng thuật ngữ quy trình để chỉ các yếu tố dòng chảy Một gói quy trình chứa đựng các lớp được dùng để mô hình hóa dòng hoạt động, sự kiện và cổng và các trật tự thực hiện trong một quy trình

Quy trình hóa nghiệp vụ là phương pháp được sử dụng để trao đổi các thông tin rộng lớn tới nhiều loại người tiếp nhận khác nhau BPMN được thiết kế với nhiều loại mô hình hóa và cho phép tạo ra các quy trình nghiệp vụ một cách chi tiết Có ba loại quy trình BPMN:

- Private Non-executable (internal) Business Process: là những quy trình nội bộ trong một tổ chức Các quy trình này thường được gọi là các dòng công việc hoặc quy trình BPM Là một quy trình riêng được mô hình cho mục đích lập tài liệu các hành vi của quy trình tại các mức độ chi tiết khác nhau

- Private Executable (internal) Business Process: là một quy trình được mô hình cho mục đích thực thi theo một ngữ nghĩa định nghĩa sẵn

- Public Process: thể hiện sự tương tác giữa quy trình nghiệp vụ riêng và quy trình khác hoặc bên tham gia

Các ký hiệu được sử dụng trong quy trình hóa nghiệp vụ:

Task - một đối tượng tác vụ chia sẻ cùng ký hiệu của quy trình con (Sub-Process)

Send Task – là một tác vụ đơn giản được thiết kế để gởi một Message đến một cá nhân liên quan đến quy trình Một khi Message được gởi, tác vụ được hoàn thành

Receive Task – là một tác vụ đơn giản được thiết kế để nhận một Message từ một cá nhân có liên quan đến quy trình Một khi Message được nhận, tác vụ được hoàn thành

Receive Task Object – đối tượng dùng để khởi tạo một quy trình sau khi nhận được một Message

Sub-Process – là một hoạt động có chứa các một chuỗi các hoạt động, cổng hoặc sự kiện khác Một Sub-Process là một đối tượng đồ họa trong một quy trình, có thể được mở rộng để thể hiện các hoạt động bên trong Đối tượng tác vụ với một ký hiệu lặp

Data Object – là đối tượng dữ liệu có thể xuất hiện nhiều lần trong một lược đồ quy trình Vòng đời của một đối tượng dữ liệu được gắn với vòng đời của quy trình hoặc quy trình con Khi một quy trình hoặc quy trình con được khởi tạo, thì tất cả đối tượng dữ liệu cũng sẽ được khởi tạo và sẽ bị hủy khi quy trình hoặc quy trình con bị hủy

DataStore – một bộ lưu trữ dữ liệu cung cấp một hệ thống nhận hoặc cập nhật thông tin lưu trữ của các hoạt động sau một quy trình

Data Associations – liên kết dữ liệu, được dùng để vận chuyển dữ liệu giữa các Data Object, các đặc tính và đầu ra/đầu ra của các hoạt động, các quy trình và các tác vụ

QUY TRÌNH KIỂM THỬ ISTQB TẠI NHÓM CONTROL MANAGER – CÔNG TY TMA SOLUTIONS

MANAGER – CÔNG TY TMA SOLUTIONS

Mô hình kiểm thử ISTQB được mô tả như hình 3-2 Mô hình này kiểm thử này bao gồm 5 hoạt động chính: a Test Planning and Control - Lập kế hoạch và điều khiển b Analysis & Design - Phân tích và thiết kế c Implementation and Execution - Triển khai và thực thi d Evaluation of Test Exit Criteria - Đánh giá các tiêu chí hoàn thành e Conclusion of Test by Test Closure Activities - Kết thúc quá trình kiểm thử Các hoạt động này có thể được áp dụng một cách tuần tự, cũng có thể trùng lắp hoặc xảy ra cùng lúc hoặc có thể được thay đổi chỉnh sửa tùy theo ngữ cảnh của hệ thống và dự án khi cần thiết, tạo sự linh hoạt trong mọi tình huống, đảm bảo tiến độ cũng như nguồn lực

Hình 3-2: Mô hình kiểm thử ISTQB [ 5 ]

Chi tiết của từng hoạt động được mô tả như sau: a Lập kế hoạch và điều khiển (Test Planning and Control): là hoạt động định nghĩa các mục tiêu của việc kiểm thử và các đặc tính của hoạt động kiểm thử theo một trật tự để đạt được các mục tiêu và sứ mệnh Điều khiển kiểm thử là một hoạt động xảy ra liên tục, xuyên suốt dự án để quan sát, thu thập dữ liệu của quá trình kiểm thử thực tế so với kế hoạch đề ra, cung cấp các báo cáo về trạng thái hoạt động, trạng thái công việc đang được tiến hành, bao gồm các sự sai lệch so với kế hoạch Hai hoạt động này liên quan đến các hành động cần thiết để đạt được sứ mệnh và mục tiêu của dự án b Phân tích và thiết kế (Analysis & Design): là hoạt động nhằm chuyển đổi các mục tiêu kiểm thử sang các điều kiện kiểm thử rõ ràng hơn và các trường hợp kiểm thử cụ thể Việc phân tích và thiết kế nhằm đảm bảo các tác vụ chính như: o Xem xét lại các thành phần cơ bản kiểm thử như yêu cầu kiểm thử, các cấp độ tích hợp phần mềm, báo cáo phân tích rủi ro, kiến trúc, thiết kế và các đặc tính về giao diện o Đánh giá khả năng có thể kiểm thử cho các thành phần kiểm thử và đối tượng kiểm thử

30 o Nhận dạng và đặt độ ưu tiên cho các điều kiện kiểm thử dựa trên sự phân tích các thành phần kiểm thử, đặc tính, hành vi và cấu trúc của phần mềm o Thiết kế và đặt độ ưu tiên cho các trường hợp kiểm thử o Nhận dạng các dữ liệu kiểm thử cần thiết để hỗ trợ các điều kiện kiểm thử và các trường hợp kiểm thử o Triển khai môi trường kiểm thử và nhận dạng các kiến trúc hạ tầng và công cụ cần cho quá trình kiểm thử o Tạo bảng thể hiện sự liên kết giữa các thành phần kiểm thử và các trường hợp kiểm thử c Triển khai và Thực thi (Implementation and Execution): là hoạt động mà các phương thức kiểm thử hoặc kịch bản kiểm thử được cụ thể hóa bởi việc kết hợp các trường hợp kiểm thử trong một trật tự nhất định và bao gồm bất cứ thông tin nào cần thiết cho việc thực thi kiểm thử Và môi trường kiểm thử được cài đặt, các trường hợp kiểm thử được thực thi Việc triển khai và thực thi bao gồm các tác vụ chính như: o Thống nhất, thực thi và đặt độ ưu tiên cho các trường hợp kiểm thử (bao gồm dữ liệu kiểm thử) o Phát triển và sắp đặt ưu tiên các phương thức kiểm thử, tạo dữ liệu kiểm thử và viết ra các kịch bản kiểm thử tự động o Tạo ra các nhóm trường hợp kiểm thử từ các phương thức kiểm thử để đạt được hiệu quả khi thực thi o Kiểm tra môi trường kiểm thử đã được cài đặt hoàn tất o Xác nhận và cập nhật bảng liên kết giữa các thành phần kiểm thử và các trường hợp kiểm thử o Thực thi các phương thức kiểm thử theo từng trường hợp kiểm thử hoặc sử dụng các công cụ thực thi kiểm thử dựa theo kết quả đã hoạch định o Lưu lại các kết quả kiểm thử và các đặc tả, phiên bản của phần mềm kiểm thử, công cụ kiểm thử o So sánh kết quả thực tế với kết quả hoạch định o Báo cáo sự khác biệt và phân tích theo trật tự để đưa ra các nguyên nhân có thể xảy ra: lỗi do code, do dữ liệu kiểm thử, tài liệu hoặc lỗi ở việc thực thi o Lặp lại các hoạt động kiểm thử theo những hành động để giải quyết mỗi sự khác biệt trên Ví dụ: Khi một lỗi do code được sửa chữa, thì

31 cần một hành động xác nhận lại lỗi sau khi được sữa chữa, để đảm bảo lỗi không còn lặp lại và không tạo ra lỗi mới d Đánh giá các tiêu chí hoàn thành (Evaluation of Test Exit Criteria): là hoạt động đánh giá việc thực thi kiểm thử so với các mục tiêu được đặt ra Việc đánh giá bao gồm các tác vụ chính như: o Kiểm tra các ghi chép trong quá trình kiểm thử so với điều kiện đầu ra được định nghĩa trong kế hoạch kiểm thử o Xem xét và đánh giá nếu cần phải thực thi thêm việc kiểm thử hoặc điều kiện đầu ra phải được thay đổi o Tổng hợp báo cáo kết quả kiểm thử cho các bên liên quan e Kết thúc quá trình kiểm thử (Conclusion of Test by Test Closure Activities): là hoạt động thu thập dữ liệu từ các hoạt động kiểm thử đã hoàn tất để tập hợp kinh nghiệm, các nhân tố, số liệu Hoạt động này có thể được thực hiện tại mỗi mốc của dự án như là khi hệ thống phần mềm được đưa ra khách hàng, hoặc khi một dự án kiểm thử được hoàn thành hoặc hủy bỏ, hoặc một mốc dự án được hoàn thành hoặc một phiên bản bảo trì được hoàn chỉnh Việc kết thúc một quá trình kiểm thử bao gồm các tác vụ chính sau: o Kiểm tra xem những yêu cầu của kế hoạch đã được hoàn thành o Kết thúc các lỗi ngẫu nhiên hoặc tạo những yêu cầu thay đổi cho tất cả những việc đang xảy ra o Ghi chép lại các điều kiện chấp thuận của hệ thống o Lưu giữ lại tình trạng của hệ thống, môi trường kiểm thử và các kiến trúc hạ tầng kiểm thử để sử dụng lại o Chuyển giao phần mềm kiểm thử đến bộ phận duy trì o Phân tích các bài học rút ra kinh nghiệm để quyết định những sự thay đổi cần thiết cho những phiên bản hoặc dự án tiếp theo o Tập hợp tất cả thông tin của dự án hiện tại để cải thiện quy trình sử dụng kiểm thử

Quy trình kiểm thử ISTBQ được chi tiết bằng BPMN như sau:

Hình 3-3: Quy trình kiểm thử ISTQB hiện tại của nhóm Control Manager bằng BPMN

ƯU VÀ NHƯỢC ĐIỂM CỦA QUY TRÌNH KIỂM THỬ HIỆN TẠI

Tuy việc ứng dụng chặt chẽ quy trình kiểm thử ISTBQ vào quá trình kiểm thử tại nhóm Contact Center, nhưng vẫn tồn tại một số lỗ hỏng – Test Escape khi sản phẩm phần mềm được chuyển giao đến người sử dụng như sau:

 Về mặt Chức năng: chưa hoàn thiện khả năng kiểm soát kiểm chứng (validation) giá trị input, thiếu log cho các chức năng trong quá trình hoạt động, một số tính năng còn bị giới hạn so với nhu cầu thực tế

 Về mặt Giao Diện: chưa được hoàn thiện: các nút chức năng như Thêm/Sửa/Sao Lưu hiển thị chưa hợp lý như sai vị trí, dư thừa

 Về Hiệu Suất hoạt động: hệ thống bị treo khi có hàng trăm kết nối truy cập cùng lúc vào hệ thống, một số giao diện xảy ra tình trạng treo sau một thời gian sử dụng

 Về mặt Bảo Mật: thiếu các chức năng khóa tài khoản khi truy cập sai phép, chưa hỗ trợ các chuẩn bảo mật mới HTTPS/TLS v1.2, các giao thức mã hóa chưa được áp dụng, các nhu cầu về độ phức tạp của mật khẩu truy cập hệ thống và dữ liệu chưa được kiểm chứng

Với thời gian ứng dụng quy trình kiểm thử phần mềm chuẩn ISTQB cùng với những kết quả đạt được qua từng dự án có thể nhận thấy được những ưu điểm và nhược điểm của quy trình này như sau: Ưu Điểm Nhược Điểm Đảm bảo tất cả các yêu cầu của sản phẩm được kiểm tra đầy đủ

Quy trình khép kín, thiếu sự tương tác với các cập nhật về mặt kỹ thuật, công nghệ Đảm bảo các hoạt động/ tác vụ kiểm thử được triển khai đầy đủ

Chưa đảm bảo tính thực tiễn của sản phẩm

Nhận dạng được các giới hạn và rủi ro có thể có trong quá trình kiểm thử

Chậm trong việc đáp ứng khi có thay đổi về yêu cầu

Nhận dạng được tất cả các nguồn tài nguyên (con người, dữ liệu, phần cứng, phần mềm, ) cần thiết

Các điều kiện chấp thuận cho sản phẩm được đảm bảo trước khi triển khai thực tế

Kịp thời khắc phục những vấn đề về chức năng hoặc phương thức triển khai của sản phẩm

QUY TRÌNH CẢI TIẾN

Từ quy trình kiểm thử ISTQB hiện tại, để thực hiện việc cải tiến quy trình đánh giá kiểm thử tại nhóm Control Manager, đề xuất mô hình quy trình mới như sau:

Hình 3-4: Quy trình cải tiến về kiểm thử phần mềm tại nhóm Control Manager

Theo như quy trình cải tiến được mô tả từ hình 3-4 và hình 3-5, việc cải tiến hướng đến việc bổ sung một số hoạt động được nêu ở giai đoạn “Initiating” và “Monitoring and Controlling” trong quy trình quản lý dự án PMI; cụ thể ứng dụng lại cho hai giai đoạn Lập kế hoạch và Đánh giá các điều kiện đầu ra của mô hình kiểm thử ISTQB Việc lựa chọn cập nhật cho hai giai đoạn này dự kiến sẽ giải quyết được các khuyết điểm hiện tại được nêu tại mục 3.4

Hình 3-5: Quy trình kiểm thử cải tiến bằng BPMN ** C ác h o ạ t độ ng c ả i ti ế n tr on g q uy t rìn h

Thứ nhất là về giai đoạn Lập kế hoạch: sơ khởi đây là giai đoạn rất quan trọng để định hướng chiến lược thực thi cho cả dự án, quyết định sự thành công của cả dự ám Nếu việc lập kế hoạch không đáp ứng đúng và đủ mọi yêu cầu của dự án, cộng với chiến lược thực thi sai, mục tiêu của dự án chưa được xác định một cách chính xác… Tất yếu, sẽ dẫn đến thất bại Chính vì vậy, giai đoạn này cần được tập trung làm rõ Các hoạt động được bổ sung như sau:

(1) Xác định người dùng trực tiếp: việc xác định đúng người sử dụng sẽ giúp làm rõ yêu cầu chức năng một cách chính xác hơn Lỗi sản phẩm xuất hiện khi các chức năng được yêu cầu bởi những cá nhân không trực tiếp sử dụng sản phẩm thì sẽ dẫn đến sự không đồng bộ/ sai tính năng trong quá trình sử dụng Một ví dụ cụ thể như: trong một sản phẩm ứng dụng về một yêu cầu thiết kế phần mềm xử lý kế toán, thông thường dữ liệu nhập vào là những con số, tuy nhiên khi một kế toán viên sử dụng phần mềm này, họ sẽ có thêm yêu cầu về việc chèn các hàm hoặc công thức để lấy ra một kết quả từ một bảng nào đó và trở thành đầu vào cho một phép tính kế toán Tuy nhiên sản phẩm ban đầu chỉ đáp ứng việc nhập liệu bằng con số Và trong quá trình kiểm thử, yêu cầu về việc nhập liệu số cũng sẽ được kiểm chứng nhưng lại thiếu việc kiểm tra hàm công thức đầu vào Chính vì vậy, sai sót ở đây là sự thiếu rõ ràng trong chức năng của sản phẩm, làm cho sản phẩm ứng dụng chưa đáp ứng đúng với nhu cầu của người sử dụng Do đó, hoạt động xác định đúng người dùng trực tiếp sẽ giúp cho việc lập trình chính xác cũng như chiến lược kiểm thử được đặt ra phù hợp với mục tiêu chức năng của ứng dụng

(2) Xác định lưu lượng thực tế cho các chức năng sản phẩm: trong môi trường thực tế cần xác định rõ nhu cầu về: số lượng truy cập hàng giờ/ hàng ngày đối với một ứng dụng để đảm bảo tính sẵn sàng của sản phẩm cũng như khả năng đáp ứng của ứng dụng đối với một lượng lớn truy cập/yêu cầu xử lý từ bên ngoài Một ví dụ cụ thể: khi phát triển hoặc kiểm thử một ứng dụng Voice over IP được triển khai cho một ngân hàng – một dạng sản phẩm cần có tính sẵn sàng và đáp ứng cao, thì đòi hỏi kiểm thử viên phải nắm rõ nhu cầu truy cập vào ứng dụng này theo giờ hoặc theo ngày để đưa ra chiến lược kiểm tra phù hợp để đáp ứng nhu cầu thực tế hoạt động tại ngân hàng trên và phải đảm bảo chất lượng cuộc gọi luôn rõ ràng Trong một số trường hợp, chúng ta cần phải xác định được mức tối đa số lượng cuộc gọi mà ứng dụng có thể đáp ứng đồng thời và vẫn đảm bảo chất lượng cuộc gọi Tương tự, cho một ứng dụng Web, đòi hỏi phải xác định rõ số lượng truy cập vào Web page theo giờ/theo ngày, và số lượng truy vấn dữ liệu theo thời gian tối đa được cho phép xử lý của ứng dụng Từ các ví dụ trên, ta nhận thấy việc xác định lưu

37 lượng thực tế cho sản phẩm nói chung và cho mỗi chức năng nói riêng có vai trò quan trọng cho việc đảm bảo chất lượng sản phẩm , đảm bảo lòng tin của khách hàng đối với nhà phát triển phẩm, tránh được các chi phí không đáng có do trì trệ, không sẵn sàng trong quá trình hoạt động của sản phẩm ứng dụng (3) Tìm hiểu các ứng dụng công nghệ về bảo mật tại môi trường triển khai: việc kiểm thử cần xác định rõ các quy trình về bảo mật dữ liệu tại môi trường triển khai sản phẩm như tường lửa, các ứng dụng chặn port, quản lý dữ liệu ra vào đang được ứng dụng tại môi trường triển khai Ví dụ về việc không tương thích với công nghệ bảo mật tại môi trường triển khai: đối với một sản phẩm Web chuyên về quản lý và phân chia tài nguyên cho các hệ thống cung cấp tính năng Voice over IP, thì việc truy cập vào Web page để thực hiện các tác vụ quản lý thông thường qua HTTPS – một giao thức truy cập Web bảo mật, tuy nhiên trong môi trường triển khai sản phẩm, đòi hỏi việc truy cập phải đảm bảo bằng giao thức mã hóa HTTP với TLS v1.2 Điều đó dẫn đến tình huống truy cập với TLS v1.2 sẽ không thực hiện được khi triển khai, gây ra chi phí phát sinh để cập nhật hỗ trợ giao thức theo yêu cầu của môi trường thực tế Từ đó, để đảm bảo chất lượng sản phẩm và thỏa mãn các yếu tố bảo mật liên quan đến ứng dụng, thì việc tìm hiểu kỹ các công nghệ bảo mật dữ liệu đang được áp dụng tại môi trường triển khai là cần thiết để tránh phát sinh những chi phí không đáng có cho việc cập nhật/ phát triển lại phần mềm

(4) Tổ chức huấn luyện và xem xét lại các bài học kinh nghiệm từ những dự án kiểm thử trước: hoạt động này nhằm xem xét lại những bài học kinh nghiệm có được từ những dự án đã xảy ra, là một nguồn tài nguyên vô giá giúp giảm thiểu những lỗi lặp đi lặp lại, qua đó cải thiện quy trình kiểm thử ngày một tốt hơn nhằm hạn chế tối đa chi phí phát sinh cho sản phẩm ứng dụng Ví dụ như: từ bài học rút ra từ việc kiểm tra sai giao thức bảo mật HTTPS ở trên, thì chúng ta sẽ tăng phạm vi kiểm thử cho các dự án tiếp theo, đảm bảo giao thức HTTPS với TLS v1.2 được kiểm tra đầy đủ trước khi triển khai tại môi trường thực tế Bên cạnh đó, hoạt động này còn nhằm cập nhật, nâng cấp kiến thức mới cho kiểm thử viên; ví dụ như tạo các khóa huấn luyện/ chia sẻ kiến thức về giao thức bảo mật cho kiểm thử viên, giúp họ nắm rõ cách thức hoạt động của giao thức bảo mật để có thể ứng dụng đúng đắn trong quá trình kiểm thử Trong hoạt động này, cũng bao gồm việc nghiên cứu, triển khai/ ứng dụng các kỹ thuật, lựa chọn các công cụ mới phù hợp với sản phẩm kiểm thử, giúp cho quá trình kiểm thử được giản đơn hơn ví dụ như các công cụ kiểm thử tự động – Automation tool, nhằm giảm bớt công sức cho kiểm thử viên nhưng vẫn đảm bảo chất lượng của sản phẩm ứng dụng

Thứ hai là về giai đoạn Đánh giá các tiêu chí hoàn thành: hoạt động đánh giá này nhằm đảm bảo sản phẩm ứng dụng đáp ứng đầy đủ các tiêu chí cần thiết của dự án trước khi đưa ra môi trường triển khai thực tế Một số tiêu chí đánh giá mức độ hoàn thành của sản phẩm như: số lượng lỗi hiện có nằm trong mức độ cho phép (mức độ chấp nhận được), không tồn tại những lỗi trầm trọng gây ảnh hưởng đến các chức năng chính của sản phẩm; tất cả các tính năng của sản phẩm đã được kiểm tra và chấp thuận; đáp ứng đầy đủ các yêu cầu về vận hành, tính sẵn sàng và bảo mật Một số hoạt động bổ sung cho giai đoạn này như sau:

(5) Cần có sự tham gia của người dùng trực tiếp: việc khuyến khích sự tham gia của người dùng trực tiếp nhằm đảm bảo sản phẩm ứng dụng hoạt động chính xác theo đúng yêu cầu ban đầu Trường hợp có những thiếu sót được phát hiện sớm sẽ được giải quyết trước khi triển khai thực tế, tránh những tổn thất không đáng có

(6) Cần có sự tham gia, đánh giá của các chuyên gia/kỹ thuật từ phía khách hàng: với sự tham gia đánh giá của các chuyên gia/kỹ thuật từ phía khách hàng nhằm đảm bảo sản phẩm ứng dụng được phát triển theo đúng kiến trúc đề ra, ứng dụng đầy đủ các tính năng bảo mật, tính khả thi khi triển khai thực tế.

ĐÁNH GIÁ MÔ HÌNH CẢI TIẾN

Với mục tiêu cải tiến quy trình kiểm thử hiện tại hướng đến việc nâng cao chất lượng phần mềm và giảm chi phí trong thời gian bảo trì, đề tài chọn phương pháp khảo sát, thu thập ý kiến từ bộ phận quản lý dự án và các nhân viên kiểm thử trực tiếp làm việc trên quy trình kiểm thử ISTQB để đánh giá quy trình cải tiến mới nhằm đảm bảo các tiêu chí sau:

 Về chất lượng: nâng cao khả năng hài lòng của khách hàng cho từng sản phẩm thông qua việc đảm bảo đúng và chính xác các yêu cầu chức năng thực tế được cung cấp bởi phần mềm ứng dụng

 Về chi phí: nâng cao hiệu quả về mặt chi phí cho quy trình sản xuất và vận hành phần mềm – các chi phí phát sinh khi lỗi xảy ra như thời gian phân tích những lỗi/sai sót, thời gian thực hiện lại coding, thời gian kiểm thử lại để đảm bảo các lỗi phần mềm được xử lý thỏa đáng và không phát sinh những lỗi mới, và các chi phí liên quan đến hoạt động kinh doanh của doanh nghiệp khi gặp sự cố về phần mềm

 Về tài nguyên con người: nâng cao khả năng sử dụng hiệu quả nguồn tài nguyên con người, tránh những phát sinh về yêu cầu thêm nhân lực để sửa lỗi hoặc phục vụ cho việc triển khai lại hệ thống

 Về mặt chiến lược quản lý: cấp quản lý có thể nắm rõ và chính xác các yêu cầu cần thiết của phần mềm để có thể hoạch định rõ công việc cho các giai đoạn của dự án phần mềm, giảm thiểu chi phí quản lý khi vấn đề xảy ra

3.6.1 Mô hình đánh giá đề xuất

Với mục tiêu chính của một quy trình kiểm thử là đảm bảo chất lượng phần mềm, trong đó việc đảm bảo chất lượng phần mềm lại là chức năng chủ chốt của quản lý chất lượng Chất lượng ở đây bao gồm chất lượng sản phẩm và chất lượng dự án, trong đó chất lượng sản phẩm là phải đảm bảo phần mềm hoạt động theo đúng nhu cầu và mong đợi của người dùng, còn chất lượng dự án là phải đảm bảo mang lại một sản phẩm yêu cầu thỏa mãn một phạm vi được thỏa thuận, đúng thời hạn và không bị vượt quá khoản chi phí dự định Việc đảm bảo chất lượng dự án sẽ được quyết định bởi hoạt động quản lý nguồn nhân lực và kiểm soát chi phí trong suốt quá trình kiểm thử [16] Chính vì vậy, bài luận hướng đến việc đánh giá tác động của các hoạt động bổ sung ứng với các tiêu chí nêu trên cho chất lượng, chi phí, tài nguyên con người và về mặt quản lý trong quy trình kiểm thử phần mềm tại nhóm Control Manager như hình 3-6

Hình 3-6: Mô hình nghiên cứu đề xuất

Cụ thể các giả thuyết đặt ra như sau:

Xác đị nh ng ườ i dùng tr ự c ti ế p:

H1a – Hoạt động xác định người dùng trực tiếp sẽ tác động đến chất lượng của quy trình kiểm thử phần mềm

H1b – Hoạt động xác định người dùng trực tiếp sẽ tác động đến chi phí của quy trình kiểm thử phần mềm

H1c – Hoat động xác định người dùng trực tiếp sẽ tác động đến việc phân bổ tài nguyên và nhân lực trong quy trình kiểm thử phần mềm

H1d – Hoạt động xác định người dùng trực tiếp sẽ tác động đến chiến lược quản lý trong quy trình kiểm thử

Xác đị nh l ư u l ượ ng ho ạ t độ ng th ự c t ế c ủ a ph ầ n m ề m:

H2a – Hoạt động xác định lưu lượng hoạt động thực tế của phần mềm tác động đến chất lượng của quy trình kiểm thử phần mềm

H2b – Hoạt động xác định lưu lượng hoạt động thực tế của phần mềm tác động đến chi phí của quy trình kiểm thử phần mềm

H2c – Hoạt động xác định lưu lượng hoạt động thực tế của phần mềm tác động đến việc phân bổ tài nguyên và nhân lực trong quy trình kiểm thử phần mềm

H2d – Hoạt động xác định lưu lượng hoạt động thực tế của phần mềm tác động đến chiến lược quản lý trong quy trình kiểm thử

Xác đị nh các nhu c ầ u công ngh ệ và b ả o m ậ t c ủ a ph ầ n m ề m:

H3a – Hoạt động xác định các nhu cầu công nghệ và bảo mật của phần mềm sẽ tác động đến chất lượng của quy trình kiểm thử phần mềm

H3b - Hoạt động xác định các nhu cầu công nghệ và bảo mật của phần mềm sẽ tác động đến chi phí của quy trình kiểm thử phần mềm

H3c - Hoạt động xác định các nhu cầu công nghệ và bảo mật của phần mềm sẽ tác động đến việc phân bổ tài nguyên và nhân lực trong quy trình kiểm thử phần mềm

H3d - Hoạt động xác định các nhu cầu công nghệ và bảo mật của phần mềm sẽ tác động đến chiến lược quản lý trong quy trình kiểm thử

T ổ ch ứ c hu ấ n luy ệ n và xem xét đ út rút kinh nghi ệ m t ừ các d ự án c ũ :

H4a – Hoạt động tổ chức huấn luyện và xem xét đút rút kinh nghiệm từ các dự án cũ sẽ tác động đến chất lượng của quy trình kiểm thử phần mềm

H4b – Hoạt động tổ chức huấn luyện và xem xét đút rút kinh nghiệm từ các dự án cũ sẽ tác động đến chi phí của quy trình kiểm thử phần mềm

H4c – Hoạt động tổ chức huấn luyện và xem xét đút rút kinh nghiệm từ các dự án cũ sẽ tác động đến việc phân bổ tài nguyên và nhân lực trong quy trình kiểm thử phần mềm

H4d – Hoạt động tổ chức huấn luyện và xem xét đút rút kinh nghiệm từ các dự án cũ sẽ tác động đến chiến lược quản lý trong quy trình kiểm thử phần mềm

Nhu c ầ u tham gia c ủ a ng ườ i dùng tr ự c ti ế p:

H5a – Hoạt động về nhu cầu tham gia của người dùng trực tiếp sẽ tác động đến chất lượng của quy trình kiểm thử phần mềm

H5b – Hoạt động về nhu cầu tham gia của người dùng trực tiếp sẽ tác động đến chi phí của quy trình kiểm thử phần mềm

H5c – Hoạt động về nhu cầu tham gia của người dùng trực tiếp sẽ tác động đến việc phân bổ tài nguyên và nhân lực trong quy trình kiểm thử phần mềm

H5d – Hoạt động về nhu cầu tham gia của người dùng trực tiếp sẽ tác động đến chiến lược quản lý trong quy trình kiểm thử phần mềm

Nhu c ầ u tham gia, đ ánh giá c ủ a các chuyên gia/k ỹ thu ậ t t ừ phía khách hàng:

H6a – Hoạt động về nhu cầu tham gia, đánh giá của các chuyên gia/kỹ thuật từ phía khách hàng sẽ tác động đến chất lượng của quy trình kiểm thử

H6b – Hoạt động về nhu cầu tham gia, đánh giá của các chuyên gia/kỹ thuật từ phía khách hàng sẽ tác động đến chi phí của quy trình kiểm thử phần mềm

KẾT QUẢ ĐÁNH GIÁ QUY TRÌNH CẢI TIẾN

KẾT QUẢ NGHIÊN CỨU SƠ BỘ ĐỊNH TÍNH

Thông qua các buổi trình bày về mục đích và nội dung nghiên cứu, các kết luận định tính thu thập được từ các ý kiến nảy sinh trong cuộc trình bày/thảo luận như sau:

 95% các ý kiến thảo luận là đồng ý về khả năng tác động của các hoạt động bổ sung có tác động cải thiện quy trình kiểm thử và cải thiện chất lượng phần mềm sau kiểm thử

 5% các ý kiến thảo luận yêu cầu làm rõ phương pháp đàm phán để đạt được sự đồng ý từ các bên có liên quan (Khách Hàng, Bộ phận quản lý phát triển phần mềm, bộ phận quản lý kiểm thử) về việc thay đổi quy trình

 Các ý kiển thảo luận là hoàn toàn đồng ý về mức độ hiệu quả của hoạt động xem xét và đút rút kinh nghiệm từ các dự án cũ Hoạt động này sẽ giúp tăng tính hiệu quả quản lý, dự đoán rủi ro cũng như từng bước cải thiện chất lượng quy trình, bổ sung kinh nghiệm cho các kiểm thử viên Hoạt động này nên được thực hiện thường xuyên cho mỗi dự án hoặc khi hoàn thành một cột mốc quan trọng trong dự án

 Các ý kiến thảo luận còn mang tính nghi ngờ về giá trị mang lại của hoạt động về nhu cầu tham gia của người dung trực tiếp (end-user) trong suốt quá trình kiểm thử của kiểm thử viên Điều này có thể không mang lại hiệu quả cao và không đảm bảo các bước của quy trình kiểm thử được tuân thủ, cũng như không đảm bảo các ràng buộc về phạm vi, thời hạn (deadline) đưa ra thị trường của phần mềm Đề xuất: Nên thực hiện các buổi demo trực tiếp và lấy ý kiến sau mỗi giai đoạn kiểm thử cho từng nhóm các chức năng phần mềm sau mỗi mốc giai đoạn

KẾT QUẢ NGHIÊN CỨU ĐỊNH LƯỢNG CHÍNH THỨC

4.2.1 Kết quả thống kê về các đối tượng tham gia khảo sát Đối Tượng Số Lượng Tỷ Lệ (%)

Quản lý dự án 8 2.7 Quản lý nhóm 22 7.4

Tư vấn kỹ thuật 17 5.7 Kiểm thử viên 252 84.3

Bảng 4-1: Bảng thống kê về đối tượng khảo sát

Theo thống kê ở bảng trên:

 Các đối tượng quản lý dự án là các cá nhân phụ trách về công việc tìm hiểu yêu cầu dự án, quyết định chiến lược, lập lịch, theo dõi tiến độ dự án, giải quyết các vấn đề nhân lực, định mức chi phí và có trách nhiệm liên lạc và cập nhật tình trạng dự án cho các bên liên quan Đối tượng này chiếm 2.7% số người khảo sát

 Quản lý nhóm là các cá nhân phụ trách về công việc tìm hiểu chi tiết yêu cầu dự án, đề xuất phạm vi và kế hoạch thực hiện dự án, theo dõi tiến độ, giải quyết và hỗ trợ các vấn đề kỹ thuật trong suốt quá trình kiểm thử, báo cáo chi tiết tiến độ dự án, tham gia vào hoạt động kiểm thử của dự án Đối tượng Quản lý nhóm chiếm 7.4% số người khảo sát

 Tư vấn kỹ thuật là các cá nhân phụ trách về yếu tố kỹ thuật trong dự án, thực hiện các trao đổi, huấn luyện và nâng cao kiến thức về kỹ thuật cho các kiểm thử viên, giải quyết các vấn đề đòi hỏi chuyên sâu về kỹ thuật, tham gia vào hoạt động kiểm thử của dự án Bộ phận tư vấn kỹ thuật chiếm 5.7% số lượng khảo sát

 Kiểm thử viên là các cá nhân thực thi các trường hợp kiểm thử để kiểm định phần mềm, tìm và theo dõi các lỗi của phần mềm, theo dõi quá trình chỉnh sửa, cập nhật phần mềm Đối tượng kiểm thử viên chiếm đa số, đạt 84.3% số lượng khảo sát

Trong bài khảo sát, các thang đo được mã hóa bằng các ký hiệu, trong đó:

- Thang đo Xác định người dùng trực tiếp được đo lường bằng biến quan sát từ XD_NGUOIDUNG1 -> XD_NGUOIDUNG5

- Thang đo Xác định lưu lượng thực tế cho các chức năng của phần mềm được đo lường bằng 4 biến quan sát từ LUULUONG1 -> LUULUONG4

- Thang đo Tìm hiểu công nghệ/bảo mật tại môi trường triển khai được đo lường bằng 3 biến quan sát từ CN_BAOMAT1 -> CN_BAOMAT3

- Thang đo Tổ chức huấn luyện và xem xét kinh nghiệm từ các dự án trước được đo lường bằng 4 biến quan sát từ HUANLUYEN1 -> HUANLUYEN4

- Thang đo Sự tham gia cộng tác từ người dùng cuối được đo lường bằng 3 biến quan sát từ TG_NGUOIDUNG1 -> TG_NGUOIDUNG3

- Thang đo Sự tham gia của các chuyên gia kỹ thuật của khách hàng được đo lường bằng 3 biến quan sát từ TG_CHUYENGIA1 -> TG_CHUYENGIA3

- Thang đo Chất lượng sản phẩm được đo lường bằng 3 biến quan sát từ CHATLUONG1 -> CHATLUONG3

- Thang đo Chi phí được đo lường bằng 3 biến quan sát từ CHIPHI1 -> CHIPHI3

- Thang đo về phân bổ tài nguyên nhân lực được đo lường bằng 3 biến quan sát từ TAINGUYEN1 -> TAINGUYEN3

- Thang đo về chiến lượng quản lý được đo lường bằng 3 biến quan sát từ QUANLY1 -> QUANLY3

Các thang đo được đánh giá thông qua hai công cụ chính là: Hệ số tin cậy Cronbach’s Alpha và Phương pháp phân tích nhân tố khám phá EFA Việc đánh giá thông qua các hệ số Cronbach’s Alpha được dùng để loại bỏ các biến không phù hợp Các biến số có hệ số tương quan tổng nhỏ hơn 0.3 sẽ bị loại và tiêu chuẩn chọn thang đo khi nó có hệ số tin cậy từ 0.6 trở lên (Nunnally & Burnstein, 1994)

Tiếp theo phương pháp phân tích nhân tố khám phá EFA được sử dụng với việc loại bỏ các biến có nhân tố tải nhỏ hơn 0.4 (Gerbing & Anderson, 1988) Và điểm dừng khi trích các yếu tố có Eigenvalue lớn hơn hoặc bằng 1 Thang đo được chấp nhận khi tổng phương sai trích bằng hoặc lớn hơn 50% (Gerbing & Anderson, 1988)

4.2.2 Kết quả phân tích hệ số tin cậy Cronbach’s Alpha

Biến quan sát Trung bình thang đo nếu loại biến

Phương sai thang đo nếu loại biến

Cronbach’s Alpha nếu loại biến này

Xác định người dùng trực tiếp: Cronbach’s Alpha = 692

Xác định lưu lượng thực tế cho các chức năng của phần mềm: Cronbach’s

Tìm hiểu ứng dụng công nghệ/ bảo mật tại môi trường triển khai:

Tổ chức huấn luyện và xem xét kinh nghiệm từ các dự án trước: Cronbach’s

Sự tham gia cộng tác từ người dùng cuối: Cronbach’s Alpha = 832

Sự tham gia của các chuyên gia kỹ thuật của khách hàng: Cronbach’s Alpha

Phân bổ tài nguyên nhân lực: Cronbach’s Alpha = 840

Chiến lược quản lý: Cronbach’s Alpha = 351

Bảng 4-2: Bảng kết quả phân tích Cronbach’s Alpha

Từ kết quả phân tích Cronbach’s Alpha trên bảng 4.2.2.1 cho thấy hệ số tương quan biến tổng của các biến quan sát XD_NGUOIDUNG5 (0.108), LUULUONG2 (0.036), HUANLUYEN4 (0.097), TG_CHUYENGIA2 (0.139) và QUANLY1 (0.046) nhỏ hơn 0.3 nên sẽ bị loại

Sau khi loại 5 biến quan sát không phù hợp ở trên, chạy lại phân tích Cronbach’s Alpha, kết quả như sau:

Biến quan sát Trung bình thang đo nếu loại biến

Phương sai thang đo nếu loại biến

Cronbach’s Alpha nếu loại biến này

Xác định người dùng trực tiếp: Cronbach’s Alpha = 833

Xác định lưu lượng thực tế cho các chức năng của phần mềm: Cronbach’s

Tìm hiểu ứng dụng công nghệ/ bảo mật tại môi trường triển khai:

Tổ chức huấn luyện và xem xét kinh nghiệm từ các dự án trước: Cronbach’s

Sự tham gia cộng tác từ người dùng cuối: Cronbach’s Alpha = 832

Sự tham gia của các chuyên gia kỹ thuật của khách hàng: Cronbach’s Alpha

Phân bổ tài nguyên nhân lực: Cronbach’s Alpha = 840

Chiến lược quản lý: Cronbach’s Alpha = 721

Bảng 4-3: Bảng kết quả phân tích Cronbach’s Alpha sau khi loại biến không phù hợp

Kết quả Cronbach’s Alpha cho thấy các thang đo đều đạt độ tin cậy Cronbach’s Alpha của các thang đo đều từ 0.6 trở lên, nhỏ nhất là của thang đo Chiến lược quản lý là 721 và cao nhất là Tổ chức huấn luyện và xem xét kinh nghiệm từ các dự án trước là 936

Các hệ số tương quan biến tổng đều đạt yêu cầu từ 0.3 trở lên Trong đó, hệ số tương quan biến tổng nhỏ nhất là biến QUANLY2=QUANLY3=.564

4.2.3 Kết quả phân tích nhân tố khám phá EFA

Bảng 4-4: Bảng kết quả phân tích KMO

Hệ số KMO = 0.891 > 0.05: phân tích nhân tố thích hợp với dữ liệu nghiên cứu Kết quả kiểm định Bartlett’s là 6232.277 với mức ý nghĩa Sig = 0.000 < 0.05, (bác bỏ giả thuyết H0: các biến quan sát không có tương quan với nhau trong tổng thể), như vậy giả thuyết về mô hình nhân tố là không phù hợp và sẽ bị bác bỏ, điều này chứng tỏ dữ liệu dùng đề phân tích là hoàn toàn phù hợp

Theo kết quả bảng 4-5, tổng phương sai trích: 69.353 % > 50% nên sẽ đạt yêu cầu Tương ứng 7 nhân tố này giải thích được 69.353 % biến thiên của dữ liệu

Hệ số Eigenvalue 1.096 >1 nên sẽ có 7 nhân tố được xét

Bảng 4-5: Bảng tổng phương sai trích

Bảng 4-6: Ma trận mẫu với phương pháp Principal Axis Factoring và Phép quay Promax

Với kết quả từ ma trận mẫu ở bảng 4-6, nhận thấy có một nhân tố giải thích được nhiều biến như nhân tố 1 giải thích được cho TG_NGUOIDUNG và XD_NGUOIDUNG; nhân tố 2 giải thích được cho CN_BAOMAT và TG_CHUYENGIA; nhân tố 3 giải thích được cho TAINGUYEN và QUANLY

Vì vậy, mô hình nghiên cứu đề xuất cần được hiểu chỉnh Việc hiệu chỉnh sẽ được thực hiện bằng phương pháp gộp biến, các biến gộp như sau: XD_NGUOIDUNG và TG_NGUOIDUNG => NGUOI DUNG; CN_BAOMAT và TG_CHUYENGIA => NHUCAU_CN_BM; TAINGUYEN và QUANLY => NHANLUC_QUANLY

Mô hình đánh giá hiệu chỉnh như sau:

Hình 4-1: Mô hình đánh giá hiệu chỉnh

Các giả thuyết của mô hình đánh giá hiệu chỉnh:

Xác đị nh ng ườ i dùng tr ự c ti ế p:

H1a – Hoạt động xác định người dùng trực tiếp sẽ tác động đến chất lượng của quy trình kiểm thử phần mềm

H1b – Hoạt động xác định người dùng trực tiếp sẽ tác động đến chi phí của quy trình kiểm thử phần mềm

H1c – Hoạt động xác định người dùng trực tiếp sẽ tác động đến việc quản lý trong quy trình kiểm thử

Xác đị nh l ư u l ượ ng ho ạ t độ ng th ự c t ế c ủ a ph ầ n m ề m:

H2a – Hoạt động xác định lưu lượng hoạt động thực tế của phần mềm tác động đến chất lượng của quy trình kiểm thử phần mềm

H2b – Hoạt động xác định lưu lượng hoạt động thực tế của phần mềm tác động đến chi phí của quy trình kiểm thử phần mềm

H2c – Hoạt động xác định lưu lượng hoạt động thực tế của phần mềm tác động

60 đến việc quản lý trong quy trình kiểm thử

T ổ ch ứ c hu ấ n luy ệ n, xem xét đ út rút kinh nghi ệ m t ừ d ự án c ũ

H3a – Hoạt động tổ chức huấn luyện, xem xét đút rút kinh nghiệm từ dự án cũ của phần mềm tác động đến chất lượng của quy trình kiểm thử phần mềm

H3b – Hoạt động tổ chức huấn luyện, xem xét đút rút kinh nghiệm từ dự án cũ của phần mềm tác động đến chi phí của quy trình kiểm thử phần mềm

H3c – Hoạt động tổ chức huấn luyện, xem xét đút rút kinh nghiệm từ dự án cũ tác động đến việc quản lý trong quy trình kiểm thử

H4a – Hoạt động tìm hiểu nhu cầu bảo mật của phần mềm tác động đến chất lượng của quy trình kiểm thử phần mềm

H4b – Hoạt động tìm hiểu nhu cầu bảo mật của phần mềm tác động đến chi phí của quy trình kiểm thử phần mềm

H4c – Hoạt động tìm hiểu nhu cầu bảo mật của phần mềm tác động đến việc quản lý trong quy trình kiểm thử

4.2.4 Kết quả phân tích nhân tố khẳng định CFA

Hình 4-2: Kết quả phân tích nhân tố khẳng định

Với kết quả phân tích ở hình 4-2 cho thấy các chỉ số CFI = 0.978, TLI = 0.975, GFI = 0.902 đều nằm trong khoảng 0.9-1 và RMSEA = 0.036, suy ra mô hình này phù hợp với dữ liệu thị trường [2]

Bảng 4-7: Bảng giá trị hệ số tin cậy tổng hợp và phương sai trích

Hệ số tin cậy và phương sai trích sẽ được tính toán dựa trên giá trị Standardized Regression Weight của kết quả phân tích CFA Với kết quả ở bảng 4-7, cho thấy các chỉ tiêu đánh giá là hệ số tin cậy tổng hợp (Composite reliability) CR đều lớn hơn 0.8 và tổng phương sai trích (Variance extracted) lớn hơn >0.5

4.2.5 Kết quả phân tích mô hình cấu trúc tuyến tính SEM

Hình 4-3: Mô hình cấu trúc tuyến tính SEM

NHANLUC_QUANLY < - NHUCAU_CN_BM 338 062 5.406 ***

CN_BAOMAT2 < - NHUCAU_CN_BM 1.000

TG_CHUYENGIA1 < - NHUCAU_CN_BM 877 042 20.938 ***

CN_BAOMAT3 < - NHUCAU_CN_BM 943 049 19.260 ***

TG_CHUYENGIA3 < - NHUCAU_CN_BM 893 055 16.376 ***

CN_BAOMAT1 < - NHUCAU_CN_BM 852 054 15.809 ***

Bảng 4-8: Bảng giá trị mô hình cấu trúc tuyến tính SEM

Từ kết quả bảng 4-8, nhận thấy có 7 giả thuyết được chấp nhận với P value <

0.05 và 5 giả thuyết bị bác bỏ

H1a Hoạt động xác định người dùng trực tiếp sẽ tác động đến chất lượng của quy trình kiểm thử phần mềm

H1b Hoạt động xác định người dùng trực tiếp sẽ tác động đến chi phí của quy trình kiểm thử phần mềm

H1c Hoạt động xác định người dùng trực tiếp sẽ tác động đến việc quản lý trong quy trình kiểm thử

H2a Hoạt động xác định lưu lượng hoạt động thực tế của phần mềm tác động đến chất lượng của quy trình kiểm thử phần mềm

H2b Hoạt động xác định lưu lượng hoạt động thực tế của phần mềm tác động đến chi phí của quy trình kiểm thử phần mềm

H2c Hoạt động xác định lưu lượng hoạt động thực tế của phần mềm tác động đến việc quản lý trong quy trình kiểm thử