Foundation Level 1 Flashcards
(39 cards)
1
Q
Software testing
A
a set of activities to discover defects and evaluate the quality of software artifacts.
2
Q
Test Objectives
A
- Evaluating work products such as requirements, user stories, designs, and code
- Ensuring required coverage of a test object
- Reducing the level of risk of inadequate software quality
- Verifying whether specified requirements have been fulfilled
- Verifying that a test object complies with contractual, legal, and regulatory requirements
- Providing information to stakeholders to allow them to make informed decisions
- Building confidence in the quality of the test object
- Validating whether the test object is complete and works as expected by the stakeholders
3
Q
Debugging
A
concerned with finding causes of the failure (defects), analyzing these causes, and eliminating them
4
Q
Typical debugging process
A
- Reproduction of a failure
- Diagnosis (finding the root cause)
- Fixing the cause
5
Q
Quality control (QC)
A
a product-oriented, corrective approach that focuses on those activities supporting the achievement of appropriate levels of quality (Testing)
6
Q
Quality assurance (QA)
A
a process-oriented, preventive approach that focuses on the implementation and improvement of processes
7
Q
Test results in QA and QC
A
- In QC they are used to fix defects
- In QA they provide feedback on how well the development and test processes are performing
8
Q
A root cause
A
a fundamental reason for the occurrence of a problem (e.g., a situation that leads to an error). Root causes are identified through root cause analysis, which is typically performed when a failure occurs or a defect is identified.
9
Q
Errors, Defects, Failures
A
Human beings make errors (mistakes), which produce defects (faults, bugs), which in turn may result in failures
10
Q
Testing principles
A
- Testing shows the presence, not the absence of defects
- Exhaustive testing is impossible
- Early testing saves time and money
- Defects cluster together
- Tests wear out
- Testing is context dependent.
- Absence-of-defects fallacy (In addition to verification, validation should also be carried out)
11
Q
Test Activities and Tasks
A
often implemented iteratively or in parallel, need to be tailored to the system and the project
- Test planning
- Test monitoring and control
- Test analysis
- Test design
- Test implementation
- Test execution
- Test completion
12
Q
The way the testing is carried out will depend on
A
- Stakeholders (needs, expectations, requirements, willingness to cooperate, etc.)
- Team members (skills, knowledge, level of experience, availability, training needs, etc.)
- Business domain (criticality of the test object, identified risks, market needs, specific legal regulations, etc.)
- Technical factors (type of software, product architecture, technology used, etc.)
- Project constraints (scope, time, budget, resources, etc.)
- Organizational factors (organizational structure, existing policies, practices used, etc.)
- Software development lifecycle (engineering practices, development methods, etc.)
- Tools (availability, usability, compliance, etc.)
13
Q
Traceability
A
- provides information to assess product quality, process capability, and project progress against business goals.
- between the test basis elements, testware associated with these elements (e.g., test conditions, risks, test cases), test results, and detected defects.
- The coverage criteria can function as key performance indicators to drive the activities that show to what extent the test objectives have been achieved
14
Q
The test management role
A
- takes overall responsibility for the test process, test team and leadership of the test activities.
- mainly focused on the activities of test planning, test monitoring and control and test completion.
NB varies depending on the context, the test management role can be performed by a team leader, by a test manager, by a development manager,
15
Q
The testing role
A
mainly focused on the activities of test analysis, test design, test implementation and test execution.
16
Q
Generic Skills Required for Testing
A
- Testing knowledge (techniques)
- Thoroughness, carefulness, curiosity, attention to details, being methodical
- Good communication skills, active listening, being a team player
- Analytical thinking, critical thinking, creativity
- Technical knowledge
- Domain knowledge (to be able to understand and to communicate with end users/business representatives)
17
Q
Independence of Testing
A
- A certain degree of independence makes the tester more effective at finding defects due to differences between the author’s and the tester’s cognitive biases
- Work products can be tested by their author (no independence), by the author’s peers from the same team (some independence), by testers from outside the author’s team but within the organization (high independence), or by testers from outside the organization (very high independence)
18
Q
The main benefit of independence of testing
A
- independent testers are likely to recognize different kinds of failures and defects compared to developers because of their different backgrounds, technical perspectives, and biases.
- an independent tester can verify, challenge, or disprove assumptions made by stakeholders during specification and implementation of the system.
19
Q
Drawbacks of independent testers
A
- Independent testers may be isolated from the development team, which may lead to a lack of collaboration, communication problems, or an adversarial relationship with the development team.
- Developers may lose a sense of responsibility for quality.
- Independent testers may be seen as a bottleneck or be blamed for delays in release.
20
Q
Test planning work products
A
- test plan
- test schedule
- risk register
- entry and exit criteria
21
Q
Risk register
A
a list of risks together with risk likelihood, risk impact and information about risk mitigation
22
Q
Test monitoring and control work products
A
- test progress reports
- documentation of control directives
- risk information
23
Q
Test analysis work products
A
- (prioritized) test conditions
- defect reports regarding defects in the test basis
24
Q
Test design work products
A
- (prioritized) test cases
- test charters
- coverage items
- test data requirements
- test environment requirements
25
Examples of test environment elements
1. stubs
2. drivers
3. simulators
4. service virtualizations
26
Test implementation work products
1. test procedures
2. automated test scripts
3. test suites
4. test data
5. test execution schedule
6. test environment elements
27
Test execution work products
1. test logs
2. defect reports
28
Test completion work products
1. test completion report
2. action items for improvement of subsequent projects or iterations
3. documented lessons learned
4. change requests
29
Test execution rate
No. of executed tests / no. of total tests
30
Test planning
defining the test objectives and then selecting an approach that best achieves the objectives within the constraints imposed by the overall context.
31
Test monitoring and control
1. ongoing checking of all test activities
2. the comparison of actual progress against the plan
32
Test analysis
1. analyzing the test basis to identify testable features and to define and prioritize associated test conditions, together with the related risks and risk levels
2. The test basis and the test objects are also evaluated to identify defects they may contain and to assess their testability
3. identify features and sets of features to be tested
4. defining and prioritising test conditions for each feature based on analysis of the test basis
NB: answers the question “what to test?” in terms of measurable coverage criteria.
33
Test design
1. Designing and prioritising test cases
2. Identifying test data to support test conditions and test cases
3. Designing the test environment and identifying required infrastructure & tools
4. Creating bi-directional traceability between test basis and test cases
5. designing the test environment and identifying any other required infrastructure and tools.
NB answered the question "how to test"
34
Test implementation
1. Developing and prioritising test procedures and creating automated test scripts
2. Creating test suits from the test procedures
3. Arranging the test suits within the test execution schedule
4. Building the test environment and verifying everything set up correct
5. Preparing test data and ensuring it is properly loaded in the test environment.
6. Verifying and updating bi-directional traceability between the test basis, test conditions, test cases, test procedure and test suites
35
Test execution
1. Recording the IDs and versions of the test items, objects tools and test ware
2. executing test either manually or with a tool
3. comparing actual results with expected results
4. analysing anomalies to establish their likely causes
5. reporting defects based on failures observed
6. logging the outcome of test execution
7. repeating test activities either as a result of action taken for an anomaly or as a part of planned testing
36
Test completion
1. Checking whether all defect reports are closed, entering change request or product backlog items for any defects that remain unresolved at the end of test execution
2. Creating a test summary report to be communicated to stakeholders
3. Finilazing and archiving the test environment, test data test infrastructure and other testware
4. handing over testware to the maintenance team, other project teams and/or other stakeholders who could benefit from its use
5. analysing lessons learned from the completed test activities to determine changes needed for future iterations, releases and projects
6. using information gathered to improve test process maturity
37
Test Basis
All documents from which the requirements of a component or system can be inferred. The documentation on which the test cases are based.
If a document can be amended only by way of formal amendment procedure, then the test basis is called a frozen test basis.
38
Test charter
A statement of test objectives, and possibly test ideas about how to test. Test charters are used in exploratory testing.
39
Error
Human action that produces an incorrect result.
