Bất cập trong quản lý mạng ngoại...

1

BỘ THÔNG TIN VÀ TRUYỀN THÔNG

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

VIỆN KHOA HỌC KỸ THUẬT BƯU ĐIỆN--------------

THUYẾT MINH TIÊU CHUẨN QUỐC GIA

TCVN xxxx-2:2019ISO/IEC/IEEE 29119-2:2013

KIỂM THỬ PHẦN MỀM - PHẦN 2: QUY TRÌNH KIỂM THỬ

Software testing - Part 2: Test processes

Hà Nội - 2019

MỤC LỤC

1. Tên gọi, mã số và nội dung tiêu chuẩn.........................................................................3

2. Nghiên cứu, khảo sát hiện trạng và đánh giá nhu cầu đối với việc kiểm thử phần mềm.....................................................................................................................................33. Tình hình tiêu chuẩn hóa trong và ngoài nước........................................................6

3.1 Ngoài nước...........................................................................................................................6

3.2 Trong nước.........................................................................................................................13

4. Phương pháp xây dựng tiêu chuẩn.........................................................................144.1. Lý do và mục đích xây dựng tiêu chuẩn.......................................................................14

4.2. Nhu cầu thực tế và khả năng áp dụng...........................................................................15

4.3. Lựa chọn tài liệu tham chiếu chính................................................................................15

4.4. Phương pháp xây dựng tiêu chuẩn.................................................................................15

5. Giới thiệu tổng quan bộ tiêu chuẩn quốc tế về kiểm thử phần mềm ISO/IEC/IEEE 29119.......................................................................................................15

5.1. Giới thiệu tổng quan bộ tiêu chuẩn ISO/IEC/IEEE 29119.........................................15

5.2. Nghiên cứu nội dung tiêu chuẩn ISO/IEC/IEEE 29119-2: Quy trình kiểm thử......28

5.2.1. Khái quát tiêu chuẩn gốc ISO/IEC/IEEE 29119-2...............................................28

5.2.2. Phạm vi áp dụng của ISO/IEC/IEEE 29119-2......................................................39

5.2.3. Sử dụng thuật ngữ “process” trong bộ tiêu chuẩn kiểm thử phần mềm............39

5.2.4. Đối chiếu các tiêu chuẩn liên quan đến ISO/IEC/IEEE 29119-2.......................40

6. Nội dung dự thảo tiêu chuẩn...................................................................................436.1. Nội dung dự thảo tiêu chuẩn..........................................................................................43

6.2. Cấu trúc dự thảo tiêu chuẩn............................................................................................43

6.3 Bảng đối chiếu dự thảo TCVN với tài liệu gốc.............................................................44

7. Kết luận.....................................................................................................................467.1. Kết quả đạt được..............................................................................................................46

7.2. Kiến nghị...........................................................................................................................46

Thư mục tài liệu tham khảo............................................................................................47

2

1. Tên gọi, mã số tiêu chuẩn1.1 Tên tiêu chuẩn: “Kỹ thuật hệ thống và phần mềm - Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử”

1.2 Mã số: TCVN xxxx-2:2019

1.3 Mục tiêu, nội dung và kết quả xây dựng tiêu chuẩn1.3.1. Mục tiêu:

- Phục vụ công tác kiểm thử phần mềm

1.3.2. Nội dung:

- Nghiên cứu, khảo sát hiện trạng và đánh giá nhu cầu đối với việc kiểm thử phần mềm.

- Nghiên cứu tình hình và xu thế chuẩn hóa đối với “Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử”.

- Nghiên cứu lựa chọn tiêu chuẩn tham chiếu chính.

- Nghiên cứu xây dựng tiêu chuẩn quốc gia “Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử”, bao gồm:

+ Quy trình kiểm thử của tổ chức;

+ Quy trình quản lý kiểm thử;

+ Quy trình kiểm thử động.

1.3.3. Kết quả:

- Thuyết minh dự thảo tiêu chuẩn Quốc gia.

- Dự thảo bộ Tiêu chuẩn Quốc gia về Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử.

2. Nghiên cứu, khảo sát hiện trạng và đánh giá nhu cầu đối với việc kiểm thử phần mềm

2.1. Kiểm thử phần mềm và vòng đời phần mềmPhần mềm - theo nghĩa thông thường là những chương trình, ứng dụng, website được viết, cài đặt và thực thi trên môi trường điện toán như: máy tính, điện thoại di động... Ngoài những điểm vừa nêu thì khái niệm phần mềm trong kiểm thử phần mềm còn mở rộng ra bao gồm cả các tài liệu, dữ liệu phù hợp và liên quan đến hoạt động của hệ thống điện toán.

Kiểm thử phần mềm là hoạt động nhằm tìm kiếm, phát hiện các lỗi của phần mềm được kiểm thử về thiết kế, mã nguồn, chức năng, dữ liệu, bảo mật, thận thiện với người dùng, tài liệu kèm theo, môi trường hoạt động, tốc độ hoạt động, khả năng tải của hệ thống.

Kiểm thử phần mềm là khâu cuối cùng trước khi chuyển sản phẩm đến khách hàng. Người kiểm thử được coi như là người đại diện cho khách hàng, là người kiểm tra cho

3

khách hàng xem sản phẩm đó đã đảm bảo chất lượng chưa. Vì vậy, người kiểm thử đóng vai trò quan trọng với sự thành công của dự án và chất lượng sản phẩm.

Tại sao kiểm thử lại cần thiết?

- Thông thường thì phần mềm không hoạt động như mong muốn sẽ lãng phí tiền bạc, thời gian, uy tín của doanh nghiệp, thậm chí có thể gây nên thương tích hay cái chết.

Ví dụ:

Website công ty có nhiều lỗi chính tả trong câu chữ làm cho khách hàng có thể lãng tránh công ty với lý do công ty trông có vẻ không chuyên nghiệp.

Một phần mềm tính toán lượng thuốc trừ sâu dùng cho cây trồng, vì lý do tính sai số lượng lên gấp 10 lần sẽ khiến nông dân phải bỏ nhiều tiền mua, cây trồng hư hại, môi trường sống, nguồn nước bị ảnh hưởng,….

- Kiểm thử phần mềm làm cho chất lượng phần mềm được nâng cao.

- Chúng ta có thể đánh giá chất lượng phần mềm dựa vào số lượng lỗi tìm thấy và các đặc tính như: tính đúng đắn, tính dễ sử dụng, tính dễ bảo trì,…

- Kiểm thử có thể đem lại sự tin tưởng đối với chất lượng phần mềm nếu có ít lỗi hoặc không có lỗi nào được tìm thấy. Nếu lỗi tìm thấy và được sửa thì chất lượng phần mềm càng được tăng. Do đó sẽ giảm chi phí trong quá trình phát triển, nâng cấp, bảo trì phần mềm

Công việc kiểm thử nên bắt đầu trong các mô hình phát triển phần mềm càng sớm càng tốt. Vậy vòng đời phần mềm là gì và các mô hình vòng đời phát triển phần mềm SDLC (software development life cycle) ảnh hưởng tới kiểm thử như thế nào?

Vòng đời phần mềm (Software life-cycle) là thời kỳ tính từ khi phần mềm được sinh (tạo) ra cho đến khi chết đi (từ lúc hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng cho đến khi loại bỏ không đâu dùng) �Các mô hình phát triển phần mềm hay gặp: Waterfall (mô hình thác nước), Prototype model (mô hình chế thử), Incremental Iterative (mô hình gia tăng), V-model (mô hình chữ V), Spiral (mô hình xoắn ốc), Agile, Rapid (mô hình phát triển ứng dụng nhanh).

Các mô hình phát triển phần mềm đều có những pha (phase) khác nhau, vì những mô hình ban đầu có một số điểm không tốt nên người ta cố gắng cải tiến thành mô hình phát triển khác hoàn thiện hơn, tốt hơn,... mà cốt lõi là chỉ để cho ra sản phẩm tốt hơn với thời gian phát triển nhanh nhất có thể. Đơn giản như mô hình thác nước (Waterfall), giai đoạn kiểm thử nằm ở cuối cùng trong quá trình phát triển phần mềm, điều này mang lại bất lợi là mãi cho đến khi phần mềm code xong cả dự án thì mới bắt đầu test, và lúc này mọi thứ đã đâu vào đấy, có thể nói theo kiểu "gạo đã nấu thành cơm". Khi phát hiện lỗi ở tài liệu yêu cầu hoặc trong mã chương trình thì phải thực hiện lại từ đầu: sửa tài liệu, sau đó sửa lại mã chương trình và kiểm thử lại nên chi phí rất tốn kém.

Với V model (mô hình chữ V) thì công việc kiểm thử được tham gia ngay từ đầu, từ lúc lấy yêu cầu là có thể "test - kiểm thử " bằng cách xem xét tài liệu yêu cầu, rồi đến xem xét đặc ta chi tiết, các bản thiết kế,... xem xét mã chương trình (code) rồi cuối cùng là kiểm thử ở mức thấp nhất - từng module, chức năng, màn hình,... đến kiểm thử tích hợp rồi kiểm thử hệ thống, kiểm thử chấp nhận... So với mô hình trước thì ở mô hình này, công việc kiểm thử đi sát hơn và ngay từ đầu khi bắt đầu phát triển. Do đó chất lượng dự án sẽ

4

tốt hơn. Nhưng tại sao người ta vẫn tiếp tục đưa ra mô hình phát triển khác? Vì ở mô hình chữ V này người ta vẫn phát triển cùng lúc cả hệ thống (nhiều yêu cầu, chức năng cùng lúc) mà rủi ro về thay đổi yêu cầu là rất lớn. Nên mô hình này vẫn có thể gặp rắc rối khi khách hàng thường xuyên thay đổi yêu cầu.

Với các mô hình phát triển phần mềm khác thì giai đoạn kiểm thử được đẩy lên sớm hơn bằng cách chia nhỏ ứng dụng, hệ thống thành các giai đoạn nhỏ để phát triển, điển hình như mô hình RUP (Rational Unified Process), Agile (scrum, XP,...)

Nói đơn giản: tùy mỗi SDLC mà sẽ có các hoạt động kiểm thử và quy trình kiểm thử khác nhau, nên nó ảnh hưởng đến kiểm thử khác nhau

Tóm lại: Do mỗi mô hình vòng đời phát triển phần mềm có các giai đoạn phát triển khác nhau, và việc kiểm thử được bắt đầu từ các giai đoạn khác nhau nên chúng ảnh hưởng đến chất lượng phần mềm và mỗi mô hình có các hoạt động kiểm thử khác nhau.

2.2. Hiện trạng và nhu cầu kiểm thử phần mềm tại Việt namTrên thế giới, ngành kiểm thử phần mềm đã xuất hiện khá lâu nhưng tại Việt Nam nói riêng, kiểm thử phần mềm mới chỉ phát triển khá mạnh trong khoảng chục năm trở lại đây.

Từ năm 2010, một số tập đoàn công nghệ thông tin trên thế giới đã thuê các công ty phần mềm tại Việt Nam gia công kiểm thử phần mềm cho họ.

Việt Nam hiện tại là một trong những địa điểm được lựa chọn và đánh giá cao, khi các doanh nghiệp ở các nước Âu, Mỹ muốn gửi công việc Kiểm thử phần mềm sang gia công ở một nước thứ ba. Ngoài ra nhiều công ty khi mở chi nhánh nghiên cứu và phát triển ở Việt Nam cũng thường bắt đầu bằng việc chuyển giao công việc kiểm thử phần mềm dưới dạng này hoặc dạng khác. Theo ước tính thì thị trường nhân lực kiểm thử phần mềm ở Việt Nam cho tới năm 2020 sẽ cần thêm khoảng trên dưới 10,000 chuyên viên kiểm thử, trong đó khoảng 50% là chuyên viên Kiểm thử phần mềm cao cấp trở lên.

Thế nhưng, cung - cầu về nhân lực làm kiểm thử phần mềm vẫn chưa ở thế cân bằng, nói cách khác Việt Nam vẫn thiếu nhiều kỹ sư kiểm thử chất lượng cao. Theo tiêu chuẩn quốc tế, tỷ lệ kỹ sư kiểm thử phần mềm tại Việt Nam còn thấp so với mặt bằng thế giới. Ở trên thế gới, tỷ lệ giữa lập trình viên và kỹ sư kiểm thử là 1:3, tức là cứ 3 lập trình viên thì có 1 kỹ sư kiểm thử, còn tỷ lệ này tại Việt Nam chỉ rơi vào khoảng 1:51, tức là cứ 5 lập trình viên mới có 1 kỹ sư kiểm thử. Rất ít người biết và quan tâm đến Kỹ sư kiểm thử. những ai theo học ngành công nghệ thông tin đều đa phần là nghĩ ngay đến nghề lập trình vì thế khiến đầu ra của nghề kiểm thử phần mềm có số lượng thấp hơn hẳn. Việc “quảng bá thương hiệu” về nghành kiểm thử chưa rộng rãi. Nói là công việc lập trình thì ai cũng biết, nhưng nếu nói mình là kiểm thử thì ít người biết và hiểu về nó. Đa phần kỹ sư kiểm thử ở Việt Nam không được qua đào tạo, không có chứng chỉ, thông thường làm lập trình sau đó chuyển sang kiểm thử, hoặc tự học khiến kiến thức không vững, không bài bản, và đặc biệt không được thực hành.

Tuy khan hiếm nhân lực như vậy nhưng tính tới thời điểm hiện tại, các đơn vị đào tạo chuyên sâu và bài bản về nghề kiểm thử phần mềm không nhiều, một số các trường đại học, sinh viên được đào tạo rất ít kiến thức liên quan đến kiểm thử phần mềm. Điều đó

1 Số liệu được cung cấp bởi chị Diệu Linh – Test manager, Trung tâm giải pháp phần mềm và tích hợp hệ thống; ngoài ra nhóm chủ trì còn thu thập được qua nguồn internet do đại diện công ty Logigear cung cấp.

5

khiến cho số lượng kỹ sư kiểm thử vẫn không đáp ứng đủ cho các dự án của các công ty tại Việt Nam.

Nhu cầu tuyển dụng kỹ sư kiểm thử hiện rất cao, chỉ cần gõ trên Google từ khóa “tuyển dụng kỹ sư kiểm thử 2015” sẽ có kết quả 117.000 kết quả trong chưa đầy 0.24 giây. Chỉ tính riêng trong tháng 7 và tháng 8 năm 2015 đã có nhiều công ty đăng thông tin tuyển dụng trên các báo điện tử như: Công ty cổ phần Trueplus Việt Nam. Công ty CP ĐT và PT Công Nghệ Truyền Thông Nam Việt, Công ty Cổ phần Cactus Software - Hà Nội, Công ty TNHH Kloon Việt Nam - Hà Nội, công ty cổ phần giải pháp phần mềm tài chính - FSS…

Nhu cầu là vậy, nhưng hiện nay số lượng các kỹ sự kiểm thử tại Việt Nam vẫn chưa đáp ứng được thị trường. Đội ngũ đào tạo Kỹ sư kiểm thử chuyên nghiệp ở Việt Nam có quy mô nhỏ và chỉ giới hạn trong một vài lĩnh vực.

3. Tình hình tiêu chuẩn hóa trong và ngoài nước3.1 Ngoài nướcSản phẩm phần mềm ngày nay đang trở thành một lĩnh vực được quan tâm và được kiểm soát chặt chẽ, theo những tiêu chuẩn nhất định. Các tiêu chuẩn có thể là các kinh nghiệm hoặc các phương pháp hiệu quả nhất, được đề xuất từ các hiệp hội nghề nghiệp như IEEE (The Institute of Electrical and Electronics Engineers, Inc), từ các tổ chức quốc tế như ISO (The International Organization for Standardization), hoặc các quy tắc chuẩn hóa để giao tiếp giữa sản phẩm với nhau,...hoặc đơn giản do chính tổ chức phát triển phần mềm đề ra để áp dụng cho chính họ.

Từ “những năm cuối thế kỷ 20, tổ chức ISO đã tập trung rất nhiều vào các tiêu chuẩn chất lượng cho phần mềm. Cách tiếp cận về chất lượng của ISO đã thực sự tiến thêm một bậc, toàn diện hơn, phù hợp hơn. Kết quả của sự tập trung này là một loạt các bộ tiêu chuẩn đã ra đời, nhằm hướng tới đánh giá chất lượng toàn diện trong suốt vòng đời của sản phẩm phần mềm, từ khi phôi thai cho tới lúc lạc hậu cần thay thế”.

Để giải quyết các hậu quả của sự chồng lấn thực tế trong lĩnh vực tiêu chuẩn hóa và các công việc liên quan tới công nghệ thông tin, ISO/IEC đã thành lập Ủy ban kỹ thuật chung, được biết đến với tên ISO/IEC JTC1. Vai trò của ủy ban này bao gồm phát triển, duy trì, khuyến khích và thuận tiện hóa các tiêu chuẩn công nghệ thông tin được yêu cầu bởi các thị trường toàn cầu để phù hợp với các nhu cầu liên quan và người sử dụng bao gồm:

Thiết kế và phát triển các hệ thống và công cụ công nghệ thông tin.

Tính thực thi và chất lượng của các sản phẩm và hệ thống công nghệ thông tin.

An ninh của các hệ thống công nghệ thông tin và thông tin.

Tính linh động của các chương trình ứng dụng.

Thao tác giữa các bộ phận của các sản phẩm và hệ thống công nghệ thông tin.

Hợp nhất các công cụ và môi trường.

Hòa hợp từ vựng công nghệ thông tin.

Các giao diện người dùng thân thiện và hài hòa.

Hiện tại có 18 tiểu ban (SC):

6

SC 02 - Các bộ ký tự mã hóa.

SC 06 - Trao đổi liên lạc và thông tin giữa các hệ thống.

SC 07 - Kỹ thuật phần mềm và hệ thống.

SC 17 - Thẻ và nhận dạng cá nhân.

SC 22 - Ngôn ngữ lập trình, môi trường của chúng và các hệ thống giao diện phần mềm.

SC 23 - Các thiết bị lưu trữ số hóa tháo lắp sử dụng công nghệ ghi quang học và/hoặc từ tính cho số hóa.

SC 24 - Đồ họa máy tính và xử lý ảnh.

SC 25 - Liên kết thiết bị công nghệ thông tin.

SC 27 - Các kỹ thuật an ninh công nghệ thông tin.

SC 28 - Các thiết bị văn phòng.

SC 29 - Mã hóa thông tin âm thanh, hình ảnh, đa truyền thông và siêu truyền thông.

SC 31 - Nhận dạng tự động và các kỹ thuật bắt giữ số liệu.

SC 32 - Quản lý và trao đổi dữ liệu.

SC 34 - Mô tả tài liệu và các ngôn ngữ xử lý.

SC 35 - Giao diện người dùng.

SC 36 - Công nghệ thông tin trong giảng dạy, học tập và tập huấn.

SC 37 - Sinh trắc học.

Trong đó, tiểu ban SC7 chịu trách nhiệm về các tiêu chuẩn kỹ thuật phần mềm và hệ thống. Các quá trình, các kỹ thuật và công cụ hỗ trợ đối với kỹ thuật hệ thống và phần mềm được tiêu chuẩn hóa nhằm phát triển, duy trì, khuyến khích và thuận tiện hóa cho việc hướng dẫn, sử dụng; để phù hợp với các nhu cầu kinh doanh, nghiên cứu và cho các đối tượng sử dụng trong lĩnh vực công nghệ thông tin. Phạm vi chịu trách nhiệm của SC7 trong kỹ thuật hệ thống và phần mềm bao gồm:

Các quá trình kỹ thuật phần mềm và hệ thống: các tiêu chuẩn mô tả, trình bày và đánh giá kỹ thuật phần mềm và hệ thống dựa theo các mô hình tham chiếu và các phép đo tiêu chuẩn.

Các sản phẩm hệ thống phần mềm: các tiêu chuẩn cung cấp cho các đối tượng sử dụng các tài liệu hướng dẫn tường minh về các phép đo và đánh giá chất lượng sản phẩm phần mềm hoặc các hệ thống ứng dụng.

Kiến trúc tổ chức kinh doanh: các tiêu chuẩn trình bày về các hệ thống kinh doanh được tích hợp kỹ thuật phần mềm và cung cấp các công cụ về kỹ thuật phần mềm và hệ thống để triển khai các hệ thống thông tin tổ chức kinh doanh.

Môi trường kỹ thuật phần mềm: các tiêu chuẩn mô tả các môi trường kỹ thuật phần mềm và việc áp dụng các tiêu chuẩn vào trong trong các môi trường đó.

Kiến thức về kỹ thuật phần mềm: các bản báo cáo kỹ thuật ISO/IEC.

7

Quản lý các tài sản phần mềm: Các tiêu chuẩn mô tả các yêu cầu cơ bản trong một môi trường quản lý tài sản phần mềm.

Vận hành công nghệ thông tin: các tiêu chuẩn cung cấp và mô tả việc quản lý các dịch vụ công nghệ thông tin.

Hình 1 - Hệ thống các tiêu chuẩn ISO về kỹ thuật hệ thống và phần mềmDựa trên việc hệ thống và phân nhóm các quá trình như trên, SC7 nhóm các tiêu chuẩn ISO một cách phù hợp và thuận tiện cho việc sử dụng chúng. Hình 1 đưa ra sơ đồ hệ thống các tiêu chuẩn ISO do tiêu ban SC7 chịu trách nhiệm. Qua đó thể hiện tính bao quát toàn diện trong cách xây dựng hệ thống tiêu chuẩn về kỹ thuật hệ thống và phần mềm của tổ chức tiêu chuẩn quốc tế ISO. Các tiêu chuẩn được xây dựng với mối liên hệ chặt chẽ với nhau từ các tiêu chuẩn mang tính chất bổ trợ cho tới các tiêu chuẩn mang tính chất hướng dẫn chung: vòng đời sản phẩm, đánh giá và triển khai các quá trình; và các tiêu chuẩn về đặc tính sản phẩm.

Các tiêu chuẩn về Kỹ thuật và hệ thống phần mềm được trình bày trong bảng 1 dưới đây:

Bảng 1 - Một số tiêu chuẩn ISO về kỹ thuật hệ thống và phần mềm

Ký hiệu tài liệu Tên tài liệu

Các tiêu chuẩn tham chiếu các quá trình và sản phẩm

ISO/IEC 12207:2013Systems and Software Engineering - Software Life Cycle Processes. (Kỹ thuật hệ thống và phần mềm - Các quá trình vòng đời phần mềm).

8


ISO/IEC/IEEE 15288:2015Systems and Software Engineering - System Life Cycle Processes. (Kỹ thuật hệ thống và phần mềm - Các quá trình vòng đời hệ thống).

ISO/IEC 29110:2011Software Engineering - Life Cycle Profiles for Very Small Entities (VSEs). (Kỹ thuật phần mềm - Sơ lược vòng đời của các thực thể rất nhỏ).

ISO/IEC 90003:2014

Software Engineering - Guidelines for the Application of ISO 9001:2000 to Computer Software. (Kỹ thuật phần mềm - Các hướng dẫn áp dụng ISO 9001:2000 cho phần mềm máy tính).

ISO/IEC TR 24748-1:2010

Systems and Software Engineering - Life cycle management - Part 1: Guide for life cycle management . (Kỹ thuật hệ thống và phần mềm - Quản lý vòng đời - Phần 1: Hướng dẫn quản lý vòng đời).

ISO/IEC TR 24748-2:2011

Systems and Software Engineering - Life cycle management - Part 1: Guide to the application of ISO/IEC 15288 (System life cycle processes. (Kỹ thuật hệ thống và phần mềm - Quản lý vòng đời - Phần 2: Hướng dẫn áp dụng tiêu chuẩn ISO/IEC 15288).

ISO/IEC TR 24748-3:2011

Systems and Software Engineering - Life cycle management - Part 1: Guide to the application of ISO/IEC 12207 (Software life cycle processes. (Kỹ thuật hệ thống và phần mềm - Quản lý vòng đời - Phần 3: Hướng dẫn áp dụng tiêu chuẩn ISO/IEC 12207).

ISO/IEC CD 24748-4

Systems Engineering - Application and management of the systems engineering process. (ISO/IEC CD 24748-4: Kỹ thuật hệ thống - Áp dụng và quản lý quá trình kỹ thuật hệ thống).

Các tiêu chuẩn đánh giá và triển khai quá trình

ISO/IEC 14764:2006Systems and Software Engineering - Software Life Cycle Processes - Maintenance. (Kỹ thuật phần mềm - Các quá trình vòng đời phần mềm - Bảo trì).

ISO/IEC 16085:2006Systems and Software Engineering - Life Cycle Processes - Risk Management. (Kỹ thuật hệ thống và phần mềm - Các quá trình vòng đời - Quản lý rủi ro).

ISO/IEC/IEEE 16326:2009 Systems and Software Engineering - Life Cycle Processes - Project Management. (Kỹ thuật hệ thống và phần mềm - Các quá trình vòng đời - Quản lý dự

9


án).

ISO/IEC/IEEE 29119-1:2013

Software and systems engineering - Software testing - Part 1: Concepts and definitions (Kỹ thuật hệ thống và phần mềm - Kiểm thử phần mềm - Phần 1: Khái niệm và định nghĩa).


Software and systems engineering - Software testing - Part 2: Test processs (Kỹ thuật hệ thống và phần mềm - Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử).


Software and systems engineering - Software testing - Part 3: Test documentation (Kỹ thuật hệ thống và phần mềm - Kiểm thử phần mềm - Phần 3: Tài liệu kiểm thử).


Software and systems engineering - Software testing - Part 4: Test techniques (Kỹ thuật hệ thống và phần mềm - Kiểm thử phần mềm - Phần 4: Kỹ thuật kiểm thử).

ISO/IEC/IEEE 29148:2011

Systems and Software Engineering - Life Cycle Processes - Requirements Engineering. (Kỹ thuật hệ thống và phần mềm) - Các quá trình vòng đời - Các yêu cầu).

ISO/IEC 15289:2006

Systems and Software Engineering - Content of Systems and Software Life Cycle Process Information Products (Documentation). (Kỹ thuật hệ thống và phần mềm - Nội dung các sản phẩn thông tin quá trình vòng đời phần mềm và các hệ thống (Tài liệu hướng dẫn)).

Các tiêu chuẩn series 20000 về quản lý dịch vụ

ISO/IEC 20000-1:2011

Information Technology - Service Management - Part 1: Service Management System Requirements. (Công nghệ thông tin - Quản lý dịch vụ - Phần 1: Các yêu cầu hệ thống quản lý dịch vụ).

ISO/IEC 20000-2:2012Information Technology - Service Management - Part 2: Code of Practice. (Công nghệ thông tin - Phần 2: Mã thực hành).

ISO/IEC TR 20000-3:2009

Information Technology - Service Management - Part 3: Guidance on Scope, Definition, and Applicability of ISO/IEC 20000-1. (Công nghệ thông tin - Quản lý dịch vụ - Phần 3: Hướng dẫn phạm vi, định nghĩa, và tính ứng dụng của ISO/IEC 20000-1).

ISO/IEC TR 20000-4:2010 Information Technology - Service Management - Part 4: Process Reference Model. (Công nghệ thông tin - Quản lý dịch vụ - Phần 4: Mô hình tham chiếu quá

10


trình).

ISO/IEC TR 20000-5:2013

Information Technology - Service Management - Part 5: Exemplar Implementation Plan for ISO/IEC 20000-1. (Công nghệ thông tin - Quản lý dịch vụ - Phần 5: Lập kế hoạch triển khai mẫu đối với ISO/IEC 20000-1).

ISO/IEC TR 20000-10:2013

Information Technology - Service Management - Part 10: Concepts and Terminology. (Công nghệ thông tin - Quản lý dịch vụ - Phần 10: Các khái niệm và thuật ngữ).

Bộ các tiêu chuẩn ISO/IEC 15504 về đánh quá trình

ISO/IEC 33001:2015 (thay thế cho ISO/IEC 15504-1:2004)

Information Technology - Process Assessment - Concepts and Vocabulary. (Công nghệ thông tin - Đánh giá quá trình - Phần 1: Các khái niệm và từ vựng).

ISO/IEC TR 15504-2:1998

Information Technology - Software Process Assessment - Part 2: A Reference Model for Processes and Process Capability. (Cộng nghệ thông tin - Đánh giá quá trình phần mềm - Phần 2: Mô hình tham chiếu đối với các quá trình và khả năng quá trình).

ISO/IEC 15504-3:2004

Information Technology - Process Assessment - Part 3: Guidance on Performing an Assessment. (Công nghệ thông tin - Đánh giá quá trình - Phần 3: Hướng dẫn thực hiện đánh giá).

ISO/IEC 15504-4:2004

Information Technology - Process Assessment - Part 4: Guidance on Use for Process Improvement and Process Capability Determination. (Công nghệ thông tin - Đánh giá quá trình - Phần 4: Hướng dẫn sử dụng cải tiến quá trình và xác định khả năng quá trình).

ISO/IEC 15504-5:2012

Information Technology - Process Assessment - Part 5: An Exemplar Process Assessment Model. (Công nghệ thông tin - Đánh giá quá trình - Phần 5: Mô hình đánh giá quá trình mẫu).

ISO/IEC TR 15504-6:2013

Information Technology - Process Assessment - Part 6: An Exemplar System Life Cycle Process Assessment Model. (Công nghệ thông tin - Đánh giá quá trình - Phần 6: Mô hình đánh giá quá trình vòng đời hệ thống mẫu).

ISO/IEC TR 15504-9:1998 Information Technology - Software Process

11


Assessment - Part 9: Vocabulary. (Công nghệ thông tin - Đánh giá quá trình phần mềm - Phần 9: Từ vựng).

ISO/IEC TS 15504-10:2011Information Technology - Process Assessment - Part 10: Safety Extension. (Công nghệ thông tin - Đánh giá quá trình - Phần 10: Mở rộng tính an toàn).

Các tiêu chuẩn liên quan đến đảm bảo chất lượng (QA) và quy trình kiểm thử được trình bày ở bảng 2 dưới đây:

Bảng 2 - Các tiêu chuẩn liên quan đến đảm bảo chất lượng và quy trình kiểm thử


Các tiêu chuẩn tham chiếu các quá trình và sản phẩm

IEEE 829:2008A standard for the format of documents used in different stages of software testing. (Tiêu chuẩn về mẫu các tài liệu được sử dụng trong các giai đoạn khác nhau của kiểm thử phần mềm)

IEEE 1061:1998

A methodology for establishing quality requirements, identifying, implementing, analyzing, and validating the process and product of software quality metrics is defined. (Phương pháp luận để thiết lập các yêu cầu chất lượng, xác định, thực thi, phân tích, và xác nhận quá trình và sản phẩm có các chỉ số chất lượng phần mềm được xác định.)

IEEE 1059:1993 Guide for Software Verification and Validation Plans (Hướng dẫn kế hoạch kiểm tra và đánh giá phần mềm)

IEEE 1008:1987 A standard for unit testing. (Tiêu chuẩn về kiểm thử đơn vị)

IEEE 1012:2004 A standard for Software Verification and Validation. (Tiêu chuẩn về kiểm tra và đánh giá phần mềm)

IEEE 1028:2008 A standard for software inspections. (Tiêu chuẩn về kiểm tra phần mềm)

IEEE 1044:2009 A standard for the classification of software anomalies. (Tiêu chuẩn về phân loại những bất thường phần mềm)

IEEE 830:1998 A guide for developing system requirements specifications. (Hướng dẫn phát triển đặc tả các yêu cầu hệ thống)

IEEE 730:2014 A standard for software quality assurance plans. (Tiêu chuẩn về kế hoạch đảm bảo chất lượng phần mềm)

IEEE 1061:1998A standard for software quality metrics and methodology. (Tiêu chuẩn về hệ phương pháp luận và các chỉ số chất lượng phần mềm)

IEEE 12207:2008 A standard for software life cycle processes and life cycle data (Tiêu chuẩn về các quá trình vòng đời phần mềm và dữ liệu

12


vòng đời)

BS 7925-1: 1998 A vocabulary of terms used in software testing. (Từ vựng về các thuật ngữ được sử dụng trong kiểm thử phần mềm)

BS 7925-2:1998 A standard for software component testing. (Tiêu chuẩn về kiểm thử thành phần phần mềm)

Nhận xét:Trong số các tiêu chuẩn liên quan đến lĩnh vực phần mềm có tiêu chuẩn ISO/IEC/IEEE 29119-2:2013 (thuộc bộ tiêu chuẩn ISO/IEC/IEEE 29119) mới được ban hành năm 2013 trình bày khá chi tiết về quy trình kiểm thử phần mềm. Cho đến nay, tiêu chuẩn này được áp dụng rộng rãi trên thế giới và được rất nhiều nước biên dịch và có tiêu chuẩn quốc gia hoàn toàn tương đương với các phiên bản của ISO/IEC/IEEE 29119-2:2013 như: Anh (BS ISO/IEC/IEEE 29119-2:2013), Đan Mạch (DS/ISO/IEC/IEEE 29119-2), Na-uy (NS-ISO/IEC/IEEE 29119-2:2013)…

3.2 Trong nướcKiểm thử phần mềm không chỉ là một nghề còn rất mới ở Việt Nam mà còn ở nhiều nơi trên thế giới. Kiểm thử phần mềm là lĩnh vực không thể thiếu để hỗ trợ thiết thực cho ngành công nghiệp phần mềm cạnh tranh mạnh với các quốc gia trong khu vực. Tại Việt Nam Kiểm thử phần mềm đã và đang phát triển khá mạnh trong khoảng chục năm trở lại đây nhưng chúng ta đang phải cạnh tranh gay gắt với các nước trên thế giới như Ấn Độ, Mỹ và Trung Quốc do gặp một thách thức về nguồn cung ứng nhân lực cho dự án của các công ty còn hạn chế.

Trước tình hình phải đảm bảo chất lượng sản phầm phần mềm, Việt Nam đã chú trọng xây dựng và ban hành hệ thống tiêu chuẩn liên quan đến sản phẩm phần mềm.

Bảng 3 - Các TCVN đã ban hành liên quan đến phần mềm

Số hiệu Tên tiêu chuẩn

TCVN 8702:2011 Công nghệ thông tin - Chất lượng sản phẩm phần mềm - Phần 1: Các phép đánh giá ngoài.

TCVN 8703:2011 Công nghệ thông tin - Chất lượng sản phẩm phần mềm - Phần 2: Các phép đánh giá trong.

TCVN 8704:2011 Công nghệ thông tin - Chất lượng sản phẩm phần mềm - Phần 3: Các phép đánh giá đánh giá chất lượng sử dụng.

TCVN 8705:2011 Công nghệ thông tin - Đánh giá sản phẩm phần mềm - Phần 1: Tổng quan.

TCVN 8706:2011 Công nghệ thông tin - Đánh giá sản phẩm phần mềm - Phần 2: Quy trình cho bên đánh giá.

TCVN 8707:2011 Công nghệ thông tin - Đánh giá sản phẩm phần mềm - Phần 3: Quy trình cho người phát triển.

TCVN 8708:2011 Công nghệ thông tin - Đánh giá sản phẩm phần mềm - Phần 4: Quy trình cho người mua sản phẩm.

13

Số hiệu Tên tiêu chuẩn

TCVN 10539:2014 Kỹ thuật hệ thống và phần mềm - Các quá trình vòng đời phần mềm.

TCVN 10540:2014 Kỹ thuật phần mềm - Yêu cầu và đánh giá chất lượng sản phẩm phần mềm - Yêu cầu chất lượng và hướng dẫn kiểm tra sản phẩm phần mềm sẵn sàng phổ biến và thương mại hóa (COTS).

Các tiêu chuẩn chỉ đưa ra các phép đánh giá chất lượng sản phẩm phần mềm và các quá trình vòng đời phần mềm. Chưa có tiêu chuẩn, quy chuẩn về kiểm thử phần mềm.

Một số dự thảo đã được xây dựng về kiểm thử phần mềm:

Bảng 4 - Các TCVN đang xây dựng liên quan đến kiểm thử phần mềm

Mã số Tên tiêu chuẩn

TCVN xxxx-1:2019 Nghiên cứu, xây dựng tiêu chuẩn quốc gia “Kiểm thử phần mềm - Phần 1: Khái niệm và định nghĩa”.

TCVN xxxx-3:2019 Nghiên cứu, xây dựng tiêu chuẩn quốc gia “Kiểm thử phần mềm - Phần 3: Tài liệu kiểm thử”.

TCVN xxxx-4:2019 Nghiên cứu, xây dựng tiêu chuẩn quốc gia “Kiểm thử phần mềm - Phần 4: Các kỹ thuật kiểm thử”.

4. Phương pháp xây dựng tiêu chuẩn4.1. Lý do và mục đích xây dựng tiêu chuẩnMột sản phầm phần mềm khi đưa vào sử dụng để được đánh giá tốt cần phải qua quy trình kiểm thử gắt gao, đây là quy trình không thể thiếu trước khi mỗi sản phẩm phần mềm được đánh giá.

Hiện nay ở Việt Nam, các doanh nghiệp không có quy trình kiểm thử phần mềm hoặc tự xây dựng và ban hành quy trình riêng cho doanh nghiệp (không tuân thủ và được chứng nhận của tổ chức quốc tế hay trong nước). Họ không tự xây dựng quy trình kiểm thử độc lập để đảm bảo chất lượng phần mềm của doanh nghiệp, quy trình kiểm thử luôn nằm trong mô hình quy trình phát triển phần mềm chung tuân theo các chuẩn quốc tế quy định. Nếu xét quản lý chất lượng theo các tiêu chuẩn quốc tế, thì ISO và CMM/CMMI (Capability Maturity Model Integration) nằm trong số các tiêu chuẩn phổ biến và quan trọng nhất đối với doanh nghiệp phần mềm. Tuy nhiên đến nay số lượng các công ty phần mềm áp dụng và đạt tiêu chuẩn CMM/CMMI tại Việt nam chỉ đếm được trên đầu ngón tay (theo báo cáo chính thức trên trang web của SEI, tổ chức phát triển CMMI và công nhận các công ty đạt chuẩn), và chủ yếu vẫn là những công ty lớn có hoặc có nguồn gốc đầu tư từ nước ngoài như FPT (CMMi level 5), PSV (CMMi level 5), Global Cybersoft (CMMi level 5), TMA (CMMi level 5), Tinh vân (CMMi level 3), Tập đoàn Viettel (CMMi level 3) vv… Do đó, cần có bộ TCVN để để phục vụ cho công tác kiểm thử phần mềm

Mục đích xây dựng tiêu chuẩn là để cung cấp một mô hình quy trình chung để kiểm thử phần mềm mà có thể được sử dụng trong bất kỳ vòng đời phát triển phần mềm nào. Mô

14

hình này quy định các quy trình kiểm thử có thể được sử dụng để kiểm soát, quản lý và thực thi kiểm thử phần mềm trong bất kỳ tổ chức, dự án hoặc hoạt động kiểm thử phần mềm nào.

4.2. Nhu cầu thực tế và khả năng áp dụngTiêu chuẩn này có thể được sử dụng để quản lý và thực hiện kiểm thử phần mềm trong bất kỳ tổ chức, dự án hoặc bất kỳ hoạt động kiểm thử nào. Tiêu chuẩn này có thể được áp dụng để kiểm thử trong mọi chu kỳ phát triển phần mềm. Nó được dùng cho các kỹ sư kiểm thử, trưởng nhóm kiểm thử, người phát triển và người quản lý dự án mà chịu trách nhiệm quản lý và thực hiện kiểm thử phần mềm.

4.3. Lựa chọn tài liệu tham chiếu chính Các phân tích ở trên cho thấy: Các tiêu chuẩn ISO/IEC là các tiêu chuẩn phù hợp, đã được nhiều quốc gia chấp thuận áp dụng.

Sau khi rà soát các tiêu chuẩn ISO/IEC liên quan, nhóm chủ trì nhận thấy chỉ có tiêu chuẩn ISO/IEC/IEEE 29119-2:2013 đưa ra đầy đủ các quy trình kiểm thử phù hợp phục vụ kiểm thử phần mềm.

Do đó, để xây dựng bộ tiêu chuẩn TCVN “Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử”, chủ trì đã lựa chọn tài liệu quốc tế: ISO/IEC/IEEE 29119-2:2013 “Softwave and systems engineering - Sofwave testing - Part 2: Test processes” làm tài liệu tham chiếu chính để xây dựng Tiêu chuẩn quốc gia về Quy trình kiểm thử phần mềm.

Tài liệu tham chiếu chính ISO/IEC/IEEE 29119-2:2013 là phần 2 của bộ tiêu chuẩn kiểm thử phần mềm ISO/IEC/IEEE 29119 và là phiên bản mới nhất hiện nay.

4.4. Phương pháp xây dựng tiêu chuẩnTrên cơ sở rà soát các tiêu chuẩn quốc tế và các quy chuẩn kỹ thuật, tiêu chuẩn quốc gia về Kỹ thuật hệ thống và phần mềm, cũng như tham khảo các phương pháp xây dựng các tiêu chuẩn/quy chuẩn, nhóm chủ trì đã xây dựng tiêu chuẩn này theo phương pháp chấp thuận có sửa đổi như sau:

Chỉnh sửa về hình thức trình bày để phù hợp với thể thức trình bày Tiêu chuẩn quốc gia theo Thông tư 03/2011/TT-BTTTT và TCVN 1-2:2008.

Tài liệu viện dẫn trong dự thảo sẽ viện dẫn trực tiếp đến TCVN tương đương (ISO/IEC 12207:2008 viện dẫn đến tiêu chuẩn TCVN 10359:2014).

Các tiêu chuẩn ISO/IEC đã có TCVN tương đương, nhóm chủ trì sẽ viện dẫn trực tiếp đến các TCVN tương đương (Tiêu chuẩn ISO/IEC 25051:2006 thay bằng TCVN 10540:2014)

5. Giới thiệu tổng quan bộ tiêu chuẩn quốc tế về kiểm thử phần mềm ISO/IEC/IEEE 29119

5.1. Giới thiệu tổng quan bộ tiêu chuẩn ISO/IEC/IEEE 29119Tháng 5 năm 2007, ISO đã thành lập một nhóm làm việc để xây dựng một bộ tiêu chuẩn mới về kiểm thử phần mềm - một lĩnh vực mới đối với ISO - ba phần đầu của bộ tiêu chuẩn này đã được công bố vào đầu tháng 9 năm 2013. Sáng kiến này được IEEE và BSI hỗ trợ chu đáo, cả IEEE và BSI đã tặng các tiêu chuẩn hiện có của họ về kiểm thử (IEEE đã tặng IEEE 829 và IEEE 1008; BSI đã tặng BS 7925-1 và BS 7925-2) cho ISO làm tài

15

liệu nguồn để xây dựng bộ tiêu chuẩn mới về kiểm thử phần mềm (các tiêu chuẩn này sẽ bị hủy bỏ khi các tiêu chuẩn mới được công bố).

Bộ tiêu chuẩn mới về kiểm thử phần mềm ISO/IEC/IEEE 29119 gồm 5 phần: Phần 1 bao gồm “khái niệm và thuật ngữ”, phần 2 là “các quy trình kiểm thử”, phần 3 là “tài liệu kiểm thử”, phần 4 là “các kỹ thuật kiểm thử” và phần 5 “kiểm thử hướng từ khóa”. Ngoài ra còn có thêm một phần được xây dựng thành một tiêu chuẩn riêng có tên “đánh giá kiểm thử”. Phần này mô tả lý do phát triển bộ các tiêu chuẩn này, tiến trình phát triển và nội dung của các phần của bộ tiêu chuẩn này.

Các phần của ISO/IEC/ IEEE 29119 đã được phát hành dưới dạng dự thảo để xem xét (và sau đó được cập nhật dựa trên hàng ngàn ý kiến) và đã được sử dụng trong một số các tổ chức đa quốc gia. Những tổ chức này đã nhận thấy những lợi ích của việc tái sử dụng các quy trình đã được xác định và tài liệu được cung cấp bởi bộ các tiêu chuẩn này phản ánh thực tiễn tốt nhất ngành kiểm thử hiện nay.

5.1.1. Bối cảnh kiểm thử phần mềm Kiểm thử phần mềm là một phần cơ bản của quá trình phát triển phần mềm từ trước khi mô hình vòng đời phát triển phần mềm được xác định. Ngày nay ước tính tỷ lệ chi phí vòng đời phát triển phần mềm dành cho kiểm thử biến đổi từ dưới 20 % đến 80% cho các hệ thống an toàn. Mặc dù có lịch sử lâu đời và chi phí cao để nghiên cứu nhưng vấn đề kiểm thử chỉ được đề cập một cách sơ sài trong các tiêu chuẩn; điều này là do việc nắm bắt thông tin trong các khóa học tập và nghiên cứu kém.

Phần này giới thiệu một bộ tiêu chuẩn mới về kiểm thử phần mềm, việc phát triển bộ tiêu chuẩn được bắt đầu vào năm 2007, đến tháng 9 năm 2013 mới có 3 phần đầu tiên được xuất bản.

5.1.2. Các tiêu chuẩn về kiểm thửCó nhiều tiêu chuẩn áp dụng chung cho phát triển phần mềm (kể cả kiểm thử), gần như tất cả trong số đó đều có phạm vi áp dụng liên quan đến an toàn. Ví dụ như tiêu chuẩn DO-178B dùng cho hệ thống điện tử hàng không (RTCA 1992 DO-178B Software considerations in airborne systems and equipment certification), Misra dùng cho ngành công nghiệp ô tô (Misra 1994 Development guidelines for vehicle based software), Def Stan 00-55 dùng cho quốc phòng (MoD 1997 Def Stan 00-55 Requirements for safety-related software in defence equipment) (Defence Standard: Những yêu cầu về an toàn liên quan đến phần mềm trong thiết bị quốc phòng), và EN 50128 dùng cho đường sắt (CENELEC 2001 EN 50128-2001 Railway applications - Software for railway control and protection systems).

EN 50128 có nguồn gốc từ IEC 61508 (IEC 1998), nó có thể áp dụng cho "các hệ thống điện/điện tử/lập trình liên quan đến an toàn”, vì thế nó có thể được sử dụng thay cho tất cả các tiêu chuẩn đã đề cập trước đó. IEC 61508 bao gồm một số yêu cầu kiểm thử phần mềm khá mới (mối quan hệ giữa các yêu cầu về phân tích giá trị biên và phân vùng tương đương), tất cả các tiêu chuẩn này không có cơ sở cho các yêu cầu kiểm thử. Lĩnh vực kiểm thử trong các tiêu chuẩn liên quan đến an toàn vẫn đang nghiên cứu.

Các tiêu chuẩn này đưa ra yêu cầu thực hiện kiểm thử phần mềm, các kỹ thuật áp dụng và mức độ bao phủ kiểm thử cần đạt được nhưng không đưa ra các định nghĩa về các quy trình, các kỹ thuật và các biện pháp bao phủ kiểm thử này. Những người thực hiện khác

16

nhau có thể có những nhận thức khá khác nhau về những định nghĩa này, điều này có thể dẫn đến sự thiếu nhất quán và hiểu lầm. Do đó, việc đưa ra một bộ tiêu chuẩn quốc tế mới về kiểm thử phần mềm sẽ làm giảm bớt vấn đề này.

Ngoài các tiêu chuẩn liên quan đến an toàn ở trên, một số tiêu chuẩn về các khía cạnh khác nhau của kiểm thử phần mềm cũng đã được công bố bởi các tổ chức như IEEE và BSI; các tiêu chuẩn này bao gồm việc kiểm thử trong từng giai vòng đời phát triển của sản phẩm (ví dụ như BS 7925-2: Kiểm thử thành phần phần mềm (BSI 1998b)) hoặc các khía cạnh cụ thể, chẳng hạn như tài liệu kiểm thử (IEEE 829 tài liệu kiểm thử (IEEE 2008)).

Chúng ta hãy tìm hiểu về các tiêu chuẩn kiểm thử đầu tiên, tiêu chuẩn IEEE 829 Tài liệu kiểm thử phần mềm, được bắt đầu nghiên cứu vào năm 1979 và nó được xuất bản 4 năm sau đó, phiên bản mới nhất được công bố năm 2008 (IEEE 2008). Sau đó IEEE xuất bản tiêu chuẩn về kiểm thử đơn vị vào năm 1987, được sửa đổi năm 2003 (IEEE 2003). Ngoài các tiêu chuẩn về kiểm thử phần mềm của IEEE, BSI cũng xuất bản hai tiêu chuẩn kiểm thử phần mềm vào năm 1998; phần 1 là từ vựng kiểm thử (BSI 1998a), phần 2 là tiêu chuẩn kiểm thử thành phần (BSI 1998b) bao gồm một quy trình kiểm thử dùng để kiểm thử thành phần (đơn vị), tuy nhiên nội dung chủ yếu là định nghĩa (và ví dụ) về các kỹ thuật thiết kế trường hợp kiểm thử.

5.1.3. Các tổ chức tiêu chuẩn hóaViệc tạo ra các tiêu chuẩn được quản lý bởi một số lượng lớn các tổ chức tiêu chuẩn hóa. Có một số tổ chức tiêu chuẩn quốc tế (ví dụ như ISO, IEC, ITU, CEN) và các tổ chức tiêu chuẩn quốc gia (ví dụ như ANSI, BSI, DIN, NEN) được đại diện trong các tổ chức quốc tế. Ngoài ra còn có một số tiêu chuẩn có phạm vi cụ thể (ví dụ: NASA, ESA, FAA trong lĩnh vực hàng không vũ trụ), các tiêu chuẩn này thường bao gồm các lĩnh vực liên quan đến an toàn.

Bên cạnh đó, các tổ chức quốc phòng cũng đã phát triển các tiêu chuẩn riêng của họ (ví dụ như DoD, MOD, NATO) nhưng họ rất quan tâm đến những tiêu chuẩn này.

Có một nhóm các tổ chức tiêu chuẩn là những tổ chức công nghệ thông tin vẫn duy trì các tiêu chuẩn (ví dụ như IEEE, INCOSE, OMG, W3C). Trong một động thái tương tự như DoD, IEEE có chính sách tặng các tiêu chuẩn của họ cho ISO, do đó làm giảm chi phí duy trì của họ và làm tăng sự gắn kết trong các tiêu chuẩn của công nghệ thông tin. IEEE đã tặng cả IEEE 829 và IEEE 1008 cho ISO để xây dựng bộ tiêu chuẩn mới ISO/IEC/IEEE 29119 về kiểm thử phần mềm.

Tổ chức tiêu chuẩn hóa quốc tế (ISO) bao gồm một mạng lưới với hơn 160 tổ chức tiêu chuẩn quốc gia và đã xuất bản trên 18.000 tiêu chuẩn vào cuối năm 2010. Bản kế hoạch chiến lược ISO (2011-2015) thể hiện một cam kết là “... nhà cung cấp hàng đầu thế giới các tiêu chuẩn quốc tế có liên quan trên toàn cầu có chất lượng cao”.

Trong lĩnh vực công nghệ thông tin và truyền thông ISO thường xuyên phối hợp với IEC (Ủy ban kỹ thuật điện quốc tế) để xuất bản các tiêu chuẩn chung. ISO và IEC đã thành lập một tiểu ban (SC7) về kỹ thuật hệ thống và phần mềm, với các điều khoản tham chiếu cho các "tiêu chuẩn của các quy trình, công cụ hỗ trợ và hỗ trợ công nghệ cho kỹ thuật của sản phẩm phần mềm và hệ thống”. Đến năm 2013, tiểu ban SC7 đã có 59 thành viên tham gia tổ chức tiêu chuẩn quốc gia. Hình 1 cho thấy số lượng các tiêu chuẩn được công bố và duy trì bởi SC7 kể từ khi tiểu ban này được thành lập.

17

Hình 2 - Các tiêu chuẩn kỹ thuật hệ thống và phần mềm ISO/IEC5.1.4. Động lực thúc đẩy xây dựng bộ tiêu chuẩn ISO/IEC/IEEE 29119 Cho đến bây giờ vẫn chưa có tiêu chuẩn kiểm thử phần mềm rõ ràng. Người tiêu dùng các dịch vụ kiểm thử phần mềm có thể không chỉ đơn giản là tìm kiếm “dấu hiệu của sự tuân thủ” và những người kiểm thử không có tài liệu thực hành tốt. Có nhiều tiêu chuẩn đề cập đến kiểm thử phần mềm, nhưng nhiều tiêu chuẩn trong số đó chồng chéo nhau và có những xung đột trong các định nghĩa, quy trình và thủ tục. Có một số tiêu chuẩn kiểm thử của IEEE rất hữu ích (ví dụ như IEEE 829, IEEE 1028) và tiêu chuẩn quốc gia (ví dụ: BS 7925-1 và BS 7925-2) nhưng những tiêu chuẩn này vẫn có những thiếu xót lớn trong tiêu chuẩn hóa kiểm thử phần mềm đó là không có kiểm thử tổ chức, quản lý kiểm thử và kiểm thử phi chức năng.

Với những xung đột và thiếu xót đề cập ở trên, giải pháp lý tưởng là cần phải phát triển một bộ các tiêu chuẩn kiểm thử phần mềm quốc tế có mức độ kiểm thử rộng hơn. Lý tưởng là xây dựng một bộ tiêu chuẩn mới về kiểm thử dựa trên các tiêu chuẩn có sẵn. Đó là động lực để xây dựng bộ tiêu chuẩn ISO/IEC/IEEE 29119.

5.1.5. Cấu trúc tổng thể của bộ tiêu chuẩn ISO 29119Đề xuất về một bộ tiêu chuẩn mới về kiểm thử phần mềm đã được ISO phê duyệt vào tháng 5 năm 2007, bộ tiêu chuẩn này được xây dựng dựa trên các tiêu chuẩn của IEEE và BSI hiện có (IEEE 829, IEEE 1008, BS 7925-1 và BS 7925-2). Vì không có nhóm làm việc có chuyên môn về kiểm thử phần mềm trong tiểu ban SC7 nên một nhóm làm việc mới có tên "Kiểm thử phần mềm” (WG26) đã được thành lập. Đến năm 2013, đã có hơn 20 quốc gia khác nhau đại diện tham dự nhóm WG26.Đề xuất ban đầu là bộ tiêu chuẩn về kiểm thử phần mềm gồm bốn phần; Hình 2 cho thấy các tiêu chuẩn kiểm thử của IEEE và BSI được dùng để xây dựng các phần từ phần 1 đến phần 4 của bộ tiêu chuẩn mới về kiểm thử (IEEE 1008 không được trình bày ở trong hình này vì nhóm làm việc không thể tìm thấy tính hữu ích của nó). Khá sớm sau khi bốn phần đầu tiên của bộ tiêu chuẩn được đưa ra, tiêu chuẩn ISO 33063 về đánh giá quy trình kiểm thử (đánh giá dựa theo các quy trình kiểm thử được định nghĩa trong phần 2) đã được tạo ra như là kết quả của một đề xuất riêng biệt, phần này vẫn đang được phát triển cùng với

18

nhóm WG10 (đánh giá quy trình) và WG26. Việc đưa một tiêu chuẩn riêng về kiểm thử hướng từ khóa (phần 5) vẫn đang dự thảo.

Hình 3 - Các phần của bộ các tiêu chuẩn về kiểm thử phần mềm ISO/IEC/IEEE 29119

Mô hình cơ bản được sử dụng làm cơ sở cho bộ tiêu chuẩn mới về kiểm thử ISO/IEC/IEEE 29119 được trình bày trong hình 3, bộ tiêu chuẩn này bao gồm bốn phần cơ bản, trong đó phần 2: Quy trình kiểm thử là phần cốt lõi, phần 3: Tài liệu kiểm thử được tạo ra như là kết quả của việc thực hiện các quy trình kiểm thử, do đó tài liệu kiểm thử mô tả các kết quả đầu ra của quy trình kiểm thử. Các yêu cầu để sử dụng các kỹ thuật kiểm thử để thực hiện kiểm thử (ví dụ như thiết kế các trường hợp kiểm thử) được định nghĩa trong phần 4: Các kỹ thuật kiểm thử, trong khi các kỹ thuật thực tế được xác định riêng. Các thuật ngữ được sử dụng cho các phần khác của bộ tiêu chuẩn này được định nghĩa trong phần 1: Khái niệm và định nghĩa.

5.1.6. Tình trạng của ISO/IEC/IEEE 29119Một tiêu chuẩn ISO tiêu biểu phải thực hiện trên 7 năm mới xuất bản, mặc dù quy định để hoàn thành một tiêu chuẩn đã được thắt chặt trong những năm gần đây nhằm nỗ lực và khuyến khích xuất bản nhanh hơn. Ví dụ, tiêu chuẩn khung ISO về các quy trình vòng đời phần mềm như ISO 12207 được hình thành vào năm 1988 nhưng đến năm 1995 mới xuất bản và tương ứng mỗi người phải nỗ lực 17000 giờ để thực hiện. Tiêu chuẩn BS 7925-1 và BS 7925-2 phải mất 8 năm để phát triển, và IEEE ước tính vào năm 1998 sẽ phải mất 2-4 năm để phát triển một tiêu chuẩn, với chi phí từ $ 2.000 đến $ 10.000 mỗi trang.

Tiến trình xuất bản bộ tiêu chuẩn ISO/IEC 29119 chậm hơn so với dự kiến - nhưng chủ yếu là do kỳ vọng của SC7 chứ không phải bản thân nhóm WG26. SC7 kỳ vọng là bộ tiêu chuẩn ISO/IEC 29119 được xây dựng dựa trên các IEEE và tiêu chuẩn của Anh trước đây (xem hình 2). Mặt khác, nhóm WG26 đã biết ngay từ đầu rằng các tiêu chuẩn quy trình kiểm thử "lõi" sẽ cần phải được phát triển từ vạch xuất phát vì các tiêu chuẩn được tặng chỉ cung cấp các quy trình kiểm thử đơn vị và không có các quy trình kiểm thử ở bất kỳ

19

cấp nào khác (như vậy sẽ không có các quy trình kiểm thử cấp tổ chức hoặc quy trình quản lý kiểm thử).

Như trình bày trong hình 3, các phần của bộ tiêu chuẩn mới về kiểm thử 29119 đã được phát triển trong một vài “đợt”. Điều này một phần là do thiếu các biên tập viên để thực hiện tất cả bốn phần của bộ tiêu chuẩn cùng một lúc.

Hình 4 - Các mốc thời gian phát triển các phần bộ tiêu chuẩn ISO/IEC 291195.1.7. Phương pháp kiểm thử trong ISO 29119Bộ các tiêu chuẩn quốc tế mới về kiểm thử được mong đợi càng gồm đầy đủ các phần càng tốt, do các phần của bộ tiêu chuẩn là rất thông dụng và có khả năng hỗ trợ kiểm thử trong nhiều lĩnh vực ứng dụng và dùng cho các mức kiểm thưc khác nhau. Nếu các tiêu chuẩn quy định liên quan đến an toàn yêu cầu phải thực hiện kiểm thử để đạt được một mức độ bao phủ kiểm thử nhất định thì bộ những tiêu chuẩn mới này đưa ra các quy trình kiểm thử để người kiểm thử làm theo, nó xác định các kỹ thuật thiết kế kiểm thử và các biện pháp để sử dụng và thực hiện tương ứng với quy trình. Mặt khác, các tiêu chuẩn này cũng được biên soạn nhằm đảm bảo việc sử dụng kiểm thử thăm dò không bị loại trừ do việc tuân thủ các tiêu chuẩn nếu họ (hoặc khách hàng của họ) mong muốn như vậy. Các tiêu chuẩn này không phải tiêu chuẩn dạng chung cho bất kỳ vòng đời cụ thể nào, vì vậy nó có thể áp dụng cho việc kiểm thử dự án sử dụng các mô hình phát triển phần mềm tuần tự, mô hình iterative và mô hình agile. Ví dụ, phần 3 của bộ tiêu chuẩn này đưa ra các ví dụ cho từng loại tài liệu kiểm thử đối với cả dự án triển khai theo mô hình tuận tự và mô hình iterative.

Các bản dự thảo của các tiêu chuẩn đã được sử dụng bởi một loạt các doanh nghiệp từ nhỏ nhất đến một số các tổ chức đa quốc gia lớn nhất. Việc này đã cung cấp thông tin phản hồi tuyệt vời để cải tiến các dự thảo - và tin chắc rằng các phương pháp kiểm thử sẽ được thực hiện tốt trong thực tế.

5.1.8. Kiểm thử dựa trên rủi ro và bộ tiêu chuẩn ISO 29119Khi phát triển bộ các tiêu chuẩn mới về kiểm thử bao gồm công nghệ (kỹ thuật kiểm thử) mới nhất có thể là một rào cản đối với việc chấp nhận (thông qua) nó, do đó cần phải lưu ý để để tránh điều này trong bộ các tiêu chuẩn mới ISO/IEC/IEEE 29119. Một số người

20

có thể cho rằng kiểm thử tiến triển quá chậm nên có rất ít kiểm thử mà có thể được mô tả như là công nghệ mũi nhọn. Có thể trong khoảng thời gian gần nhất, các tiêu chuẩn mới về kiểm thử có thể đưa ra các yêu cầu được mọi người bàn đến nhiều nhất để khẳng định sự tuân thủ là bắt phải sử dụng một phương pháp kiểm thử dựa trên rủi ro.

Kiểm thử dựa trên rủi ro (RBT) đã rất nổi bật trong vòng hơn 20 năm, và được công nhận là một phương pháp chủ đạo trong hơn nửa thời gian đó, giờ nó là một phần không thể thiếu trong hệ thống cấp chứng chỉ phổ biến, chẳng hạn như chứng chỉ kiểm thử phần mềm quốc tế ISTQB (với hơn 250.000 kỹ sư kiểm thử có chứng chỉ ISTQB trên toàn thế giới). Mặc dù vậy, nhưng thực tế là RBT không phải là một phương pháp phức tạp về lý thuyết, người ta vẫn hiếm thấy RBT đang được áp dụng thành công như nó có thể và rất nhiều học viên kiểm thử có vẻ “hạnh phúc” không biết gì về nó.

Khi sử dụng RBT, phải phân tích rủi ro để xác định và loại bỏ rủi ro, do đó những rủi ro nhận thức trong hệ thống cung cấp (và phát triển của hệ thống này) có thể được ưu tiên và phân loại. Việc ưu tiên nhằm xác định thứ tự kiểm thử (rủi ro ưu tiên cao hơn được giải quyết sớm hơn), trong khi các loại rủi ro được sử dụng để quyết định các hình thức kiểm thử thích hợp nhất để thực hiện (ví dụ giai đoạn kiểm thử nào, kỹ thuật kiểm thử nào và điều kiện kết thúc kiểm thử nào được sử dụng). Một tác dụng không mong muốn của việc sử dụng phương pháp này là bất kỳ thời điểm nào rủi ro được truyền đi có thể chỉ đơn giản là truyền đi là những rủi ro còn tồn tại (những rủi ro chưa được kiểm chứng). Các kết quả thực hiện kiểm thử dựa trên rủi ro nhận thức và do tình hình phát triển kinh doanh một cách tự nhiên sẽ thay đổi nguy cơ rủi ro theo thời gian do đó đòi hỏi RBT phải được xem như là một hoạt động liên tục. Các bên liên quan dồn hết tâm trí vào các hoạt động này để đảm bảo rằng càng lưu ý được nhiều rủi ro càng tốt và thống nhất được cách xử lý tương ứng (hoặc không nếu quyết định không giải quyết rủi ro).

Tuy nhiên các ứng dụng của RBT không được áp dụng một cách có hiệu quả trên nhiều dự án. Điều này là do phạm vi áp dụng của RBT quá hẹp, nó không bao gồm các cấp độ cao hơn của kiểm thử, chẳng hạn như trong các chiến lược kiểm thử tổ chức, và nó không được sử dụng làm cơ sở cho việc lập kế hoạch kiểm thử bao gồm toàn bộ cuộc sống chu kỳ. RBT cũng có thể không đáp ứng được kỳ vọng khi nó không được tích hợp vào các hoạt động quản lý rủi ro rộng hơn trong một tổ chức, hoặc khi RBT chỉ được sử dụng để giải quyết các rủi ro trong các phần mềm chuyển giao hơn là xem xét các rủi ro đối với các hoạt động kiểm thử. Những thách thức này phần lớn có thể được giải quyết bởi ngành công nghiệp thay đổi quan điểm của mình về RBT và mở rộng quan điểm của mình. Các tiêu chuẩn mới về kiểm thử có thể không giải quyết vấn đề này mặc dù nó đề cập đến RBT, nó không chỉ rõ cách thức RBT được áp dụng.

Tuy nhiên, các tiêu chuẩn mới về kiểm thử có thể nâng cao hiểu biết về RBT trong cộng đồng kiểm thử. Có lẽ là thách thức lớn nhất đối với việc sử dụng có hiệu quả của RBT là thiếu sự thuần thục của các những người hành nghề kiểm thử, và nếu bộ các tiêu chuẩn mới được công nhận và việc những người hành nghề kiểm thử nắm bắt được RBT sẽ “khuyến khích” nhiều trong lĩnh vực này.

5.1.9. Các phần của bộ tiêu chuẩn ISO/IEC/IEEE 29119Bộ tiêu chuẩn này gồm một tập các tiêu chuẩn quốc tế về kiểm thử phần mềm có thể được áp dụng cho bất kỳ chu kỳ phát triển phần mềm hoặc tổ chức nào, gồm có các quy trình, tài liệu, các công nghệ, kiểm thử hướng từ khóa. Bộ tiêu chuẩn này gồm 5 phần:- ISO/IEC 29119-1: 2013 Định nghĩa và khái niệm

21

http://www.softwaretestingstandard.org/part1.php

- ISO/IEC 29119-2: 2013 Các quy trình kiểm thử - ISO/IEC 29119-3: 2013 Tài liệu kiểm thử- ISO/IEC 29119-4: 2015 Các kỹ thuật kiểm thử phần mềm - ISO/IEC 29119-5: Kiểm thử hướng từ khóa (đang dự thảo)

Bộ tiêu chuẩn ISO/IEC/IEEE 29119 ra sẽ đời thay thế một số các tiêu chuẩn hiện tại về kiểm thử phần mềm:- IEEE 829 Test Documentation- IEEE 1008 Unit Testing- BS 7925-1 Vocabulary of Terms in Software Testing- BS 7935-2 Software Component Testing Standard

5.1.9.1 Phần 1 (ISO/IEC/IEEE 29119-1)Phần 1 giới thiệu về bộ tiêu chuẩn và bao gồm toàn bộ các định nghĩa áp dụng cho tất cả các phần khác của bộ tiêu chuẩn cũng như mô tả các khái niệm kiểm thử cơ bản mà bộ tiêu chuẩn được xây dựng. Phần này (được trình bày trong hình 5) giải thích những phần khác nhau của bộ tiêu chuẩn là gì và cách thức tiêu chuẩn có thể được sử dụng bởi những mô hình vòng đời khác nhau dưới đây. Phần 1 có thể được coi là nền tảng của các tiêu chuẩn kiểm thử phần mềm của IEEE.

Hình 5 - ISO/IEC 29119 Phần 1 - Khái niệm và từ vựngMục đích của ISO/IEC/IEEE 29119-1 là giúp người đọc nắm bắt và sử dụng các tiêu chuẩn khác trong bộ tiêu chuẩn ISO/IEC/IEEE 29119 một cách dễ dàng. Tiêu chuẩn ISO/IEC/IEEE 29119-1 giới thiệu các từ vựng trong đó tất cả các tiêu chuẩn trong bộ tiêu chuẩn ISO/IEC/IEEE 29119 được xây dựng và cung cấp các ví dụ việc áp dựng từng khái niệm trong thực tế. ISO/IEC/IEEE 29119-1 trình bày các định nghĩa và miêu tả các khái niệm về kiểm thử phần mềm và cách áp dụng các quy trình, tài liệu và các kỹ thuật được định nghĩa trong bộ tiêu chuẩn ISO/IEC/IEEE 29119.

22




5.1.9.2. Phần 2 (ISO/IEC/IEEE 29119-2)ISO/IEC/IEEE 29119-2 định nghĩa một mô hình quy trình chung về kiểm thử phần mềm, có thể được sử dụng trong bất kỳ vòng đời phát triển phần mềm (SDLC) nào. Vai trò của quy trình kiểm thử phần mềm là để kiểm soát, quản lý và thực thi kiểm thử phần mềm trong bất kỳ tổ chức, dự án hoặc hoạt động kiểm thử phần mềm nào. Tiêu chuẩn kiểm thử phần mềm ISO/IEC/IEEE 29119-2 chú trọng đến việc giảm thiểu rủi ro, và do đó nó áp dụng phương pháp kiểm thử dựa trên rủi ro. Việc thực hiện tiêu chuẩn ISO/IEC/IEEE 29119-2 cho phép kiểm thử phần mềm được ưu tiên và tập trung vào các tính năng quan trọng nhất và các thuộc tính chất lượng của từng hệ thống cần kiểm thử.Các quy trình kiểm thử trong phần 2 của bộ tiêu chuẩn ISO/IEC/IEEE 29119 được định nghĩa sử dụng một mô hình 3 lớp như được trình bày trong hình 6.

Hình 6 - ISO/IEC/IEEE 29119 Phần 2 - Các quy trình kiểm thửĐáng chú ý là lớp thấp nhất trong mô hình được định nghĩa là các quy trình kiểm thử động, do đó, mô hình tổng thể không bao gồm bất kỳ quy trình kiểm thử tĩnh nào. Điều này là bởi vì không thể đạt được sự đồng thuận trong trong nhóm WG26 (hoặc SC7) về việc đưa ra quy trình kiểm thử tĩnh trong tiêu chuẩn này. Điều này sẽ được giải quyết trong các phiên bản tiếp theo.

Mặc dù kế hoạch kiểm thử được phát triển áp dụng cho tiêu chuẩn ISO/IEC/IEEE 29119 được dự kiến sẽ bao gồm việc xem xét cả kiểm thử tĩnh và kiểm thử động, nhưng lớp thấp nhất của các quy trình kiểm thử trong bộ tiêu chuẩn ISO/IEC/IEEE 29119 hiện chỉ giới hạn ở kiểm thử động. Các quy trình kiểm thử động này sẽ được thực thi bất cứ khi nào kế hoạch kiểm thử đưa ra kiểm thử động (ví dụ kiểm thử đơn vị, kiểm thử hệ thống, kiểm thử hiệu năng).

23

Hình 7 - Tám quy trình kiểm thử trong ISO/IEC/IEEE 29119 Hình 7 cho thấy một bộ hoàn chỉnh tám quy trình kiểm thử quy định trong bộ tiêu chuẩn ISO/IEC/IEEE 29119. Mỗi quy trình được tạo thành từ một tập hợp các hoạt động, các hoạt động này bao gồm một tập hợp các nhiệm vụ cụ thể. 5.1.9.3. Phần 3 (ISO/IEC/IEEE 29119-3)Có một mối liên kết chặt chẽ giữa phần 2 (quy trình kiểm thử) và phần 3 (tài liệu kiểm thử). Các đầu ra của các quy trình quy định tại phần 2 nhìn chung tương ứng với các tài liệu hướng dẫn kiểm thử quy định tại phần 3. Vì phần 3 là một tiêu chuẩn về tài liệu kiểm thử, nó phải tuân theo các cấu trúc và định dạng được định nghĩa trong ISO/IEC 15289.Cấu trúc cơ bản của phần 3 được trình bày trong hình 8 - các phụ lục kèm theo dự kiến sẽ được sử dụng cho hầu hết cho những người thực hiện kiểm thử.

Hình 8 - ISO/IEC/IEEE 29119 Phần 3 - Tài liệu kiểm thử

24

ISO/IEC/IEEE 29119-3 quy định các mẫu tài liệu kiểm thử phần mềm có thể được sử dụng cho bất kỳ tổ chức, dự án hoặc hoạt động kiểm thử nào. Tài liệu kiểm thử mô tả trong phần này chính là đầu ra của các quy trình kiểm thử được quy định trong ISO/IEC/IEEE 29119-2. Mỗi mẫu tài liệu quy định trong tiêu chuẩn ISO/IEC/IEEE 29119-3 được thiết kế dựa trên những yêu cầu của tổ chức. Tiêu chuẩn này sẽ thay thế tiêu chuẩn IEEE 829.Mục đích của ISO/IEC/IEEE 29119-3 là cung cấp các mẫu tài liệu hướng dẫn kiểm thử phần mềm bao trùm toàn bộ chu kỳ kiểm thử phần mềm. Mỗi mẫu tài liệu có thể được thay đổi cho phù hợp với nhu cầu riêng của từng tổ chức khi triển khai thực hiện các tiêu chuẩn để hỗ trợ việc thực hiện tiêu chuẩn trong bất kỳ mô hình vòng đời phát triển phần mềm nào. Tất cả các mẫu tài liệu phù hợp với các quy trình kiểm thử trong ISO/IEC/IEEE 29119-2 và có thể được tạo ra cách áp dụng các quy trình được quy định trong tiêu chuẩn đó.Các tài liệu được đề cập trong ISO/IEC/IEEE 29119-3 bao gồm:

+ Tài liệu hướng dẫn quy trình kiểm thử của tổ chức, bao gồm:- Chính sách kiểm thử- Chiến lược kiểm thử của tổ chức.+ Tài liệu hướng dẫn quy trình quản lý kiểm thử, bao gồm:- Kế hoạch kiểm thử.- Báo cáo tình trạng kiểm thử- Báo cáo kết thúc kiểm thử+ Tài liệu hướng dẫn quy trình kiểm thử động, bao gồm:- Tài liệu đặc tả thiết kế kiểm thử- Tài liệu đặc tả trường hợp kiểm thử- Tài liệu đặc tả thủ tục kiểm thử- Những yêu cầu về dữ liệu kiểm thử- Báo cáo tính sẵn sàng dữ liệu kiểm thử - Những yêu cầu về môi trường kiểm thử- Báo cáo tính sẵn sàng của môi trường kiểm thử- Kết quả thực tế- Kết quả kiểm thử- Bản ghi quá trình thực hiện kiểm thử- Báo cáo sự cố kiểm thử.

5.1.9.4. Phần 4 (ISO/IEC/IEEE 29119-4)Những người sử dụng phần 2 của tiêu chuẩn được yêu cầu để tạo ra các kế hoạch kiểm thử bao gồm các yêu cầu về kỹ thuật thiết kế trường hợp kiểm thử được chỉ định (và được sử dụng) và điều kiện kết thúc kiểm thử đạt được. Các kỹ thuật thiết kế trường hợp kiểm thử và các phương pháp bao phủ tương ứng được quy định tại phần 4 của bộ tiêu chuẩn. Mỗi kỹ thuật thiết kế trường hợp kiểm thử được định nghĩa chính thức (trong phần quy định của tiêu chuẩn), nhưng các ví dụ tương ứng cho thấy cách thức áp dụng các kỹ thuật được trình bày trong các phụ lục.

25

Phần 4 được trình bày trong hình 9. Phần 4 được xây dựng dựa trên BS 7925-2, vì vậy người sử dụng tiêu chuẩn này sẽ nhận thấy sự tương ứng chặt chẽ với phần 4. Có sự khác biệt đáng kể so với BS 7925-2 là phần 4 có phụ lục về kiểm thử các đặc tính chất lượng (tức là kiểm thử phi chức năng). Điều này cho thấy các kỹ thuật thiết kế kiểm thử là thích hợp cho việc kiểm thử từng đặc tính chất lượng được xác định trong bộ tiêu chuẩn ISO/IEC 25000 (SQuaRE).

Hình 9 - ISO/IEC/IEEE 29119 Phần 4 - Các kỹ thuật kiểm thửMục đích của ISO/IEC/IEEE 29119-4 là định nghĩa một tiêu chuẩn quốc tế bao gồm các kỹ thuật kiểm thử phần mềm (cũng được biết đến như là các kỹ thuật thiết kế trường hợp kiểm thử và các phương pháp kiểm thử) mà có thể được sử dụng trong suốt quy trình Thiết kế và chuẩn bị kiểm thử trong bất kỳ tổ chức hoặc mô hình chu kỳ phát triển phần mềm nào.Danh mục các kỹ thuật thiết kế trường hợp kiểm thử trong phần 4 bao gồm: Các kỹ thuật kiểm thử dựa trên đặc tả- Phân tích giá trị biên - Đồ thị nguyên nhân - kết quả- Phương pháp phân loại cây- Kỹ thuật kiểm thử tổ hợp- Bảng quyết định- Phân vùng tương đương- Đoán lỗi- Kiểm thử ngẫu nhiên- Kiểm thử theo kịch bản- Mô hình trạng thái - Kiểm thử theo cú pháp

Các kỹ thuật kiểm thử dựa trên cấu trúc

26

- Kiểm thử nhánh/ kiểm thử dựa trên bảng quyết định - Kiểm thử điều kiện nhánh- Kiểm thử kết hợp điều kiện nhánh- Kiểm thử luồng dữ liệu- Kiểm thử bao phủ quyết định điều kiện (MCDC)- Kiểm thử câu lệnh

Các kỹ thuật kiểm thử dựa trên kinh nghiệm- Đoán lỗi.

5.1.9.5. Phần 5 (ISO/IEC/IEEE 29119-5)ISO/IEC/IEEE 29119-5 là phần 5 của tiêu chuẩn kiểm thử phần mềm ISO/IEC/IEEE 29119. Tiêu chuẩn ISO/IEC/IEEE 29119-5 đưa ra một chuẩn quốc tế để hỗ trợ kiểm thử hướng từ khóa. Mục đích của ISO/IEC/IEEE 29119-5 là định nghĩa một tiêu chuẩn quốc tế để hỗ trợ kiểm thử hướng từ khóa. Kiểm thử hướng từ khóa là cách miêu tả các trường hợp kiểm thử bằng cách sử dụng một bộ từ khóa được xác định trước. Các từ khóa này là những tên mà được liên kết với một tập các hành động được yêu cầu để thực hiện một bước cụ thể trong một trường hợp kiểm thử. Bằng cách sử dụng các từ khóa miêu tả các bước kiểm thử thay vì sử dụng ngôn ngữ tự nhiên, các trường hợp kiểm thử có thể dễ hiểu, duy trì và tự động hóa hơn. Phần này hiện vẫn đang dự thảo.5.1.9. Kết luậnVới chi phí cao cho kiểm thử và tính kỷ luật cao nhưng thật ngạc nhiên khi một bộ hoàn chỉnh các tiêu chuẩn kiểm thử vẫn không có. Ngoài nhu cầu của người tiêu dùng các dịch vụ kiểm thử và những người tham gia thực hiện kiểm thử đang mong muốn có tài liệu hướng dẫn về thực hành kiểm thử, thì hiện nay nhiều đơn vị cũng có nhu cầu có một tiêu chuẩn để dùng làm kiến thức thực hiện chứng nhận kiểm thử. Trong nhiều năm, các tiêu chuẩn phát triển phần mềm có phạm vị ứng dụng liên quan đến an toàn và/hoặc các tiêu chuẩn phát triển phần mềm có ứng dụng cụ thể đã quy định các hình thức kiểm thử được thực hiện và các điều kiện kết thúc kiểm thử khác nhau cần đạt được, nhưng vẫn chưa có tiêu chuẩn nào mô tả cách thức thực hiện kiểm thử cũng không mô tả cách thức tính mức bao phủ kiểm thử. Bộ các tiêu chuẩn ISO/IEC/IEEE 29119 mới về kiểm thử phần mềm sẽ giúp giải quyết các vấn đề này.Bộ tiêu chuẩn mới về kiểm thử này đưa ra những thực hành về kiểm thử ở mức tổ chức (qua nhiều dự án), kiểm thử ở cấp quản lý (lập kế hoạch, giám sát và kiểm soát và kết thúc kiểm thử), và những thực hành cho các quy trình thiết kế và thực hiện kiểm thử động. Cũng như các quy trình kiểm thử (mà đặc biệt là phương pháp kiểm thử dựa trên rủi ro), tài liệu hướng dẫn kiểm thử, các kỹ thuật thiết kế trường hợp kiểm thử và từ vựng kiểm thử cũng được đề cập trong bộ các tiêu chuẩn mới này. Các tiêu chuẩn bổ sung đang được phát triển sau khi xuất bản các phần đầu tiên đó là tiêu chuẩn đánh giá quy trình kiểm thử và tiêu chuẩn kiểm thử hướng từ khóa.Việc công bố bộ các tiêu chuẩn mới ISO/IEC/IEEE 29119 về kiểm thử phần mềm đã được bắt đầu, bộ tiêu chuẩn cung cấp cho ngành kiểm thử (và khách hàng của họ) một khối lượng kiến thức về kiểm thử đã được quốc tế chấp nhận. Các tiêu chuẩn kiểm thử được xây dựng dựa trên các tài liệu nguồn từ IEEE và BSI mà sau đó các nguồn tài liệu

27

này sẽ bị "hủy bỏ". Bộ các tiêu chuẩn kiểm thử này là thành quả của hơn 6 năm làm việc của một nhóm các chuyên gia đến từ hơn 20 quốc gia.

5.2. Nghiên cứu nội dung tiêu chuẩn ISO/IEC/IEEE 29119-2: Quy trình kiểm thử5.2.1. Khái quát tiêu chuẩn gốc ISO/IEC/IEEE 29119-2Theo như phân tích ở phần trên thì bộ tiêu chuẩn mới về kiểm thử phần mềm được bắt đầu xây dựng vào tháng 5 năm 2007 gồm 5 phần nhưng đến tháng 9 năm 2013 mới có 3 phần đầu tiên được xuất bản, đó là: phần 1, phần 2, phần 3. Do đó ISO/IEC/IEEE 29119-2:2013 là phiên bản mới nhất hiện nay có tên gọi đầy đủ là ISO/IEC/IEEE 29119-2 Software and systems engineering-Software testing - Part 2: Test processes. ISO/IEC/IEEE 29119-2 là tiêu chuẩn về kiểm thử phần mềm, được chuẩn bị bởi Ủy ban kỹ thuật liên hợp ISO/IEC JTC 1 về công nghệ thông tin (Joint Technical Committee ISO/IEC JTC) và Tiểu ban SC 7 về các kỹ thuật và hệ thống phần mềm (Subcommittee SC 7, Software and systems engineering) hợp tác cùng với Ủy ban các tiêu chuẩn về kỹ thuật hệ thống và phần mềm của hiệp hội máy tính IEEE, dưới sự thỏa thuận hợp tác của tổ chức phát triển các tiêu chuẩn giữa ISO và IEEE.

Mục đích của ISO/IEC/IEEE 29119-2 là định nghĩa một mô hình quy trình chung để kiểm thử phần mềm mà có thể được sử dụng trong bất kỳ vòng đời phát triển phần mềm nào. Mô hình này quy định các quy trình kiểm thử có thể được sử dụng để kiểm soát, quản lý và thực thi kiểm thử phần mềm trong bất kỳ tổ chức, dự án hoặc hoạt động kiểm thử phần mềm nào. Có 8 quy trình kiểm thử (như được trình bày trong hình 7): Quy trình kiểm thử của tổ chức (chỉ có một quy trình)Quy trình quản lý kiểm thử có 3 quy trình: Quy trình Lập kế hoạch kiểm thử Quy trình Giám sát và kiểm soát kiểm thử Quy trình kết thúc kiểm thử

Quy trình kiểm thử động có 4 quy trình: Quy trình Thiết kế và chuẩn bị kiểm thử Quy trình Thiết lập và duy trì môi trường kiểm thử Quy trình Thực hiện kiểm thử Quy trình Báo cáo sự cố kiểm thử

Mỗi quy trình đều có cấu trúc chung, nó bao gồm:- Tên quy trình- Mục đích của quy trình- Kết quả của quy trình- Các hoạt động- Các nhiệm vụ- Đầu ra của quy trình.

5.2.1.1. Quy trình kiểm thử của tổ chức Quy trình kiểm thử của tổ chức được sử dụng để triển khai và quản lý các tài liệu đặc tả kiểm thử của tổ chức. Những đặc tả này thường được dùng trong toàn bộ tổ chức (tức là

28

đặc tả này không áp trên dự án cụ thể). Chính sách kiểm thử và chiến lược kiểm thử của tổ chức là những ví dụ về đặc tả kiểm thử của tổ chức. Quy trình kiểm thử của tổ chức thường chỉ mang tính chung chung và có thể được sử dụng để triển khai và quản lý các tài liệu kiểm thử cụ thể phi dự án, chẳng hạn như chiến lượng kiểm thử có thể áp dụng cho một số dự án liên quan.Chính sách kiểm thử của tổ chức là một tài liệu liên quan đến việc quản lý và thực hiện các kế hoạch, nó mô tả mục đích, mục tiêu và phạm vi tổng thể của quá trình kiểm thử trong một tổ chức. Nó cũng đưa ra các thực hành kiểm thử của tổ chức và cung cấp một khuôn mẫu để thiết lập, xem xét đánh giá và cải tiến liên tục chính sách, chiến lược kiểm thử của tổ chức và phương pháp để lập kế hoạch quản lý kiểm thử.Chiến lược kiểm thử của tổ chức là một tài liệu kỹ thuật chi tiết định nghĩa cách thức thực hiện kiểm thử trong tổ chức. Đây là một tài liệu chung cung cấp các hướng dẫn cho một số dự án trong tổ chức và nó không phải là tài liệu cụ thể phi dự ánChỉ có một Quy trình kiểm thử của tổ chức và các hoạt động của quy trình này được trình bày trong hình 10. Nó được sử dụng để phát triển và duy trì các tài liệu đặc tả kỹ thuật kiểm thử tổ chức, phổ biến nhất của tài liệu đặc tả kỹ thuật kiểm thử đó là các chính sách kiểm thử và chiến lược kiểm thử tổ chức. Tài liệu đặc tả kiểm thử tổ chức thường áp dụng cho một số (nếu không phải tất cả) các dự án trong một tổ chức, như vậy tài liệu đặc tả kiểm thử tổ chức không phải là dự án cụ thể - chúng đảm bảo phương pháp kiểm thử phù hợp được duy trì cho tất cả các dự án. Nếu tổ chức đủ lớn để thực hiện các dự án mà khác hoàn toàn (ít nhất là trong các chương trình khác nhau) thì có thể có các tài liệu đặc tả kiểm thử tổ chức riêng biệt cho từng chương trình.Mục đích của Quy trình kiểm thử của tổ chức là để triển khai, giám sát việc tuân thủ và duy trì các đặc tả kiểm thử của tổ chức, cụ thể như chính sách và chiến lược kiểm thử của tổ chức.

Hình 10- Quy trình kiểm thử của tổ chứcChính sách kiểm thử định nghĩa phạm vi kiểm thử, mô tả các nguyên tắc và mục tiêu kiểm thử mức cao dự kiến của tất cả các kiểm thử trong một tổ chức. Nó được dự kiến là một

29

tài liệu cấp cao chỉ có hai trang đó mà các thành viên có thể hiểu, và phù hợp với các chính sách cấp điều hành khác, chẳng hạn như chính sách chất lượng. Chính sách kiểm thử cung cấp hướng dẫn và những hạn chế về chiến lược kiểm thử tổ chức và hoạt động như một khuôn khổ mà trong đó tất cả các kiểm thử của tổ chức phải được thực hiện. Nội dung của chính sách kiểm thử có thể là “tất cả kiểm thử phù hợp với các tiêu chuẩn kiểm thử phần mềm ISO/IEC/IEEE 29119”.

Ngược lại với các chính sách kiểm thử, chiến lược kiểm thử tổ chức là một tài liệu kỹ thuật đưa ra thực hành kiểm thử trên tất cả các dự án của tổ chức, dự kiến bao gồm nhiều trang. Chiến lược kiểm thử phải phù hợp với chính sách kiểm thử (giả sử có một) và định nghĩa một tập hợp các nguyên tắc kiểm thử có thể tái sử dụng mà có thể được người quản lý kiểm thử sử dụng như là cơ sở cho kế hoạch kiểm thử cụ thể, do đó làm giảm các quyết định cần thiết ở mức kiểm thử của mình và đảm bảo tính thống nhất giữa các dự án. Nội dung của chiến lược kiểm thử tổ chức có thể là “điều kiện đầu ra cho kiểm thử đơn vị phải đạt được mức bao phủ câu lệnh 100%”.Kết quả triển khai thành công của Quy trình kiểm thử của tổ chức gồm:- Các yêu cầu đối với đặc tả kiểm thử của tổ chức được xác định; - Các đặc tả kiểm thử của tổ chức được triển khai; - Các đặc tả kiểm thử của tổ chức được các bên liên quan chấp thuận;- Các đặc tả kiểm thử của tổ chức được phép sử dụng;- Sự tuân thủ các đặc tả kiểm thử của thử tổ chức được giám sát;- Những cập nhật đối với đặc tả kiểm thử của tổ chức phải được các bên liên quan chấp thuận;- Những cập nhật đối với đặc tả kiểm thử của tổ chức được thực hiện.Đầu ra của quy trình kiểm thử: Kết quả thực hiện quy trình kiểm thử này sẽ tạo được đầu ra dưới đây:- Đặc tả kiểm thử của tổ chứcVí dụ: chính sách kiểm thử của tổ chức, chiến lược kiểm thử của tổ chức.

5.1.2.2. Các quy trình quản lý kiểm thử Có ba quy trình quản lý kiểm thử như trình bày trong hình 11, đó là:

- Quy trình lập kế hoạch kiểm thử;

- Quy trình giám sát và kiểm soát kiểm thử;

- Quy trình kết thúc kiểm thử.

Các quy trình này được sử dụng để quản lý các quy trình kiểm thử mức thấp hơn của một dự án cụ thể, chẳng hạn như kiểm thử động (như trình bày trong hình) kiểm thử tĩnh (không được trình bày trong hình vì không phải là một phần của tiêu chuẩn) và quản lý kiểm thử mức thấp hơn. Khi các quy trình quản lý kiểm thử được sử dụng ở mức dự án và dự án là đủ lớn, thì kế hoạch kiểm thử dự án này có thể đòi hỏi phải lập các kế hoạch kiểm thử và thực hiện cho từng giai đoạn kiểm thử (ví dụ như kiểm thử hệ thống, kiểm thử chấp nhận người dùng) hoặc các loại kiểm thử cụ thể (ví dụ: kiểm thử hiệu năng, kiểm thử khả năng sử dụng).

30

Hình 11 - Các quy trình quản lý kiểm thửTrong khi thực hiện các quy trình quản lý kiểm thử này, nên tuân thủ mọi ràng buộc hoặc các hướng dẫn được quy định trong chính sách kiểm thử hoặc chiến lược kiểm thử tổ chức, trừ khi có lý do để không tuân thủ, trong trường hợp này việc không tuân thủ nên được thỏa thuận và được ghi lại.

5.1.2.2.1. Quy trình lập kế hoạch kiểm thửQuy trình lập kế hoạch kiểm thử được sử dụng để triển khai kế hoạch kiểm thử. Tùy theo mức độ của dự án mà quy trình này đã thực hiện, kế hoạch kiểm thử này có thể là một bản kế hoạch chung cho dự án hoặc bản kế hoạch cho từng giai đoạn kiểm thử khác nhau như kế hoạch kiểm thử hệ thống hoặc bản kế hoạch cụ thể cho từng kiểu kiểm thử như kế hoạch kiểm thử hiệu năng.

Hình 12 trình bày các hoạt động cần thực hiện để xây dựng bản kế hoạch kiểm thử. Nội dung của bản kế hoạch kiểm thử được xây dựng thông qua việc thực hiện các hoạt động đã được xác định, bản dự thảo kế hoạch kiểm thử sẽ được xây dựng dần dần cho tới khi hoàn thiện sẽ được ghi lại. Do tính lặp đi lặp lại của quy trình, một số hoạt động được trình bày hình 12 có thể cần phải xem xét lại trước khi đưa ra bản kế hoạch kiểm thử hoàn thiện. Một số hoạt động tiêu biểu như TP3, TP4, TP5 và TP6 sẽ cần phải thực hiện đi thực hiện lại để đạt được bản kế hoạch kiểm thử có thể chấp nhận được

31

Hình 12 - Quy trình lập kế hoạch kiểm thửKết quả triển khai thành công của Quy trình lập kế hoạch kiểm thử gồm:- Phạm vi công việc của dự án kiểm thử đã được phân tích và nắm rõ;- Các bên liên quan mà sẽ tham gia vào việc lập kế hoạch kiểm thử đã được xác định và đã được thông báo;- Những rủi ro được xử lý thông qua kiểm thử đã được xác định, được đánh giá, phân loại theo mức độ ảnh hưởng của rủi ro;- Xác định chiến lược kiểm thử, môi trường kiểm thử, công cụ kiểm thử và dữ liệu kiểm thử;- Xác định nhu cầu về nhân lực và nhu cầu đào tạo; - Lập lịch trình cụ thể cho từng hoạt động kiểm thử;- Ngân sách được ước lượng, tính toán cụ thể; - Thỏa thuận kế hoạch kiểm thử với tất cả các bên liên quan và gửi tới tất cả các bên liên quan.Đầu ra của của Quy trình lập kế hoạch kiểm thử gồm:- Kế hoạch kiểm thử.

5.1.2.2.2. Quy trình giám sát và kiểm soát kiểm thửQuy trình giám sát và kiểm soát kiểm thử được trình bày trong hình 14 mô tả chi tiết liệu rằng các quy trình kiểm thử có phù hợp với kế hoạch kiểm thử và đặc tả kiểm thử của tổ chức như chính sách kiểm thử của tổ chức và chiến lược kiểm thử của tổ chức không. Nếu có những sai khác nhiều so với các hoạt động, tiến trình đã được lên kế hoạch, hoặc các

32

khía cạnh khác của kế hoạch kiểm thử thì sẽ phải thực hiện các hoạt động để chỉnh sửa hoặc bổ sung cho những sai khác này.

Quy trình này có thể được áp dụng để quản lý toàn bộ dự án kiểm thử (thông thường được thực hiện bởi một số kiểu kiểm thử và giai đoạn kiểm thử) hoặc quản lý quá trình kiểm thử của một giai đoạn riêng (ví dụ như kiểm thử hệ thống) hoặc một kiểu kiểm thử (ví dụ kiểm thử hiệu năng). Trong trường hợp sau nó được sử dụng như là một phần của hoạt động giám sát và kiểm soát kiểm thử động được mô tả trong Quy trình kiểm thử động. Khi nó được dùng như là một phần của hoạt động giám sát và kiểm soát kiểm thử một dự án hoàn chỉnh thì nó sẽ tương tác trực tiếp với các quy trình quản lý kiểm thử được sử dụng để quản lý các giai đoạn kiểm thử riêng lẻ và các kiểu kiểm thử dự án.

Hình 13 - Quy trình giám sát và kiểm soát kiểm thửKết quả triển khai thành công của Quy trình giám sát và kiểm soát kiểm thử gồm:

- Các phương thức tập hợp các phương pháp phù hợp để giám sát tiến trình kiểm thử và thay đổi rủi ro.

- Tiến trình kiểm thử dựa theo bản kế hoạch kiểm thử đã được giám sát;

- Những rủi ro liên quan đến kiểm thử đã được thay đổi và những rủi ro mới xuất hiện đã được xác định, phân tích và đưa ra hành động xử lý cần thiết.

- Đưa ra các hành động kiểm soát cần thiết;

- Thông báo cho các bên liên quan những hành động kiểm soát cần thiết;

- Quyết định về việc dừng kiểm thử phải được chấp thuận;

- Báo cho các bên liên quan tiến trình kiểm thử và những thay đổi liên quan đến rủi ro.

Đầu ra của Quy trình giám sát và kiểm soát kiểm thử gồm:

- Báo cáo tình trạng kiểm thử;

33

- Kế hoạch kiểm thử đã được cập nhật;

- Các hướng dẫn kiểm soát kiểm thử (Ví dụ: những thay đổi về kiểm thử, kế hoạch kiểm thử, dữ liệu kiểm thử, môi trường và bố trí nhân sự);

- Thông tin về rủi ro sản phẩm và dự án

5.1.2.2.3. Quy trình kết thúc kiểm thửQuy trình kết thúc kiểm thử được trình bày trong hình 14 được thực hiện khi đã có được sự thỏa thuận rằng tất cả các hoạt động kiểm thử đã hoàn tất. Quy trình này sẽ được thực hiện để kết thúc kiểm thử được tiến hành tại một giai đoạn kiểm thử cụ thể (ví dụ: kiểm thử hệ thống) hoặc một kiểu kiểm thử (ví dụ kiểm thử hiệu năng) và để kết thúc kiểm thử nghiệm đối với một dự án đã hoàn thành.

Hình 14 - Quy trình kết thúc kiểm thửKết quả triển khai thành công của Quy trình kết thúc kiểm thử gồm:a) Tài nguyên kiểm thử được lưu lại hoặc gửi trực tiếp cho các bên liên quan;b) Môi trường kiểm thử ở trong trạng thái sẵn sàng (ví dụ nó đã sẵn sàng cho dự án kiểm thử tiếp theo);c) Tất cả các yêu cầu kiểm thử được thỏa mãn và được xác minh;d) Báo cáo kết thúc kiểm thử được ghi lại;e) Báo cáo kết thúc kiểm thử được chấp thuận;f) Báo cáo kết thúc kiểm thử được thông báo cho các bên liên quan.Đầu ra của Quy trình kết thúc kiểm thử gồm:- Báo cáo kết thúc kiểm thử.5.1.2.3. Các quy trình kiểm thử động Có 4 quy trình kiểm thử động được trình bày trong hình 16, đó là:- Quy trình thiết kế và chuẩn bị kiểm thử;- Quy trình thiết lập và duy trì môi trường kiểm thử;

34

- Quy trình thực hiện kiểm thử; - Quy trình báo cáo sự cố kiểm thử.Cần lưu ý rằng nếu kiểm thử tĩnh cũng là một phần của tiêu chuẩn, hai quy trình (“Quy trình thiết lập môi trường kiểm thử” và “Quy trình báo cáo sự cố kiểm thử”) có thể được dùng chung giữa quy trình kiểm thử tĩnh và động vì cả hai quy trình kiểm thử tĩnh và động đòi hỏi phải có một môi trường kiểm thử và cả hai cũng đòi hỏi các lỗi phải được phân tích và sau đó báo cáo, khi cần thiết.

Hình 15 - Các Quy trình kiểm thử độngCác hoạt động kiểm thử động được đưa ra trong bản kế hoạch kiểm thử, chiến lược kiểm thử tổ chức và chính sách kiểm thử. Ví dụ, kế hoạch kiểm thử có thể chỉ rõ những tính năng được kiểm thử là gì, chiến lược kiểm thử tổ chức có thể chỉ rõ rằng điều kiện kết thúc kiểm thử nào đó đạt được, và các chính sách kiểm thử có thể chỏ rõ rằng báo cáo sự cố thực hiện theo quy trình quản lý lỗi của tổ chức.

Các mục tiêu được xác định trong kế hoạch kiểm thử được sử dụng để nhận biết các phương pháp kiểm thử mà được sử dụng để xác định cách thức kiểm thử thực tế theo kế hoạch kiểm thử. Định nghĩa của các phương pháp này, hoạt động so sánh với kế hoạch kiểm thử, và quyết định về những đáp ứng thích hợp được thực hiện trong quy trình “Giám sát và kiểm soát kiểm thử”.

5.1.2.3.1. Quy trình thiết kế và chuẩn bị kiểm thửQuy trình thiết kế và chuẩn bị kiểm thử được sử dụng để tạo ra các trường hợp kiểm thử và các thủ tục kiểm thử; các trường hợp kiểm thử và các thủ tục kiểm thử này thường được đưa ra trong đặc tả kiểm thử nhưng có thể được thực hiện ngay, ví dụ, nếu thực hiện kiểm thử thăm dò, chúng không được ghi trước trong tài liệu. Trong hình 17 các hoạt động này được trình bày theo một trình tự hợp lý, nhưng trong thực tế sẽ lặp đi lặp lại giữa rất nhiều các hoạt động, thường xuyên với các hoạt động TD3 đến TD5 xảy ra song song trong các khoảng thời gian thực tế.

35

Quy trình này đòi hỏi các kỹ sư kiểm thử phải áp dụng một hoặc nhiều kỹ thuật thiết kế kiểm thử để tạo ra các trường hợp kiểm thử và các thủ tục kiểm thử nhằm mục đích đạt được điều kiện kết thúc kiểm thử, thường được miêu tả bằng thuật ngữ đo mức bao phủ kiểm thử. Các kỹ thuật thiết kế kiểm thử và điều kiện kết thúc kiểm thử này được quy định trong kế hoạch kiểm thử. Các kỹ thuật thiết kế kiểm thử và các biện pháp được định nghĩa trong ISO/IEC/IEEE 29119-4: Các kỹ thuật kiểm thử.

Hình 16 - Quy trình Thiết kế và chuẩn bị kiểm thửKết quả triển khai thành công của Quy trình thiết kế và chuẩn bị kiểm thử gồm:

- Cơ sở kiểm thử cho từng hạng mục kiểm thử đã được phân tích;

- Các tính năng được kiểm thử được kết hợp với các tập tính năng;

- Các điều kiện kiểm thử được đưa ra;

- Các hạng mục bao phủ kiểm thử được đưa ra;

- Các trường hợp kiểm thử đã được tạo ra;

- Các bộ kiểm thử đã được tập hợp;

- Các thủ tục kiểm thử đã được đưa ra.

Đầu ra của Quy trình thiết kế và chuẩn bị kiểm thử gồm:

- Các đặc tả kiểm thử (đặc tả thiết kế kiểm thử, đặc tả trường hợp kiểm thử và đặc tả thủ tục kiểm thử) và thông tin về khả năng lần vết liên quan;

- Yêu cầu về dữ liệu kiêm thử;

36

- Yêu cầu về môi trường kiêm thử.

5.1.2.3.2. Quy trình thiết lập và duy trì môi trường kiểm thử;Quy trình thiết lập và duy trì môi trường kiểm thử được sử dụng để thiết lập và duy trì môi trường kiểm thử mà tiến hành các hoạt động kiểm thử trong đó. Việc duy trì môi trường kiểm thử có thể liên quan đến những thay đổi dựa trên các kết quả kiểm thử trước đó. Nếu có quy trình quy trình quản lý cấu hình và quy trình quản lý thay đổi thì những thay đổi đối với môi trường kiểm thử có thể được quản lý bằng cách sử dụng các quy trình này.

Hình 17 - Quy trình thiết lập và duy trì môi trường kiểm thửKết quả triển khai thành công của Quy trình thiết lập và duy trì môi trường kiểm thử gồm:

- Môi trường kiểm thử được hiết lập ở trạng thái sẵn sàng kiểm thử;

- Tình trạng của môi trường kiểm thử phải được thông báo cho tất cả các bên liên quan;

- Môi trường kiểm thử được duy trì.

Đầu ra của Quy trình thiết lập và duy trì môi trường kiểm thử gồm:

- Môi trường kiểm thử;

- Dữ liệu kiểm thử;

- Báo cáo tính sẵn sàng của môi trường kiểm thử;

- Báo cáo tính sẵn sàng dữ liệu kiểm thử;

- Nâng cấp môi trường kiểm thử (nếu có thể);

5.1.2.3.3. Quy trình thực hiện kiểm thử; Quy trình thực hiện kiểm thử được sử dụng để chạy các thủ tục kiểm thử được tạo ra từ Quy trình thiết kế và chuẩn bị kiểm thử trên môi trường kiểm thử được thiết lập bởi quy trình thiết lập và duy trì môi trường kiểm thử. Quy trình thực hiện kiểm thử có thể cần phải thực hiện một số lần vì tất cả các thủ tục kiểm thử sẵn có có thể không được thực

37

hiện lặp đi lặp lại. Nếu một vấn đề được xác nhận thì nó sẽ được kiểm thử lại bằng cách vào lại Quy trình thực hiện kiểm thử.

Hình 18 - Quy trình thực hiện kiểm thửTrong hình 19 các hoạt động được trình bày theo một trình tự theo logic, nhưng trong thực tế phải lặp đi lặp lại rất nhiều hoạt động. Việc so sánh các kết quả kiểm thử và ghi lại chi tiết quá trình thực hiện kiểm thử thông thường được xen kẽ với việc thực hiện các thủ tục kiểm thử.

Kết quả triển khai thành công của Quy trình thực hiện kiểm thử gồm:

- Các thủ tục kiểm thử đã được thực hiện;

- Kết quả thực tế được ghi lại;

- Kết quả thực tế và kết quả mong đợi đã được so sánh;

- Kết quả kiểm thử đã được xác định.

Đầu ra của Quy trình thực hiện kiểm thử gồm:

- Kết quả thực tế;

- Kết quả kiểm thử;

- Nhật ký thực hiện kiểm thử.

5.1.2.3.4. Quy trình báo cáo sự cố kiểm thửQuy trình báo cáo sự cố kiểm thử được sử dụng để báo cáo sự cố kiểm thử. Quy trình này sẽ được vào lại khi kết quả của việc xác định lỗi kiểm thử và những trường hợp mà xuất hiện điều gì đó bất thường hoặc không mong muốn trong khi thực hiện kiểm thử, hoặc khi việc kiểm thử lại được thông qua.

38

Hình 19 - Quy trình báo cáo sự cố kiểm thửKết quả triển khai thành công của Quy trình báo cáo sự cố kiểm thử gồm:

- Kết quả kiểm thử đã được phân tích;

- Những sự cố mới được xác nhận;

- Báo cáo chi tiết về những sự cố mới được lập;

- Tình trạng và chi tiết của những lỗi được tạo ra trước đó được xác định;

- Báo cáo chi tiết về những sự cố được tạo ra trước đó được cập nhật nếu thích hợp;

- Báo cáo sự cố mới và/ hoặc báo cáo sự cố đã được cập nhật đã được thông báo cho các bên liên quan.

Đầu ra của Quy trình báo cáo sự cố kiểm thử gồm:

- Báo cáo sự cố.

5.2.2. Phạm vi áp dụng của ISO/IEC/IEEE 29119-2- Tiêu chuẩn này quy định các quy trình kiểm thử có thể được sử dụng để quản lý và

thực hiện kiểm thử phần mềm cho bất kỳ tổ chức, dự án hoặc hoạt động kiểm thử nào. Nó bao gồm những mô tả về quy trình kiểm thử chung mà xác định các quy trình kiểm thử phần mềm.

- Tiêu chuẩn này có thể áp dụng để kiểm thử trong tất cả các mô hình vòng đời phát triển phần mềm.

- Tiêu chuẩn này được áp dụng cho các kỹ sư kiểm thử, người quản lý kiểm thử, các nhà phát triển và người quản lý dự án, đặc biệt là những người chịu trách nhiệm quản lý và thực hiện kiểm thử phần mềm.

5.2.3. Sử dụng thuật ngữ “process” trong bộ tiêu chuẩn kiểm thử phần mềmThuật ngữ “process” đã được sử dụng trong tiêu chuẩn TCVN 10539:2014 (ISO/IEC 12207:2008) và được định nghĩa là “quá trình”. Tuy nhiên thuật ngữ “process” trong tiêu chuẩn này sẽ là “quy trình”, chứ không phải “quá trình”. Khái niệm “quá trình” hoặc

39

“quy trình” có thể tương đối về mặt ngữ nghĩa nhưng theo định nghĩa trong TCVN ISO 9000:2007 thì: - Quá Trình là tập hợp các hoạt động có liên quan lẫn nhau hoặc tương tác để biến đổi

đầu vào thành đầu ra.

- Quy trình/ Thủ Tục là cách thức cụ thể để tiến hành một hoạt động hay quá trình.

Phân tích kỹ hơn, khái niệm "quá trình" thường được dùng để chỉ các "hoạt động" có quan hệ hoặc tương tác. Ví dụ, quá trình "tuyển dụng" ám chỉ một loạt các hoạt động nhằm biến đổi "đầu vào" như nhu cầu tuyển dụng (số lượng, năng lực, trách nhiệm, quyền hạn, chế độ đãi ngộ...), ngân sách tuyển dụng, các kênh tuyển dụng sẵn có trên thị trường, sức lao động của bộ máy tuyển dụng... thành "đầu ra" là ứng viên thỏa mãn các yêu cầu tuyển dụng được tuyển. Nói đến "quá trình" là nói đến các hoạt động liên quan và các đầu vào tham gia, đầu ra được tạo ra.

Khái niệm “quy trình” được dùng để chỉ một “cách thức” hay “phương thức” thực hiện một quá trình/công việc. Nói đến “quy trình là nói đến trình tự của các hoạt động, phương pháp, trách nhiệm và quyền hạn, năng lực cần thiết, thời gian, cơ sở hạ tầng/thiết bị cần thiết, hoạt động kiểm soát và yêu cầu hồ sơ.

Trong ISO/IEC/IEEE 29119-2 có 8 quy trình kiểm thử, mỗi quy trình đều phải thực hiện tuần tự các hoạt động và nhiệm vụ cụ thể. Do đó, theo định nghĩa trong TCVN ISO 9000:2007 về “quá trình” và “quy trình” cũng như phân tích ở trên thì TCVN 10539:2014 (ISO/IEC 12207:2008) sử dụng thuật ngữ “process” là “quá trình” và ISO/IEC/IEEE 29119-2 sử dụng thuật ngữ “process” là “quy trình” là hoàn toàn hợp lý và phù hợp với ngữ cảnh.

5.2.4. Đối chiếu các tiêu chuẩn liên quan đến ISO/IEC/IEEE 29119-2Từ phụ lục B đến phụ F, trình bày mối quan hệ giữa các quy trình trong tiêu chuẩn ISO/IEC/IEEE 29119-2 và các quy trình trong các tiêu chuẩn:

- Tiêu chuẩn TCVN 10359:2014 (ISO/IEC 12207:2008)

- Tiêu chuẩn ISO/IEC 15288:2008

- Tiêu chuẩn ISO/IEC 17025: 2005

- Tiêu chuẩn TCVN 10540:2014 (ISO/IEC 25051:2006)

- Tiêu chuẩn BS 7925-2:1998

- Tiêu chuẩn IEEE Std 1008-2008

5.2.3.1. TCVN 10539:2014 (Tiêu chuẩn ISO/IEC 12207)TCVN 10539:2014 được xây dựng trên cơ sở tiêu chuẩn ISO/IEC 12207:2008

Tiêu chuẩn này thiết lập một khung hướng dẫn chung về các quá trình vòng đời phần mềm với những khái niệm được định nghĩa rõ ràng và có thể được tham chiếu trong lĩnh vực công nghệ phần mềm. Tiêu chuẩn bao gồm các quá trình, các hoạt động, và các nhiệm vụ được áp dụng trong suốt quá trình mua sản phẩm phần mềm hoặc dịch vụ, và trong suốt quá trình cung cấp, phát triển, vận hành, bảo trì và xử lý của các sản phẩm phần mềm. Trong đó, phần mềm bao gồm cả phần phần mềm của phần sụn.

40

Tiêu chuẩn cũng cung cấp một quá trình có thể được sử dụng để định nghĩa, kiểm soát, và cải tiến các quá trình vòng đời phần mềm.

Các quá trình, các hoạt động và các nhiệm vụ của tiêu chuẩn này - hoặc độc lập hoặc kết hợp với tiêu chuẩn ISO/IEC 15288 - cũng có thể áp dụng trong quá trình mua sản phẩm của một hệ thống có phần mềm.

Tiêu chuẩn này được áp dụng cho các đối tượng bao gồm bên mua sản phẩm hệ thống, các sản phẩm phần mềm và các dịch vụ, nhà cung cấp và các bên liên quan như: bên phát triển, bên khai thác, bên bảo trì, bên quản lý, bên quản lý đảm bảo chất lượng, và người sử dụng các sản phẩm phần mềm.

Các giới hạn của tiêu chuẩn này bao gồm:

- Không trình bày chi tiết các quá trình vòng đời trong giới hạn về các phương pháp hoặc các thủ tục cần thiết để đáp ứng các yêu cầu và kết quả của quá trình.

- Không trình bày chi tiết tài liệu hướng dẫn trong giới hạn về tên, định dạng, nội dung tường minh và phương tiện ghi báo cáo.

- Không qui định mô hình vòng đời phần mềm hoặc hệ thống, phương pháp luận triển khai, phương pháp, mô hình hoặc kỹ thuật đặc trưng. Các bên tham gia sử dụng tiêu chuẩn chịu trách nhiệm đối với việc lựa chọn một mô hình vòng đời cho dự án phần mềm và ánh xạ các quá trình, hoạt động và nhiệm vụ trong tiêu chuẩn này lên trên mô hình đó. Các bên tham gia cũng chịu trách nhiệm đối với việc lựa chọn và áp dụng các phương pháp phát triển phần mềm và thực hiện các hoạt động và nhiệm vụ phù hợp đối với dự án phần mềm.

- Không dự định gây mâu thuẫn với các chính sách, các thủ tục, và các tiêu chuẩn của bất kỳ tổ chức nào; hoặc với các điều luật và pháp luật của bất kỳ quốc gia nào. Nếu có bất kỳ mâu thuẫn nào như vậy nên được giải quyết trước khi áp dụng tiêu chuẩn này.

5.2.3.2. Tiêu chuẩn ISO/IEC 15288ISO/IEC 15288 (phiên bản mới nhất hiện nay là SO/IEC/IEEE 15288:2015 Systems and software engineering - System life cycle processes)

Tiêu chuẩn ISO/IEC 15288:2008 - Kỹ thuật hệ thống và phần mềm - Các quá trình vòng đời hệ thống, nằm trong nhóm các tiêu chuẩn tham chiếu các quá trình và sản phẩm. Tiêu chuẩn thiết lập một khung hướng dẫn chung để mô tả vòng đời các hệ thống được con người phát triển. Tiêu chuẩn xác định một bộ các quá trình cùng hệ thống thuật ngữ liên kết. Các quá trình này có thể được áp dụng ở mức độ bất kỳ trong cấu trúc của hệ thống. Các bộ các quá trình này được lựa chọn có thể áp dụng xuyên suốt vòng đời để quản lý và thực hiện các giai đoạn của vòng đời hệ thống. Việc này được hoàn thiện thông qua sự tham gia tất cả các chủ thể có liên quan, với mục đích cao nhất là đạt được sự hài lòng của khách hàng.

Tiêu chuẩn ISO/IEC 15288:2008 cũng cung cấp các quá trình hỗ trợ xác định, kiểm soát và cải tiến các quá trình vòng đời được sử dụng trong một tổ chức hoặc một dự án. Các tổ chức và các dự án có thể sử dụng tiêu chuẩn các quá trình vòng đời này khi mua sản phẩm và cung cấp các hệ thống.

41

Tiêu chuẩn ISO/IEC 15288 là tiêu chuẩn các quá trình hệ thống được xây dựng với cùng một cấu trúc tương tự như tiêu chuẩn ISO/IEC 12207 bao gồm các quá trình, hoạt động, nhiệm vụ và kết quả đạt được. Tiêu chuẩn được xây dựng thể hiện mối liên hệ với tiêu chuẩn ISO/IEC 12207 khi mà phần mềm là một phần tích hợp của hệ thống tổng thể. 5.2.3.3. Tiêu chuẩn TCVN ISO 17025:2007TCVN ISO 17025:2007 được xây dựng dựa trên ISO/IEC 17025:2005 Yêu cầu chung về năng lực của phòng thử nghiệm và hiệu chuẩn ). TCVN ISO 17025:2007 là tiêu chuẩn về hệ thống quản lý chất lượng áp dụng chuyên biệt cho phòng thử nghiệm và hiệu chuẩn, do tổ chức quốc tế về tiêu chuẩn hóa ISO ban hành.Tiêu chuẩn TCVN ISO 17025:2007 được thiết kế để hợp nhất với tiêu chuẩn TCVN ISO 9001 - hệ thống quản lý chất lượng, vì vậy tiêu chuẩn ISO/IEC 17025 không chỉ đưa ra các yêu cầu để quản lý và đảm bảo năng lực kỹ thuật mà còn bao gồm những quy định về hệ thống quản lý chất lượng để đạt được khả năng đưa ra những kết quả đo lường/thử nghiệm tin cậy cao và được quốc tế thừa nhận.Tiêu chuẩn TCVN ISO 17025:2007 bao gồm 5 phần, trong đó phòng thí nghiệm cần phải thấu hiểu và đáp ứng các yêu cầu trong phần 4 và phẩn 5 của tiêu chuẩn này.

5.2.3.4. Tiêu chuẩn TCVN 10540:2014 (ISO/IEC 25051)Tiêu chuẩn TCVN 10540:2014 được xây dựng dựa trên tiêu chuẩn ISO/IEC 25051:2006 Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing. Tiêu chuẩn này áp dụng cho các sản phẩm phần mềm COST.Trong tiêu chuẩn này, thuật ngữ COST được sử dụng như tính từ và có nghĩa “Sẵn sàng phổ biến và thương mại”.Tiêu chuẩn này thiết lập:

a) Các yêu cầu chất lượng cho sản phẩm phần mềm COST;b) Các yêu cầu kiểm tra tài liệu cho kiểm tra sản phẩm phần mềm COST, bao gồm yêu

cầu kiểm tra, trường hợp kiểm tra, và báo cáo kiểm tra;c) Hướng dẫn đánh giá tính tuân thủ sản phẩm phần mềm COST.

Tiêu chuẩn này cũng bao gồm các khuyến nghị cho các sản phẩm phần mềm COST an toàn hay quan trọng.Tiêu chuẩn này chỉ liên quan đến cung cấp sự tin cậy cho người sử dụng rằng sản phẩm phần mềm COST sẽ thực hiện như nó được cung cấp và phân phối. Nó không liên quan đến quá trình sản xuất (bao gồm các hoạt động và sản phẩm trung gian, như các đặc tính). Hệ thống chất lượng của nhà cung cấp nằm ngoài phạm vi của tiêu chuẩn này.Tiêu chuẩn này có thể được sử dụng như sau:- Các yêu cầu mức cao cho đặc tính sản phẩm phần mềm COST: sử dụng điều 5, “Các

yêu cầu chất lượng” như đầu vào để xây dựng các đặc tính cho sản phẩm phần mềm COST;

- Các yêu cầu kiểm tra phần mềm như một phần của sản phẩm phần mềm COST: xây dựng tài liệu kiểm tra dựa trên các yêu cầu xác định trong điều 6, “Các yêu cầu cho tài liệu kiểm tra”.

5.2.3.5. Tiêu chuẩn BS 7925-2BS 7925-2 (phiên bản mới nhất hiện nay là BS 7925-2:1998) có tên gọi đầy đủ là BS 7925-2 Software testing - Software component testing.

42

BS 7925-2 là tiêu chuẩn phần mềm, nó định nghĩa toàn bộ quy trình kiểm thử, kỹ thuật tạo các trường hợp kiểm thử và các hoạt động khác mà được sử dụng để kiểm thử thành phần. Nhiệm vụ chính của BS 7925-2 là xác định cách thức thành phần phần mềm được kiểm tra bằng sự trợ giúp của quy trình kiểm thử động Tiêu chuẩn này định nghĩa các quy trình kiểm thử thành phần phần mềm sử dụng các kỹ thuật thiết kế trường hợp kiểm thử cụ thể và các kỹ thuật đo lường. Tiêu chuẩn này cho phép người sử dụng trực tiếp nâng cao chất lượng kiểm thử phần mềm và sản phẩm phần mềm của họ.5.2.3.6. Tiêu chuẩn IEEE 1008IEEE Std 1008 là tiêu chuẩn về kiểm thử đơn vị phần mềm, Kiểm thử phần mềm là một quy trình bao gồm việc thực thi kế hoạch kiểm thử, mua lại bộ kiểm thử và đo lường đơn vị kiểm thử theo các yêu cầu của nó. Việc đo lường đòi hỏi phải sử dụng dữ liệu mẫu để thực thi đơn vị và so sánh thuộc tính thực tế của đơn vị với thuộc tính quy định của nó như quy định trong tài liệu hướng dẫn các yêu cầu của đơn vị phần mềm.Tiêu chuẩn này xác định một phương pháp kiểm thử đơn vị có hệ thống và kiểm thử đơn vị theo tài liệu. Phương pháp này sử dụng thiết kế đơn vị và thông tin thực thi đơn vị để xác định mức độ hoàn thành kiểm thử.Tiêu chuẩn này mô tả một quy trình kiểm thử gồm một hệ thống các giai đoạn kiểm thử, các hoạt động, nhiệm vụ và định nghĩa một tập tối thiểu các nhiệm vụ cho từng hoạt động. Tiêu chuẩn này yêu cầu thực hiện từng hoạt động. Đối với từng nhiệm vụ trong một hoạt động, tiêu chuẩn này đòi hỏi hoặc là các nhiệm vụ đó phải được thực hiện, hoặc kết quả trước đó phải có có sẵn và được xác minh lại.Tiêu chuẩn này có thể được áp dụng để kiểm thử mức đơn vị của phần mềm hoặc phần sụn. Tuy nhiên, tiêu chuẩn này không quy định bất kỳ loại phần mềm hoặc phần sụn nào được áp dụng, tiêu chuẩn này cũng không quy định bất kỳ loại phần mềm hoặc phần sụn nào cần phải được kiểm thử mức đơn vị. Tiêu chuẩn này áp dụng để kiểm thử các đơn vị mới được phát triển và sửa đổi.

6. Nội dung dự thảo tiêu chuẩn6.1. Nội dung dự thảo tiêu chuẩnNội dung dự thảo TCVN xxx:2015 “Kỹ thuật hệ thống và phần mềm - Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử” hoàn toàn tương đương với tiêu chuẩn gốc ISO/IEC/IEEE 29119-2:2013.

6.2. Cấu trúc dự thảo tiêu chuẩnTiêu chuẩn này gồm 08 điều và 07 phụ lục sau:

1. Phạm vi áp dụng

2. Sự phù hợp

3. Tài liệu viện dẫn

4. Thuật ngữ và định nghĩa

5. Mô hình quy trình kiểm thử

43

6. Quy trình kiểm thử của tổ chức

7. Quy trình quản lý kiểm thử

8. Quy trình kiểm thử động

Phụ lục A (Tham khảo) Ví dụ về quy trình thiết kế kiểm thử

Phụ lục B (Qui định) Đối chiếu các quy trình TCVN xxxx-2:201x (ISO/IEC/IEEE 29119-2:2013) và TCVN 10359:2014

Phụ lục C (Tham khảo) Đối chiếu Quy trình của TCVN xxxx-2:201x (ISO/IEC/IEEE 29119-2:2013) và ISO/IEC 15288:2008

Phụ lục D (Tham khảo) Đối chiếu Quy trình của TCVN xxxx-2:201x (ISO/IEC/IEEE 29119-2:2013) và ISO/IEC 17025:2005

Phụ lục E (Tham khảo) Đối chiếu Quy trình của TCVN xxxx-2:201x (ISO/IEC/IEEE 29119-2:2013) và TCVN 10540:2014

Phụ lục F (Tham khảo) Đối chiếu Quy trình của TCVN xxxx-2:201x (ISO/IEC/IEEE 29119-2:2013) và BS 7925-2:1998

Phụ lục G (Tham khảo) Đối chiếu Quy trình của TCVN xxxx-2:201x (ISO/IEC/IEEE 29119-2:2013) và IEEE std 1008-2008.

6.3 Bảng đối chiếu dự thảo TCVN với tài liệu gốcBảng 5 - Bảng đối chiếu dự thảo TCVN với tài liệu gốc

Bản dự thảo TCVN xxxx-2:201x

Tài liệu gốc ISO/IEC/IEEE 29119-2:2013 Phương pháp xây dựng

Lời giới thiệu Introduction Chấp thuận nguyên vẹn

1. Phạm vi áp dụng 1. Scope Chấp thuận nguyên vẹn

2. Sự phù hợp 2. Conformance Chấp thuận nguyên vẹn

3. Tài liệu viện dẫn 3. Normative references Chấp thuận nguyên vẹn

4. Thuật ngữ và định nghĩa

4. Terms and definitions Chấp thuận nguyên vẹn

5. Mô hình quy trình kiểm thử nhiều lớp

5. Multi-Layer Test Process Model

Chấp thuận nguyên vẹn

6. Quy trình kiểm thử của tổ chức

6 Organizational Test Process Chấp thuận nguyên vẹn

6.1. Giới thiệu 6.1 Introduction Chấp thuận nguyên vẹn

6.2. Quy trình kiểm thử của tổ chức

6.2 Organizational Test Process


7. Quy trình quản lý kiểm thử

7 Test Management Processes Chấp thuận nguyên vẹn


7.2. Quy trình lập kế hoạch kiểm thử

7.2 Test Planning Process Chấp thuận nguyên vẹn

44



7.3. Quy trình kiểm soát và giám sát kiểm thử

7.3 Test Monitoring and Control Process


7.4. Quy trình kết thúc kiểm thử

7.4 Test Completion Process Chấp thuận nguyên vẹn

8. Quy trình kiểm thử động

8 Dynamic Test Processes Chấp thuận nguyên vẹn


8.2. Quy trình thực hiện và thiết kế kiểm thử

8.2 Test Design & Implementation Process


8.3. Quy trình thiết lập và duy trì môi trường kiểm thử

8.3 Test Environment Set-Up & Maintenance Process


8.4. Quy trình thực hiện kiểm thử

8.4 Test Execution Process Chấp thuận nguyên vẹn

8.5. Quy trình báo cáo sự cố kiểm thử

8.5 Test Incident Reporting Process


Phụ lục A (tham khảo): Ví dụ về Quy trình thiết kế kiểm thử

Annex A (informative) Partial Example Test Design Process


Phụ lục B (quy định): Đối chiếu Quy trình của TCVN xxxx-2:201x và TCVN 10359:2014

Annex B (normative) ISO/IEC/IEEE 29119-2 and ISO/IEC 12207:2008 Process Alignment


B.1. Tổng quan B.1 Overview Chấp thuận nguyên vẹn

B.2. Ánh xạ TCVN 10359:2014 đến TCVN xxxx-2:201x

B.2 ISO/IEC 12207:2008 to ISO/IEC/IEEE 29119-2 Mapping


Phụ lục C (tham khảo): Đối chiếu Quy trình của TCVN xxxx-2:201x và ISO/IEC 15288:2008

Annex C (informative) ISO/IEC/IEEE 29119-2 and ISO/IEC 15288:2008 process alignment


Phụ lục D (tham khảo): Đối chiếu Quy trình của TCVN xxxx-2:201x và TCVN ISO 17025:2007

Annex D (informative) ISO/IEC/IEEE 29119-2 and ISO/IEC 17025:2005 process alignment


Phụ lục E (tham khảo): Đối chiếu Quy trình của TCVN xxxx-2:201x và

Annex E (informative) ISO/IEC/IEEE 29119-2 and ISO/IEC 25051:2006 process


45



TCVN 10540:2014 alignment

Phụ lục F (tham khảo): Đối chiếu Quy trình của TCVN xxxx-2:201x và BS 7925-2:1998

Annex F (informative) ISO/IEC/IEEE 29119-2 and BS 7925-2:1998 process alignment


Phụ lục G (tham khảo): Đối chiếu Quy trình của TCVN xxxx-2:201x và IEEE std 1008-2008

Annex G (informative) ISO/IEC/IEEE 29119-2 and IEEE Std 1008-2008 process alignment


7. Kết luận7.1. Kết quả đạt đượcTiêu chuẩn đã đạt được một số kết quả sau:Căn cứ theo nội dung đăng ký đã được duyệt tiêu chuẩn hoàn hiện toàn bộ các mục nêu trong đề cương khoa học công nghệ, bao gồm: - Bản thuyết minh Quy chuẩn kỹ thuật với đầy đủ nội dung đã đăng ký - Bản dự thảo QCVN về quy trình kiểm thử.

7.2. Kiến nghịĐề xuất sửa đổi tên đăng ký theo đề cương “Nghiên cứu, xây dựng tiêu chuẩn quốc gia “Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử” thành “Kỹ thuật hệ thống và phần mềm - Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử” theo đúng tên tài liệu gốc ISO/IEC/IEEE 29119:2 và giống với các TCVN đã ban hành như: TCVN 10539:2014, TCVN 10540:2014.

46

Thư mục tài liệu tham khảo[1] BS 7925-2:1998, Softwaretesting - Softwarecomponent testing[2] BS 7925-1:1998, Softwaretesting - Vocabulary[3] IEC 60300-3-9:1995,Risk Analysis of technological systems[4] IEEE Std 601.12-1990, IEEE Standard Glossary of Software Engineering Terminology[5] IEEE Std 829-2008, IEEE Standard for Software and System Test Documentation[6] IEEE Std 1008-1987, IEEE Standard for Software UnitTesting[7] IEEE Std 1012-2012, IEEE Standard for Systemand Software Verification and Validation[8] IEEE Std 1028-2008, IEEE Standard for Software Xem xéts and Audits[9] ISO 15489-1:2001, Information and documentation - Records management - Part 1: General[10] ISO 31000:2009, Risk management - Principles and guidelines[11] ISO 9001:2008, Quality management systems - Requirements[12] TCVN 10539:2014 (ISO/IEC 12207:2008), Kỹ thuật hệ thống và phần mềm - Các quá trình vòng đời phần mềm.[13] ISO/IEC 16085:2006, Systems and software Engineering - Life cycle Processes - Risk Management[14] ISO/IEC 25000:2005, Software Engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE[15] ISO/IEC 25010:2011, Systems and Software Engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models[16] TCVN 10540:2014 (ISO/IEC 25051:2006), Kỹ thuật phần mềm - Yêu cầu và đánh giá chất lượng sản phẩm phần mềm - Yêu cầu chất lượng và hướng dẫn kiểm tra sản phẩm phần mềm sẵn sàng phổ biến và thương mại hóa (COTS)[17] ISO/IEC 90003:2004, Software engineering - Guidelines for the application of ISO 9001:2000 to computer software.[18] ISO/IEC/IEEE 24765:2010, Systems and software engineering - Vocabulary [19] International Software Testing Qualifications Board (ISTQB), Standard glossary of terms used in Software Testing [online]. Updated 1 April 2010 [viewed 11 April 2011]. Available from: http://www. i s tqb.o r g/

47

http://www.istqb.org/

GIẢI TRÌNH SỬA ĐỔI SAU HỘI THẢO 1

Tên tiêu chuẩn: Nghiên cứu xây dựng tiêu chuẩn quốc gia “Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử”

Mã số: 27-15-KHKT-TC

Chủ trì: Ths. Vũ Hồng Sơn

Đơn vị thực hiện: TT Đo lường và Ứng dụng công nghệ - Viện Khoa học Kỹ thuật Bưu điện

NỘI DUNG SỬA ĐỔI

STT Ý kiến Giải trình

1 Phần Lời nói đầu: Nội dung dự thảo không nên thay đổi vị trí các điều khoản, nên để theo tài liệu gốc cho tiện theo dõi. Vì thế nên sửa thành: “TCVN xxxx-2:2015 hoàn toàn tương đương ISO/IEC/IEEE29119-2:2013”

Tiếp thuĐã thực hiện sửa lại phần lời nói đầu trong dự thảo

2 Về thuật ngữ trong dự thảo:Giải thích tại sao các thuật ngữ được định nghĩa trong phần 1 – Thuật ngữ và định nghĩa lại được nhắc lại trong phần 2 này.

Chú thích trong Phần 4 của dự thảo đã giải thích khá rõ nên nhóm chù trì không giải thích thêm nữa.

3 Bố cục của dự thảo: Nên giữ nguyên theo tài liệu gốc để tiện theo dõi và để giống với dự thảo phần 1 và dự thảo phần 3 của bộ tiêu chuẩn về kiểm thử phần mềm.

Tiếp thuĐã sửa lại bố cục theo tài liệu gốc

4 Tài liệu viện dẫn: Đối với các tài liệu viện dẫn nước ngoài nên bổ sung thêm cả phần Tiếng Việt.

Ví dụ: ISO/IEC/IEEE 29119-1, “Software and systems engineering - Software testing - Part 1: Concepts and definitions” sửa thành: ISO/IEC/IEEE 29119-1, “Software and systems engineering - Software testing - Part 1: Concepts and definitions” (ISO/IEC/IEEE 29119-1, “Kỹ thuật hệ thống và phần mềm - Kiểm thử phần mềm - Phần 1: Khái niệm và định nghĩa”)

Tiếp thu

5 Về giải thích từ ngữ: Giải thích tại sao lại dịch từ Process là “Quy trình” trong khi TCVN 10539:2014 dịch là “Quá trình”

Tiếp thuĐã giải thích trong mục 5.2.3 của Báo cáo thuyết minh

48

6 Về thống nhất thuật ngữ:Có một số thuật ngữ được đưa ra trong cả dự thảo phần 1, dự thảo phần 2 và dự thảo phần 3 nhưng nhóm chủ trì của 3 dựa thảo này vẫn chưa thống nhất được và mỗi chủ trì dịch theo một nghĩa khác nhau.

Nhóm chủ trì dự thảo phần 1, phần 2 và phần 3 đã có một buổi làm việc thống nhất các thuật ngữ chung của 3 phần. Tuy nhiên còn một số thuật ngữ như: performance testing, Organizational Test Policy, security testing, Specification, test sub-process vẫn chưa thống nhất được

7 Về báo cáo thuyết minh:- Kiểm thử phần mềm do tiểu ban SC7 chịu

trách nhiệm nên liệt kê các tiêu chuẩn liên quan đến tiêu chuẩn kiểm thử phần mềm.

- Phân tích kỹ bộ tiêu chuẩn ISO/IEC/IEEE 29119 về kiểm thử phần mềm để từ đó giải thích tại sao bộ tiêu chuẩn này lại thay thế một số tiêu chuẩn về kiểm thử trước đó như: BS 7925-1, BS 7925-2, IEEE 829.

Tiếp thuĐã bổ sung và giải thích trong phần 3.1 và 5.1 của Báo cáo thuyết minh

8 Về dự thảo: - Những câu có dấu “; và” nên bỏ.

- Về thuật ngữ: cần phải thống nhất lại với phần 1 và phần 3

- Việt hóa một số từ: “code” → “mã”, “timeline” → “mốc thời gian”

- Hình vẽ: Việt hóa hình vẽ từ hình 7 đến hình 13.

- Phụ lục A còn một số đoạn chưa dịch hết, đề nghị dịch hết phụ lục A

Tiếp thu

49

GIẢI TRÌNH SỬA ĐỔI SAU HỘI THẢO 2


Mã số: 27-15-KHKT-TC


Đơn vị thực hiện: TT Đo lường và Ứng dụng công nghệ - Viện Khoa học Kỹ thuật Bưu điện

NỘI DUNG SỬA ĐỔI

STT Ý kiến Giải trình

1 Về trình bày thuật ngữ trong dự thảo:Các định nghĩa, thuật ngữ nên trình bày theo tài liệu gốc và theo các TCVN đã ban hành. Tức là sau mỗi khoản mục phải xuống dòng, ví dụ:4.1. Kết quả thực tế (actual results) nên sửa thành4.1. Kết quả thực tế (actual results)

Tiếp thuĐã sửa lại bố cục theo tài liệu gốc

2 Về thống nhất thuật ngữ:Đề xuất nên thống nhất một số thuật ngữ mà nhóm chủ trì 3 phần chưa thống nhất được ở hội thảo 1, đó là:performance testing → kiểm thử hiệu năng

security testing → kiểm thử khả năng bảo mật

Specification → đặc tả

test sub-process → Quy trình kiểm thử con

testcase → trường hợp kiểm thử

Tiếp thu

3 Về dự thảo: - Mục 4.23. Kiểm thử theo kịch bản → Kiểm

thử có kịch bản.

- Mục 4.26. Nền tảng kiểm thử → Cơ sở kiểm thử

- Mục 4.48 trang 15 nên sửa “Diễn giải cụ thể về quy trình kiểm thử con” → “Những trường hợp cụ thể của quy trình kiểm thử con”.

- Nên sửa “tài liệu đặc tả (specification)” → “Đặc tả” để thống nhất với phần 1 và phần 2

Tiếp thu

50

- Trang 37, việt hóa từ testcase.

- Hình 13, trang 44, thống nhất dịch lại quy trình báo cáo sự cố kiểm thử là quy trình báo cáo sự cố kiểm thử.

- Quy trình Thiết kế và chuẩn bị kiểm thử (Test Design and Implementation Process) đề xuất sửa thành Quy trình thiết kế và chuẩn bị kiểm thử

51


HỌC VIỆN CN BƯU CHÍNH VIỄN THÔNG

VIỆN KHOA HỌC KỸ THUẬT BƯU ĐIỆN

CỘNG HOÀ XÃ HỘI CHỦ NGHĨA VIỆT NAMĐộc lập - Tự do - Hạnh phúc

Hà Nội, ngày 15 tháng 10 năm 2015

BÁO CÁO SỬA CHỮA THEO KẾT LUẬN CỦA HỘI ĐỒNG NGHIỆM THU CẤP

CƠ SỞ TIÊU CHUẨN KHOA HỌC CÔNG NGHỆ


Mã số: 27 - 15 - KHKT - TC


Đơn vị thực hiện : TT Đo lường và Ứng dụng công nghệ - Viện Khoa học Kỹ thuật Bưu điện.

NỘI DUNG GIẢI TRÌNH

Ý kiến của phản biện và hội đồng Giải trình ý kiến

Phan biên Nguyễn Hai Anh

Thuyết minh dự thảo tiêu chuẩn:

Theo qui định về trình bày, tên bảng phải ở trên bảng.

Tiếp thu, đã đảo lại vị trí tên bảng lên trên bảng.

Dự thảo tiêu chuẩn:

Điều 1. Phạm vi áp dụng, đoạn 1 nên thay “nó bao gồm các mô tả chung …” thành “tiêu chuẩn này bao gồm các mô tả chung …”

Tiếp thu, đã thay từ “nó” thành “tiêu chuẩn này”.


Nên xem xét thay thế tiêu chuẩn ISO/IEC/IEEE 29119-1 và ISO/IEC/IEEE 29119-3 thành TCVN xxxx-1:201x (ISO/IEC/IEEE 29119-1) và TCVN xxxx-3:201x (ISO/IEC/IEEE 29119-3).

Tiếp thu, đã thay thế


Điều 4. Tài liệu viện dẫn, nên dịch là: “Tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa nêu trong ISO/IEC/IEEE 24765 và các thuật ngữ và định nghĩa dưới đây” cho thống nhất với phần 1 và

Tiếp thu, đã sửa lại cho phù hợp với phần 1, 3

52

phần 3 của bộ tiêu chuẩn.


Điều 5. Mô hình quy trình kiểm thử nhiều lớp, thay từ “khoản” thành “điều”. Lưu ý, thay toàn bộ từ “khoản” thành “điều” trong dự thảo TCVN.

Tiếp thu, đã thay toàn bộ “khoản” và “mục” thành “điều” trong toàn bộ dự thảo.


Chú ý các từ “sẽ” trong dự thảo tiêu chuẩn, “shall” là “phải”, “should” là “nên”, “must” là “cần”, “can” là “có thể”.

Đã rà soát, sửa đổi, thống nhất dịch lại các từ “shall”, “should”, “must”, “can” trong toàn bộ bản dự thảo tiêu chuẩn


Thống nhất từ “thực hiện kiểm thử” và “thực thi kiểm thử” (Điều 5, khoản 2, mục iii so với điều 8.4)

Đã rà soát, sửa đổi, thống nhất thuật ngữ “thực hiện kiểm thử - execution” trong toàn bộ bản dự thảo tiêu chuẩn


Điều 7.1, mục c) sửa lại thành “quy trình kết thúc kiểm thử”

Đã rà soát, sửa đổi lại thành “quy trình kết thúc kiểm thử”

Phan biên Vũ Lê Hạnh


Trang bìa nên thống nhất với 02 bộ thuyết minh đi kèm của tiêu chuẩn MS 26-15-KHKT-TC và 27-15-KHKT-TC.

Tiếp thu


Nên đặt các đề mục ở mức khác nhau với khoảng cách tương xứng với phần nội dung của mục trước đó.

Tiếp thu


Thay ký hiệu bằng chữ.

Một số từ tiếng Anh, ví dụ như “tester” chưa dịch ra tiếng Việt.

Một số từ viết tắt tiếng Việt, ví dụ như “CNTT” chưa có chú thích cụ thể.

Tiếp thu, đã thay ký hiệu bằng chữ, đã dịch một số từ tiếng Anh sang tiếng Việt và đã viết đầy đủ câu của từ CNTT


Có một số đề mục nằm ở một trang trong khi nội dung nằm hoàn toàn ở trang kế tiếp, ví dụ “tình trạng của ISO/IEC

Đã rà soát, sửa đổi lại để nội dung và đề mục không nằm cách biệt nhau.

53

29119”.


Việt hóa nốt các hình vẽ.

Một số đầu mục còn chưa được đánh số, ví dụ “Các tổ chức tiêu chuẩn hóa”.

Đã rà soát, đánh số các đầu mục còn chưa được đánh số và việt hóa các hình vẽ còn để tiếng Anh.


Thống nhất Mục lục với tài liệu gốc và 2 bản dự thảo TCVN đi kèm.

Tiếp thu, đã sửa đổi.


Một số từ còn sai chính tả, ví dụ “Ngoài ra bo tiêu chuẩn này”

Đã rà soát, sửa lại lỗi chính tả trong toàn dự thảo.


Một số dấu ngoặc kép mở bị cách với từ trong ngoặc, ví dụ như “ tương đương”



Nên dịch từ “comformance”là “tuân thủ”

Do đây là TCVN chứ không phải QCVN và xét trong ngữ cảnh của phần 2, nhóm chủ trì vẫn giữ nguyên là “sự phù hợp”.

Các ý kiến khác trong giám định cơ sở

Một số hình vẽ chưa được việt hóa Đã việt hóa các hình chưa được dịch hết sang tiếng Việt.

Thống nhất thuật ngữ “thực thi” và “thực hiện”Thống nhất thuật ngữ với các phần

Tiếp thu, đã rà soát và thống nhất thuật ngữ giữa các phần.

Bổ sung bảng viết tắt Trong thuyết minh và dự thảo, từ viết tắt CNTT, nhóm chủ trì đã viết đầy đủ nên không phải làm bảng viết tắt nữa.

54


HỌC VIỆN CN BƯU CHÍNH VIỄN THÔNG

VIỆN KHOA HỌC KỸ THUẬT BƯU ĐIỆN

CỘNG HOÀ XÃ HỘI CHỦ NGHĨA VIỆT NAMĐộc lập - Tự do - Hạnh phúc

Hà Nội, ngày 15 tháng 10 năm 2015

BÁO CÁO SỬA CHỮA THEO KẾT LUẬN CỦA HỘI ĐỒNG NGHIỆM THU

CẤP BỘ TIÊU CHUẨN KHOA HỌC CÔNG NGHỆ


Mã số: 27 - 15 - KHKT - TC


Đơn vị thực hiện : TT Đo lường và Ứng dụng công nghệ - Viện Khoa học Kỹ thuật Bưu điện.

NỘI DUNG GIẢI TRÌNH


Phan biên Nguyễn Hữu Quốc


Thống nhất tên tiêu chuẩn giữa kết quả tiêu chuẩn và tên tiêu chuẩn tại trang 43 của Báo cáo tiêu chuẩn. Thuyết minh tiêu chuẩn đề nghị là ‘Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử”, không bao gồm “Kỹ thuật hệ thống và phần mềm”. Điều chỉnh lại cụm từ Quy chuẩn kỹ thuật, QCVN theo đúng kết quả tiêu chuẩn tại trang 42.

Bảo lưu vì:

- Tên tiêu chuẩn theo đề cương là: Nghiên cứu xây dựng tiêu chuẩn quốc gia “Kiểm thử phần mềm – Phần 2: Quy trình kiểm thử” nên quyển Báo cáo tiêu chuẩn khoa học phải ghi tên đúng theo tên của đề cương đã đăng ký.

- Đối với quyển thuyết minh thì đặt tên theo kết quả đăng ký tiêu chuẩn: “Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử”.

- Đối với dự thảo thì cũng phải đặt tên theo kết quả đăng ký tiêu chuẩn: “Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử” nhưng để phù hợp với tài liệu gốc cũng như thống nhất với các TCVN đã ban hành trước đó, nhóm chủ trì đã có kiến nghị trong phần 7.2 của thuyết minh là đặt tên theo tài liệu tham chiếu gốc: “Kỹ thuật hệ thống và phần mềm - Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử”

Thuyết minh dự thảo tiêu chuẩn: Tiếp thu, đã thay đổi phông chữ trong hình

55


Phông chữ trong hình vẽ và văn bản chưa nhất quán.

vẽ cho thống nhất với phông chữ trong quyển thuyết minh và báo cáo tiêu chuẩn.

Dự thảo tiêu chuẩn:Mục 7.4.4.2, sử dụng từ khôi phục lại môi trường kiểm thử chưa chính xác, nội hàm của nó là thu hồi tài nguyên, khôi phục lại môi trường kiểm thử đã cấp cho dự án kiểm thử.

Tiếp thu, đã thay từ “khôi phục lại môi trường kiểm thử” thành “thu hồi tài nguyên và khôi phục lại môi trường kiểm thử”.

Phản biện Vũ Lê Hạnh


Trang bìa nên thống nhất với 02 bộ thuyết minh đi kèm của tiêu chuẩn MS 26-15-KHKT-TC và 27-15-KHKT-TC.

Tiếp thu (ý kiến này đã được giải trình sau nghiệm thu cấp cơ sở rồi)


Đề mục của các phần đôi khi không được tách rời trên một dòng riêng so với phần nội dung. Ví dụ như các phần “1.1 Tên tiêu chuẩn”, “1.2 Mã số”.

Tiếp thu, đã sửa đổi


Các đề mục ở mức khác nhau chưa có khoảng tách rời tương xứng với phần nội dung của mục trước đó. Ví dụ như mục “2. Nghiên cứu, khảo sát hiện trạng và đánh giá nhu cầu đối với việc kiểm thử phần mềm”.


Thuyết minh dự thảo tiêu chuẩn:Việc đánh số đề mục chưa được thống nhất. Đã có đề mục đến mức 5 như là mục “5.1.2.2.2” trong khi mục “1.3 Mục tiêu, nội dung và kết quả tiêu chuẩn” lại chứa 3 mục con a, b và c thay vì 1.3.1, 1.3.2 và 1.3.3


Thuyết minh dự thảo tiêu chuẩn:Phần tên cột của bảng đôi khi không được lặp lại trong các trang kế tiếp khi bảng dài hơn 1 trang. Ví dụ như bảng 1.



Việc phân cấp danh sách đôi chỗ chưa được thực hiện triệt để. Ví dụ như danh


56


sách “Các tài liệu được đề cập trong ISO/IEC/IEEE 29119-3 bao gồm:”

Thuyết minh dự thảo tiêu chuẩn:Nội dung đôi chỗ chưa thống nhất. Ví dụ như trong 3 trang xung quanh câu “Hình 87 cho thấy một…” không hề thấy có hình nào đánh số 87 cả.

Tiếp thu, đã sửa đổi lại là “Hình 7….”

Thuyết minh dự thảo tiêu chuẩn:Các khái niệm cơ bản đôi khi không thống nhất. Ví dụ như “Quy trình kiểm thử tổ chức” và “Quy trình kiểm thử của tổ chức”.

Đã rà soát, thống nhất dịch là “Quy trình kiểm thử của tổ chức”.


Một số quan điểm chưa thuyết phục như là “Ngành kiểm thử này đã xuất hiện khá lâu, vào khoảng những năm đầu của thế kỷ trước và được áp dụng vào lĩnh vực phát triển phần mềm không lâu sau đó”


Thuyết minh dự thảo tiêu chuẩn:Một đôi chỗ lập luận còn chưa được chặt chẽ. Ví dụ như “Kiểm thử phần mềm bao gồm nhiều lĩnh vực, từ các phần mềm trò chơi, đến các phần mềm lĩnh vực ngân hàng”. Kiểm thử có nhiều lĩnh vực hay công nghệ phần mềm có nhiều lĩnh vực?


Thuyết minh dự thảo tiêu chuẩn:Một số thông tin cần thêm nguồn gốc tham khảo. Ví dụ như “Theo tiêu chuẩn quốc tế, tỷ lệ kỹ sư kiểm thử phần mềm tại Việt Nam còn thấp so với mặt bằng thế giới”

Tiếp thu, đã cập nhật.

Dự thảo tiêu chuẩn:Tài liệu dự thảo tiêu chuẩn của dự án trình bày chưa thống nhất với bộ 2 dự án đi kèm (26-15-KHKT-TC và 28-15-KHKT-TC), ví dụ như trang bìa của 3 tiêu chuẩn có 3 cách trình bày khác nhau..

Nhóm chủ trì đã trình bày dự thảo TCVN theo đúng quy định trong TCVN 1,2 : 2008.

Dự thảo tiêu chuẩn: Tiếp thu, đã sửa đổi.

57

Ý kiến của phản biện và hội đồng Giải trình ý kiếnCác đề mục ở mức khác nhau chưa có khoảng tách rời tương xứng với phần nội dung của mục trước đó. Ví dụ như mục “2. Sự phù hợp”


Một số dấu ngoặc kép mở bị cách với từ trong ngoặc, ví dụ như “ tương đương”


Dự thảo tiêu chuẩn:Các khái niệm cơ bản đôi khi bị sử dụng không thống nhất. Ví dụ như “Quy trình kiểm thử tổ chức” và “Quy trình kiểm thử của tổ chức”.

Tiếp thu, đã rà soát và thống nhất lại trong toàn bộ dự thảo và thuyết minh là “Quy trình kiểm thử của tổ chức”.

Dự thảo tiêu chuẩn:Một số từ chưa đúng với ngữ nghĩa tiếng Anh gốc trong ngữ cảnh. Ví dụ như “completion” dịch sang tiếng Việt trong ngữ cảnh xây dựng bộ tiêu chuẩn thì có nghĩa là “hoàn thành” chứ không nên dùng từ “kết thúc” – tương đương với từ finish/termination trong tiếng Anh.

Một số từ khi dịch từ tiếng Anh sang tiếng Việt thì cần thiết là phải Việt hóa sao cho phù hợp với ngữ cảnh. Từ “completion” có rất nhiều nghĩa, có thể là “hoàn thành” hoặc “làm xong”. Tuy nhiên khi áp dụng vào mục đích tiêu chuẩn này, 3 nhóm chủ trì tiêu chuẩn của 3 phần đã xem xét, tìm hiểu và thống nhất dịch là “kết thúc”, phù hợp với ngữ cảnh.

Một số từ chưa đúng với ngữ nghĩa tiếng Việt trong ngữ cảnh. Ví dụ như “clause 6” trong câu “a) Organizational Test Process (clause 6)” dịch sang tiếng Việt trong ngữ cảnh xây dựng bộ tiêu chuẩn thì có nghĩa là “chương 6” hoặc “phần 6” chứ không nên dùng từ “điều 6”

Theo ý kiến góp ý của các đại biểu tham dự nghiệm thu cấp cơ sở và cũng theo quy định dịch một số từ tiếng Anh sang tiếng Việt trong các TCVN và QCVN trong đó có từ “clause” sẽ được dịch là “điều” chứ không phải là “khoản”, “phần” hoặc “chương”.

Đôi chỗ việc chuyển ngữ còn thiếu. Ví dụ như mục “4.69 Mức kiểm thử (test level)”, bản gốc là “specific instantiation of a test sub-process”, bản dịch thiếu mất đại từ chỉ số lượng “a”. Hiện sử dụng bản dịch “Trường hợp cụ thể của quy trình kiểm thử con”. Bản đầy đủ nên là “Trường hợp cụ thể của một quy trình kiểm thử con”

Mục 4.69 trong dự thảo là test type chứ không phải là test level, do đó nội dung không giống như ý kiến góp ý của phản biện.


Vẫn còn có đề mục “mồ côi” như đề mục “4.6.”

Tiếp thu, đã điều chỉnh lại cho phù hợp

Các ý kiến khác trong giám định cơ sở

58


Các tài liệu vẫn còn lỗi soạn thảo. Tiếp thu, đã rà soát lại toàn bộ dự thảo

Làm rõ mối tương quan giữa bộ tiêu chuẩn ISO 29119 với các tiêu chuẩn đã có.

Đã được làm rõ trong Dự thảo, từ phụ lục D đến phụ lục G.

Mục 8.5.5 trong dự thảo, đề nghị bỏ phần a vì không có phần b

Do tiêu chuẩn này được xây dựng trên cơ sở chấp thuận nguyên vẹn ISO/IEC/IEEE 29119-2 nên trong dự thảo không có phần b vì tài liệu gốc không có phần này.

Bổ sung lý thuyết vòng đời phần mềm vào thuyết minh dự thảo.

Tiếp thu, đã bổ sung vào điều 2.1 của quyển thuyết minh.

Rà soát lại thuật ngữ và bám sát nghĩa chuyên ngành của thuật ngữ.

Tiếp thu, đã rà soát

Trình bày thuyết minh dự thảo theo quy định, bổ sung rà soát hệ thống TCVN có liên quan đến Kiểm thử phần mềm và vòng đời phần mềm.

- Thuyết minh dự thảo không bắt buộc trình bày theo quy định. Tuy nhiên nhóm chủ trì cũng đã trao đổi với chủ trì của tiêu chuẩn 26-15-KHKT-TC và 28-15-KHKT-TC để thống nhất về font, trang bìa…

- TCVN liên quan đến kiểm thử phần mềm hiện chưa có tiêu chuẩn nào, hiện chỉ có các tiêu chuẩn TCVN đã ban hành liên quan đến chất lượng phần mềm và đánh giá sản phẩm phần mềm nhóm chủ trì đã trình bày trong bảng 3 của Thuyết minh; TCVN liên quan đến vòng đời phần mềm cũng được trình bày trong bảng 3 của Thuyết minh.

Trình bày Dự thảo theo quy định. Nhóm chủ trì đã trình bày Dự thảo theo đúng quy định trong TCVN 1-2: 2008

Điều 2. Sự phù hợp, có điều 2.1 nhưng không có điều 2.2

Do tiêu chuẩn này được xây dựng trên cơ sở chấp thuận nguyên vẹn ISO/IEC/IEEE 29119-2 nên trong dự thảo không có điều 2.2 vì tài liệu gốc không có phần này.

59

Bất cập trong quản lý mạng ngoại...

Documents

Transcript of Bất cập trong quản lý mạng ngoại...