Fundamentals of Testing - Chương 1 Foundation Level Syllabus(ISTQB)

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

1.1.1 Ngữ cảnh về hệ thống phần mềm

• Phần mềm là một phần của cuộc sống hiện đại, từ những phần mềm nghiệp vụ đến những sản phẩm phục vụ con người.
• Hầu hết mọi người đều có lúc trải qua việc Phần mềm làm việc không đúng như mong đợi
• Phần mềm làm việc không chính xác có thể dẫn đến nhiều rắc rối, ví dụ như: mất tiền, thời gian, quan hệ, hoặc mạnh hơn là gây ra chấn thương và cái chết.

1.1.2 Nguyên nhân gây ra lỗi

• Error: là một hành động của con người tạo ra một kết quả không chính xác
• Fault: Là một biểu hiện lỗi trong phần mềm. Được biết đến như bug hày defect. Khi chạy phần mềm, fault có thể gây ra failure
• Failure: Failure là độ chênh lệch giữa phần mềm thực tế sai khác với mong đợi Tại sao lại xảy ra lỗi trong phần mềm?
• Do phần mềm được viết bởi còn người
• Mà con người thì có giới hạn về kiến thức
• Còn người còn thiếu kỹ năng
• Con người còn có thể tạo ra sự nhầm lẫn
• Do chịu sức ép lớn để bàn giao sản phẩm đúng deadline
• Hay do thiếu thời gian để kiểm thử
• Hoặc có thể do hệ thống chưa hoàn thành

1.1.3 Vai trò của testing trong Phát triển phần mềm, Mantenance và Vận hành

• Test một cách cẩn thận hệ thống và tài liệu có thể giúp giảm rủi ro cho các vấn đề có thể xảy ra trong quá trình vận hành phần mêm và đảm bảo được chất lượng của hệ thống, nếu lỗi được tìm thấy và sửa trước khi hệ thống được phát hành để sử dụng.
• Kiểm thử phần mềm cũng là một yêu cầu tròn hợp đồng và các yêu cầu pháp lý hoặc chuẩn công nghiệp.

1.1.4 Testing và Quality

• Testing đo đạc được chất lượng của phần mềm
• Testing có thể tìm ra lỗi, khi lỗi được loại bỏ thì chất lượng ( độ tin cậy) được cải thiện Testing để làm gì?

• Đảm bảo các thực hiện, chức năng của hệ thống chạy đúng
• Đảm bảo chất lượng của hệ thống: độ tin cậy, tính sử dụng, bảo trì, tái sử dụng, khả năng test...
• Testing là 1 phần của đảm bảo chất lượng
• Chất lượng được đo đạc bằng lỗi được tìm thấy trong các yêu cầu và đặt tính về functional và non-functional
• Testing mang đến sự tự tin về chất lượng khi lỗi được tìm thấy hoặc không có.
• Bằng cách học các bài học kinh nghiệm từ dự án trước chúng ta cải tiến được quy trình đó cải tiếng chất lượng cho hệ thống trong tương lai.

1.1.5 Testing khi nào là đủ?

Phụ thuộc vào RISK:

• Rủi ro của việc không nhìn thấy lỗi quan trọng
• Rủi ro của việc phát sinh chi phí lỗi
• Rủi ro của việc phát hành phần mềm chưa được kiểm tra
• Nguy cơ mất uy tín thị trường
• Nguy cơ thiếu một cánh cửa thị trường
• Rủi ro trong việc test quá mức, test không hiệu quả
• Thời gian test luôn bị giới hạn Sử dụng Risk để xác định:
• Test gì trước
• Test gì nhiều hơn
• Làm thế nào để kiểm tra kỹ lưỡng từng hạng mục
• Cái gì không test Sử dụng Risk để:
• Phân bố thời gian hợp lý cho việc testing bằng việc phân thứ tự ưu tiên

1.2 Testing là gì?

• Thường mọi người hiểu khái niệm test chỉ là chạy test, chạy phần mềm nhưng đó chỉ là 1 phần không phải tất cả các hoạt động test

• Các hoạt động, test tồn tại trước và sau khi chạy phần mềm bao gồm: lên kế hoạch và kiểm soát, chọn điều kiện test, thiết kế và chạy test case, kiểm tra kết quả, đánh giá tiêu chí kết thúc, báo cáo trong quy trình test và các hoạt động đóng sau khi giai đoạn test hoàn thành. Test thì bao gồm cả review tài liệu, source code, phân tích tĩnh.

• Cả Dynamic và static testing được sử dụng đồng thời để đạt được mục đích giống nhau và sẽ cung cấp thông tin để cải tiến hệ thống đang được test và các quy trình. Test gồm các mục tiêu sau:

  • Tìm defects
  • Thu thập sự tự tin vào chất lượng
  • Cung cấp thông tin để ra quyết định
  • Ngăn ngừa defects

• Quy trình và các hoạt động test được thực hiện sớm trong chu kỳ( cí dụ kiểm tra các tài liệu test) giúp ngăn ngừa lỗi xảy ra trong code. Hoạt động review tài liệu và việc phát hiện và giải quyết các vấn đề phát sinh cũng giúp cho ngăn ngừa lỗi xuất hiện trong code

• Các chi phí tìm kiếm và sửa chữa các defect tăng lên đáng kể trong suốt vòng đời

• Có các quan điểm khác nhau về mục đích khác nhau trong từng giai đoạn:

  • Test trong giai đoạn phát triển phần mềm có thể tìm được rất nhiều lỗi dễ dàng và có thể sửa sớm
  • Test trong giai đoạn Chấp nhận sản phẩm là để kiểm tra xem hệ thống đã làm việc đúng như mong đợi chưa, đúng với yêu cầu chưa
  • Trong một vài trường hợp thì là để đánh giá chất lượng của phần mềm để đưa ra thông tin nhà đầu tư về rủi ro của việc phát hành hệ thống tại thời điểm đó
  • Bảo trì testing bao gồm test để đảm bảo không có lỗi mới xuất hiện quá trình thay đổi, chỉnh sửa
  • Trong quá trình test vận hành thì mục đích chính là đánh giá các đặc tính của hệ thống như độ tin cậy, tính sẵn sàng. Sự khác nhau của debugging và testing

• Test động tìm ra các defect hay bug. Debugging là hoạt động của developer để tìm, phấn tích và sửa nguyên nhân gây ra defect

• Và tester phải thực hiện test lại để đảm bảo là các hoạt động sửa lỗi giải quyết triệt để. Nên khi phân vai trò ta thấy tester là người thực hiện test, developer thực hiện debug

1.3 Bảy nguyên lý cơ bản của testing

1. Testing shows presence of defects - Test chỉ ra lỗi

• Test có thể cho thấy các defect vắng mặt, nhưng không thể chứng minh rằng không có defect
• Test làm giảm xác suất của các defect chưa được khám phá còn lại trong một phần mềm nhưng, ngay cả khi không có defect được tìm thấ, nó không phải là một bằng chứng về tính đúng đắn. 2. Exhaustive testing is impossible - Test toàn bộ là không thể
• Test tất cả mọi thứ ( tất cả các kết hợp của các yếu tố đầu vào và điều kiện tiên quyết) là không khả thi
• Thay vì kiểm tra đầy đủ, hãy phân tích rủi ro và ưu tiên nên được sử dụng để tập trung các nỗ lực thử nghiệm 3. Early testing - Test sớm
• Hoạt động thử nghiệm nên bắt đầu càng sớm càng tốt trong chu kỳ phần mềm hoặc vòng đời phát triển phần mềm và nên tập trung vào mục tiêu được xác định
• Thực hiện các thử nghiệm thiết kế và hoạt động xem xét càng sớm thì thấy lỗi sớm khi đó ít tốn công để tìm và sửa chữa 4. Defect clusreing - phân cụm lỗi
• Một số lượng nhỏ các mô- đun thường có chứa hầu hết các lỗi được phát hiện trong quá trình thử nghiệm trước khi phát hành, hoặc là chịu trách nhiệm cho hầu hết các thất bại hoạt động
• Quy tắc 80/20: Module lõi thường chứa 80% lỗi 5. Pesticide paradox - Hiệu ứng thuốc trừ sâu
• Nếu các thử nghiệm tương tự được lặp đi lặp lại một lần nữa, không có defect mới có thể được tfm thấy
• Để khắc phục nghịch lý thuốc trừ sâu này, các trường hợp kiểm tra cần phải được thường xuyên rà soát và sửa lỗi; kiểm tra mới và khác nhau cần phải được ghi vào các phần khác nhau của phần mềm để tìm các defect có khả năng nhiều hơn. 6. Testing is context dependent - Testing trong ngữ cảnh độc lập
• Test được thực hiện khác nhau trong bối cảnh khác nhau
• Ví dụ: phần mềm an toàn quan trọng là kiểm tra khác nhau từ một trang web thương mại điện tử 7. Absence of error fallacy - Vắng mặt của lỗi
• Tìm và sửa lỗi không giúp gì nếu hệ thống được xây dựng là không sử dụng được và không đáp ứng nhu cầu và mong đợi của người sử dụng.

1.4 Quy trình và các giai đoạn kiểm thử phần mềm

1.4.1 Test Planning and control

• Lập kế hoạch test là hoạt động xác định mục tiêu của việc test và chỉ rõ các hoạt động test để đạt được mục tiêu và trọng tâm
• Kiểm soát test là hoạt động diễn ra liên tục để so sánh giữa tiến độ thhuwjc tế và kế hoạch, báo cáo trạng thái ( gồm cả những cái sai lệch so với kế hoạch). Kiểm soát test phải đưa ra được các hành động cần thiết để đạt được mục tiêu của dự án. Các hoạt động kiểm soát test được thực hiện và kiểm tra suốt cả dự án
• Kế hoạch test phải được cập nhật phù hợp với những hoạt động điều hành và kiểm soát

1.4.2 Test analysis and Design

• Phân tích và thiết kế test dựa vào các mục tiêu test để chuyển đổi thành các điều kiện test và testcase
• Các hoạt động của phân tích và thiết kê:
  • Xem xét các cơ sở cho test ( yêu cầu, cá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)
  • Đánh giá khả năng test của test base và các đối tượng test
  • Xác định và sắp xếp thứ tự ưu tiên của các điều kiện test dựa vào phân tích các test items, đặc tả, hiệu ứng và cấu trúc của phần mềm
  • Thiết kế và sắp xếp thứ tự ưu tiên cho testcase
  • Xác định các dứ liệu test để phục vụ cho test conditions và testcases
  • Xác định môi trường test cần thiết lập và các yêu cầu về hạ tầng, công cụ
  • Tạo ma trận theo dõi 2 chiều giữa test basic và test cases

1.4.3 Test Implementation and Execution

• Thực hiện test và chạy test là hoạt động xây dựng các thủ tục test được chỉ ẽo bằng việc kết hợp giữa các test case và các thông tin cần thiết khác cho việc thực hiện test, thiết lập môi trường test và chạy test
• Gồm các tasks sau:
  • Chuẩn hóa, xây dựng và sắp xếp ưu tiên test case ( bao gồm cả xác định test data)
  • Xây dựng và ưu tiên các thủ tục test, tạo test case chuẩn bị thủ tục và viết test scripts tự động test
  • Tạo bộ test suites từ thủ tục test cho việc chạy test hiệu quả
  • Kiểm tra các môi trường được thiết lập đúng chưa
  • Kiểm tra và cập nhật ma trận theo dõi test basic và test cases
  • Chạy các thủ tục test bằng tay hoặc tự động bằng tool
  • Ghi nhận kết quả chạy test và các vấn đề phát hiện được, phiên bản được test, công cụ test tài sản test
  • So sánh kết quả thực tế và kết quả mong đợi
  • Báo cáo lỗi và phân tích chúng để tim ra nguyên nhân ( lỗi trong code, trong test data, trong tài liệu test hoặc sai ở cách thực hiện test)
  • Lặp lại các hoạy động test để xác nhận các sửa lỗi là phù hợp, những phần xung quanh không xảy ra lỗi nữa

1.4.4 Evaluating Exit Criteria and Reporting

• Đánh giá tiêu chí kết thúc được thực hiện khi việc chạy test đã đạt được đến mục tiêu trong kế hoạch, nó nên được làm ở mỗi level của test
• Các tasks chính:
  • Kiểm tra các kết quả test với các tiêu chí kết thúc trong kế hoạch
  • Đánh giá xem có cần phải test thêm nữa không hoặc phải sửa exit criteria không
  • Viết báo cáo test gửi nhà đầu tư

1.4.5 Test Closure Activities

• Là hoạt động thu nhập dữ liệu từ các hoạt động test đã hoàn thành để tập trung lại các kinh nghiệm, tài sản test.
• Hoạt động này diễn ra ở mỗi giai đoạn của dự án, khi hệ thống được phát hành hoặc khi dự án test hoàn thành, giai đoạn kết thúc, phát hành sản phẩm
• Các tasks chính gồm:
  • Kiểm tra các sản phẩm được lên kế hoạch phát hành đã phát hành chưa
  • Đóng các báo cáo lỗi hoặc nâng cao các ghi chú thay đổi cho phần còn xót lại
  • Tài liệu hóa chấp nhận hệ thống của khách hàng
  • Hoàn thiện và thu hồi tài sản test, môi trường và hạ tầng việc tái sử dụng
  • Bàn giao tài sản test cho tổ chức
  • Phân tích các bài học kinh nghiệm để xác định các thay đổi cần thiết cho các ban hành trong tương lai hoặc dự án khác
  • Sử dụng các thông tin thu thập để cải tiến hoạt động test

1.5 Khía cạnh tâm lý của kiểm thử phần mềm

1.5.1 Why test?

• Để chứng minh thỏa mãn các yêu cầu
• Để tìm lỗi
• Giảm chi phí
• Chứng ming hệ thống thỏa mãn nhu cầu người dùng
• Đánh giá chất lượng phần mềm

1.5.2 Hướng tiếp cận test tốt hơn

• Test hệ thống:
  • Test những gì nó nên làm
  • Không test những gì nó không nên làm => Goal: show working và success: Hệ hống làm việc
• Hướng tiếp cận test tốt hơn:
  • Test những gì nó không nên làm
  • Không test những gì nó nên làm => Goal: tìm defects và success: Hệt hống fails

  1.5.3 Vai trò của tester

• Tester có quyền: - Được thông báo chính xác về tiến độ và sự thay đổi phần mềm - Biết về các mảng phần mềm của developer - Được bàn giao code đã test theo chuẩn - Làm việc chuyên nghiệp - Tìm lỗi - Tạo TCs và test plan - Có lỗi báo cáo thực hiện nghiêm túc - Dự đoán về mức độ lỗi trong tương lai - Cải tiến quy trình kiểm thử của riêng bạn
• Trách nhiệm của tester:
  • Thực hiện theo plan, scripts
  • Báo cáo lỗi khách quan và thực tế
  • KIểm tra các test là đúng trước khi report lỗi phần mềm
  • Đánh giá rủi ro khách quan
  • Đặt thứ tự ưu tiên cái mà bạn test
  • Giao tiếp trung thực

1.5.4 Các mức độ độc lập trong kiểm thử

Test by developer

• Tự kiểm tra công việc?
  • Tìm được 30%-50% lỗi
  • Luôn giả thiết về nghiệp vụ
  • Kèm theo những biểu cảm, tâm lý:
    • Không muốn tìm lỗi
    • Không chủ động tìm lỗi
• Mức độ test độc lập - Các Trường hợp test không được xây dựng bởi người viết ra phần mềm ( thấp nhất) - Test phải được xây dựng bởi người khác - Test cần được xây dựng bởi người từ những phòng ban khác - Test cần được xây dựng bởi người từ những tổ chức khác ( cáo nhất)

1.5.5 Re-test và Test hồi quy

Re-test sau khi lỗi được sửa

• Chạy test, phần mềm bị lỗi, báo cáo lỗi
• Phiên bản phần mềm mới với lỗi được sửa
• Chạy lại Case trên:
  • Lặp lại chính xác những gì đã phát hiện lỗi
  • Trên cùng môi trường
  • Trên cùng đầu vào và các điều kiện ban đầu
• Nếu Test Pass thì lỗi đã được sửa đúng
• Chạy lại test nếu lần chạy lại vẫn fail. Regression Test - Test hồi quy
• Test hồi quy thực hiện ở tất cả các level
• Tập hợp các chuẩn Test của gói kiểm tra hồi quy ( Dành cho test tự động)
• Rất tốt khi được tự động hóa
• Một tài sản đang phát triển nhưng cần phải được hồi quy
• Test hồi quy được thực hiện khi:
  • Sau khi phần mềm được thay đổi theo yêu cầu, bao gồm cả sửa lỗi
  • Khi môi trường thay đổi, ngay cả khi các chức năng vẫn như cũ
  • Đối với các bản sửa lỗi khẩn cấp ( hoặc chỉ là một tập hợp con)
• Bộ kiểm tra hồi quy tự động
  • Phát triển theo thời gian
  • Thường xuyên được chạy
  • Có thể trở nên khá lớn
  • Duy trì các gói thử nghiệm hồi quy gồm:
    • Loại bỏ các test lặp đi lặp lại ( Test những cái đã được test trong các điều kiện thử nghiệm tương tư)
    • Kết hợp giữa các test cases
    • Lựa chọn 1 tập con khác của bộ kiểm tra hồi quy đầy đủ để chạt mỗi khi thực hiện test hồi quy
    • Loại bỏ các test mà không tìm được lỗi trong thời gian dài
  • Test hồi quy và test tự dộng
    • Tool chạy tự động là các tool để test hồi quy, chúng chạy đi chạy lại các test case
    • Một khi được tự động thì các test hồi quy được chạy thường xuyên hơn
    • Các test tự động là rất có ý nghĩa ( tiết kiệm khoảng 2-10 lần so với chạy bằng tay)
    • Đừng chạy tự động mọi thứ - kế hoạch chỉ chạy những cái gì tự động trước thì chỉ làm tự động những cái đó thôi

  1.5.6 Kết quả mong đợi của testing

  • Dự đoán kết quả mong đợi là 1 phần trong quy trình thiết kế test case
    • Oracle giả định là giả định rằng kết quả chính xác có thể được dự đoán

1.5.7 Thứ tự ưu tiên

• Chúng ta không thể test mọi thứ
• KHông bao giờ có đủ thời gian để test mọi thứ bạn muốn
• Thế thì bạn nên test cái gì? Nguyên lý quan trọng nhất Làm thế nào để phân thứ tự ưu tiên
  • Các tiêu chí xếp bậc có thể lấy ( dựa vào risks): - Kiểm tra nơi lỗi xảy ra nghiêm trọng nhất - Kiểm tra nơi lỗi nhìn thấy rõ nhất - Hỏi khách hàng về thứ tự ưu tiên của yêu cầu - Tiêu chí quan trọng nhất đối với việc kinh doanh của khách hàng - Tất cả các vùng thường xuyên bị thay đổi - Tất cả các vùng có vấn đề nhiều nhất trong quá khứ - Hầu hết các khu vực phức tạp, hoặc kỹ thuật quan trọng.

Bài viết được tham khảo tại:" http://www.istqb.org/downloads/send/2-foundation-level-documents/3-foundation-level-syllabus-2011.html4"