Tìm hiểu về ISTQB Certification – Foundation Level syllabus - Phần 2

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ư ở bài trước chúng ta đã hiểu được khái niệm cũng như những nguyên tắc kiểm thử cơ bản thì ở bài này tôi sẽ giới thiệu những phần tiếp theo trong cuốn ISTQB Certification - Foundation Level syllabus 2011 đề cập đến các mức độ kiểm thử và biết được những mức độ này được thực hiện khi nào trong chu trình phát triển phần mềm.

**1.5. Tâm lý học trong kiểm thử **

Tóm tắt:

• Qua nội dung của phần này chúng ta sẽ có thể giải thích thế nào là tâm lý học trong việc kiểm thử và cách nó ảnh hưởng tới sự thành công của việc kiểm thử.

• Bạn nên nhớ lại tầm quan trọng của những mục tiêu rõ ràng, sự kết hợp đúng đắn của “self-testing” (tự kiểm thử), “independent testing” (kiểm thử độc lập) và sự cẩn trọng, chu đáo, sự tôn trọng lẫn nhau trong giao tiếp giữa tester và những người khác trong cùng một nhóm dư án, đặc biệt là về bugs.

• Bạn có thể giải thích sự khác biệt giữa cách suy nghĩ của tester và lập trình viên và lí do những khác biệt đó có thể dẫn đến mâu thuẫn.

1.5.1. Mindset (Tư duy)

• Tư duy được dùng trong khi testing và review khác với tư duy được sử dụng trong khi phát triển phần mềm

• Với tư duy chính xác thì lập trình viên có thể tự kiểm tra những dòng lệnh của chính họ

• Các đối tượng được thiết lập bởi người quản lý và các bên liên quan khác

• Kiểm thử độc lập có thể được thực hiện ở bất kì mức nào của việc kiểm thử

• Kiểm tra các tính năng: Mục đích để tìm ra những thiếu sót và xác thực phần mềm có đầy đủ những tính năng của nó.

1.5.2. Các mức của kiểm thử độc lập:

Một vài cấp độ của sự độc lập (từ thấp tới cao)

• Kiểm thử được thiết kế bởi những người viết ra SUT (software under test) .
• Kiểm thử được thiết kế bởi những người khác (Ví dụ trong đội phát triển)
• Kiểm thử được thiết kế bởi người từ nhóm/tổ chức khác nhau (ví dụ một đội test độc lập hoặc các chuyên gia kiểm thử)
• Kiểm thử được thiết kế bởi người từ những tổ chức hoặc công ty khác (ví dụ như outsourcing)

1.5.3. Tâm lý kiểm thử:

• Kiểm thử viên có thể bị coi như những người phê bình sản phẩm hoặc người làm ra phần mềm.

• Kiểm thử thường được coi như một hoạt động phá hoại (mặc dù kiểm thử rất có tính xây dựng trong sự quản lý các rủi ro của sản phẩm)

• Tìm kiếm sự thất bại/lỗi trong một hệ thống thì yêu cầu:

  • Sự tò mò khám phá sản phẩm
  • Có con mắt của nhà phê bình
  • Chú ý tới chi tiết dù là nhỏ nhất
  • Có kinh nghiệm vào việc phán đoán lỗi cơ bản
  • Có giao tiếp tốt với đội phát triển

1.5.4. Tính xây dựng hay phá hoại:

• Nếu lỗi, thiếu sót hay những sự cố được tester và người phát triển giao tiếp mang tính xây dựng → Những bất đồng giữa tester, người phân tích, thiết kế và phát triển có thể được tránh được

• Tester và Test leader cần có kĩ năng cá nhân tốt để giao tiếp những thông tin thực tế về những thiếu sót, tiến trình và những rủi ro mang tính xây dựng..

• Những thiếu sót được tìm và sửa trong khi kiểm thử sẽ tiết kiệm được thời gian và tiền bạc và giảm được những rủi ro sau này.

1.5.5. Nâng cao kĩ năng giao tiếp

• Cách để nâng cao kĩ năng giao tiếp đó là:
• Bắt đầu bằng sự hợp tác lẫn nhau hơn là tranh luận - nhắc nhở mọi người hướng tới chất lượng hệ thống tốt hơn
• Giao tiếp tìm ra trên sản phẩm theo kiểu trung lập, tập trung vào thực tế mà ko cần chỉ trích người tạo ra lỗi.
• Cố gắng hiểu cảm giác mà mọi người cảm thấy và tại sao họ làm như vậy
• Đảm bảo rằng những người khác đã hiểu điều bạn nói.

1.6. Code of ethics (Đạo đức nghề nghiệp)

Tham gia kiểm thử phần mềm cho phép các cá nhân tìm hiểu được các thông tin bí mật và bản quyền. Đạo đức nghề nghiệp là cần thiết, những lí do khác để đảm bảo rằng thông tin không được dùng với mục đích không phù hợp thì ISTQB chỉ ra những qui tắc đạo đức nghề nghiệp như dưới đây:

• Public: Tester có những hành động nhất quán một cách công khai
• Client and employer: Làm vì lợi ích tốt nhất của khách hàng, sử dụng lao động phù hợp với lợi - Product: Chứng nhận kiểm thử phần mềm sẽ đảm bảo nhận lại được những gì họ yêu cầu (trên sản phẩm và hệ thống họ kiểm thử) có thể gặp mức tiêu chuẩn chuyên nghiệp cao nhất
• Judgment: Chứng nhận kiểm thử phần mềm sẽ bảo trì tính toàn vẹn và phụ thuộc vào sự phán đoán chuyên nghiệp của họ
• Management: Chứng nhận kiểm thử phần mềm mức test managers và leaders sẽ thúc đẩy đạo đức để tiến tới trở thành người quản lý kiểm thử phần mềm.
• Profession: Chứng nhận kiểm thử phần mềm sẽ nâng cao tính toàn vẹn và uy tín của nghề đối phù hợp với lợi ích chung
• Colleagues: Chứng nhận kiểm thử phần mềm sẽ tương thích và có tính hỗ trợ với đồng nghiệp và thúc đẩy sự hợp tác với đội developers
• Self: Chứng nhận kiểm thử phần mềm xác sẽ tham gia học tập nghiên cứu lifelong liên quan đến việc thực hành nghề nghiệp của họ và sẽ thúc đẩy một cách tiếp cận đạo đức

2. Testing throughout the software life cycle: (Kiểm thử ở mọi khâu trong vòng đời của phần mềm)

2.1. Những mô hình phát triển phần mềm

• Những mô hình phát triển phần mềm theo trình tự:

  • Mô hình Waterfall
  • Mô hình chữ V

• Mô hình phát triển lặp

  • Mẫu (Prototyping)</li>
  • Phát triển ứng dụng nhanh chóng (Rapid Application Development)
  • Quy trình thống nhất hợp lý (Rational Unified Process)
  • Mô hình phát triển phần mềm linh hoạt

• Mô hình Waterfall (thác nước)

Mô hình thác nước là một trong những mô hình được thiết kế sớm nhất từ trước tới giờ.

Nó có thời gian phát triển một cách tự nhiên mà những công việc được thực thi liên tiếp

Kiểm thử được thực hiện tới cuối vòng đời phần mềm để những lỗi được tìm ra và kết thúc cho tới ngày được phát hành chính thức.

• Mô hình chữ V

• Mặc dù mô hình chữ V có nhiều phiên bản khác nhau nhưng một dạng phổ biến của mô hình chữ V sử dụng bốn mức độ test tương ứng với bốn mức độ phát triển

• Component Test/ Unit Test: Đảm bảo rằng thực hiện kiểm tra các tính năng được thực hiện đúng các chức năng được mô tả như trong tài liệu chi tiết. Người thực hiện Unit Test: Lập trình viên

• Intergration Test: Để tìm ra những vấn đề về giao diện cũng như những xung đột giữa các phần được tích hợp. Người thực hiện: Người thiết kế phần mềm/ Kĩ sư phần mềm.

• System Test: Kiểm tra xem hệ thống hoàn chỉnh có chạy đúng các chức năng như yêu cầu hay không và độ chính xác mà hệ thống thực hiện như thế nào. Người thực hiện: Kỹ sư kiểm thử</li>

• Acceptance Test: Xác định hệ thống có được thỏa mãn và được chấp nhận bởi khách hàng/ người dùng cuối hay không. Người thực hiện: Khách hàng

  Sự khác nhau giữa Verification và Validation

• Verification: Xác nhận rằng các sản phẩm công việc phản ánh đúng các yêu cầu theo quy định nói cách khác xác minh đảm bảo rằng bạn đang làm đúng cách

• Xác nhận rằng các sản phẩm sẽ hoàn thành đúng mục đích sử dụng nói cách khác đảm bảo rằng bạn đã làm đúng sản phẩm</li>

  Các mô hình phát triển lặp

• Đây là chu trình thiết lập lên các yêu cầu, thiết kế, xây dựng và kiểm thử một hệ thống trong chuỗi chu trình phát triển ngắn ví dụ như prototyping, Rapid Application Development (RAD) , hoặc Rational Inified Process (RUP) và mô hình phát triển Agile.

• Mô hình phát triển Agile Scrum

Định nghĩa: Phát triển Agile "là một thuật ngữ chung cho một số phương pháp phát triển phần mềm lặp và tăng dần.

• Các phương pháp phổ biến nhất bao gồm:

  • Extreme Programming (XP)
  • Scrum
  • Crystal
  • Phương thức phát triển hệ thống động(DSDM)
  • Phát triển gọn (Lean Development)
  • Feature-Driven Development (FDD): Phát triển hướng tính năng

• Kiểm thử trong một mô hình chu trình phần mềm

Trong bất kì mô hình chu trình phần mềm nào đều có vài yếu tố để kiểm thử thật tốt đó là:

• Cho mỗi họat động phát triển thì đều có hoạt động kiểm thử tương ứng
• Mỗi một mức độ kiểm thử nào cũng đều có đặc tả chi tiết đối tượng kiểm thử theo mức đó
• Phân tích và thiết kế kiểm thử cho mỗi mức độ kiểm thử đều bắt đầu trong suốt hoạt động phát triển tương ứng.
• Các mức độ kiểm thử có thể được kết hợp hoặc sắp xếp lại phù thuộc vào dự án hoặc kiến trúc hệ thống.

2.2. Các mức độ kiểm thử

Mỗi một mức độ kiểm thử có phương pháp tiếp cận và trách nhiệm tương ứng theo từng mức.

Kiểm thử dữ liệu cấu hình của hệ thống sẽ được xem xét trong quá trình lập test plan.

Các mức độ test bao gồm:

• Component Testing/Unit Testing: Kiểm thử mức đơn vị
• Intergration Testing: Kiểm thử tích hợp
• System Testing: Kiểm thử hệ thống
• Acceptance Testing: Kiểm thử chấp nhận

+Component Testing (Unit Test) tìm ra những lỗi trong các function, module, object hay class...có thể test riêng biệt. Quá trình này có thể được hoàn thành cô lập phụ thuộc vào khái niệm của vòng đời phát triển của hệ thống. Driver hoặc trình máy ảo Simulators có thể được sử dụng

Một cách điển hình, kiểm thử mức đơn vị được thực hiện bằng cách kiểm thử những dòng mã lệnh với sự trợ giúp của môi trường phát triển như các framwork hoặc các tool debug. Unit test được thực hiện thường xuyên sẽ nâng cao kĩ năng cho lập trình viên. Lỗi thường được sửa ngay khi họ phát hiện ra

Một phương pháp tiếp cận Unit Test đó là chuẩn bị và viết testcase tự động trước khi lập trình. Nó được gọi là test-first approach hoặc test-driven.

+Integration Testing: kiểm tra giao diện giữa các đơn vị, sự tương tác giữa các phần khác nhau của hệ thống như hệ điều hành, các file hệ thống với phần cứng, giao diện giữa các system. Có nhiều mức độ kiểm tra tích hợp và có thể được thực hiện trên các đối tượng thử ngiệm với các kích thước khác nhau như:

Component integration testing: Kiểm tra sự tương tác giữa các đơn vị phần mềm và được thực hiện sau kiểm thử mức đơn vị

System integration testing: Kiểm tra sự tương tác giữa cac hệ thống khác nhau hoặc giữa phần cứng với phần mềm và có thể hoàn thành sau system testing

Ngân sách cho kiểm thử tích hợp càng lớn thì càng khó tách lỗi thành những đơn vị chi tiết, điều này có thể dẫn tới việc tăng thời gian cho việc gỡ lỗi (debug)

Kiểm thử những đặc điểm phi chức năng cụ thể (ví dụ như performance) có thể bao gồm kiểm tra tích hợp giống như kiểm thử chức năng vậy

Ở mỗi giai đoạn tích hợp, tester tập trung hoàn toàn vào integration itself, lấy ví dụ nếu đang tích hợp module A với module B thì cần kiểm thử sự giao tiếp giữa các module chứ không phải tính năng của riêng module nào được thực hiện trong unit test. Cả phương pháp tiếp caạn chức năng và cấu trúc có thể được sử dụng

+System Testing

Kiểm thử hệ thống quan tâm tới các hoạt động/hành vi của cả hệ thống hoặc sản phẩm

Kiểm thử hệ thống có thể bao gồm các yếu tố kiểm thử dựa trên:

• Rủi ro
• Các đặc tả chức năng
• Tiến trình kinh doanh
• Các usecase
• Những tương tác với hệ điều hành
• Nhân lực hệ thống...

Ở giai đoạn kiểm thử hệ thống thì môi trường test nên giống với môi trường cuối cùng nhất có thể dể giảm rủi ro lỗi môi trường có thể tìm ra khi test

Một team kiểm thử độc lập thường là người thực hiện giai đoạn kiểm thử hệ thống.

+Acceptance Testing: Thường là trách nhiệm của khách hàng và người dùng hệ thống

Mục tiêu của kiểm thử chấp nhận là để tạo sự tự tin trong hệ thống và những đặc điểm phi chức năng chi tiết của hệ thống

• Tìm ra lỗi không phải là muc tiêu chính trong giai đoạn kiểm thử chấp nhận. Acceptance test có thể đánh giá sự sẵn sàng cho việc triển khai và sử dụng của hệ thống, mặc dù nó không nhất thiết phải là mức test cuối cùng. Kiểm thử tích hợp hệ thống qui mô lớn có thể thực hiện sau acceptance test

Kiểm thử chấp nhận có thể được thực hiện ở nhiều mốc thời gian trong vòng đời phần mềm ví dụ như:

• Sản phẩm có thể được kiểm thử chấp nhận khi nó được cài đặt hoặc tích hợp

• Kiểm thử chấp nhận tính khả dụng của một thành phần (component) có thể được thực hiện trong suốt qúa trình unit test

• Kiểm thử chấp nhận một chức năng mở rộng mới có thể thực hiện trước kiểm thử hệ thống.

• Phân loại: Kiểm thử chấp nhận có kiểu Alpha và Beta test

Alpha testing: Là việc kiểm thử hoạt động chức năng thực tế hoặc gỉa lập do người dùng/khách hàng tiềm năng hoặc một nhóm testđộc lập thực hiện tại nơi sản xuất phần mềm. Alpha test là một hình thức kiểm thử chấp nhận nội bộ trước khi phần mềm được tiến hành kiểm thử beta

Beta testing: Được thực hiện sau alpha testing. Các phiên bản của phần mềm được biết như là các phiên bản beta- chúng được phát hành tới một số lượng giới hạn người dùng bên ngoài nhóm sản xuất phần mềm. Sản phẩm được phát hành đến một nhóm người để test nhiều hơn nữa có thể chắc chắn rằng sản phầm có một số bug. Thi thoảng các phiên bản beta được phát hành rộng rãi để tăng phạm vi phản hồi từ một lượng người sử dụng tương lai lớn nhất.

2.3. Các dạng kiểm thử

Một dạng kiêm thử thì trọng tâm vào những mục tiêu thử nghiệm cụ thể có thể là bất kỳ mục tiêu nào như dưới đây:

• Một chức năng được thực hiện trong phần mềm

• Một đặc tính chất lượng phi chức năng như tinh tin cậy hoặc tính khả dụng

• Cấu trúc hoặc kiến trúc của phần mềm/hệ thống

• Những thay đổi liên quan tới: Kiểm thử xác nhận rằng lỗi đã được fix hoặc kiểm thử hồi qui (tìm ra những thay đổi ngoài ý muốn)

• Kiểm thử chức năng (Function Testing) có thể được thực hiện ở tất cả các mức test và kiểm tra xem phần mềm/hệ thống **làm gì **

Kỹ thuật dựa trên đặc điểm có thể được sử dụng để lấy những điều kiện và kiểm tra từ các chức năng của phần mềm hay hệ thống.

Chức năng kiểm tra xem xét các hành vi bên ngoài của phần mềm (kiểm tra hộp đen).

• Kiểm thử phi chức năng (Non- function Testing): Là kiểm tra xem phần mềm/hệ thống hoạt động như thế nào và cũng có thể được thực hiện ở bất kỳ mức kiểm thử nào

Kiểm thử phi chức năng xem xét các hành vi bên ngoài của phần mềm và trong hầu hết các trường hợp sử dụng kỹ thuật kiểm thử hộp đen để thực hiện điều đó.

Kiểm thử phi chức năng bao gồm: test performance, load test, stress test...

• Kiểm thử cấu trúc (Structure Testing) giúp đo lường sự triệt để trong kiểm thử thông qua đánh giá mức độ bao phủ một loại cấu trúc. Loại kiểm thử này cũng có thể được thực hiện trong tất cả các mức test

Kiểm thử những thay đổi ngoài mong muốn: Bao gồm có Confirmation testing (hay còn gọi là re-test) và kiểm thử hồi qui (Regression testing)

Confirmation testing: Sau khi một lỗi được tìm ra và fix thì phần mềm cần được test lại để xác nhận rằng lỗi đó đã được loại bỏ thành công

Regression testing: Là quá trình kiểm thử lại những chương trình đã test trước đó rồi để rà soát lại những bug có thể còn sót lại sau khi có những thay đổi về chức năng của hệ thống. Kiểm thử hồi qui có thể được thực hiện ở tất cả các mức test bao gồm kiểm thử chức năng, phi chức năng và kiểm thử cấu trúc

• Kiểm thử bảo trì (Maintenance Testing) Kiểm tra bảo trì được thực hiện trên một hệ thống hoạt động hiện có và được thực hiện khi hệ thống có yêu cầu được sửa đổi, hoặc hệ thống được thay đổi hoàn toàn sang môi trường mới...

Kiểm thử bảo trì nhằm mục đích kiểm thử những phần/chức năng được thay đổi ngoài ra còn bao gồm kiểm thử hồi quy test lại những chức năng được cũ nhằm đảm bảo những chức năng được thay đổi không làm ảnh hưởng gì tới những chương trình cũ vốn đã hoạt động đúng. Phụ thuộc vào sự thay đổi hệ thống ra sao mà maintenance testing có thể được thực hiện ở toàn bộ test level hoặc bất kỳ một mức nào cụ thể và quyết định xem kiểm thử hồi quyy cần nhiều hay ít. Kiểm thử bảo trì có thể gặp khó khăn nếu tài liệu đặc tả chi tiết của phần mềm không được cập nhật mới nhất hoặc tester thiếu hổng kiến thức về domain.

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