Chapter 2 /
TESTING THROUGHOUT THE
SOFTWARE DEVELOPMENT
LIFECYCLE
A SDLC model defines how different development
phases and types of activities
performed within this process relate to each other
models include: /
sequential development models (waterfall model, V-model).
iterative development models (spiral model, prototyping).
incremental development models (Unified Process).
Some activities within software development processes can
also be described by more detailed software
development methods and Agile practices
Example include: /
acceptance test-driven development (ATDD)
Behavior-driven development (BDD)
domain-driven design (DDD)
Extreme programming (XP)
feature-driven development (FDD)
Kanban, Lean IT, Scrum
Test-driven development (TDD).
Impact of the Software
Development Lifecycle on Testing
Testing must be adapted to the SDLC to succeed. The choice of the
/
SDLC impacts on the:
1. Scope and timing of test activities (test levels and test types) Level
of detail of test documentation
2. Choice of test techniques and test approach
3. Extent of test automation
4. Role and responsibilities of a tester
In sequential development models
The initial phases /
Testers typically participate in requirement reviews, test analysis, and
test design.
The executable code is usually created in the later phases.
So typically dynamic testing cannot be performed early in the SDLC
In some iterative and incremental
development models
/
it is assumed that each iteration delivers a working prototype or
product increment.
This implies that in each iteration both static and dynamic testing
may be performed at all test levels.
Frequent delivery of increments requires fast feedback and
extensive regression testing.
Agile software development assumes that
change may occur throughout the project.
Therefore , lightweight work product documentation and extensive
/
test automation to make regression testing easier are favored in
agile projects.
Also, most of the manual testing tends to be done using experience-
based test techniques that do not require extensive prior test
analysis and design.
Different between [sequential & Agile ]
Requirement Document Epics > User Story
Design Flow chart
Software Development Lifecycle
and Good Testing Practices
For every software development activity, there is a corresponding /
test activity, so that all development activities are subject to quality
control
Different test levels have specific and different test objectives, which
allows for testing to be appropriately comprehensive while avoiding
redundancy
Test analysis and design for a given test level begins during the
corresponding development phase of the SDLC, so that testing can
adhere to the principle of early testing.
Testers are involved in reviewing work products as soon as drafts of
this documentation are available, so that this earlier testing and
defect detection can support the shift-left strategy.
Testing as a Driver for Software
Development
TDD BDD ATDD /
1. Directs the coding 1. Expresses the desired 1. Derives tests from
behaviour of an
through test cases application with test acceptance
(instead of cases written in a simple criteria as part of
extensive software form of natural language,
the system design
which is easy to
design) understand by process
stakeholders – usually
2. Tests are written using the
first, then the Given/When/Then format.
2. Tests are written
code is written to before the part of
2. Test cases are then the application is
satisfy the tests, automatically
and then the tests translated into developed to
and code are executable tests satisfy the tests
refactored
Select SDLC Based on?
1. Time To market , Scope /
2. Project Context
3. Business priority
4. Project and product Risk
Dev-Ops and Testing
1. Dev-Ops is an organizational approach aiming to create synergy by
getting development (including testing) and operations to work
together to achieve a set of common goals. /
مقسومه لفريقين االول وهوDevelopment كانت ازاي عمليهSDLC اوال الزم نعرف الحياه في .2
ودول مسؤلين عن كتابه الكودDevelopers .3
Deployment ودول مسؤلين عنOperation team .4
بعدOperation Team يخلص من كتابه الكود يستلمهDevelopers هوان بعدDeployment .5
فبدا يحصل مشاكل, شغاله كدهCycle وتفضل,Production Environment كده بيرفعه علي
يقول الكود تمامDeveloper يرجع الكود ل ديفيلوبير يجيDeploy وهي ان لو حصل مشكله في
Operation المشكله في
والعكس حتيOperation يكتسب مهرات منDeveloper وهكذا بعد كده بدا يظهر عندنا التطور بدا .6
Dev-Ops اطلق عليهمDeveloper &Operation ظهر ناس يمتلكون خبره
Operation و عند خبرهDeveloper هو شخصDev-Ops .7
Dev-Ops & Testing
/
هل الموضوع هنا خلص اني اكتب الكود وارفعه وخالص يجي هني بقي Testing Teamيعملوا .1
test
} Tools {Jenkins ,Dockers ,AWSالخاصه ب Dev-OPS .2
Automationخالص الكود بيتكتب بيتم رفعه علي Git-Hubوبعد كده تعمله الموضوع كله .3
Test
Push Code >>Built >>Test>>Runالموضوع كله Automation .4
Benefits of Dev-Ops
1. Fast feedback on the code quality /
2. Promotes automated processes like CI/CD that facilitate
establishing stable test environments
3. Increases the view on non-functional quality characteristics
(performance, reliability)
4. Automation through a delivery pipeline reduces the need for
repetitive manual testing
5. The risk in regression is minimized due to the scale and range of
automated regression tests
Risks of Dev-Ops
The Dev-Ops delivery pipeline must be defined and established
CI / CD tools must be introduced and maintained
Test automation requires additional resources and may be difficult
to establish and maintain
(CI/CD) متستعجلش هنفهم كلنا ايه هو
CI / CD
CI >>Continuous Integration
/
Code pull TEST Deploy
Git MAVEN JUNIT Kubernetes
الفكره ان كل واحد في التيم شغالGIT زيVersion control System شغال بDeveloper : التكامل المستمر
وهنيIntegration فممكن يحصل مشاكل فيBranches معين في النهايه بيتم عمل تجميع لكلBranch علي
CI >>Continuous Integration يكمن فايده
DEV وتبتدي تشوف المشاكل فrun وTest بمعيير انت حططها علشان تقدر تعملcode review في انه بيعمل
الموضوع كلهTest علشان تعملTester ليك كاbuilt بيطلعلك نسخه اوBranch Testing بيعمل
Automation
CD >>Continuous Delivery
بيكون مربوط بال productionاو النسخه الي مع العميل فيبدا يديني مؤشر اني اضيفه لل
ده /
productionوال ال ويبدا يرفعه علي Productionاو app Storeبعد عمل كل cycle
Built Test Releas
Shift Left –Approach
The principle of early testing is sometimes referred to as
shift-left because it is an approach where testing is /
performed earlier in the SDLC.
Shift-left normally suggests that testing should be done
earlier (not waiting for code to be implemented or for
components to be integrated), but it does not mean
that testing later in the SDLC should be neglected
بيقولي ايه بقي انearly Testing بيحقق مبداءShift-left Approach
بعدTesting بس ده مش معناه اني اهمل, الزم يبدا بدري مش بعد الكودtesting
. قبل وبعدTest كده يعيني
“shift-left” in testing, which include
1. Reviewing the specification from the perspective of testing. These review activities
on specifications often find potential defects, such as ambiguities, incompleteness,
and inconsistencies
/
2. Writing test cases before the code is written and have the code run in a test harness
during code implementation
3. Test Harness: test Should be done now in environment by use {Drivers ,Stubs }
4. Using CI and even better CD as it comes with fast feedback and automated
component tests to accompany source code when it is submitted to the code
repository
5. Completing static analysis of source code prior to dynamic testing, or as part of an
automated process
6. Performing non-functional testing starting at the component test level, where
possible.
7. This is a form of shift-left as these non-functional test types tend to be performed
later in the SDLC when a complete system and a representative test environment
are available
Retrospectives and Process
Improvement
Retrospectives (also known as “post-project meetings” and project
/
retrospectives) are often held at the end of a project or an iteration,
at a release milestone, or can be held when needed.
The timing and organization of the retrospectives depend on the
particular SDLC model being followed.
In these meetings the participants (not only testers, but also e.g.,
developers, testers, product owner, business analysts)
او لما نكون محتاجينهRelease بعدIteration, اوproject بيحصل في نهايهmeeting ده
{, testers, product owner , Business analysts developers}مين بيحضر
Retrospectives and Process
Improvement ,Discuss
1. What was successful, and should be retained? /
2. What was not successful and could be improved?
3. How to incorporate the improvements and retain the
successes in the future?
Typical benefits for testing include
1. Increased test effectiveness / efficiency (by implementing /
suggestions for process improvement)
2. Increased quality of test ware (by jointly reviewing the test
processes)
3. Team bonding and learning (e.g., as a result of the opportunity to
raise issues and propose improvement points)
4. Improved quality of the test basis (as deficiencies in the extent and
quality of the requirements could be addressed and solved)
5. Better cooperation between development and testing (as
collaboration is reviewed and optimized regularly)
Test Levels and Test Types
Component testing Component integration testing
/
1. focuses on testing 1. focuses on testing the
components in isolation. interfaces and
interactions between
It often requires specific components
support, such as test 2. performed by
harnesses or unit test developers
frameworks 3. strategy approaches like
2. performed by { bottom-up
developers top-down
big-bang }
Test basis in component
Detailed Design /
Code
Data module
Component Specification
Typical defect or failure
Incorrect data ,missing Data
Incorrect Sequence Time Interface
System Testing
System testing System integration testing
/
focuses on the overall behaviour g focuses on testing the interfaces
and capabilities of an entire of the system under test and other
system or product, often including systems and external services
functional testing of end-to-end
performed by Tester
tasks and the non-functional
testing of quality characteristics
performed by Tester
System Integration test basis
1. Software or System Testing
2. Sequence Diagram
/
3. Use case
4. Architecture
5. Work flow
Typically Defect or failure in System Testing
1. Massage infrastructure
2. Interface mismatch
3. Error of System Communication
Acceptance testing
focuses on validation and on demonstrating readiness for /
deployment, which means that the system fulfils the user’s business
needs. Ideally, acceptance testing should be
performed by the intended users
Acceptance testing types
User Acceptance testing (UAT)
1-Check usability of system
/
2-System Appropriate End-user
3-bussnies process already verifying
Operation Acceptance testing (OAT)
1-Test Software It simulates the environment
2- Focus Effort System Restore , Beck-up
3-Check Disaster Recovery
4-Check permission
Disaster Recovery: when System is Turn off because any Reason
What happened in my work, System Allow user to End Work
5-maintenance test : System allow user to End task ,ADD Feature easy
or should make Change in all the system.
/
6- Data load migration : System have problem in data loading .
7-Government Contract and Regularity.
Objectiveof Acceptance testing : System Work on The most difficult
circumstances .
1- ALPHA testing : Check System in organization Site Environment .
2 - Beta Testing : Check System in Client or {Real} Environment
Acceptance testing Test basis
Business process /
Regularity Standers , Contract
System requirement
Risk analysis requirement
OBJECTIVES :
1-System Under Test
2- Business Configuration
Test levels are distinguished by the following non-exhaustive
list of attributes, to avoid overlapping of test
activities
1. Test object /
2. Test objectives
3. Test basis
4. Defects and failures
5. Approach and responsibilities
Test Types
1. Functional testing /
2. Non-functional testing
3. Black-box testing
4. White-box testing
Functional testing
Evaluates the Objective of functional
/
functions that a testing?
component or system functional completeness,
should perform. The functional correctness
functions are “what” functional appropriateness
the test object should
do
The system depends on it in the most difficult circumstances
Non-functional software quality
characteristics
1. Performance efficiency : the ability of a system to utilize resources effectively
/
and efficiently to meet its performance requirements.
2. Compatibility : System Compatible With Environment .
3. Usability : Ease of user use Software .
4. Reliability : The system depends on it in the most difficult circumstances.
5. Security : Save To Transport Data.
6. Maintainability : the ease with which a software system can be maintained or
updated over time.
1. Portability : the ability of a software system to run on different
platforms or environments without modification.
2. Load testing : Load testing involves testing a system or application
under expected load. /
3. Stress testing : Stress testing assesses a system's ability to handle
extreme conditions.
4. Security : Save To Transport Data.
5. Maintainability : the ease with which a software system can be
maintained or updated over time.
Black-box testing
is specification-based and derives tests from documentation /
external to the test object.
The main objective of black-box testing is checking the system's
behaviour against its specifications.
White-box testing
is structure-based and derives tests from the system's /
implementation or internal structure (e.g., code, architecture, work
flows, and data flows)
The main objective of white-box testing
is to cover the underlying structure by the tests to the acceptable level.
Confirmation Testing and
Regression Testing
/
Changes are typically made to a component or system
to either enhance it by adding a new feature or to fix it
by removing a defect.
Testing should then also include confirmation testing and
regression testing.
Confirmation testing
/
Confirmation testing confirms that an original defect has been
successfully fixed. Depending on the risk,
one can test the fixed version of the software in several ways,
including:
1. executing all test cases that previously have failed due to the
defect, or, also by
2. adding new tests to cover any changes that were needed to fix
the defect
Regression testing
confirms that no adverse consequences have been caused by a change.
1- including a fix that has already been confirmation tested. /
2- These adverse consequences could affect the same component where
the change was made, other components in the same system, or even
other connected systems.
3- Regression testing may not be restricted to the test object itself but can
also be related to the environment.
4- It is advisable first to perform an impact analysis to optimize the extent of
the regression testing. Impact analysis shows which parts of the software
could be affected.
5- Regression test suites are run many times and generally the number
of regression test cases will increase with each iteration or release, so
regression testing is a strong candidate for automation.
6- Automation of these tests should start early in the project. /
7- Where CI is used, such as in Dev-Ops it is good practice to also
include automated regression tests.
8- Depending on the situation, this may include regression tests on
different levels.
9- Confirmation testing and/or regression testing for the test object are
needed on all test levels if defects are fixed and/or changes are made
on these test levels
Sanity Testing : The primary goal of sanity testing is to ensure that the
basic and essential features of the software are functioning as /
expected after a specific change
Smoke Test : also known as build verification testing, is a preliminary
level of testing that is conducted on a software build to determine if
it is stable and suitable for more in-depth testing.
Maintenance 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