Tìm hiểu về ISTQB Certification – Foundation Level syllabus

Như chúng ta đã biết thì kiểm thử phần mềm (KTPM) là khâu quan trọng và xuyên suốt trong toàn bộ chu kỳ phát triển một phần mềm. Do đó vai trò của chuyên gia KTPM ngày càng được nhấn mạnh và không thể thiếu trong bất kỳ dự án nào.

Tuy nhiên để trở thành một chuyên gia KTPM thì kiến thức cần có là gì? Và hiện nay có những tiêu chuẩn quốc tế nào để huấn luyện và đánh giá?

Nếu như chứng chỉ MCSD và MCSE của Microsoft dành cho chuyên gia phát triển phần mềm và kỹ sư hệ thống. Chứng chỉ CCNA, CCNP của Cisco dành cho chuyên gia mạng thì lĩnh vực KTPM có chứng chỉ ISTQB. ISTQB (International Software Testing Qualifications Board) được thành lập vào tháng 11/2002 tại Edinburgh (Scotland), đây là một loại chứng chỉ khá nổi tiếng dành cho lĩnh vực KTPM và được công nhận rộng rãi trên thế giới đặc biệt tại châu Âu và Mỹ. Tại Việt Nam tổ chức Testing (Vietnamese Testing Board - VTB) cũng được thành lập vào năm 2007.

Vai trò của ISTQB là cung cấp hệ thống chứng nhận quốc tế nhằm chuyên môn hóa kiểm thử phần mềm và kiểm định hệ thống dựa trên các đề cương chuẩn.

Chứng chỉ ISTQB hiện có 3 mức độ:

•      Mức cơ bản (cấp độ 1) ISTQB Foundation level
  

•      Mức nâng cao (cấp độ 2) ISTQB Advanced level
  

•      Mức chuyên gia (cấp độ 3) ISTQB Expert level
  

(Click vào hình để theo dõi chi tiết)

Bài viết dưới đây sẽ giới thiệu chi tiết về mức độ ISTQB cơ bản (Foundation Level Syllabus)

•      Mức độ này cần nắm vững các nguyên tắc cơ bản của Kiểm định phần mềm (nền tảng của quá trình kiểm định phần mềm)
  

•      Thực hiện kiểm định phần mềm trong suốt chu trình sản xuất phần mềm (Các mức test, các loại test…)
  

•      Các kỹ thuật kiểm định phần mềm tĩnh (Review quá trình kiểm định phần mềm)
  

•      Các kỹ thuật kiểm định phần mềm động (Các kỹ thuật dựa vào blackbox và white box)
  

•      Quản lý kiểm định phần mềm (Lập kế hoạch test, đánh giá và đưa ra các chiến lược test)
  

•      Biết vận dụng các công cụ hỗ trợ việc kiểm định phần mềm (Các loại test tool, hiệu quả của việc sử dụng các test tool và ứng dụng vào tổ chức/công ty)
  

1. Mức độ cơ bản của kiểm thử

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

1.1.1. Khái niệm về các hệ thống phần mềm

Các hệ thống phần mềm là một phần không thể thiếu của cuộc sống, từ những ứng dụng kinh doanh tới những sản phẩm tiêu thụ. Hầu hết mọi người đều đã từng sử dụng những sản phẩm phần mềm không hoạt động đúng như mong đợi. Phần mềm mà không hoạt động chính xác có thể dẫn tới rất nhiều vấn đề ví dụ như tổn thất tiền bạc, thời gian thachí có thể nguy hiểm tới tính mạng con người.

VD: Máy khám bệnh (1985) Các Therac-25 được xem như là lời cảnh báo đối với việc triển khai rộng rãi các phần mềm trong các ứng dụng an toàn sức khỏe. Các chuyên gia nghiên cứu các hệ thống như vậy cảnh báo rằng các phần mềm có thể giết chết một vài người.

(Click vào hình để theo dõi chi tiết)

1.1.2. Những lí do gây ra khuyết điểm của phần mềm

(Click vào hình để theo dõi chi tiết)

Con người có thể gây ra một lỗi (mistake) dẫn tới khuyết điểm (bug) trong khi lập trình hoặc ở tài liệu. Nếu có một khuyết điểm trong lập trình thì hệ thống có thể thất bại trong cách làm điều phải làm (hoặc làm việc không nên làm) dẫn tới thất bại. Lỗi có thể xảy ra trong phần mềm, hệ thống hoặc tài liệu. Lỗi xảy ra có thể bởi vì do con người làm sai hoặc có thể do áp lực thời gian, lập trình phức tạp, công nghệ thay đổi hoặc là do quá nhiều nhân tố hệ thống khác.

1.1.3. Vai trò của kiểm thử trong phát triển phần mềm, bảo trì và điều hành

Kiểm thử nghiêm ngặt của hệ thống và tài liệu có thể giúp giảm thiểu các rủi ro, các vấn đề xảy ra trong suốt quá trình điều hành và góp phần làm nên chất lượng hệ thống phần mềm nếu các lỗi được phát hiện và sửa trước khi hệ thống được phát hành đưa vào sử dụng.

Kiểm thử phần mềm có thể được yêu cầu khi gặp hợp đồng hoặc các yêu cầu hợp lệ, hoặc trong tiêu chuẩn đặc tả công nghiệp.

1.1.4. Kiểm thử và chất lượng

Với sự giúp đỡ của kiểm thử, thật dễ dàng hơn cho việc đo lường chất lượng phần mềm trong các khái niệm về các bug được tìm ra cho cả các yêu cầu chức năng và phi chức năng (như tính tin cậy, tính khả dụng, tính bảo trì…)

Kiểm thử mang lại tính tin cậy cho chất lượng phần mềm nếu tìm ra được rất ít hoặc không có lỗi nào. Khi kiểm thử tìm ra lỗi, chất lượng của hệ thống phần mềm tăng lên khi những lỗi đó được sửa chữa

Bài học nên được rút kinh nghiệm từ những dự án trước. Đồng thời kiểm thử cũng nên được tích hợp giống một trong những hoạt động đảm bảo chất lượng.

1.1.5. Kiểm thử bao nhiêu là đủ?

• Cần cân nhắc đến mức độ rủi ro

  • Kỹ thuật

  • Sản phẩm kinh doanh

  • Các rủi ro của dự án

  • Những hạn chế của dự án như thời gian và ngân sách

• Nên cung cấp đầy đủ thông tin cho các bên liên quan để đưa ra quyết định về bàn giao phần mềm hoặc hệ thống đã qua kiểm thử

• Ví dụ: Phát hiện sai sót tỷ lệ: 90-95% của các lỗi hiện diện trong hệ thống sau kiểm thử (SUT).

• Kiểm thử được chấm dứt khi một tiêu chí đầy đủ được đáp ứng:

• Một biện pháp tốt trong quá trình thử nghiệm đã được thực hiện;

• Liên quan một thử nghiệm thiết lập cho chương trình, các đặc tả hoặc cả hai;
  

• Có thể liên quan kiểm tra hồ sơ thiết lập để hoạt động của chương trình.
  

1.2. Kiểm thử là gì?

• Bạn có thể nên nhớ các yếu tố chung chung của kiểm thử

• Bạn nên mô tả cách kiểm thử có thể tìm ra lỗi, cung cấp sự tự tin và các cách để ngăn chặn lỗi.

• Bạn nên giải thích các nguyên tắc cơ bản của kiểm thử (phần 1.3)

• Bạn cũng cần phải nắm rõ những khái niệm cơ bản như: mã lệnh ( code ), debug-ging (gỡ lỗi) phát triển phần mềm (development of software), các yêu cầu(requirement), xem xét (review), kiểm thử cơ bản(test basic), các trường hợp kiểm thử (testcase)…

(Click vào hình để theo dõi chi tiết)

1.2.1. Các hoạt động kiểm thử

Kiểm thử không chỉ bao gồm thực hiện kiểm thử

Các hoạt động kiêm thử còn bao gồm:

o Lên kế hoạch và xử lý

o Lựa chọn các điều kiện kiểm thử

o Thiết kế các trường hợp kiểm thử (viết testcase)

o Kiểm tra kết quả

o Đánh giá các tiêu chuẩn hoàn thành

o Báo cáo quá trình kiểm thử

o Hoàn thiện

o Đóng gói sản phẩm

o Xem xét tài liệu (bao gồm cả mã nguồn)

o Phân tích tĩnh

1.2.2. Các yếu tố kiểm thử

o Tìm ra lỗi (Thực hiện một chương trình)

o Đạt được sự tự tin về mức độ chất lượng

o Cung cấp thông tin cho việc ra quyết định

o Ngăn ngừa các lỗi (Phân tích một chương trình hoặc tài liệu của nó)

o Phát triển kiểm thử (thành phần, tích hợp và kiểm thử hệ thống): tìm ra lỗi và sửa lỗi

o Kiểm thử chấp nhận: để xác nhận rằng hệ thống làm việc như mong muốn, đạt được sự tự tin rằng phần mềm đã đúng với yêu cầu của khách hàng

o Kiểm thử bảo trì: Không có lỗi mới nào được phát hiện trong suốt quá trình lập trình phần thay đổi.

o Kiểm tra hoạt động để đánh giá đặc điểm hệ thống như độ tin cậy và tính sẵn sàng.

o Trong một số trường hợp để đánh giá chất lượng của phần mềm (không có ý định sửa chữa các khuyết tật) để cung cấp thông tin cho các bên liên quan về nguy cơ phát hành hệ thống tại một thời gian nhất định.

1.3. Các nguyên tắc kiểm thử

•      Nguyên tắc 1: Thử nghiệm cho thấy sự xuấ hiện của các lỗi
  

•      Nguyên tắc 2: Thử nghiệm chi tiết là không thể
  

•      Nguyên tắc 3: thử nghiệm sớm
  

•      Nguyên tắc 4: phân nhóm lỗi
  

•      Nguyên tắc 5: Thuốc trừ sâu nghịch lý
  

•      Nguyên tắc 6: Thử nghiệm là hoàn cảnh phụ thuộc
  

•      Nguyên tắc 7: Sự vắng mặt-của-các lỗi
  

o Nguyên tắc 1: Thử nghiệm cho thấy sự xuất hiện của các lỗi

• Có thể chỉ ra rằng các lỗi có hiện diện</li>

  • Không thể chứng minh được rằng không có lỗi

  • Giảm khả năng không thể tìm ra lỗi trong phần mềm

  • Mặc dù không tìm ra lỗi thì cũng không có bằng chứng về tính đúng đắn. o Nguyên tắc 2: kiểm thử chi tiết là không thể

  • Kiểm thử mọi thứ (tất cả các sự kết hợp của đầu vào và các điều kiện trước) không được khả thi trừ các trường hợp thông thường

  • Chúng ta sử dụng các rủi ro và các mức độ ưu tiên để trọng tâm vào các nỗ lực kiểm thử

o Nguyên tắc 3: Kiểm thử sớm

Các hoạt động kiểm thử nên bắt đầu: - Càng sớm càng tốt trong phần mềm hoặc vòng đời phát triển hệ thống - Nên trọng tâm vào các đối tượng đã được định nghĩa -> sẽ giúp tìm ra bug sớm

o Nguyên tắc 4: Phân nhóm lỗi

Công sức kiểm thử sẽ được tập trung tương ứng vào kết quả mong đợi và mật độ các lỗi của các modules. Một số lượng nhỏ các module bao gồm hầu hết các lỗi đã được tìm ra trong suốt quá trình kiểm thử trước khi release, hoặc là trách nhiệm cho hầu hết các lỗi hệ thống.

o Nguyên tắc 5: Pesticide paradox

Nếu cùng một trường hợp kiểm thử được lặp đi lặp lại nhiều lần, thậm chí cùng các trường hợp đó không tìm ra được bug nào nữa. Để vượt qua “pesticide paradox” này thì testcase cần được review thường xuyên và chỉnh sửa, và các trường hợp test mới cần được viết để thực hành cho những phần khác nhau của hệ thống phần mềm để tìm ra được nhiều lỗi hơn.

o Nguyên tắc 6: Kiểm thử là một khái niệm phụ thuộc

Kiểm thử được hoàn thành một cách khác nhau trong những khái niệm khác nhau. Lấy VD là một phần mềm an toàn được kiểm thử khác nhau từ một trang web điện tử

o Nguyên tắc 7: Sự vắng mặt của các lỗi

Tìm ra và sửa các lỗi không hữu ích nếu bản built là không khả dụng và không theo nhu cầu và mong đợi của người dùng.

1.4. Qui trình kiểm thử cơ bản

(Click vào hình để theo dõi chi tiết)

1.4.1. Kế hoạch kiểm thử và xử lý

•      Kế hoạch kiểm thử là hoạt động định nghĩa các đối tượng của kiểm thử và đặc tả các hoạt động kiểm thử với mục đích đạt được các đối tượng và nhiệm vụ.
  

•      Kiểm soát kiểm thử (Test control) liên quan tới các hoạt động cần thiết để đạt được các đối tượng và nhiệm vụ của dự án. Với mục đích kiểm soát được quá trình kiểm thử thì các hoạt động kiểm thử nên được điều khiển trong suốt dự án. Kế hoạch kiểm thử mang lại những phản hồi từ các hoạt động điều khiển và kiểm soát
  

1.4.2. Phân tích và thiết kế kiểm thử

• Đây là hoạt động xuyên suốt mà những đối tượng kiểm thử thông thường được chuyển đổi đến những điều kiện và các trường hợp kiểm thử rõ rệt

• Hoạt động phân tích và thiết kế kiểm thử có những nhiệm vụ sau:

o Review kiểm thử cơ bản (như các yêu cầu, các mức độ rủi ro, báo cáo phân tích rủi ro, kiến trúc, thiết kế, đặc tả giao diện)

o Đánh giá mức độ khả dụng của kiểm thử cơ bản và các đối tượng kiểm thử

o Xác định thứ tự ưu tiên các điều kiện kiểm thử dựa trên phân tích cac yếu tố kiểm thử, bản đặc tả cấu trúc của phần mềm.

o Thiết kế và đánh giá mức độ ưu tiên của các trường hợp kiểm thử

o Xác định sự cần thiết của dữ liệu kiểm thử (test data) để hỗ trợ các điều kiện và các trường hợp kiểm thử

o Thiết kế môi trường kiểm thử và xác định bất cứ cơ sở hạ tầng và các test tool được yêu cầu

1.4.3. Thực thi kiểm thử

Đây là hoạt động mà những kịch bản hoặc các thủ tục kiểm thử được đặc tả bởi dự kết hợp các trường hợp kiểm thử theo thứ tự riêng và bao gồm bất cứ thông tin cần thiết nào cho việc thực thi test, môi trường được thiết lập và việc kiểm thử được chạy.

Việc thực thi kiểm thử bao gồm những nhiệm vụ như dưới đây:

• Hoàn thiện, thực thi và phân thứ tự ưu tiên các trường hợp kiểm thử (bao gồm cả test data)

• Phát triển và phân thứ tự ưu tiên cho những thủ tục kiểm thử, tạo dữ liệu test, viết kịch bản test tự động…

• Tạo ra những bộ kiểm thử từ những test procedures để thực thi kiểm thử một cách hiệu quả

• Xác nhận môi trường kiểm thử đã được thiết lập chính xác
  

• Thực thi các test procedure cả cách thủ công hoặc sử dụng các tool kiêm thử tự động
  

• Đưa ra các kết quả mong muốn của quá trình thực thi test và các phiên bản của phần mềm
  

• So sánh kết quả thự tế và kết quả mong đợi
  

• Báo cáo sự khác biệt và phân tích chúng để tìm ra nguyên do lỗi (trong khi lập trình, trong dữ liệu đặc tả, trong tài liệu test hoặc lỗi khi kiểm thử được thực thi)
  

1.4.4. Đánh giá tiêu chí exit và thực hiện báo cáo

Đây là hoạt động mà việc thực thi kiểm thử được thẩm định lại các đối tượng đã được định nghĩa. Việc này nên được hoàn thành cho lỗi mức kiểm thử

Việc đánh giá này bao gồm các nhiệm vụ sau:

• Kiểm tra lại lịch sử test một lần nữa để tránh sót những Exit criteria đã được đặc tả trong kế hoạch test

• Thẩm định nếu cần nhiều kiểm thử hơn hoặc nếu exit criteria đó cần được thay đổi

• Viết báo cáo kết luận cho những bên liên quan tới dự án.

1.4.5. Những hoạt động chấm dứt quá trình kiểm thử

Kiểm thử chấm dứt khi hệ thống phần mềm được release, một dự án kiểm thử được hoàn thành (hoặc bị hủy) là một mốc milestone đạt được, hoặc sự bảo trì đã được hoàn thành

(Còn tiếp)

Tài liệu tham khảo

• http://www.istqb.org/downloads/viewcategory/16.html (Foundation Level Syllabus (2011 E-book)

• http://www.testingvn.com/viewtopic.php?f=38&t=7465&sid=aae575cd20829c512ee629e06ea386dc