Unit:3

Agile Testing
Agile Life Cycle
Scrum Impact on Software Testing
• The Scrum methodology can pose a challenge
for software testers who are used to more
traditional waterfall-development processes.
• However, after implementation of Scrum
methodology telecom project, testing team
has found positive advantages that described
below in details:-
 A. Early Involvement

• Because of early involvement of tester in development

strategy and requirement planning, Tech Mahindra has
observed following impact on testing .
Impact on Testing: -
• Tester should get ready with testing data and be
proactive in getting information on what needs to be
tested.
• Help to cover all testing scenarios while writing test cases
• Tester input help for testing estimation.
• Tester can set his own strategy for execution.
 B. Daily Scrum/Stand up Meeting
• The daily meeting is an important element of SCRUM as it
allows the team to get together, discuss issues, and cross-
pollinate ideas.
• One of the key governance practices in Agile is the use of
'Daily Stand Up' meeting where everybody on the team
reports on three questions - 'what they were working on
yesterday',
• 'what they are going to work on today' and 'any obstacles to
getting work completed'. For large projects, each team has a
'Daily Stand Up' with representatives from each team rolling
up their progress reports to a project/program level 'Daily
Stand Up'.
 B. Daily Scrum/Stand up Meeting
• Impact on Testing: -
– Daily Scrum meetings serve the development and testing to fix
the daily issues.
– Help to check out development progress report so that tester
can manage testing schedule accordingly
– Help to clear testing doubt /design issues, so that tester can
cover all test cases.
– The tester is aware of the actions taken on blocking issues
(environment, backend system) occurred during the testing
process and resolution for the same along with their progress.
– Help tester to identify dependencies that may or may not
affect the individual testers work package.
 C. Daily Build /Release

• Before Agile, implementation daily builds of software coding,

integration and linking and compiling the entire code is one of the
challenging and time consuming task.
• Because of changing requirement every time, need to change
coding. Therefore, in this context it is difficult to compiling and
linking all the files that make up a computer program.
• Sometimes developers develop and develop and develop and 6
months later, they finally try to put everything together.
• This task was difficult to manage in telecom project for all changing
requirement, but in some releases, it was possible to fix daily build.
• (For example, if developer wants to check the qualities of code
before sending complete iteration)
 C. Daily Build /Release

• Impact on Testing: -
– Daily software builds used to raise the visibility of
development work and ensure that code modules
integrate.
– Daily build really a great help to testing team to test
build wise requirement and help to prepared testing
documentation at right time.
– Form development prospective it is also help to fix
daily defect found in testing.
 D. Iteration Wise Testing

• In telecom Project currently using Agile

methodologies and have scheduled 2 week iterations;
sometime we have tested in 1 week also. The
selections of iteration week
• Were normally depended on size of build and
requirement complexity. Whenever required we
tested and delivered solution by using daily build also.
• Tech Mahindra has observed quickly turns into
development and testing. Testing quickly turns is as
below:-
 D. Iteration Wise Testing

• Impact on Testing: -
– Help to prepare testing strategy well in advance
– Help to manage/assign tester for particular
iteration
– Help to track testing individual performance
– Help to tester to understand functionality,
dependency while writing test cases
– Help to track tester performance/weakness as per
iteration wise
 E. Time-boxing Requirements

• Agile projects time-box as a matter of course, because they have fixed

the people and iteration size, and then decide which features/stories
to attack in a particular iteration.
• Since each iteration is of fixed duration, you only start what you can
complete in that iteration; given the number of people, you have
available to perform the work.
• Time-boxing is a technique to force the project team to make
structured choices about what fits into the product and what doesn't.
• The team works on one thing at a time, finishing that piece before
going on to the next.
• If you cannot figure out how to complete all the work in the available
time, and you cannot use an Agile lifecycle, use time-boxing to force
smaller pieces into fixed periods.
 E.Time-boxing Requirements

• Impact on Testing: -
– Help to plan out testing strategy for particular
release with respect to time
– Help tester to complete task within planned
schedule.
– Helps test manager to check tester work
performance.
 F.Requirement Management

• It is reasonable to define what you are going to build before you build
it; to identify the requirements for something before you code it.
• What is not reasonable is defining all of the requirements in a
comprehensive document before you begin implementation. Then it is
much better to rank you requirements as per priority and just
categorize them (high, medium, low).
• Also, check whether changing requirement is dependent on any other
requirement; it would help us to estimate development and testing
effort.
• Team distributed across onshore/offshore the same practice will be
through tele-conference and video conference.
• It is especially critical here to manage hand-offs across time zones and
ensure effective communication and management of defects.
 F.Requirement Management

• Impact on Testing: -
– While identifying requirement tester should know
about complexity and dependency of that
requirement.
– Easy for tester to cover test case for those
requirement which are mandatory for client
– Help to set bug fix priority as per importance of
requirement considering client impact
– Based on requirement category, Test Lead can
easily estimate testing timeframe.
 G.Retrospective Meeting

• The sprint retrospective meeting is held at the

end of every sprint after the sprint review
meeting. The team and Scrum-Master meet to
discuss what went well and what to improve
in the next sprint. The product owner does not
attend this meeting
 G.Retrospective Meeting

• Impact on Testing: -
– Help tester to plan for new iteration as per
development feedback and vise versa
– Help for testing planning for next iteration
releases
– Help to improve testing activity as per feedback of
development and CM team
 Agile Testing Strategies

• To understand how testing activities fit into

agile system development it is useful to look
at it from the point of view of the system
delivery lifecycle (SDLC).
• Figure 2 is a high-level view of the agile SDLC,
indicating the testing activities at various SDLC
phases. This section is organized into the
following topics:
 Agile Testing Strategies

• Project initiation
– The whole team
– The independent test team
– Test environment setup
• Development team testing
– Continuous integration
– Test-driven development (TDD)
– Test-immediately after approach
• Parallel independent testing
• Defect management
• End-of-lifecycle testing
• Who is doing this?
• Implications for test practitioners
Agile Testing Strategies

Figure 2
 1.Project Initiation

• During Inception, often called "Sprint 0" in Scrum or

"Iteration 0" in other agile methods, your goal is to get
your team going in the right direction.
• Although the mainstream agile community doesn't like
talking about this much, the reality is that this phase can
last anywhere from several hours to several weeks
depending on the nature of the project and the culture of
your organization.
• From the point of view of testing the main tasks are to
organize how you will approach testing and start setting
up your testing environment if it doesn't already exist.
 1.Project Initiation cont…

• The "Whole Team" Organizational Strategy

• The Independent Test Team (Advanced Strategy)
• Testing Environment Setup
– Adopt open source software (OSS) tools for developers.
– Adopt both OSS and commercial tools for independent
testers.
– Have a shared bug/defect tracking system.
– Invest in testing hardware.
– Invest in virtualization and test lab management tools.
– Invest in continuous integration (CI) and continuous
deployment (CD) tools.
 2.Development Team Testing Strategies

• Agile development teams generally follow a whole team strategy

where people with testing skills are effectively embedded into the
development team and the team is responsible for the majority of
the testing.
• This strategy works well for the majority of situations but when
your environment is more complex you'll find that you also need
an independent test team working in parallel to the development
and potentially performing end-of-lifecycle testing as well.
• Regardless of the situation, agile development teams will adopt
practices such as continuous integration which enables them to
do continuous regression testing, either with a
test-driven development (TDD) or test-immediately after
approach.
 2.1 Continuous Integration (CI)

• Continuous integration (CI) is a practice where

at least once every few hours, preferably more
often, you should:
– Build your system.
– Run your regression test suite(s).
– Perform static analysis.(Quality Analysis)
 2.2 Test-Driven Development (TDD)

• Test-driven development (TDD) is an agile development technique

practice which combines:

– Refactoring. Refactoring is a technique where you make a small change to your

existing source code or source data to improve its design without changing its
semantics.
– Examples of refactoring include moving an operation up the inheritance
hierarchy and renaming an operation in application source code; aligning fields
and applying a consistent font on user interfaces; and renaming a column or
splitting a table in a relational database.
– When you first decide to work on a task you look at the existing source and ask
if it is the best design possible to allow you to add the new functionality that
you're working on. If it is, then proceed with TFD. If not, then invest the time to
fix just the portions of the code and data so that it is the best design possible
so as to improve the quality and thereby reduce your technical debt over time.
 2.2 Test-Driven Development (TDD)

– Test-first development (TFD). With TFD you write a single test

and then you write just enough software to fulfill that test. The
steps of test first development (TFD) are overviewed in the UML
activity diagram of Figure .
– The first step is to quickly add a test, basically just enough code
to fail.
– Next you run your tests, often the complete test suite although
for sake of speed you may decide to run only a subset, to ensure
that the new test does in fact fail. You then update your
functional code to make it pass the new tests.
– The fourth step is to run your tests again. If they fail you need to
update your functional code and retest. Once the tests pass the
next step is to start over.
 Why is TDD important?

• Many projects fail because they lack a good

testing methodology.

• It’s common sense, but it isn’t common

practice.

• The sense of continuous reliability and success

gives you a feeling of confidence in your code,
which makes programming more fun.
26
 Why (TDD)?
Why is TDD
TDD can lead to more modularized, flexible, and extensible code

Clean code

Leads to better design

Better code documentation

More productive

Good design
 How does it work?
 Have a requirement. Let’s say “create a new random card, as for a
card game”.
 Think about what could be a reasonable test to verify compliance
with the requirement.
 Write the test before writing the code. Of course, the test will fail,
and that’s ok.
 Keep things simple.
 Then, write only the minimally necessary code to make the test
pass.
 This is a process of discovery; as you identify possible
improvements, refactor your code relentlessly to implement
them.
 Build, keep, and frequently run your cumulative collection of
tests.

28
2.2 Test-Driven Development (TDD)

Figure . The Steps of test-first development (TFD).

 2.2 Test-Driven Development (TDD)

There are two levels of TDD:

• Acceptance TDD (ATDD). You can do TDD at the
requirements level by writing a single customer test, the
equivalent of a function test or acceptance test in the
traditional world. Acceptance TDD is often called
behavior-driven development (BDD) or story test-driven
development, where you first automate a failing story
test, then driving the design via TDD until the story test
passes (a story test is a customer acceptance test).
• Developer TDD. You can also do TDD at the design level
with developer tests.
Figure . How ATDD and developer TDD fit together
 TDD at the Unit-Test Level
How?
• Don‘t start with objects (or design, or ...), start
with a test.
– Write new code only if an automated test has
failed.
– First think of the goal, the required functionality.
– Then think of the perfect interface for that
operation (from the outside, black-box view).
 TDD at the Unit-Test Level
How?
• Run the test often – very often.
– To determine whether you‘ve reached the goal.
– To catch any bugs that have crawled back In.

• Make little steps (during coding and refactoring)

– So little that you feel comfortable with them.
– Make them larger if you feel.

– Make them smaller if you don‘t proceed with your

expected velocity.
 Use Tools
• Framework for automating the unit tests
– E.g. Junit
• Integrated development environment
– For writing tests, using auto-completion and generation of missing
code.
– For running the tests
– For refactoring
– E.g. Eclipse
• Build environment
– For executing tests automatically and during the build process
– For computing code coverage
– For generating test reports
– E.g. Maven
 TDD at the Acceptance-Test Level:
Iterative Software Development
• At the start of the iteration, the customer explains the
expected functionality to the team. The customer prioritizes
for business value and urgency, the team estimates the effort
and cost.
• Then the team brainstorms the necessary tasks to implement
the functionality, details the estimation and team members
select their tasks.
• During the iteration, the team holds short status meetings in
order to discuss the current tasks, the achievements and the
problems.
• At the end of the iteration, the team demonstrates to the
customer the increment of potentially shippable functionality.
TDD at the Acceptance-Test Level:
Iterative Software Development
 TDD at the Acceptance-Test Level:
Acceptance Testing
•Don‘t wait until the software has been written in order to start with
acceptance testing.
•Write the acceptance tests as soon as possible.
•Build the unit tests upon the acceptance tests.
•Execute the acceptance tests during the iteration to understand the
progress.
• Execute the acceptance tests at the end of the iteration in order to verify
that the requested functionality has been built.
TDD at the Acceptance-Test Level:
Acceptance Testing
 Why?
TDD at Acceptance Tests Level
• Better collaboration between customer and developer, faster
feedback.
• Customer / Business / User / Domain Expert
– Specifies the requirements
– In the language of the business, focusing on the scenarios, the flow of
events, the dynamic behavior
– In an executable form
– Where the execution can be automated
– Before the requirements are implemented
 Why?
TDD at Acceptance Tests Level

Targets errors not found by unit testing

􀂄 Requirements are mis-interpreted by developer
􀂄 Interface of software is not as intended
􀂄 Modules don‘t integrate with each other
 Exploratory Testing

(https://www.guru99.com/exploratorytesting.html
#:~:text=EXPLORATORY%20TESTING%20is%20a%20type,as%20a%20%22think
ing%22%20activity
.)

 Exploratory testing, is all about discovery, investigation and learning.

 It emphasizes on personal freedom and responsibility of the individual
tester.
 Test cases are not created in advance but testers check system on the fly.
They may note down ideas about what to test before test execution.
 The focus of exploratory testing is more on testing as a "thinking" activity.
 Exploratory testing is simultaneous process of test design and test
execution all done at the same time.
 Risk based testing
 Risk based testing is prioritizing the feature's, modules and functions of
the Application Under Test based on impact and likelihood of failures.
 It involves assessing the risk based on the complexity, business criticality,
usage frequency, visible areas, Defect prone areas, etc.
 Risk is the occurrence of an uncertain event with a positive or negative
effect on the measurable success criteria of a project.
 It could be events that have occurred in the past or current events or
something that could happen in the future.
Risks can be positive or negative.
• Positive risks are referred to as opportunities and help in business
sustainability. For example investing in a New project, Changing business
processes, Developing new products.
• Negative Risks are referred to as threats and recommendations to
minimize or eliminate them must be implemented for project success.

https://www.guru99.com/risk-based-testing.html
 Regression tests
 Regression Testing is defined as a type of software testing to confirm that a
recent program or code change has not adversely affected existing features.
 Regression Testing is nothing but full or partial selection of already executed
test cases which are re-executed to ensure existing functionalities work fine.
 This testing is done to make sure that new code changes should not have
side effects on the existing functionalities. It ensures that old code still works
once the new code changes are done
Need of Regression Testing
Regression Testing is required when there is a
• Change in requirements and code is modified according to the requirement
• New feature is added to the software
• Defect fixing
• Performance issue fix

Regression Testing tools like QTP, Selenium web driver

(https://www.guru99.com/regression-testing.html)
 Test automation
• Manual Testing is performed by a human sitting in front of a computer
carefully executing the test steps.
• Automation Testing means using an automation tool to execute your test
case suite.
• The automation software can also enter test data into the System Under
Test, compare expected and actual results and generate detailed test
reports. Test Automation demands considerable investments of money
and resources.
Automated software testing is important due to following reasons:
• Manual Testing of all workflows, all fields, all negative scenarios is time
and money consuming.
• It is difficult to test for multilingual sites manually.
• Automation does not require Human intervention. You can run automated
test unattended (overnight)
• Automation increases the speed of test execution
• Automation helps increase Test Coverage
• Manual Testing can become boring and hence error-prone.
Conti..

Which Test Cases to Automate?

Test cases to be automated can be selected using the following criterion to
increase the automation ROI
• High Risk - Business Critical test cases
• Test cases that are repeatedly executed
• Test Cases that are very tedious or difficult to perform manually
• Test Cases which are time-consuming

The following category of test cases are not suitable for automation:
• Test Cases that are newly designed and not executed manually at least
once
• Test Cases for which the requirements are frequently changing
• Test cases which are executed on an ad-hoc basis.

(https://www.guru99.com/automation-testing.html)
Conti…
Automated Testing Process:
 Securing Agile software
Steps to Integrate Security into Agile Software
Development
1. Add security acceptance criteria in user stories.
2. Stakeholders can conduct various security tests during
product review
3. Develop proper code conventions for Open Web
Application Security Project® (OWASP) Proactive Controls
4. Use Agile Retrospectives
5. Integrate Continuous Integration Security Practices in
the SDLC.
6. Build security into your pipeline.
(https://www.bridge-global.com/blog/6-essential-steps-to-integrate-security-in-agile-software-development/)
THANK YOU