ISTQB CTFL Chapter 1 - Quiz with 100% correct answers

Typical Objectives of Testing 1.) To prevent defects by evaluate work products such as requirements, user stories, design, and code 2.) To verify whether all specified requirements have been fulfilled. 3.) To check whether the test object is complete and validate if it works as the users and other stakeholders expect. 4.) To build confidence in the level of quality of the test object. 5.) To find defects and failures thus reduce the level of risk of inadequate software quality. 6.) To provide sufficient information to stakeholders to allow them to make informed decisions especially regarding the level of quality of the test object. 7.) To comply with contractual, legal, or regulatory requirements or standards, and/or to verify the test object's compliance with such requirements or standards. Debugging is the development activity that finds, analyzes, and fixes such defects. Brainpower Read More Previous Play Next Rewind 10 seconds Move forward 10 seconds Unmute 0:00 / 0:00 Full screen Testing's Contributions to Success 1.) Having testers involved in requirement reviews or user story refinement could detect defects in these work products. The identification and removal of requirements defects reduces the risk of incorrect or untestable untestable features being developed. 2.) Having testers work closely with system designers while the system is being designed can increase each party's understandings of the design and how to test it. This increased understanding can reduce the risk of fundamental design defects and enable tests to be identified at an early stage. 3. Having testers work closely with developers while the code is under development can increase each party's understandings of the code and how to test it. This increased understanding can reduce the risk of defects within the code and the tests. 4. Having testers verify and validate the software prior to release can detect failures that might otherwise have been missed, and support the process of removing the defects that caused the failures(i.e., debugging's). This increases the likelihood that the software meets stake holder needs and satisfies requirement. Component testing (unit testing, module testing) A test level that focuses on individual hardware or software components. Objectives of Component Testing 1. Reducing Risk 2. Verifying whether the functional and non-functional behaviors of the component are as designed and specified 3. Building confidence in the component's quality 4. Finding defects in the component 5. Preventing defects from escaping to higher test levels Test Basis For Component Testing 1. Detailed design 2. Code 3. Data model 4. Component specifications Test Objects for Component Testing 1.Components, units or modules 2.Code and data structures 3.Classes 4.Database modules Typical Defects and Failures for Component Testing 1.Incorrect functionality (e.g., not as described in design specifications) 2.Data flow problems 3.Incorrect code and logic Integration Testing A test level that focuses on interactions between components or systems. Objectives of Integration Testing 1. Reducing risk 2. Verifying whether the functional and non-functional behaviors of the interfaces are as designed and specified 3. Building confidence in the quality of the interfaces 4. Finding defects (which may be in the interfaces themselves or within the components or systems) 5. Preventing defects from escaping to higher test levels Test Basis for Integration Testing 1. Software and system design 2. Sequence diagrams 3. Interface and communication protocol specifications 4. Use cases 5. Architecture at component or system level 6. Workflows 7. External interface definitions Test Objects for Integration Testing 1.Subsystems 2.Databases 3.Infrastructure 4.Interfaces 5.APIs 6.Microservices Typical Defects and Failures For Component Integration Testing 1. Incorrect data, missing data, or incorrect data encoding 2. Incorrect sequencing or timing of interface calls 3. Interface mismatch 4. Failures in communication between components 5. Unhandled or improperly handled communication failures between components 6. Incorrect assumptions about the meaning, units, or boundaries of the data being passed between components Typical Defects and Failures for Integration Testing 1. Inconsistent message structures between systems 2. Incorrect data, missing data, or incorrect data encoding 3. Interface mismatch 4. Failures in communication between systems 5. Unhandled or improperly handled communication failures between systems 6. Incorrect assumptions about the meaning, units, or boundaries of the data being passed between systems 7. Failure to comply with mandatory security regulations System Testing A test level that focuses on verifying that a system as a whole meets specified requirements. Objectives of System Testing 1.Reducing risk 2.Verifying whether the functional and non-functional behaviors of the system are as designed and specified 3.Validating that the system is complete and will work as expected 4.Building confidence in the quality of the system as a whole 5.Finding defects 6. Preventing defects from escaping to higher test levels or production Test Basis for System Testing 1. System and software requirement specifications (functional and non-functional) 2. Risk analysis reports 3. Use cases 4. Epics and user stories 5. Models of system behavior 6. State diagrams 7. System and user manuals Test Objects for System Testing 1. Applications 2. Hardware/software systems 3. Operating systems 4. System under test (SUT) 5. System configuration and configuration data Typical Defects and Failures for System Testing 1.Incorrect calculations 2. Incorrect or unexpected system functional or non-functional behavior 3.Incorrect control and/or data flows within the system 4.Failure to properly and completely carry out end-to-end functional tasks 5.Failure of the system to work properly in the system environment(s) 6.Failure of the system to work as described in system and user manuals Acceptance Testing A test level that focuses on determining whether to accept the system. Objectives of acceptance testing 1. Establishing confidence in the quality of the system as a whole 2. Validating that the system is complete and will work as expected 3. Verifying that functional and non-functional behaviors of the system are as specified Common forms of acceptance testing 1.User acceptance testing 2.Operational acceptance testing 3.Contractual and regulatory acceptance testing 4.Alpha and beta testing. user acceptance testing User acceptance testing of the system is typically focused on validating the fitness for use of the system by intended users in a real or simulated operational environment. The main objective is building confidence that the users can use the system to meet their needs, fulfill requirements, and perform business processes with minimum difficulty, cost, and risk. operational acceptance testing A type of acceptance testing performed to determine if operations and/or systems administration staff can accept a system. alpha testing A type of acceptance testing performed in the developer's test environment by roles outside the development organization. beta testing A type of acceptance testing performed at an external site to the developer's test environment by roles outside the development organization. Test Basis for Acceptance Testing 1. Business processes 2. User or business requirements 3. Regulations, legal contracts, and standards 4. Use cases and/or user stories 5. System requirements 6. System or user documentation 7. Installation procedures 8. Risk analysis reports Test Basis for Operational Acceptance Testing Backup and restore procedures Disaster recovery procedures Non-functional requirements Operations documentation Deployment and installation instructions Performance targets Database packages Security standards or regulations Test Type A group of test activities based on specific test objectives aimed at specific characteristics of a component or system. Functional Testing Testing performed to evaluate if a component or system satisfies functional requirements. non-functional testing Testing performed to evaluate that a component or system complies with non-functional requirements. White Box Testing Testing based on an analysis of the internal structure of the component or system. change-related testing A type of testing initiated by modification to a component or system. confirmation testing A type of change-related testing performed after fixing a defect to confirm that a failure caused by that defect does not reoccur. Regression Testing A type of change-related testing to detect whether defects have been introduced or uncovered in unchanged areas of the software. Rational Unified Process (RUP) A proprietary adaptable iterative software development process framework consisting of four project lifecycle phases: inception, elaboration, construction and transition. Scrum An iterative incremental framework for managing projects commonly used with Agile software development. Work Products that Can be Examined by Static Testing 1. Specifications, including business requirements, functional requirements, and security requirements. 2.Epics, user stories, and acceptance criteria. 3.Architecture and design specifications. 4. Code. 5.Testware, including test plans, test cases, test procedures, and automated test scripts 6.User guides. 7.Web pages. 8.Contracts, project plans, schedules, and budget planning. 9. Configuration set up and infrastructure set up Models, such as activity diagrams, which may be used for Model-Based testing Benefits of Static Testing 1. Detecting and correcting defects more efficiently, and prior to dynamic test execution. 2. Identifying defects which are not easily found by dynamic testing. 3. Preventing defects in design or coding by uncovering inconsistencies, ambiguities, contradictions, omissions, inaccuracies, and redundancies in requirements. 4. Increasing development productivity (e.g., due to improved design, more maintainable code). 5. Reducing development cost and time. 6. Reducing testing cost and time. 7. Reducing total cost of quality over the software's lifetime, due to fewer failures later in the lifecycle or after delivery into operation. 8. Improving communication between team members in the course of participating in reviews. Compared with dynamic testing, typical defects that are easier and cheaper to find and fix through static testing include: 1. Requirement defects (e.g., inconsistencies, ambiguities, contradictions, omissions, inaccuracies, and redundancies). 2. Design defects (e.g., inefficient algorithms or database structures, high coupling, low cohesion). 3. Coding defects (e.g., variables with undefined