Começar. É Gratuito
ou inscrever-se com seu endereço de e-mail
Rocket clouds
ISTQB por Mind Map: ISTQB

1. Fundamentals of Testing

1.1. What is testing

1.1.1. Findin defects

1.1.2. Gaining confidence about the level of quality and providing information.

1.1.3. Preventing defects

1.2. Fundamental test process

1.2.1. Planning and control

1.2.2. Analysis and design

1.2.3. Implementation and execution

1.2.4. Evaluating exist criteria and reporting

1.2.5. Test closure activities

1.3. Viewpoints in testing

1.3.1. development testing to cause as many failures as possible so that defects in the software are identified and can be fixed

1.3.2. Acceptance testing to confirm that the system works as expected, to gain confidence that it has met the requirements.

1.3.3. Testing to assess the quality of the software, to give information to stakeholders of the risk of releasing the system at a given time.

1.3.4. Maintenance testing no new defects have been introduced during dev of the changes.

1.3.5. Operational testing assess system characteristics such as reliability or availability

1.4. Debugging V.S. Testing

1.4.1. Dynamic testing shows failures that are caused by defects

1.4.2. Debugging The development activity that finds, analyse and removes the cause of failure

1.4.3. Subsequent re-testing ensures that the fix does resolve the failure

1.5. Seven Testing Principles

1.5.1. Testing shows presence of defects Testing can show that defects are present but cannot guarantee the correctness of the system.

1.5.2. Exhaustive testing is impossible Testing everything is not feasible except for trivial cases. risk analysis and priorities should be used.

1.5.3. Early testing Start early

1.5.4. Defect clustering means that the majority of the defects are caused by a small number of modules, i.e. the distribution of defects are not across the application but rather centralized in limited sections of the application.

1.5.5. Pesticide paradox test cases need to be regularly reviewed and revised, and new and different tests need to be written to test different parts of the software.

1.5.6. Testing is context dependent Testing is done differently in different contexts.

1.5.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.

1.6. Test Process

1.6.1. Test Planning and Control Test Planning:Defining the objectives of testing and the specification of test activities in order to meet the objectives and mission. Test Control: ongoing activity of comparing actual progress against the plan, and reporting the status, including deviations from the plan. the testing activities should be monitored throughout the project.

1.6.2. Test Analysis and design Reviewing the test basis Evaluating testability of the test basis and test objects Identifying and prioritizing test conditions based on analysis of test items, the specification, behavior and structure of the software Designing and prioritizing high level test cases Identifying necessary test data to support the test conditions and test cases Designing the test environment setup and identifying any required infrastructure and tools Creating bi-directional traceability between test basis and test cases

1.6.3. Test implementation and execution Finalizing, implementing and priotizing test cases Developing and prioritizing test procedures, creeating test data and writting automated test scripts.

1.6.4. Evaluating exit criteria and reporting

1.6.5. Test closures activities

2. Static Technique

2.1. Review Process

2.1.1. Formal Review Activitivies Planning Kick-off Individual preparation Examination/evaluation/recording of results Rework Follow-up

2.1.2. Informal Review No formal process May take the form of pair programming or a technical lead reviering designs and code Results may be documented Varies in usefulness depending on the reviewers Main purpose: inexpensive way to get some benefit

2.1.3. Walkthrough meeting led by author may take the form of scenarios, dry runs, peer group participation Open-ended sessions optional pre-meeting preparation of reviewers Optional preparation of a review report including list of findings. Optional scribe May vary in practice from quite informal to very formal Main purposes: learning, gaining understanding, finding defects.

2.1.4. Technical Review Documented. defined defect-detection process that includes peers and technical experts with optional management participation May be performed as a peer review without management participation Ideally led by trained moderator Pre-meeting preparation by reviewers Optional use of checklists preparation of a review report which includes the list of findings, the verdict whether the software product meets its req and. where appropriate, recommendations related to findings may vary in practice from quite informal to very formal Main purpose: discussing,

2.1.5. Inspection

2.1.6. Roles and Responsibilities Manager decides on the execution of reviews allocates time in project schedules determines if the review objectives have been met. Moderator Leads the review of the document planning the review running the meeting following-up after the meeting Author The writer or person with chief resp. for the documents to be reviewed. Reviewers identify and describe defects Scribe Documents all the issues, problems and open points that were identified during the meeting.

3. Testing Throughout the Software Life Cycle

3.1. Software Development Life Cycle

3.1.1. Requirement

3.1.2. Design

3.1.3. Develop

3.1.4. Test (Validate)

3.1.5. Deploy (Implement)

3.1.6. Support (Maintain)

3.2. Software Development Models

3.2.1. V-model (Sequential Development Model) Component (unit) testing Test basis Test objects tested in isolation most thorough look at detail ERROR HANDLING INTERFACES Integration testing Test basis Test objects Component integration testing System integration testing more than one tested component communication between components what the set can perform that is not possible individually non-functional aspects if possible Big-Bang integration Incremental Integration Top-Down Integration Bottom-up Integration Thread integration System testing last integration step functional non-functional Integration testing in the large Acceptance testing User acceptance testing operational (acceptance testing Contract and regulation acceptance testing Alpha and beta testing

3.2.2. Iterative-incremental Development Models The process of establishing requirements, designing, building and testing a system in a series of short development cycles.

3.2.3. Waterfall model

3.2.4. Testing within a Life Cycle Model

3.3. Test Types

3.3.1. Functional Testing Black Box Testing

3.3.2. Non-functional Testing Black Box Testing

3.3.3. Structural Testing White Box Testing

3.3.4. Re-testing and Regression Testing

4. Test Design Techniques

4.1. q

5. Test Management

6. Tool Support for Testing