Professional Documents
Culture Documents
Revision .NEW Syllabus V4
Revision .NEW Syllabus V4
BY .WOLF TEAM
What is Testing?
time pressure
complexity of work products
processes, infrastructure or interactions
Defect
includes elaborating the test conditions into test cases and other
testware (e.g., test charters). This activity often involves the
identification of coverage items,
Elopraite test conditions
Design and prioritize Test Cases
Identify necessary test data to Support test Conditions
Design Environment
How to Test ?
Test implementation
يعملو هل الموضوع هني خلص اني اكتب الكود وارفعه وخالص يجي هني بقيTeam Testing
test
} Tools {Jenkins ,Dockers ,AWS ,الخاصه ب Devops
الموضوع كله Automationخالص الكود بيتكتب بيتم رفعه علي Git-Hubوبعد كده تعمله test
CI >>Continuous Integration
ده بيكون مربوط بال productionاو النسخه الي مع العميل فيبدا يديني مؤشر اني اضيفه لل
productionوال ال ويبدا يرفعه علي Productionاو app Storeبعد عمل كل cycle
Functional testing
Non-functional testing
Black-box testing
White-box testing
Functional testing
Upgrades or
Modifications migrations Retirement
such as planned such as from one such as when an
enhancements platform to another, application reaches
(release-based), which can require the end of its life.
corrective changes or tests associated with When a system is
hot fixes the new environment retired, this
as well as of the can require testing of
changed software data archiving if long
data-retention
periods are required
Ch 3 : Static Testing Basics
Static testing can detect defects in the earliest phases of the SDLC
fulfilling the principle of early testing
It can also identify defects which cannot be detected by dynamic
testing
Unreachable code,
Defects in non-executable workproducts)
Static testing provides the ability to evaluate the quality
build confidence in work products, By verifying the documented
requirements
the stakeholders can also make sure that these requirements
describe their actual needs
Since static testing can be performed early in the SDLC
Communication will also be improved between the involved
stakeholders, For this reason, it is recommended to involve a wide
variety of stakeholders in static testing
Differences between Static Testing
and Dynamic Testing
Static and dynamic testing (with analysis of failures) can both lead
to the detection of defects , however there are some defect types
that can only be found by either static or dynamic testing.
Static testing finds defects directly, while dynamic testing causes
failures from which the associated defects are determined through
subsequent analysis
Static testing may more easily detect defects that lay on paths
through the code that are rarely executed or hard to reach using
dynamic testing
Static testing can be applied to non-executable work products,
while dynamic testing can only be applied to executable work
products
Static testing can be used to measure quality characteristics that
are not dependent on executing code (e.g., maintainability), while
dynamic testing can be used to measure quality characteristics that
are dependent on executing code (e.g., performance efficiency)
Typical defects that are easier and/or
cheaper to find through static testing include:
Defects in requirements (e.g., inconsistencies, ambiguities,
contradictions, omissions , inaccuracies, duplications)
Design defects (e.g., inefficient database structures, poor
modularization)
Certain types of coding defects (e.g., variables with undefined
values, undeclared variables , unreachable or duplicated code,
excessive code complexity)
Deviations from standards (e.g., lack of adherence to naming
conventions in coding standards)
Incorrect interface specifications (e.g., mismatched number, type
or order of parameters)
Specific types of security vulnerabilities (e.g., buffer overflows)
Gaps or inaccuracies in test basis coverage (e.g., missing tests for
an acceptance criterion)
Review Process Activities {planning}
During review initiation, the goal is to make sure that everyone and
everything involved is prepared to start the review.
This includes making sure that every participant has access to the
work product under review, understands their role and
responsibilities and receives everything needed to perform the
review.
Individual review
white & Black Box عديت منdefects مش بس كده انت كمان هتالقيلي اي
Black-Box Test Techniques
Equivalence Partitioning
Boundary Value Analysis
Decision Table Testing
State Transition Testing
Equivalence Partitioning
Boundary Value analysis
Decision Table Testing
Conditions TC TC TC TC
User name T f T f
Password F F T T
Action E E T E
Case 1 – Username and password both were wrong. The user is shown an
error message.
Case 2 – Username was correct, but the password was wrong. The user is
shown an error message.
Case 3 – Username was wrong, but the password was correct. The user is
shown an error message.
Case 4 – Username and password both were correct, and the user
navigated to the homepage
State Transition Testing
Error guessing
Exploratory testing
Checklist-based testing
Error Guessing
Select the testers with the right level of experience and skills,
suitable for a given risk type
Apply an appropriate level of independence of testing
Conduct reviews and perform static analysis
Apply the appropriate test techniques and coverage levels
Apply the appropriate test types addressing the affected quality
characteristics
Perform dynamic testing, including regression testing
Test Monitoring, Test Control and
Test Completion
Test monitoring is concerned with gathering
information about testing. This information is used to
assess test progress and to measure whether the test exit
criteria or the test tasks associated with the exit criteria
are satisfied, such as meeting the targets for coverage
of product risks, requirements, or acceptance criteria.
Test control
Test period
Test progress (Ahead or behind schedule), including any notable
deviations
Impediments for testing, and their workarounds
Test metrics (see section 5.3.1 for examples)
New and changed risks within testing period
Testing planned for the next period
test completion report
A test completion report is prepared during test completion,
when a project, test level, or test type is complete and when, ideally, its
exit criteria have been met. This report uses test progress reports and
other data. Typical test completion reports include:
Test summary
Testing and product quality evaluation based on the original test plan
(i.e., test objectives and exit criteria)
Deviations from the test plan (e.g., differences from the planned
schedule, duration, and effort).
Testing impediments and workarounds
Test metrics based on test progress reports
Unmitigated risks, defects not fixed • Lessons learned that are relevant
to the testing
Communicating the Status of
Testing
Verbal communication with team members and other
stakeholders
Dashboards (e.g., CI/CD dashboards, task boards, and
burn-down charts)
Electronic communication channels (e.g., email, chat) •
Online documentation
Formal test reports
.Configuration Management
In testing, configuration management (CM) provides a
discipline for identifying, controlling, and tracking work
products such as test plans, test strategies, test conditions, test
cases, test scripts, test results, test logs, and test reports as
configuration items.
To properly support testing, CM ensures the following:
All configuration items, including test items (individual parts
of the test object), are uniquely identified, version controlled,
tracked for changes, and related to other configuration items
so that traceability can be maintained throughout the test
process
• All identified documentation and software items are
referenced unambiguously in test documentation
Defect Management
Time saved by reducing repetitive manual work (e.g., execute regression tests, re-
enter the same
test data, compare expected results vs actual results, and check against coding
standards)
Prevention of simple human errors through greater consistency and repeatability
(e.g., tests are
consistently derived from requirements, test data is created in a systematic manner, and
tests are
executed by a tool in the same order with the same frequency) More objective
assessment (e.g., coverage) and providing measures that are too complicated for
humans to derive
Easier access to information about testing to support test management and test
reporting (e.g., statistics, graphs, and aggregated data about test progress, defect
rates, and test execution duration)
• Reduced test execution times to provide earlier defect detection, faster feedback
and faster time to market
• More time for testers to design new, deeper and more effective tests
Potential risks of using test
automation include:
Unrealistic expectations about the benefits of a tool (including functionality and ease
of use).
Inaccurate estimations of time, costs, effort required to introduce a tool, maintain test
scripts and change the existing manual test process.
Using a test tool when manual testing is more appropriate.
Relying on a tool too much, e.g., ignoring the need of human critical thinking.
The dependency on the tool vendor which may go out of business, retire the tool, sell
the tool to a different vendor or provide poor support (e.g., responses to queries,
upgrades, and defect fixes).
Using an open-source software which may be abandoned, meaning that no further
updates are
available, or its internal components may require quite frequent updates as a further
development.
The automation tool is not compatible with the development platform.
Choosing an unsuitable tool that did not comply with the regulatory requirements
and/or safety standards.
End of
syllabus : thanks Wolf family