This Doc for only short notes to memorize those before the Exam

1. Test design involves using test conditions to create test cases and other necessary
testware, such as test data requirements and test charters for exploratory testing.
Test environment requirements
2. Test execution involves executing test cases (as part of test procedures)
3. Test analysis is used to identify the features that require testing. The test
basis(requirement) is analyzed and defined as test conditions, which are then
prioritized along with related risks
4. Test implementation includes the generation of test procedures, such as manual
and automated test scripts, which are created from test cases and may be
assembled into test suites. . Test procedures are prioritized and arranged in a test
execution schedule.
5. Determining which risks are worth testing is part of risk management, and risk
mitigation in particular
6. Traceability between the identified risks and written test conditions provides a
means of determining which further test conditions need to be written.
7. Domain knowledge that can be used to understand and communicate with end-
users and business representatives is one of the generic skills required by testers.
8. one of the main tenets ‫ مبادي‬of exploratory testing is that the test cases are
generated during the testing, not scripted in advance
9. The whole-team approach allows any team member with the requisite skills and
knowledge to undertake any task, however that does not mean that team members
can take on any role at any time. Typically, they only take on roles in which they are
competent, and there is no suggestion that every team member can do every role
10. In agile software development, deliverables (Docs) are produced in each iteration,
and the frequent delivery of increments necessitates extensive regression testing.
11. If a sequential development model is used, then early in the lifecycle no code is
available for execution, and so during this time static testing (e.g., reviews) is
performed. Later in the lifecycle, when code is available for execution, dynamic
testing is possible. Note, however, that preparation for dynamic testing will often
occur early in any software development lifecycle
12. Testers should review work products as soon as drafts are available to enable early
testing as part of a shift-left approach
13. t. Testers typically review work products that form the test basis (requirments) as
part of test analysis, not before test analysis and design
14. DevOps enhances testing in several ways, such as by providing fast feedback on
code quality, automated regression testing that minimizes regression risk, and
promoting a shift-left approach with high-quality code submission and component
tests
15. Automated processes like continuous integration/continuous delivery (CI/CD) in
DevOps facilitate stable test environments and reduce the need for manual testing,
however, there is a risk of overlooking the importance of manual testing, especially
from a user's perspective
16. Automated processes like continuous integration/continuous delivery (CI/CD) in
DevOps facilitate stable test environments and reduce the need for manual testing,
however, there is a risk of overlooking the importance of manual testing, especially
from a user's perspective
17. System testing examines the behavior and capabilities of the complete system and
covers non-functional testing of quality characteristics, which includes security
testing. This type of testing is often performed by an independent test team based
on system specifications
18. Confirmation tests are created and run when the test object is fixed, and regression
tests are (ideally) run whenever the test object is enhanced (changed)
19. . Confirmation testing verifies that a defect has been fixed correctly and so is
concerned with testing changes to the test object. However, regression testing
ensures that changes (including changes to the operational environment) do not
have negative effects on unchanged software
20. Regression testing ensures that changes do not have negative effects on unchanged
software. Confirmation testing verifies that a defect has been fixed – and so is
concerned with changed code
21. Usability can be tested by Static A lack of usability provided through the user
interface can be detected through a review using a suitable checklist and Dynamic
lack of usability can also be identified by getting several typical users to dynamically
test the user interface and provide feedback on its usability
22. A code review can detect code that cannot be reached by any path, however
dynamic tests can only exercise reachable code and cannot determine that code
cannot be reached without running every possible combination of inputs and input
states
23. . In branch testing, the test cases are derived from knowledge of the control flow of
the test object
24. In decision table testing, the test cases are derived from the specification that
describes the business logic, Decision table testing is typically based on an analysis
of business logic,
25. Decision table testing is a black-box test technique, so it is based on an analysis of
the specified behavior of the test object without reference to its internal structure.
The test cases are independent of how the software is implemented.
26. . Branch testing is a white-box test technique, so test cases are based on an analysis
of the test object’s internal structure and processing, e test cases are dependent on
how the software is designed and coded, they can only be created after the design
or implementation of the test object
27. Testing finds defects either directly through static testing, or indirectly by causing
failures in dynamic testing, and debugging fixes defects. So, testing does not find
the cause of defects and debugging does not fix the causes of defects.
28. The ‘absence-of-defects fallacy’ is concerned with the idea that ensuring
correctness in accordance with the requirements (i.e., verifying the absence of
implementation defects) does not guarantee user satisfaction with the system. To
address this it is also necessary to validate that the system meets users' needs and
expectations, fulfills business objectives, and outperforms competing systems.
29. The testing role is not primarily the responsibility of a single individual from outside
the team. Instead the testing is more likely to be performed by various team
members following the wholeteam approach
30. The test management role primarily involves activities related to test planning, test
monitoring and control, and test completion, while the testing role is primarily
responsible for the technical and engineering aspects of testing, such as test
analysis, test design, test implementation, and test execution. Thus the test
management role is not normally responsible for test analysis and test design,
although it is correct to say that the testing role is primarily responsible for test
implementation and execution
31. the whole-team approach fosters superior team dynamics, promotes robust
communication and collaboration, and generates a synergistic effect that benefits
the entire project
32. Developer's familiarity means they can efficiently find many defects in their own
code. And, rather than developers and testers having a shared background,
developers having a different background to testers is normally cited as the reason
that testers and developers find different kinds of defects
33. Shift-left emphasizes the importance of starting testing earlier in the software
development lifecycle (SDLC). Implementing shift-left testing necessitates additional
training, and increased effort and costs during the early stages of the SDLC,
nevertheless, overall savings should be higher.
34. Confirmation testing will check that the updates have resulted in a correct
implementation, and then regression testing will be used to ensure that no defects
have been introduced or uncovered in unchanged areas of the system, confirmation
testing precedes regression testing
35. Regression testing should be used to ensure that no defects have been introduced
or uncovered in unchanged areas of the system when the update was made,
however it is also necessary to perform confirmation testing that will check that the
updates have resulted in a correct implementation
36. Obtaining feedback from stakeholders early and often in the software development
process can be highly beneficial. It facilitates early communication of potential
quality issues, can prevent misunderstandings about requirements, and ensures
that any changes in stakeholder requirements are understood and implemented
sooner
37. Technical review - This type of review is performed by technically qualified
reviewers and led by a moderator. The objectives are to gain consensus and make
decisions on technical problems while also evaluating quality and building
confidence in the work product, generating new ideas, motivating and enabling
authors to improve, and detecting anomalies
38. To ensure successful reviews, it's important to break the work product into parts
that are small enough to be reviewed in a reasonable timescale to prevent reviewers
from losing focus during individual review or review meetings

39. Experience-based test techniques can detect defects that may be missed using
black-box (and white-box) test techniques. Hence, experience-based test techniques
are complementary to black-box test techniques and white-box test techniques and
both black-box test techniques and experience-based test techniques can be used in
all SDLCs

40. Fault attacks are a methodical approach to the implementation of error guessing
and require the tester to create or acquire a list of possible errors, defects and
failures, and to design tests that will identify defects associated with the errors,
expose the defects, or cause the failures

41. If the checklists are high-level, some variability in the actual testing is likely to occur,
resulting in potentially greater coverage but less repeatability. If two testers follow a
checklist of high-level items, each of them may use different test data, test steps,
etc. This way, one tester will probably cover some areas not covered by the other
tester and this will result in increased coverage

42. This acceptance criterion describes an example scenario that must be realizable by
the system. And This acceptance criterion describes what rules or regulations the
system must adhere to (in this case, the right to be forgotten). Acceptance criteria
should be written in collaboration with business representatives, and therefore
should be written in language they understand

43. Testing quadrants group test levels and test types separately according to several
criteria. They do not represent any combinations of test levels and test types and
they are not related to any location within a software development lifecycle. Both
test levels and test types are treated separately in the testing quadrants mode

44. Building confidence in the quality of the test object is achieved by executing tests
that pass

45. The whole team approach promotes robust communication and collaboration
between the team members, While the whole team approach prioritizes collective
accountability for quality, each individual team member is still equally accountable
for quality, The whole team approach is about how the team works together, with
the aim of higher quality deliverables, but it does not necessarily result in faster
deployment to end users, When using the whole team approach, testers work with
business representatives to create acceptance tests. There is no suggestion that the
approach will reduce collaboration with external business users.
46. Testers and developers have varied backgrounds, technical viewpoints, and
potential biases, allowing testers to usefully challenge assumptions made by
stakeholders during system specification and implementation. Thus, this is an
advantage

47. The main disadvantage of independence in testing is that testers may become
isolated from the development team, leading to communication problems, a lack of
collaboration, and potentially an adversarial relationship, with testers being blamed
for delays and bottlenecks in the release process.

48. One of the disadvantages of independence in testing is that testers may become
isolated from the development team, leading to developers feeling less accountable
for quality.

49. The primary benefit of independence in testing is that testers are more likely to
identify different types of failures and defects compared to developers, due to their
varied backgrounds, technical viewpoints, and potential biases, including cognitive
bias

50. a) Is correct. Each test level has specific and distinct test objectives as a different
form of test object (e.g., single component, complete system) is tested at each test
level and overlapping test objectives would lead to unnecessary duplication

51. DevOps generally increases the visibility of non-functional quality characteristics,

such as performance and reliability,
52. Automated processes like continuous integration/continuous delivery (CI/CD) used
in DevOps facilitate stable test environments,
53. Automated processes like CI/CD used in DevOps generally reduce the need for
manual testing,
54. DevOps implementation can pose several risks and challenges, including the need to
define and set up the delivery pipeline, introduce and maintain CI/CD tools, and
establish and maintain test automation
55. The benefits of retrospectives are based on increased effectiveness and efficiency
through process improvements;
56. c) Is correct. Testing quadrants allow managers and other stakeholders to
understand the relationships between test types, the activities they support (team
support or product critique), and the viewpoint they are focused on (business- or
technology-facing)
57.