Certified Tester
Foundation Level Syllabus
Version 2018 Version
International Software Testing Qualifications Board
Trong chủ đề này mình sẽ so sánh một số nội dung khác nhau giữa ISTQB 2011 và phiên bản 2018.
Lần này mình sẽ nói về bảy nguyên tắc kiểm thử phần mềm (Seven Testing Principles). Những nguyên tắc cơ bản của kiểm thử là gì? Chúng có thay đổi theo thời gian hay không?
Nguyên bản
Đề cương ISTQB 2011
Principles
A number of testing principles have been suggested over the past 40 years and offer general guidelines common for all testing.
Principle 1 – Testing shows presence of defects
Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, it is not a proof of correctness.
Principle 2 – Exhaustive testing is impossible
Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, risk analysis and priorities should be used to focus testing efforts.
Principle 3 – Early testing
To find defects early, testing activities shall be started as early as possible in the software or system development life cycle, and shall be focused on defined objectives.
Principle 4 – Defect clustering
Testing effort shall be focused proportionally to the expected and later observed defect density of modules. A small number of modules usually contains most of the defects discovered during pre- release testing, or is responsible for most of the operational failures.
Principle 5 – Pesticide paradox
If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new defects. To overcome this “pesticide paradox”, test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to find potentially more defects.
Principle 6 – Testing is context dependent
Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce site.
Principle 7 – Absence-of-errors fallacy
Finding and fixing defects does not help if the system built is unusable and does not fulfill the users’ needs and expectations.
Đề cương ISTQB 2018
A number of testing principles have been suggested over the past 50 years and offer general guidelines common for all testing.
1. Testing shows the presence of defects, not their absence
Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, testing is not a proof of correctness.
2. Exhaustive testing is impossible
Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Rather than attempting to test exhaustively, risk analysis, test techniques, and priorities should be used to focus test efforts.
3. Early testing saves time and money
To find defects early, both static and dynamic test activities should be started as early as possible in the software development lifecycle. Early testing is sometimes referred to as shift left. Testing early in the software development lifecycle helps reduce or eliminate costly changes (see section 3.1).
4. Defects cluster together
A small number of modules usually contains most of the defects discovered during pre-release testing, or is responsible for most of the operational failures. Predicted defect clusters, and the actual observed defect clusters in test or operation, are an important input into a risk analysis used to focus the test effort (as mentioned in principle 2).
5. Beware of the pesticide paradox
If the same tests are repeated over and over again, eventually these tests no longer find any new defects. To detect new defects, existing tests and test data may need changing, and new tests may need to be written. (Tests are no longer effective at finding defects, just as pesticides are no longer effective at killing insects after a while.) In some cases, such as automated regression testing, the pesticide paradox has a beneficial outcome, which is the relatively low number of regression defects.
6. Testing is context dependent
Testing is done differently in different contexts. For example, safety-critical industrial control software is tested differently from an e-commerce mobile app. As another example, testing in an Agile project is done differently than testing in a sequential lifecycle project (see section 2.1).
7. Absence-of-errors is a fallacy
Some organizations expect that testers can run all possible tests and find all possible defects, but principles 2 and 1, respectively, tell us that this is impossible. Further, it is a fallacy (i.e., a mistaken belief) to expect that just finding and fixing a large number of defects will ensure the success of a system. For example, thoroughly testing all specified requirements and fixing all defects found could still produce a system that is difficult to use, that does not fulfill the users’ needs and expectations, or that is inferior compared to other competing systems.
Xem thêm so sánh test objectives of istqb 2011 and istqb 2018
Tiếng Việt (được dịch bởi tvn)
Đề cương ISTQB 2011
Nguyên tắc kiểm thử
Dưới đây là một số nguyên tắc kiểm thử đã được đề xuất hơn 40 năm và nó cung cấp những hướng dẫn chung về kiểm thử.
Nguyên tắc 1 – Kiểm thử chỉ ra sự hiện diện của lỗi
Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng không thể chứng minh rằng phần mềm không có lỗi. Kiểm thử làm giảm xác suất lỗi chưa tìm thấy vẫn còn trong phần mềm, thậm chí là không còn lỗi nào, nó không phải là bằng chứng của sự chính xác.
Nguyên tắc 2 – Exhaustive testing is impossible
Kiểm thử mọi thứ (tất cả các tổ hợp của điều kiện input đầu vào) là không thể thực hiện được, trừ phi nó chỉ bao gồm một số trường hợp bình thường (ít trường hợp tổ hợp thì có thể test toàn bộ được). Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên sự mức độ ưu tiên chúng ta có thể tập trung việc kiểm thử vào một số điểm cần thiết.
Nguyên tắc 3 – Kiểm thử sớm
Để tìm được bug sớm, các hoạt động kiểm thử nên được bắt đầu càng sớm càng tốt trong qui trình phát triển (vòng đời phát triển) phần mềm hoặc hệ thống, và nên tập trung vào các hoạt động đã định trước.
Nguyên tắc 4 – Sự tập trung của lỗi
Nỗ lực kiểm thử nên tập trung một cách cân đối vào mật độ lỗi dự kiến và lỗi phát hiện ra sau đó trong các mô-đun. Một số ít các mô-đun thường chứa nhiều lỗi không phát hiện ra trong lúc kiểm thử trước khi phát hành (release), hoặc chịu trách nhiệm cho hầu hết các lỗi hoạt động của phần mềm.
Nguyên tắc 5 – Nghịch lý thuốc trừ sâu
Nếu việc kiểm thử tương tự nhau được lặp đi lặp lại nhiều lần, thì cuối cùng sẽ có một số trường hợp kiểm thử (ca kiểm thử - test case) sẽ không còn tìm thấy bất kỳ lỗi nào mới. Để khắc phục "nghịch lý thuốc trừ sâu" này, các trường hợp kiểm thử cần phải được xem xét và sửa đổi thường xuyên, và cần phải viết các test case mới và khác nhau để thực hiện nhiều phần khác nhau của phần mềm hoặc hệ thống để tìm ra lỗi tiềm ẩn nhiều hơn nữa.
Nguyên tắc 6 – Kiểm thử theo các ngữ cảnh độc lập
Nguyên tắc này là việc testing phụ thuộc vào ngữ cảnh, test trong nhiều ngữ cảnh khác nhau. Ví dụ, một phần mềm cần tính an toàn cao thì được kiểm thử khác so với một trang thương mại điện tử.
Nguyên tắc 7 – Sự sai lầm về việc không có lỗi
Việc tìm và sửa chữa lỗi sẽ không giúp được gì nếu hệ thống được xây dựng xong nhưng không thể dùng được và không đáp ứng được nhu cầu và sự mong đợi của người dùng. (Nghĩa là nếu sau khi code, test rồi fix bug, làm đủ tất cả các trường hợp và cuối cùng cho ra một sản phẩm không như mong đợi hoặc không đáp ứng được nhu cầu của khách hàng thì dự án phần mềm đó coi như thất bại mặc dù đã được test xong)
Đề cương ISTQB 2018
Dưới đây là một số nguyên tắc kiểm thử đã được đề xuất hơn 50 năm và nó cung cấp những hướng dẫn chung về kiểm thử.
1. Kiểm thử chỉ ra sự hiện diện của lỗi, chứ không phải sự vắng mặt của chúng
Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, testing is not a proof of correctness.
2. Kiểm thử toàn bộ mọi thứ là không thể
Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Rather than attempting to test exhaustively, risk analysis, test techniques, and priorities should be used to focus test efforts.
3. Kiểm thử sớm tiết kiệm thời gian và tiền bạc
To find defects early, both static and dynamic test activities should be started as early as possible in the software development lifecycle. Early testing is sometimes referred to as shift left. Testing early in the software development lifecycle helps reduce or eliminate costly changes (see section 3.1).
4. Lỗi gom lại với nhau thành nhóm
A small number of modules usually contains most of the defects discovered during pre-release testing, or is responsible for most of the operational failures. Predicted defect clusters, and the actual observed defect clusters in test or operation, are an important input into a risk analysis used to focus the test effort (as mentioned in principle 2).
5. Đề phòng nghịch lý thuốc trừ sâu
If the same tests are repeated over and over again, eventually these tests no longer find any new defects. To detect new defects, existing tests and test data may need changing, and new tests may need to be written. (Tests are no longer effective at finding defects, just as pesticides are no longer effective at killing insects after a while.) In some cases, such as automated regression testing, the pesticide paradox has a beneficial outcome, which is the relatively low number of regression defects.
6. Kiểm thử phụ thuộc vào ngữ cảnh
Testing is done differently in different contexts. For example, safety-critical industrial control software is tested differently from an e-commerce mobile app. As another example, testing in an Agile project is done differently than testing in a sequential lifecycle project (see section 2.1).
7. Sự vắng mặt của lỗi là một ảo tưởng
Some organizations expect that testers can run all possible tests and find all possible defects, but principles 2 and 1, respectively, tell us that this is impossible. Further, it is a fallacy (i.e., a mistaken belief) to expect that just finding and fixing a large number of defects will ensure the success of a system. For example, thoroughly testing all specified requirements and fixing all defects found could still produce a system that is difficult to use, that does not fulfill the users’ needs and expectations, or that is inferior compared to other competing systems.
Xem thêm so sánh mục tiêu kiểm thử giữa istqb 2011 và istqb 2018
Ad blocker detected: Our website is made possible by displaying online advertisements to our visitors. Please consider supporting us by disabling your ad blocker on our website.
So sánh ISTQB 2011 và ISTQB 2018: 7 nguyên tắc kiểm thử
Chuyên đề thảo luận các vấn đề liên quan đến ISTQB Certificate.
(ISTQB = International Software Testing Qualifications Board)
(ISTQB = International Software Testing Qualifications Board)
Forum rules
Trong chuyên đề này, các bạn chỉ thảo luận các vấn đề liên quan đến ISTQB Certificate.
Trong chuyên đề này, các bạn chỉ thảo luận các vấn đề liên quan đến ISTQB Certificate.
Post Reply
1 post
• Page 1 of 1
-
- Admin
- Posts: 4900
- Joined: Tue 10 Aug, 2010 10:11 am
- Location: HCM
- Contact:
Post Reply
1 post
• Page 1 of 1
Return to “ISTQB Certificate - Chứng chỉ ISTQB”
Jump to
- Software Testing - Kiểm thử phần mềm
- ↳ Software Testing - Kiểm thử phần mềm
- ↳ Agile Testing
- ↳ Game Testing
- ↳ Mobile Testing - Kiểm thử trên thiết bị di động
- ↳ Android Testing
- ↳ Iphone
- ↳ Black Berry
- ↳ Others
- ↳ Black box Testing - Kiểm thử hộp đen
- ↳ White box Testing - Kiểm thử hộp trắng
- ↳ Performance Testing - Kiểm thử hiệu năng
- ↳ Security Testing - Kiểm thử bảo mật
- ↳ Automation Testing - Kiểm thử tự động
- ↳ Quick Test Pro (QTP)
- ↳ Hướng dẫn cài đặt
- ↳ Hướng dẫn sử dụng
- ↳ Selenium
- ↳ Hướng Dẫn Cài Đặt Selenium
- ↳ Hướng Dẫn Sử Dụng Selenium
- ↳ Load Runner
- ↳ Hướng Dẫn Cài Đặt Load Runner
- ↳ Hướng Dẫn Sử Dụng Load Runner
- ↳ JMeter
- ↳ NUnit
- ↳ Hướng Dẫn Cài Đặt NUnit
- ↳ Hướng Dẫn Sử Dụng NUnit
- ↳ JUnit
- ↳ Hướng Dẫn Cài Đặt JUnit
- ↳ Hướng Dẫn Sử Dụng JUnit
- ↳ Automation Framework
- ↳ Katalon Studio
- ↳ Bug Tracking/Management System - Bug và Công cụ Quản lý Bug
- ↳ Bugzilla Management System - Hệ thống quản lý bug Bugzilla
- ↳ Mantis Management System - Hệ thống quản lý bug Mantis
- ↳ Test cases - Tập hợp các trường hợp kiểm thử
- ↳ Test Plans - Kế hoạch kiểm thử
- ↳ 日本語のソフトウェア.テスト
- ↳ Others - Các vấn đề khác
- Quản lý Kiểm thử Phần mềm
- ↳ Câu Lạc Bộ Test Leaders
- ↳ Ước lượng trong kiểm thử phần mềm
- ↳ Chiến lược kiểm thử phần mềm
- ↳ Các vấn đề khác trong quản lý nhóm
- Đào tạo Tester - Training
- ↳ Đào tạo Tester
- ↳ Fresher Tester
- ↳ ISTQB CTFL
- ↳ Đào tạo Agile Tester
- ↳ Đào tạo JMeter
- ↳ Đào tạo Automation Tester
- ↳ Đào tạo API Testing
- ↳ Dạy Appium - Mobile Automated Test
- ↳ Java for Testers
- ↳ SQL for Testers
- ↳ Tư vấn việc làm
- ↳ Tạo CV ấn tượng
- ↳ Kinh nghiệm phỏng vấn
- ↳ Học Soft Skills
- ↳ Góc chia sẻ kinh nghiệm của Tester Việt nam
- Software Testing Certificate - Chứng chỉ Kiểm thử phần mềm
- ↳ ISTQB Certificate - Chứng chỉ ISTQB
- ↳ ISTQB Exam - Question - Sample
- ↳ ISTQB Test Online
- ↳ ISTQB Syllabus - Tài liệu học ISTQB material
- ↳ Thuật ngữ kiểm thử phần mềm
- ↳ Others - Các vấn đề khác liên quan đến ISTQB
- ↳ ISTQB Agile Tester
- ↳ ISEB Certificate - Chứng chỉ ISEB
- ↳ ISEB Exam - Question - Sample
- ↳ ISEB Study Material - Tài liệu học ISEB
- ↳ Other - Các vấn đề khác liên quan đến ISEB
- ↳ Others - Các chứng chỉ khác
- TVN Club
- ↳ TVN Club
- ↳ Lịch Offline TVN CLub
- ↳ Tài liệu - Video - TVN Club
- Việc làm Tester - Job
- ↳ Ngàn cơ hội từ ITviec.com
- ↳ Tuyển Tester/QC - Tp.HCM
- ↳ Tuyển Tester/QC - Hà Nội
- ↳ Tuyển Tester/QC - Đà Nẵng
- ↳ Tạo hồ sơ - cơ hội để nhà tuyển dụng thấy bạn
- ↳ QA - QC - Tester có kinh nghiệm
- ↳ QA - QC - Tester mới ra trường
- Templates - Các loại biểu mẫu
- ↳ Test Case Template - Test case mẫu
- ↳ Test Plan Templates - Test plan mẫu
- ↳ Other - Các loại biểu mẫu khác
- Thông tin khác
- ↳ Thắp sáng niềm tin
- ↳ Quỹ khuyến học TESTING VN
- ↳ Bếp Cháo Bình An
- ↳ Dzui Dzui Dzui
- ↳ Larva
- ↳ Tom and Jerry
- ↳ Nghệ thuật sống - Hạt giống tâm hồn
- ↳ Học Tiếng Anh Online
- ↳ Học Tiếng Anh qua Hình ảnh
- ↳ Học Tiếng Anh qua Truyện vui
- ↳ Học Tiếng Anh qua Test case
- ↳ Học Tiếng Nhật cùng Trang Mèo
- ↳ Soft hỗ trợ Kiểm thử phần mềm
- ↳ BA - Phân Tích hệ thống
- ↳ Thông tin về diễn đàn
- ↳ Thông báo từ Diễn đàn
- ↳ Hỏi đáp thắc mắc về diễn đàn
- Quảng cáo - Rao vặt
- ↳ Tin tức CNTT
- ↳ Quảng cáo - Rao vặt