1. (1) What is Testing?
1.1. Denifition
1.1.1. Including static and dynamic testing
1.1.2. Detecting defects
1.1.3. Ensure product satisfy requirement
1.2. Typical Objectives
1.2.1. To evaluate work products
1.2.2. To find failures and defects
1.2.3. To verify requirements fulfilled
1.2.4. To validate test object
1.2.5. To build confidence quality
1.2.6. To provide information to stakeholders to make decisions
1.2.7. To reduce the level of risk of inadequate software quality
1.2.8. To comply with contractual, legal, or regulatory requirements or standards
1.3. Testing and Debugging
1.3.1. Testing (Tester)
1.3.1.1. Show failures that are caused by defects in the software
1.3.1.2. Check the fixes resolved the defects
1.3.2. Debugging (Dev)
1.3.2.1. Find, analyze and remove the causes of failures in a component or system.
2. (3) Seven Testing Principles
2.1. Testing shows the presence of defects, not their absence
2.2. Exhaustive testing is impossible
2.3. Early testing saves time and money
2.4. Defects cluster together
2.5. Tests wear out
2.6. Testing is context dependent
2.7. Absence-of-errors is a fallacy
3. (5) Essential Skills
3.1. Skills Required for Testing
3.1.1. Testing knowledge
3.1.2. curiosity ans attention to details
3.1.3. communication skills
3.1.4. Analytical and critical thinking
3.1.5. Technical knowledge
3.1.6. Domain knowledge
3.2. Whole Team Approach
3.2.1. everyone is responsible for quality
3.2.2. Team members share the same workspace
3.2.3. Testers work closely with other team members
3.3. Independence of Testing
3.3.1. makes the tester more effective at finding defects
3.3.2. verify, challenge, or disprove assumptions made by stakeholders
3.3.3. Not a replacement for familiarity
3.3.4. may lead to a lack of collaboration, communication problems
4. (2) Why is Testing Necessary?
4.1. Testing’s Contributions to Success
4.1.1. In requirements reviews or user story refinement
4.1.1.1. reduces the risk of incorrect or untestable functionality being developed
4.1.2. In system design
4.1.2.1. reduce the risk of fundamental design defects
4.1.2.2. enable tests to be identified at an early stage
4.1.3. In development
4.1.3.1. reduce the risk of defects within the code and the tests
4.1.4. Verify and validate the software prior to release
4.1.4.1. increases the likelihood that the software meets stakeholder needs and satisfies requirements
4.2. Quality Assurance and Testing
4.2.1. Quality assurance (QA)
4.2.1.1. process-oriented
4.2.1.2. Assure quality
4.2.1.3. Preventive
4.2.2. Testing (Major form of QC)
4.2.2.1. product-oriented
4.2.2.2. Control quality
4.2.2.3. Corrective
4.2.2.4. Finding bugs
4.3. Errors, Defects, and Failures
4.3.1. Errors (Mistake)
4.3.1.1. A human action that produces an incorrect result.
4.3.2. Fault (Defect, Bug)
4.3.2.1. A manifestation of an error in software
4.3.2.2. if executed, a fault may cause a failure
4.3.2.3. fail to perform
4.3.3. Failure
4.3.3.1. Deviation of the software from its expected delivery or service
4.4. Defects, Root Causes and Effects
4.4.1. The root causes of defects are the earliest actions or conditions that contributed to creating the defects
4.4.2. Identify their root causes of defects => reduce the occurrence of similar defects in the future
4.4.3. Root cause analysis improves process
4.4.3.1. => prevent a significant number of future defects from being introduced
5. (4) Test Process
5.1. Test Process in Context
5.1.1. Testing is depending on various contextual factors
5.1.1.1. Stakeholders (needs, expectations, requirements)
5.1.1.2. Team members (skills, knowledge)
5.1.1.3. Business domain
5.1.1.4. Technical factors (type of software)
5.1.1.5. Project constraints (scope, time, budget, resources)
5.1.1.6. Organizational factors (organizational structure)
5.1.1.7. Software development lifecycle
5.1.1.8. Tools (availability, usability)
5.2. Test Activities and Tasks => Test Work Products
5.2.1. Test planning
5.2.1.1. Task
5.2.1.1.1. Define the objectives of testing
5.2.1.1.2. Define the approach
5.2.1.2. Work products
5.2.1.2.1. Test plan
5.2.1.2.2. Test schedule
5.2.1.2.3. Entry and Exit criteria
5.2.2. Test monitoring and control
5.2.2.1. Task
5.2.2.1.1. Monitoring: Comparing actual progress against the test plan
5.2.2.1.2. Control: Taking actions necessary to meet the objectives of the test plan
5.2.2.2. Work products
5.2.2.2.1. Test progress report
5.2.2.2.2. Risk information
5.2.3. Test analysis
5.2.3.1. Task: identify what to test
5.2.3.1.1. Evaluating the test basis and test items
5.2.3.1.2. Identifying features and sets of features to be tested
5.2.3.1.3. Defining and prioritizing test conditions for each feature based
5.2.3.2. Work products
5.2.3.2.1. Test condition (prioritized))
5.2.3.2.2. Acceptance criteria
5.2.4. Test design
5.2.4.1. Task: identify how to test
5.2.4.1.1. Designing and prioritizing test cases and sets of test cases
5.2.4.1.2. Defining the test data requirements
5.2.4.1.3. Designing the test environment
5.2.4.2. Work products
5.2.4.2.1. Test cases (prioritized)
5.2.4.2.2. test charters
5.2.4.2.3. Test data and environment requirements
5.2.5. Test implementation
5.2.5.1. Task: answers the question “do we now have everything in place to run the tests?
5.2.5.1.1. Creating test suites and automated test scripts
5.2.5.1.2. Arranging the test suites
5.2.5.1.3. Building the test environment
5.2.5.1.4. Preparing test data
5.2.5.2. Work products
5.2.5.2.1. Test procedures
5.2.5.2.2. automated test scripts
5.2.5.2.3. test suites and data
5.2.5.2.4. test execution schedule
5.2.6. Test execution
5.2.6.1. Task: run test
5.2.6.1.1. Executing tests
5.2.6.1.2. Comparing actual results with expected results
5.2.6.1.3. Reporting defects
5.2.6.1.4. Logging the outcome of test execution
5.2.6.2. Work products
5.2.6.2.1. Test logs
5.2.6.2.2. Defect reports
5.2.7. Test completion
5.2.7.1. Task
5.2.7.1.1. Entering change requests or product backlog items
5.2.7.1.2. Creating a test completion report
5.2.7.1.3. Finalizing and archiving
5.2.7.1.4. Analyzing lessons learned
5.2.7.2. Work products
5.2.7.2.1. Test completion report
5.2.7.2.2. Action items for improvement
5.2.7.2.3. Change requests
5.2.7.2.4. Documented lessons learned
5.3. Traceability between the Test Basis and Test Work Products
5.3.1. Verify that the requirements are covered by test cases
5.3.2. evaluate the level of residual risk in a test object
5.3.3. Analyzing the impact of changes
5.3.4. Improving the understanding of test progress and summary reports
5.3.5. Providing information to assess product quality, process capability, and project progress
5.4. Roles in Testing
5.4.1. Test management
5.4.1.1. team leadership
5.4.1.2. planning,monitoring & control,and completion
5.4.2. Testing
5.4.2.1. analysis, design, implementation ,and execution